План дизайна, принести его вам

Привет всем, яноль один, сегодня я хочу поговорить с вами о незаметной части процесса разработки——Дизайн. Возможно, вы не слышали об этом, или вы можете просто делать движения, не грести, это очень важно!

В Byte я столкнулся с более полным, стандартизированным и эффективным процессом разработки:дизайн требований к продукту => Грубая оценка потребностей => сделать дизайн => грубая оценка => Детальная оценка потребностей => Расписание => развивать => Обнаружение и исправление ошибок => code review => онлайн

На самом деле, до того, как я начал работать, я слышал о большинстве процессов или испытал их во время своей стажировки.Дизайниcode reviewТеперь, для чего эти два?

• Дизайн: После получения требования напишите документ с описанием моментов рассмотрения, связанных с реализацией требования, разделением модулей и т. д., с которыми вы или другие лица можете ознакомиться в будущем.
• Code review: проверьте свой код с наставником или руководителем, прежде чем передавать код для слияния, позвольте другим наблюдать за вашим кодом в качестве стороннего наблюдателя, проводите мозговой штурм, улучшайте код и обнаруживайте нерассмотренные граничные проблемы.

Если честно,какой план дизайна?Когда я первый раз был стажером в небольшой компании,то меня вдруг позвал продукт.Мне потребовалось 5 минут,чтобы объяснить функции,которые он хотел реализовать в следующей версии , а потом сразу спросите меня:Как вы думаете, сколько времени это займет? Моя оценка такова, что он будет онлайн через 5 дней, это нормально?

Я:? ? ? ? ? ? ? ? ?(Внутренний разум: я просто знал это требование, откуда мне знать, сколько времени мне потребуется, чтобы сделать это так быстро! Вы говорите, 5 дней, всего 5 дней, в любом случае, я сказал, что 6 дней бесполезны)

Это слишком возмутительно. Может быть, статус-кво многих небольших компаний таков, как я сказал! Это очень плохо.Требований в быстрой итерации версии много, а сроки разработки относительно сжаты.Это только заставит разработчиков постараться реализовать функции быстро, не учитывая каких-либо проблем с производительностью, не говоря уже о том, чтобы заставить Вас Думаешь о границах. Если вы будете продолжать так долго, то глубоко осознаете, что находитесь в бесконечной быстрой итерации проекта, овертаймы и ночевки могут быть обычным явлением, и у вас будет время освоить новые знания или заняться любимым делом. делать, а сделать не получится.Появится лишнее время на то, чтобы уделить внимание всей линии жизненного цикла потребностей, которые вы берете на себя от разработки до запуска, и не будете ходить на ревью регулярно, поэтому личный проект опыта и технического накопления очень мало

Некоторые друзья ранее в частном порядке обсуждали со мной подобную ситуацию, и я также предложил ему работать в среде с «самообучением» и «регулярным просмотром и размышлением».

Так обстоит дело с Учителем Дашэном. Я помню, как он сказал в прямом эфире, что, когда он перешел на 360, самым важным фактором для него было «оставить достаточно времени для учебы». Это действительно очень хорошо. Вы также можете увидеть, действительно ли ваша текущая ситуация способствует вашему собственному развитию, а затем составить долгосрочные планы.

ну давайте вернемся к делу!

Почему мы пишем дизайн-проекты?

Цель состоит в том, чтобы прояснить собственное мышление и иметь более четкое представление о требованиях, прежде чем вы действительно начнете программировать. Какой модуль ранее не рассматривался, а затем корректируется структура ранее написанного кода и извлекается код, что, несомненно, снижает эффективность разработки.

Другой момент заключается в том, что по прошествии длительного времени в этой функции вдруг появляется ошибка, которую вы должны исправить.Вы можете забыть код, который вы написали.В это время вы можете увидеть план дизайна, который вы написали ранее, который также можно использовать в качестве новая запись Отличный ресурс для ознакомления с существующим кодом!

Я глубоко сочувствую второму пункту.Когда вы переходите в новый отдел, вы всегда берете на себя 1-2 исходных кода проекта, а затем вам приходится читать логику их кода, что очень болезненно, потому что вы не понимаете фон этих требований вообще. , и я не понимаю полной идеи дизайна чужого кода. Это не то же самое, что держать толстую книгу и грызть ее!

Если предыдущие люди написали схему дизайна, вы можете найти соответствующие документы при просмотре каждого модуля, что более эффективно ~

Итак, как написать дизайн-проект?

Вся программа условно разделена на4части:Информация о потребностях,Программа исследований,конкретный план,разное

1. Информация о спросе

