День восемьсот восьмидесятый. #BestPractices #CodeReview
Лучшие Практики для Эффективных Обзоров Кода. Начало
Обзор кода, если проведён правильно, позволяет разработчикам предоставлять оптимальный исходный код, одновременно узнавая больше об эффективном написании и отладке кода.
Процесс написания кода требует больших умственных усилий и концентрации, что очень затрудняет достижение безупречного результата. Однако важно помнить, что идеального кода не бывает. Программисты должны стремиться к созданию «лучшего» кода, который можно постоянно улучшать. Проверка работы автора кода не может гарантировать предотвращение всех ошибок, но может защитить пользователей от их возникновения. Вот почему интеграция обзоров кода в процесс разработки помогает предоставлять высококачественные приложения.
Обзор кода - это систематическая проверка исходного кода ПО, используемая для выявления ошибок на ранних стадиях, отслеживания возможных упущений и повышения общего качества и согласованности кода. Этот процесс помогает коду оставаться более удобным для сопровождения. Анализ кода, проводимый коллегами-программистами и специалистами по обеспечению качества, направлен на ускорение и оптимизацию процесса разработки ПО.
Важно убедиться, что все члены команды понимают правила и рекомендации по проведению обзора кода в компании. Взаимная проверка кода - это объединение усилий для повышения производительности, а не конкуренция.
1. Знайте, что искать
Разработчики должны точно знать, какие аспекты им следует охватить: дизайн, функциональность, стиль, логику, структуру, согласованность, покрытие тестами, сложность кода и т.д. Некоторые из вышеупомянутых характеристик могут быть проверены автоматически благодаря статическим анализаторам кода (например, структура, логика или покрытие тестами), в то время как другие (например, дизайн и функциональность) требуют проверки вручную.
Чтобы сделать процесс проверки более эффективным, рецензенты должны сосредоточиться на следующих вопросах:
- Можно ли чётко понять, что делает код?
- Код работает так, как ожидалось?
- Соответствует ли код нормативным требованиям?
Если они могут ответить на эти вопросы с уверенностью «да», код можно считать хорошим.
2. Автоматизируйте перед проверкой
Стоит обратить внимание на непрерывную интеграцию, то есть на выполнение серии автоматических тестов при сборке и тестировании кода каждый раз, когда происходит изменение. Перед экспертной оценкой должна проводиться непрерывная интеграция. Когда серия автоматических тестов проходит, разработчики получают код с меньшим количеством ошибок, а процесс ручной проверки становится более плавным и быстрым, что экономит время разработчиков.
3. Ограничьте время обзора
Эффективная проверка может быть проведена только тогда, когда разработчики на 100% сосредоточены на выполняемой задаче. Большинство исследований показывают, что, когда люди занимаются какой-либо деятельностью, требующей высокой концентрации, их эффективность снижается через 60 минут. При проверке кода не нужно торопиться. Лучше разбить этот процесс на короткие сеансы, что даст разработчикам возможность отдохнуть и тем самым улучшить качество проверки.
4. Проверяйте не больше 400 строк кода в час
Одна неправильно рассмотренная строка кода может иметь плохие последствия для всей системы. Вот почему попытка проверить как можно больше строк за один сеанс может привести к провалу всей команды разработчиков. Обзор кода нельзя делать в спешке, иначе он теряет смысл. Попытка сосредоточиться максимум на 400 строках для каждого сеанса проверки приведёт к более тщательному и эффективному процессу проверки.
Окончание следует…
Источник: https://dzone.com/articles/9-best-practices-for-effective-code-review
Лучшие Практики для Эффективных Обзоров Кода. Начало
Обзор кода, если проведён правильно, позволяет разработчикам предоставлять оптимальный исходный код, одновременно узнавая больше об эффективном написании и отладке кода.
Процесс написания кода требует больших умственных усилий и концентрации, что очень затрудняет достижение безупречного результата. Однако важно помнить, что идеального кода не бывает. Программисты должны стремиться к созданию «лучшего» кода, который можно постоянно улучшать. Проверка работы автора кода не может гарантировать предотвращение всех ошибок, но может защитить пользователей от их возникновения. Вот почему интеграция обзоров кода в процесс разработки помогает предоставлять высококачественные приложения.
Обзор кода - это систематическая проверка исходного кода ПО, используемая для выявления ошибок на ранних стадиях, отслеживания возможных упущений и повышения общего качества и согласованности кода. Этот процесс помогает коду оставаться более удобным для сопровождения. Анализ кода, проводимый коллегами-программистами и специалистами по обеспечению качества, направлен на ускорение и оптимизацию процесса разработки ПО.
Важно убедиться, что все члены команды понимают правила и рекомендации по проведению обзора кода в компании. Взаимная проверка кода - это объединение усилий для повышения производительности, а не конкуренция.
1. Знайте, что искать
Разработчики должны точно знать, какие аспекты им следует охватить: дизайн, функциональность, стиль, логику, структуру, согласованность, покрытие тестами, сложность кода и т.д. Некоторые из вышеупомянутых характеристик могут быть проверены автоматически благодаря статическим анализаторам кода (например, структура, логика или покрытие тестами), в то время как другие (например, дизайн и функциональность) требуют проверки вручную.
Чтобы сделать процесс проверки более эффективным, рецензенты должны сосредоточиться на следующих вопросах:
- Можно ли чётко понять, что делает код?
- Код работает так, как ожидалось?
- Соответствует ли код нормативным требованиям?
Если они могут ответить на эти вопросы с уверенностью «да», код можно считать хорошим.
2. Автоматизируйте перед проверкой
Стоит обратить внимание на непрерывную интеграцию, то есть на выполнение серии автоматических тестов при сборке и тестировании кода каждый раз, когда происходит изменение. Перед экспертной оценкой должна проводиться непрерывная интеграция. Когда серия автоматических тестов проходит, разработчики получают код с меньшим количеством ошибок, а процесс ручной проверки становится более плавным и быстрым, что экономит время разработчиков.
3. Ограничьте время обзора
Эффективная проверка может быть проведена только тогда, когда разработчики на 100% сосредоточены на выполняемой задаче. Большинство исследований показывают, что, когда люди занимаются какой-либо деятельностью, требующей высокой концентрации, их эффективность снижается через 60 минут. При проверке кода не нужно торопиться. Лучше разбить этот процесс на короткие сеансы, что даст разработчикам возможность отдохнуть и тем самым улучшить качество проверки.
4. Проверяйте не больше 400 строк кода в час
Одна неправильно рассмотренная строка кода может иметь плохие последствия для всей системы. Вот почему попытка проверить как можно больше строк за один сеанс может привести к провалу всей команды разработчиков. Обзор кода нельзя делать в спешке, иначе он теряет смысл. Попытка сосредоточиться максимум на 400 строках для каждого сеанса проверки приведёт к более тщательному и эффективному процессу проверки.
Окончание следует…
Источник: https://dzone.com/articles/9-best-practices-for-effective-code-review
День восемьсот восемьдесят первый. #BestPractices #CodeReview
Лучшие Практики для Эффективных Обзоров Кода. Окончание
Начало
5. Давайте конструктивную обратную связь
Взаимная проверка кода направлена на повышение производительности команды, а не на разжигание конкуренции между автором кода и рецензентом. В любом случае код необходимо проверять. И если разработчики воспринимают это как процесс обучения, а не критику своей работы, это способствует общему успеху проекта. Получение конструктивной обратной связи побудит разработчиков учиться на своих ошибках и расширять свои возможности. Рецензенты могут оставлять комментарии с префиксом «Nit:» (от «nitpicking» - придирки). Это означает, что такие вещи не обязательно должны исправляться, а имеют образовательную цель и помогают разработчикам постоянно совершенствовать свои навыки. Например:
Если цели процесса обзора кода определены заранее, гораздо проще измерить эффективность кода и решить, приносит ли проверка пользу и помогает ли достичь ожидаемых результатов. Настройка внешних и внутренних показателей позволяет разработчикам улучшить качество кода. Примерами внешних показателей могут быть «уменьшение процента дефектов, сообщаемых конечными пользователями» или «уменьшение количества дефектов, обнаруженных до запуска продукта».
Внутренние показатели включают:
- Скорость проверки.
- Дефектность: среднее количество ошибок, обнаруженных за один сеанс.
- Плотность дефектов: среднее количество ошибок на строку кода.
7. Комментируйте код для рецензента
Комментарии предоставляет информацию о том, что пытается выполнить каждая строка или раздел кода. Они также могут показать рецензенту, какие изменения были внесены, какие методы модификации кода использовались и почему это было полезно. Эта практика способствует более глубокому пониманию кода рецензентом и упрощает общий процесс проверки кода. Например:
Разработчик – человек, поэтому может упустить из виду некоторые аспекты кода. Чек-лист сделает процесс проверки более последовательным, поскольку будет постоянно напоминать о том, что следует проверять. Он особенно полезен для рецензента, поскольку помогает проводить проверку по конкретным критериям. Однако существует и такое понятие, как личный чек-лист. Если автор кода знает о своих типичных ошибках и недостатках в работе, он может составить чек-лист, чтобы постоянно улучшать качество своего кода. Кроме того, чек-листы проверки кода очень важны для выявления упущений, которые труднее всего проверять, потому что сложно обнаружить отсутствие чего-либо.
Вот некоторые вопросы для чек-листа:
- Легко ли понять код?
- Соответствует ли форматирование кода соглашению по проекту?
- Достаточно ли модульная структура кода?
- Соответствует ли выбранное решение требованиям?
- Проверена ли вся логика и все ошибки?
- Есть ли проблемы в безопасности?
- Как дела с производительностью? (Есть ли очевидные моменты для оптимизации?)
- Весь ли код покрыт тестами?
- Насколько эффективно и информативно описание пул реквеста?
9. Включайте всех
Чем больше будет глаз, тем легче найти ошибку. Люди, как правило, работают лучше, если знают, что их работа будет проверена. Неважно, какой уровень квалификации у программиста - каждый должен участвовать в процессе обзора кода. Младшие разработчики могут обучаться новым или альтернативным методам выполнения чего-либо у своих старших коллег, а старшие могут совершенствовать свои навыки программирования, написав код, понятный и читаемый для всех.
Источник: https://dzone.com/articles/9-best-practices-for-effective-code-review
Лучшие Практики для Эффективных Обзоров Кода. Окончание
Начало
5. Давайте конструктивную обратную связь
Взаимная проверка кода направлена на повышение производительности команды, а не на разжигание конкуренции между автором кода и рецензентом. В любом случае код необходимо проверять. И если разработчики воспринимают это как процесс обучения, а не критику своей работы, это способствует общему успеху проекта. Получение конструктивной обратной связи побудит разработчиков учиться на своих ошибках и расширять свои возможности. Рецензенты могут оставлять комментарии с префиксом «Nit:» (от «nitpicking» - придирки). Это означает, что такие вещи не обязательно должны исправляться, а имеют образовательную цель и помогают разработчикам постоянно совершенствовать свои навыки. Например:
var file = app != null && !string.IsNullOrEmpty(app.FilePath);6. Установка целей и сбор метрик
// Nit: может быть заменено на
// !string.IsNullOrEmpty(app?.FilePath);
Если цели процесса обзора кода определены заранее, гораздо проще измерить эффективность кода и решить, приносит ли проверка пользу и помогает ли достичь ожидаемых результатов. Настройка внешних и внутренних показателей позволяет разработчикам улучшить качество кода. Примерами внешних показателей могут быть «уменьшение процента дефектов, сообщаемых конечными пользователями» или «уменьшение количества дефектов, обнаруженных до запуска продукта».
Внутренние показатели включают:
- Скорость проверки.
- Дефектность: среднее количество ошибок, обнаруженных за один сеанс.
- Плотность дефектов: среднее количество ошибок на строку кода.
7. Комментируйте код для рецензента
Комментарии предоставляет информацию о том, что пытается выполнить каждая строка или раздел кода. Они также могут показать рецензенту, какие изменения были внесены, какие методы модификации кода использовались и почему это было полезно. Эта практика способствует более глубокому пониманию кода рецензентом и упрощает общий процесс проверки кода. Например:
// Начинаем с 1, чтобы 0 был недопустимым8. Используйте чек-листы
// и это можно было проверять при передаче параметра извне
public enum SupplierStatsType {
All = 1, General = 2, Custom = 3
}
Разработчик – человек, поэтому может упустить из виду некоторые аспекты кода. Чек-лист сделает процесс проверки более последовательным, поскольку будет постоянно напоминать о том, что следует проверять. Он особенно полезен для рецензента, поскольку помогает проводить проверку по конкретным критериям. Однако существует и такое понятие, как личный чек-лист. Если автор кода знает о своих типичных ошибках и недостатках в работе, он может составить чек-лист, чтобы постоянно улучшать качество своего кода. Кроме того, чек-листы проверки кода очень важны для выявления упущений, которые труднее всего проверять, потому что сложно обнаружить отсутствие чего-либо.
Вот некоторые вопросы для чек-листа:
- Легко ли понять код?
- Соответствует ли форматирование кода соглашению по проекту?
- Достаточно ли модульная структура кода?
- Соответствует ли выбранное решение требованиям?
- Проверена ли вся логика и все ошибки?
- Есть ли проблемы в безопасности?
- Как дела с производительностью? (Есть ли очевидные моменты для оптимизации?)
- Весь ли код покрыт тестами?
- Насколько эффективно и информативно описание пул реквеста?
9. Включайте всех
Чем больше будет глаз, тем легче найти ошибку. Люди, как правило, работают лучше, если знают, что их работа будет проверена. Неважно, какой уровень квалификации у программиста - каждый должен участвовать в процессе обзора кода. Младшие разработчики могут обучаться новым или альтернативным методам выполнения чего-либо у своих старших коллег, а старшие могут совершенствовать свои навыки программирования, написав код, понятный и читаемый для всех.
Источник: https://dzone.com/articles/9-best-practices-for-effective-code-review