Проверка кода - Лучшие практики

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

• Как поднять код на проверку?
• Как должен выполняться обзор кода?
• Примеры проверки кода.

Как поднять код на проверку?

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

• Размер изменений. Размер кода, отправляемого на проверку, должен определяться в зависимости от типа. Например, когда разработчик реализует функцию, более короткие изменения предпочтительнее более длительных. Ответственность за разбиение функции на части лежит на владельцах кода. Каждый фрагмент должен быть четко определен и привязан к определенной функциональности большой функции. Например, разработчик может отправить одно изменение, которое содержит макет страницы в одном PR (запрос на вытягивание) и реализацию этого фрагмента в другом PR. Ветви Git могут быть созданы следующим образом для более крупных функций: feature/featureName будет действовать как основная ветвь, последовательные фрагменты могут быть названы как feature/featureName-api, feature/featureName-layout. В этом случае каждая ветвь определяет подмножество более крупной функции.
• Самопроверка и самопроверка. Когда разработчик почувствует, что разработка завершена, он должен убедиться, что у него есть время, чтобы провести самопроверку с помощью различий. Это экономит много времени для рецензентов, а также позволяет избежать постоянных изменений в процессе рецензирования. Каждый код, созданный для PR, должен быть самотестирован с использованием набора тестов, и разработчик должен убедиться, что все тестовые примеры проходят, а сборка зеленая. Очень важно поднять CR с помощью соответствующих тестовых примеров, поскольку это облегчит работу рецензента, и он сможет легко проверить, были ли охвачены все тестовые примеры в соответствии с функцией или ошибкой. .
• Проверка форматирования, стиля и синтаксиса. Большую часть человеческого времени при проверке следует тратить только на логику программирования, а не на проверку форматирования, стиля и синтаксиса. Они должны быть покрыты средствами автоматизации, используемыми в проектах. В Интернете доступны различные предпочтительные инструменты, такие как ESLint, Prettier и т. Д. Большинство современных IDE также поддерживают их как настраиваемые подключаемые модули, с помощью которых вы можете исправлять ошибки во время самой разработки.
• Правильные сообщения о фиксации, описание Каждый раз, когда разработчик поднимает PR (запрос на извлечение), он должен убедиться, что было дано правильное сообщение о фиксации. Сообщение о фиксации Git может быть с заглавной буквы, короче 50 символов как заголовок для внесенных изменений. Подробное представление может быть дано в описании PR со справочным изображением дизайна страницы (при необходимости), может быть заключено в 120 символов, также разрешены маркеры :) Ниже приведен образец для хорошее и плохое сообщение о фиксации.

//BAD COMMIT MESSAGE:
Bug Fix
//GOOD COMMIT MESSAGE:
Bug-Fix: Enable the button when there is no error

Если вы используете какие-либо инструменты управления проектами, такие как JIRA или Freshrelease, вы даже можете указать соответствующий заголовок заявки в сообщении о фиксации. Что также проясняет постановку проблемы для обозревателей. Например, сообщение о фиксации может иметь вид FT-123: Enable the button when there is no error, где FT-123 - номер тикета. Благодаря различным веб-перехватчикам, предоставляемым GitHub, они могут быть даже полезны при автоматическом обновлении статуса заявок в вашем инструменте управления проектами.

Кому следует проверять код?

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

Как должен выполняться обзор кода?

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

