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

Как избежать этой ситуации? Ответ в заголовке - обзор кода.

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

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

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

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

Давайте посмотрим на них поближе.

Что мы проверяем: на что обращать внимание при проверке кода

Почему мы общаемся: когда хорошее обсуждение предотвращает плохие действия

Как мы управляем проверкой кода: советы по эффективной организации процесса

Часть 1. Проверьте код

На что обращать внимание при проверке кода.

Запустите код на своем компьютере

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

Пользовательский опыт

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

Целостность важнее индивидуальности

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

Помните об архитектуре кода

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

Упростите

Чем проще это сделать, тем легче его читать, понимать и поддерживать. Сократите необоснованно тяжелые фрагменты кода.

Многопоточность

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

Чрезмерная оптимизация

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

Случаи ошибок

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

Следуйте своим указаниям

Код должен соответствовать стилю кода, точка. Ясность, простота и единство кода - это не прихоть, а необходимость. Легко поддерживать, легко понимать.

Именование и внешний вид

Скорее всего, вашим коллегам придется работать с вашим кодом, поэтому убедитесь, что они его понимают. Имена должны быть четкими и относиться к классам, объектам, функциям и т. Д.

Комментарии

Комментарии всегда должны отвечать на вопрос «почему это делается именно так?» И больше ни на что. Пожалуйста, не объясняйте, как вы это сделали. Важно сосредоточиться на содержании и логике, а не на форме.

Часть 2. Обсудить

Когда хорошее обсуждение предотвращает плохие действия.

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

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

Соблюдайте правила

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

По моему опыту, письменные инструкции - лучшая гарантия от споров из-за стиля.

Примите решение

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

Вместо этого вам следует выполнить три простых шага:

  • Скажите, что не так с кодом (а не с человеком). Объясните, почему это может вызвать проблемы
  • Представьте другое решение

Оставайтесь сосредоточенными

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

Хвалите их

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

Все комментарии равны

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

Будьте ясны

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

Задавайте вопросы

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

Управление конфликтами

Иногда некоторые люди не хотят вас выслушивать и записывают все ваши причины (и даже отказываются приводить свои собственные). Что вы можете сделать в этом случае:

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

Часть 3. Улучшение процесса

Советы по эффективной организации процесса.

Расскажите нам, что вы сделали

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

Разделите запрос на вытягивание на части

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

Ответить на все комментарии

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

Искать все?

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

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

Участие

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

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

Подробности

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

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

Надеюсь, мой опыт поможет вам создать простую процедуру проверки кода.