Лучшие практики . Производительность. Рабочие процессы

Пора перейти к игре по обзору кода

Установки и подходы к более действенному и эффективному анализу кода

Проверка кода, несомненно, играет важную роль в обеспечении инженерного качества при разработке программного обеспечения.

Во время обзорных сессий роль РЕЦЕНЗЕНТОВ так же важна, как и PR-ВЛАДЕЛЬЦА, но мы редко говорим об этом. Поэтому сегодня мы сконцентрируемся на проверке кода на стороне РЕЦЕНЗЕНТОВ .

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

В этой статье мы поговорим о менталитете, подходах и поведении, чтобы стать более продуктивным и эффективным РЕЦЕНЗЕНТ и внести наибольший вклад для сессий проверки кода.

ПРИМЕЧАНИЕ. Рекомендации по созданию запросов на слияние будут обсуждаться в отдельной статье.

0. Установите правильный менталитет

Давайте сначала договоримся о правильном менталитете

  • PR - это черный ящик, который нужно раскрыть
  • У вас нет всего времени на просмотр одного PR
  • Не весь код обязательно идеально написан
  • Владельцы PR тоже люди. Относитесь к PR-владельцам так, как вы хотели бы, чтобы относились к вам

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

1. Относитесь к PR как к черному ящику, который нужно раскрыть.

1. 1. Узнайте, «зачем» создается PR.

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

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

Если «почему» оказывается неуместным или неоправданным с точки зрения рентабельности, это красный флаг, чтобы не тратить больше усилий на PR.

1.2. Понять предполагаемую архитектуру и структуру кода

Обзор дизайна обычно проводится перед фактическим кодированием. Однако, если вы пропустите такие занятия, я рекомендую запросить дизайнерскую документацию или краткое объяснение.

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

1.3. Прочтите все сообщения фиксации (не код)

Сообщения о фиксации должны быть информативными и содержательными (Мы обсудим это в другой статье). Если это не так, следует предупредить владельца PR.

Это позволит вам проверить, соответствует ли реализация предполагаемому дизайну и структуре кода.

Если сообщения о фиксации не соответствуют изменениям, описанным в описании PR, это будет красный флаг.

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

2. Сосредоточьтесь на важных аспектах

2.1. Составьте список приоритетов

Есть несколько аспектов Pull Request для проверки. Некоторые аспекты могут быть более важными, чем другие. Рекомендуется сосредоточиться на наиболее ответственных.

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

Каждая команда должна сформировать свой собственный список приоритетов. Вот пример для справки.

1. Software Design & Code Structure
2. Functionalities
3. Logical correctness 
4. Performance
5. Test Coverage
6. Readability
7. Code styles and linting

2.2. При необходимости просматривайте поэтапно

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

Это позволит владельцу PR переварить и избежать перегрузки.

2.3. Сначала обратите внимание на красные флаги

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

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

3. Оставляйте хорошие комментарии

3.1. Оставляйте полезные комментарии

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

Еще лучше давать предложения без жалоб.

3.2. Убедить, а не командовать

Кодовая база принадлежит команде. Все владеют долей. Если вы хотите изменений, а не команд, как насчет того, чтобы убедить владельцев PR своими доводами и доводами?

Решения должны принадлежать владельцам PR, точно так же, как вы хотели бы в ваших собственных PR.

Это позволило бы каждому соответствовать командному стандарту в долгосрочной перспективе. Это также повысит доверие человека к вам.

Примеры убеждения

  • Поскольку ... я бы посоветовал ... Что вы думаете?
  • Вот X подходов… Вот плюсы и минусы… Какой из них вы бы предпочли?
  • … более рекомендуется.

3.3. Будьте вежливы и профессиональны

Это легко проверить. Вам просто нужно представить, допустимо ли, когда кто-то оставляет подобные комментарии в ваших PR.

Напоминаем, что все остальные также могут читать ваши комментарии.

3.4. Обобщите повторяющиеся предложения в материалах обзора

Если оставить 20+ Please add trailing comma или Please use camel case, PR будет загроможден. Это повысит вероятность того, что владельцы PR пропустят более важные комментарии.

Вместо этого я рекомендую оставить сводный комментарий Please add trailing comma to ALL <the pattern>. Это СУХО (не повторяйтесь) прямо здесь.

3.5. Оставьте список дел, если есть несколько задач с высоким приоритетом

Список флажков Markdown - хороший инструмент для этого.

Based the discussed items, here are the suggested items
- [ ] Item 1
- [ ] Item 2
- [ ] Item 3
Please let me know if anything is confusing.

3.6. При необходимости предложите живой обзор

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

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

Заключение

Сосредоточивая внимание на наиболее важных областях и оставляя вежливые комментарии к действию, мы все будем счастливы разработчиками, предоставляя высококачественные продукты.

Как вы думаете, что еще может помочь повысить продуктивность при просмотре PR

Сообщите мне свое мнение.

Спасибо за прочтение!