Как инженер-разработчик, вы должны иметь дух инженера, и вы должны иметь четкое представление о требованиях, которые вы принимаете, в том числе: кто является другим соответствующим персоналом, ответственным за это требование (продукт, тестирование, пользовательский интерфейс, поддержка). конец и т. д.), меня Какова предыстория появления этого спроса, когда спрос будет предложен, и когда он будет запущен...

Формат следующий:

一、需求相关信息
​
  需求背景：因为我们要做线下推广，提高xxxxxxxxx
  PRD：文档链接
  产品：小华
  UI：小明
  测试：小红
  前端：零一
  服务端：小张
  联调时间：2021.07.30
  提测时间：2021.07.31
  上线时间：2021.08.10

Напишите это содержание в начале плана проектирования, чтобы люди, связанные или не связанные с этим требованием, могли сразу его увидеть.Если у вас возникнут проблемы, вы можете сразу же точно найти соответствующего человека.

2. Программное исследование

Эта часть в основном требует от нас сравнения множества различных схем при рассмотрении технического выбора реализации функции, всестороннего рассмотрения преимуществ и недостатков каждой схемы, а также возможности правильного выбора и улучшения для формирования набора технических схем, подходящих для текущей сцены.

Возьмем относительно простой пример. Предположим, что на этот раз у вас есть сложная анимация, которую нужно реализовать в вашем запросе. Тогда вы можете рассмотреть следующие направления.

• Делал ли я раньше подобную анимацию, которую можно использовать для справки?
• Есть ли в компании готовая библиотека или код, который можно использовать?
• Есть ли в отрасли готовая библиотека или относительно хорошая идея реализации?
• Что бы я сделал, если бы не использовал другую библиотеку и использовал нативную реализацию? Есть ли другие проблемы, такие как совместимость?

После понимания этих четырех сценариев нам нужно подумать о том, какой из них лучше между чужими решениями и моим собственным, и каковы преимущества и недостатки? Применимо ли чужое решение к нашему текущему сценарию? После всестороннего рассмотрения многих факторов мы выбираем относительно надежный план реализации.

Выполняя описанные выше шаги, мы можем поддерживать надежность и качество кода, который мы печатаем дальше!

3. Конкретные планы

Эта часть самая важная, она охватывает почти все, о чем вам нужно подумать:Полный процесс бизнеса,проектирование структуры данных,Логическое описание основных функций,Обработка исключений,безопасность,представление,Совмещение с существующим бизнесом,Повторное использование компонентов

По крайней мере, убедитесь, что другие люди и вы сами можете четко понять ваши идеи дизайна, идеи написания кода и разделение модулей, когда вы видите введение конкретного решения. Вы можете выражать свои идеи в любой форме, такой как псевдокод, блок-схемы или обычный текст и т. д.

Просто для демонстрации:

"блок-схема"

Дизайн блок-схемы может помочь вам лучше понять свои собственные потребности, а также позволить другим интуитивно понять эту потребность.

"Поддельный код"

function getSomeData() {
  let data; 
  if(无缓存) {
    // 请求数据
    if(请求异常) // 展示错误页面;
    data = 请求到的数据;
  }
  
  // 展示页面
}

Псевдокод может показать общие идеи кодирования, прежде чем вы напишете конкретный код для его реализации, поэтому, когда вы вместе просматриваете свой план дизайна, вы можете четко знать, как ваш код должен быть реализован, потому что это псевдокод, поэтому он не является техническим. Ваши одноклассники могут понять это, а затем дать вам несколько советов!

«Модульный дивизион»

Разделение модулей также является отправной точкой для проверки вашей архитектуры.Вы должны четко продумать, какой из вашего кода должен быть выделен в виде отдельного модуля, какие можно использовать в качестве общедоступных компонентов, а какие тесно связаны с бизнесом.

«Схема вариантов использования»

Диаграммы вариантов использования могут помочь вам организовать каждую большую и маленькую сцену в соответствии с вашими требованиями. Это может не дать большого эффекта, если вы просто обдумаете это. Когда вы перечислите их, вы можете обнаружить, что в этом процессе чего-то не хватает. мыслите более комплексно и обращайте внимание на некоторые уголки и уголки. Вставлена ​​маленькая пасхалка.У меня есть коллега по фронтенду, который очень хорошо пишет юзкейсы.Как-то руководитель пошутил, что он пишет слишком подробно, и все очень тщательно обдумано, и может даже дать как есть. тест это тестовый случай, хххх

Приведенные мной примеры относительно просты, и каждый может действовать в соответствии со своей реальной ситуацией.

