Проблема

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

  1. Время — когда вы просматриваете чужой код, трудно сказать, сколько времени это займет. Я помню обзоры кода, которые у меня были с более чем 150 измененными классами, или те, которые модифицировали класс, содержащий более 4000 строк кода.
  2. Переключение контекста — задача проверки кода редко приходит, когда у вас есть на нее время, а это означает, что вам нужно остановить то, над чем вы работаете, и выделить для этого время.
  3. Разногласия — поскольку обычно для каждой проблемы существует более одного решения, трудно рассмотреть решение, с которым вы можете не согласиться, и прокомментировать его.
  4. Стиль кода — в большинстве мест, с которыми я работал, включая текущий, отсутствие определенного стиля кода затрудняет просмотр кода в стиле, отличном от вашего, и относительно того, сколько комментариев. это в обзоре кода.
  5. Отсутствие документации — при просмотре кода обычно к нему не добавляется диаграмма UML/классов или документация, а это означает, что вы должны понять логику, которая была сделана.

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

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

Методические рекомендации

  1. Выделенное время — очевидно, что существует разная продолжительность проверок кода: от тех, которые могут занять менее 30 минут, до тех, которые могут занять несколько дней (помните, 150 занятий). При работе как в Спринтах, так и в Канбане вы можете примерно указать, сколько времени в неделю вам нужно потратить на ревью кода (если не уверены, просто запишите, в течение месяца за каждую неделю и возьмите среднее время). Допустим, это 5 часов в неделю.
    Выделите 1 час каждый день в то время, которое, по вашему мнению, соответствует вашему графику, на проверку кода и используйте этот час для проверки кода. Очевидно, что бывают дни, когда эта продолжительность может увеличиваться или уменьшаться, но это позволит вам выделить для этого время в течение недели.
  2. Предварительные требования. Это может показаться небольшим, но наличие контрольного списка того, что требуется для отправки проверки кода, может значительно упростить процесс проверки для разработчика. Этот список может варьироваться от одного рабочего места к другому, но несколько примеров включают добавление требования билета к запросу на включение, запуск автоматизации кода, запуск инструментов, таких как линтер, для исправления проблем с синатом, выполнение внутреннего тестирования, написание модульных тестов. для него и запуск самого кода. Один из способов реализовать это — добавить шаблон по умолчанию в код-ревью с контрольным списком того, что было сделано до его отправки.
  3. Избегайте пинг-понговых комментариев. Я видел много случаев, когда разработчики вступали в ожесточенные споры в ходе проверки кода из-за их образа мышления, стиля кода или отношения к коду, который изначально был написан ими. Наоборот, комментарии должны основываться на логике, а не на эмоциях, и давать здравую аргументацию вашим аргументам. Если вы видите, что комментарии превращаются в споры, я предлагаю назначить короткую встречу, чтобы обсудить их конкретно.

Техники

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

  1. Прочитайте требования — вы будете удивлены, как часто об этом забывают. Во многих случаях из-за дублирующихся требований или тех, которые были изменены с момента написания исходных, решение часто отклоняется от них, а в некоторых случаях был добавлен код, который вообще не связан с требованиями. Это должно стать отправной точкой проверки кода.
  2. Комментируйте только изменения в код-ревью — очень много раз я видел, как разработчики комментируют в код-ревью изменения, не связанные с запросом на вытягивание. Это часто является причиной того, что проверка кода растягивается за пределы расчетного времени. Я знаю, что это заманчиво, но даже если вы видите в пулл-реквесте код, который, по вашему мнению, неверен, но не связан с изменениями, внесенными разработчиком в пулл-реквест, не комментируйте его в рамках проверки кода. Что касается того, как вы можете справиться с этими проблемами, здесь есть много вариантов, о которых я не буду говорить.
  3. Запустите код. Во многих случаях недостаточно просто просмотреть код. Только при запуске и просмотре журналов, связанных с потоком, вы обнаружите проблемы. В некоторых случаях для запуска кода может потребоваться особая конфигурация, поэтому она должна быть частью передачи проверки кода.
  4. Рефакторинг против обслуживания кода — баланс здесь тонкий, и при просмотре кода вам нужно подумать, в каких случаях разработчику было бы лучше написать дублированный код, который не будет подвергать опасности существующий код и в каких случаях лучше использовать рефакторинг. Это никогда не бывает черно-белым, здесь есть много оттенков серого, на которые влияет время, необходимое разработчику для утверждения кода, способ использования кода в других целях и опасность регрессии.
  5. Логика превыше синтаксиса. Комментарии к обзору кода обычно различаются между стилем и синтаксисом кода и логикой, реализованной в коде. Найдите правильный баланс здесь. Я предпочитаю использовать подход написания комментариев, основанных только на логике, и если есть что-то, связанное с синтаксисом, я либо ссылаюсь на наши определения стиля кодирования в команде, либо поднимаю это на собраниях разработчиков.
  6. Читаемость важнее эффективности. В некоторых случаях лучше писать более длинный код, если он более удобочитаем и облегчит другим людям его понимание и рефакторинг позже. Я видел много случаев, когда сверхэффективный код был написан таким образом, что вызывал недоумение у других разработчиков, а затем подвергался рефакторингу с ошибками из-за его реализации. Другой вариант — добавить комментарии к коду, если есть основания полагать, что комментарий поможет понять реализацию.

Заключение

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