Отчет. Что такое качественный код
 Скачать 21.97 Kb.
|
|
Что такое качественный код? Не существует точного определения этого термина. Как правило, понимание того, как должен выглядеть качественный исходный код, основывается на многолетнем опыте специалиста. В профессиональной среде судят ещё по нескольким свойствам: Восприятие. Код не перегружен сложными конструкциями, поэтому его легко понять даже без дополнительной документации или комментариев; Сопровождение. В продуманный код легко вносить изменения: менять конфигурации или даже платформы; Расширение. В него просто добавить новую функциональность без риска сломать алгоритм кода. Даже если возникнут какие-то неполадки, их можно быстро устранить; Передача. Хороший код можно передать другим разработчикам для поддержки или доработки, и у них не возникнет трудностей с его прочтением; Покрытие тестами. Чем выше процент покрытия кода тестами, тем больше вероятность избежать ненужных багов в будущем. Плюсы и минусы code-review. Плюсы: Техника Code Review помогает на ранних стадиях находить некоторые ошибки и избавляться от непонятных и запутанных решений. Код легко передавать между участниками процесса. Благодаря Code Review снижается так называемый bus-фактор, или «фактор автобуса». Минусы: Приходится тратить время на то, чтобы посмотреть и при необходимости прокомментировать код, а разработчику — на исправление ошибок. Новые дополнения попадают на этап тестирования не сразу, а только после прохождения review, из-за чего немного сдвигается график внутри этапа. Что такое Code Review Code Review - это процесс проверки и анализа кода задачи разработчиком перед ее релизом. CR (Code Review) выполняется не тем человеком, который делал задачу, а другими членами команды. Результатом CR является обратная связь по выполненной задаче: необходимость внести правки, либо готовность задачи к последующему тестированию и релизу. Зачем нужен Code Review Code Review может являться частью процесса выполнения задачи (частью workflow). Может показаться, что ревьювить должен только тимлид или старший разработчик, но хорошей практикой является если в процессе ревью задач участвуют все разработчики. Таким образом можно не только распределить нагрузку от ревью, но и составить у команды более широкое представление о выполняемых задачах. Также это помогает делиться best practices внутри команды. Положительные эффекты в команде от Code Review: понижает busfactor: больше людей в команде в курсе выполняемой задачи, в случае необходимости внесения изменений в задачу как минимум два человека смогут это сделать. Задача больше не завязана на одного разработчика. помогает найти и выявить баги и недоработки на этапе разработки задачи: так как задача сразу проверяется как минимум двумя разработчиками, это повышает вероятность нахождения упущенных кейсов, которые без код ревью могли бы попасть на бой. повышается читаемость и качество кода и как следствие - его поддержка в будущем: код понятен не только одному человеку, а нескольким участниками команды, это упрощает и ускоряет разработку в будущем. обучаемость сотрудников: разные реализации и подходы к решению задач могут заимствоваться участниками команды друг у друга во время код ревью развитие и поддержание здоровой культуры в команде: участники команды учатся друг у друга и учатся давать качественную обратную связь, повышается взаимодействие внутри команды. Минусы: при разработке задачи на реализацию тратится чуть больше времени в задаче задействованы как минимум два разработчика (тот, кто делал задачу и тот, кто ее ревьювил) Рекомендации по организации Code Review Code Review может быть организован по-разному в разных командах. Главное, чтобы команда заранее обговорила и утвердила свои внутренние правила, которых она хочет придерживаться и с которыми все согласны, чтобы каждый раз не возвращаться к этому вопросу. Общие рекомендации: Избегать рутинных проверок Code Style людьми: автоматизировать такие проверки. Можно использовать для этого любые подходящие вам инструменты для автоматической проверки code style используемого вами языка программирования. Например, для PHP это может быть PHP Coding Standards Fixer https://cs.symfony.com/ Не нужно тратить время разработчиков на то, что можно автоматизировать. Также обратная связь по поводу code style от людей воспринимается как “придирки” и может создать не очень позитивную атмосферу в команде. Code Review должен проводиться для каждого участника команды, вне зависимости от уровня. Не должно быть такого, что ревьювят только задачи, которые сделали Junior разработчики, тем временем Senior разработчики не отдают свои задачи на ревью. Необходимо, чтобы ревью проводилось для задач всех разработчиков. Code Review является частью процесса и необходим каждой задаче. Это правило избавляет от лишних споров и холиваров насчет небольших задач. Ревью проходят все задачи без исключений. Code Review проводится перед релизом задачи и перед передачей ее в тестирование. Это помогает избегать повторного тестирования, а также соблазна оставить все как есть, ведь “и так работает”. К задачам, которые уже на бою, никто не захочет повторно возвращаться. Избегать слишком больших объемов кода в одном Code Review. Если задача большая, то необходимо отправлять ее на ревью частями. Есть рекомендуемое число 200-400 строк в одном ревью. При увеличении количества строк, эффективность и продуктивность ревью резко падает. Если нет возможности внести какие-то правки после ревью, то необходимо завести задачу в трекере задач, а в коде оставить ToDo с ее номером Чего следует избегать: Если Code Review непостоянная часть процесса разработки, то это приведет к нестабильному ревью, его будут откладывать и команда не получит всех плюсов этого процесса. Старшие разработчики рвьювят новых и младших разработчиков. Это создает плохую культуру в команде, а также не позволяет младшим разработчикам увидеть какие-то решения старших разработчиков, на которых они могли бы поучиться и узнать что-то новое. Не автоматизировать процесс ревью и не использовать сторонние инструменты для ревью. Никто не любит заниматься рутинными процессами. Нужно автоматизировать все, что можно автоматизировать. На что обращать внимание во время Code Review Чеклист для разработчика перед отправкой на ревью: Проверить, что реализация соответствует всем указанным в исходной задаче условиям Проверить соответствие Code Style и другим принятым в команде гайдлайнам, например, наличию unit-тестов и документации Протестировать задачу локально и убедиться, что она работает, как нужно Подготовить описание для ревьювера, если какой-то информации в задаче не хватает Проверить, нужны ли какие-то комментарии в самом коде и добавить при необходимости Чеклист для ревьювера: Ознакомиться и понять цель и суть задачи Проверить общую архитектуру и подход к решению Проверить реализацию Проверить мелкие детали (имена функций и переменных и т.д.) Проверить наличие тестов и документации по необходимости Итоги ревью: Список ToDo: изменения, которые необходимо внести в код после ревью Вопросы: обозначить свои вопросы по частям кода, которые непонятны после ревью Предложения по улучшению: внести свои предложения и пожелания по коду задачи и/или связанных задач. Например, договориться о создании задачи по обновлению старого метода в других участках кода на новый и завести на это ToDo и задачу в трекере задач и поставить ее в тех. долг команды. Также отдельно хочется отметить, что если вы ревьювите чью-то задачу и видите какие-то хорошие подходы и решения, то скажите об это автору. Положительная обратная связь тоже очень важна. ЗАКЛЮЧЕНИЕ Процесс Code Review достаточно прост, а его плюсы заметно преобладают над минусами, но в ряде ситуаций вы легко обойдетесь без него. К примеру, нет смысла проводить Code Review при разработке прототипа или MVP — минимально жизнеспособного продукта. Главная задача такого проекта — получить от пользователей обратную связь, чтобы построить гипотезы для дальнейшего развития. Структура этих приложений делается максимально простой, и в дальнейшем код всё равно предстоит переписывать кардинальным образом. Ещё Code Review не нужен в работе над простыми приложениями, которые делаются раз и навсегда. Так что, если вы не планируете в будущем изменять или дорабатывать свой проект, можно сэкономить время. |