• Позитивное отношение к коммиттерам. Единственной целью должно быть улучшение качества фиксации. Необязательно всегда находить плохую часть кода. Когда рецензенты видят хороший код, созданный их коллегами, они всегда могут оставить положительный комментарий к нему. Распознавание сверстников в коде считается оскаром для многих программистов. Разработчик потратил бы ночи на разработку функции, неправильный или грубый комментарий испортит всю энергию разработчика. Старайтесь быть вежливыми и аккуратными в том, что вы говорите. Позитивное взаимодействие создает отличную связь с товарищами по команде.
• Обмен знаниями. Рецензенты могут быть экспертами в своей области. У них будет опыт передовой практики или эффективный способ внедрения. Если рецензент находит лучший алгоритм для подхода к постановке проблемы в коде, он должен не стесняться объяснять разработчику подход с разумным описанием, чтобы убедить, почему это лучший подход. Если рецензент комментирует только предложение, у разработчика может возникнуть несколько вопросов, почему его подход неэффективен по сравнению с предложением. Всегда приступайте к разумному описанию запрошенных изменений.
• Согласованность. Рецензенты должны убедиться, что изменения, внесенные разработчиком, согласованы во всем проекте. Они должны убедиться, что соответствующее изменение кода хорошо адаптировано к базе кода и будет ли оно проще для любых будущих миграций или изменений.
• Читаемость. Убедитесь, что вы как рецензент уловили изменения в разумные сроки. Разработчики должны давать разумные имена используемым переменным, методам и классам, и они должны иметь для них законное значение. Убедитесь, что соответствующие комментарии, связанные с документацией, добавлены для классов, методов и везде, где это необходимо. Это позволяет любым будущим разработчикам в команде, которые видят код, лучше его понять. Если в код добавляются какие-либо TODO, рецензенты должны убедиться, что разработчик поднимает их как тикет в вопросах GitHub или любого инструмента управления проектами, такого как JIRA или Freshrelease .
• Возможность повторного использования. Одним из ключевых моментов, которые следует отметить для любых гигантских приложений, является возможность повторного использования. Программисты должны убедиться, что большая часть кода, который они пишут, может быть повторно использована и адаптирована для будущих случаев. Это помогает повысить ремонтопригодность кода и уменьшает количество строк, которые вы пишете для одной и той же логики. Если какое-либо из новых изменений может использовать существующий код для решения той же проблемы, рецензенты должны рекомендовать такие существующие компоненты для повторного использования.
• Шаблоны. Каждый проект следует своим шаблонам дизайна и стандартным шаблонам в отношении соглашения об именах, определениях типов и т. д. Рецензенты должны убедиться, что текущие изменения адаптированы и реализованы с следовали шаблонам.
• Производительность. Программисты должны убедиться, что любые изменения, внесенные в код, не должны снижать производительность приложения. Они должны убедиться, что изменения слабо связаны и имеют ли они как можно меньше зависимостей.
• Случаи автоматизации. Проверка кода должна происходить только после того, как пройдены все проверки автоматизации. Рецензенты могут проверить, имеют ли соответствующие изменения сильное покрытие тестовых случаев. Слово «покрытие» вызвало разный взгляд на разработчиков по всему миру. Лично для меня есть два способа обозначить «покрытие»: хорошее покрытие и сильное покрытие. Хорошее покрытие - это случай, когда вы покрыли все свои строки кода с помощью тестовых примеров, тогда как сильное покрытие - это что-то, где вы покрываете все строки кода различными аспектами функции с большим дела проходят проверку. Всегда рекомендуется иметь сильное освещение, чтобы убедиться, что функция безупречна.

Примеры проверки кода

• Комментарий к отзыву. Как уже упоминалось ранее о положительной атмосфере, всегда старайтесь различать предложения и требуемые изменения. Большинство успешных компаний следят за использованием префикса, чтобы дифференцировать свои комментарии. Например, для предложения «Предложение: можете ли вы попробовать использовать Map () вместо HashMap?» для требуемых изменений «Изменить: используйте карту () вместо HashMap », за которым следует разумное объяснение. Если вам непонятен код, не забудьте спросить автора и узнать о нем, прежде чем оставлять комментарий, например, «Это ожидаемое поведение? Если да, не могли бы вы объяснить причину? ».
• Отвечая на отзывы, авторы не должны обижаться на изменения, предложенные рецензентом. Если вы не можете понять причину запрошенного изменения, всегда лучше взаимодействовать с рецензентом в режиме реального времени, чтобы понять причину. Убедитесь, что вы всегда отвечаете на комментарии к обзору, это может быть либо подтверждение, либо даже после того, как это будет сделано. Благодарности также могут следовать за использованием префикса, как в предыдущем пункте, например, «ACK: Спасибо за это предложение, будет изменено». После внесения запрошенных изменений убедитесь, что вы ответили на эти комментарии как «Готово». Это уведомит рецензента о том, что вы внесли необходимые изменения.

Если у вас есть какие-либо вопросы, не стесняйтесь оставлять комментарии, и если этот блог помог и вам, пожалуйста, покажите свою поддержку, хлопнув :)