Есть несколько других вещей, которые вам нужно учитыватьДолжны ли некоторые из ваших интерфейсов учитывать вопросы безопасности?, например, нажавsubmitЭто увеличит количество лотерейных розыгрышей, так почему бы другим злонамеренно не подделать некоторую информацию, чтобы скрыть количество лотерейных розыгрышей? иБудут ли у вашей страницы проблемы с производительностью?? Если вы хотите расширить другие функции по этому требованию в будущем,Как вы думаете, ваш код масштабируется?? Конечно, вы должны учитывать гораздо больше, чем это Я надеюсь, что каждый инженер может тщательно обдумать свой собственный план и стремиться к совершенству, чтобы он был квалифицированным инженером!

4. Другое

Последнюю часть можете оставить на ваше усмотрение, вы можете записать все, что связано с этим требованием, я лично думаю, что вы можете написать это:

• Проблемы и решения, с которыми вы столкнулись при написании дизайн-проекта
• После того, как ваш код появится в сети, какие отзывы пользователей, если он хорош, то где он хорош, если нет, то в чем проблема и как ее решить
• В ходе исследования своей программы вы узнали, в чем программы других людей не работают или на чем стоит поучиться?
• В течение всего процесса разработки, если вы чувствуете, что какой-то процесс нехороший (неэффективное, бесполезное общение и т. д.), вы можете записать это здесь, а затем найти соответствующего персонала для обсуждения улучшений.
• more...

Во всяком случае, здесь вы идете

Практические чувства

В начале, когда меня попросили написать дизайн-план, я немного сопротивлялся и думал про себя, почему мне нужно писать документ перед написанием кода, разве это не увеличивает мою нагрузку?

Позже руководитель сказал мне, что время на написание плана дизайна не будет засчитываться в мое время разработки, но перед временем разработки дайте мне 3-4 дня, посвященных написанию плана дизайна (внутренняя ос: woc? Так здорово! Пишу! Пишу!), это не пахнет, поэтому я начал пробовать писать план дизайна

В процессе написания я обнаружил, что в процессе я могу обнаружить некоторые проблемы, которые не учли мои коллеги, это с точки зрения разработки, поэтому студенты, изучающие продукт, неизбежно упустят некоторые моменты, и в случае разбора я Иногда я нахожу граничные проблемы, которые никто не рассматривал.Может быть, никто не рассматривал их, или может быть, что мои идеи уникальны, но это все в порядке.Когда весь соответствующий персонал унифицирует мой дизайн-план позже, мы можем вместе обсудите правильное и неправильное. Ну, это все вещи, о которых вы не можете думать, просто думая о них в своей голове, или, когда вы думаете о них, вы не можете их вовремя записать, и вы забываете их, когда развиваете их!

После того, как я закончу написание плана дизайна, соответствующий персонал назначит встречу, чтобы выслушать меня вместе с моим планом дизайна.Студенты на разных должностях имеют разные точки зрения, чтобы увидеть проблему, и у всех разные идеи, поэтому может быть выявлено много проблем. здесь. , а также может иметь дело со многими плохими моментами. Например, мой руководитель имеет богатый опыт. Каждый раз, когда я прохожу план проектирования, он будет напоминать мне, где могут быть проблемы с безопасностью. Не забудьте это учитывать.

Позже студенты-испытатели разберут несколько тестовых случаев и попросят всех просмотреть случай. Вы уже составляли план дизайна раньше и хорошо знакомы со своими потребностями. Тогда вы поймете больше, когда протестируете случай ваших потребностей. тест рассматривает Когда дело доходит до того, что вы не учли, может быть, он упустил какой-то момент, и вы его рассмотрели, они дополняют друг друга.

После завершения вышеуказанного контента моя идея написания кода стала ясна, и это действительно экономит много времени! После того, как я закончу разработку, я снова протестирую себя.Как протестировать? Просто сравните это с тестами, которые я разработал и протестировал на самотестировании, Вы же не можете сказать, что не пробежали здесь, просто возьмите это для теста, не так ли?

Словом, урожай еще большой, но для реализации дизайн-плана еще нужен не очень короткий цикл разработки.Спрос только что озвучен, а времени писать вам дизайн-план, когда он выходит в интернет, нет. за 5 дней не то что считать.Слишком много дел, и вам сложно самому что-то опрокинуть.

Но ох~ Я неожиданно обнаружил еще одно скрытое преимущество написания планов дизайна! Разве мы не пишем наш прошлый проектный опыт и опыт работы в нашем резюме.Они тесно связаны с потребностями проектов, которые мы сделали.Если вы написали план дизайна для каждого требования раньше, то писать резюме будет бесполезно. фильтр+копировать и вставить

Ваше мнение о дизайн-плане вы можете выразить в комментариях~

яноль один, если эта статья была вам полезна, пожалуйста, помогитеотличный👍🏻