По моему опыту, как и в случае любой задачи, вам потребуется определенный уровень подготовки, прежде чем вы сможете приступить к работе, чтобы вы могли наиболее эффективно использовать свое время.
Код-ревью — это способ №1 улучшить качество кода. (Опрос SmartBear)
В этом случае ваша ответственность заключается в том, чтобы понять, чего именно от вас ожидают, чтобы вы могли сосредоточиться в правильном направлении.
Просмотр чужого кода может показаться тривиальной задачей, но поверьте мне, это никогда не бывает легко. Если вы собираетесь рецензировать чужой код, от вас есть определенный уровень ожиданий. Если у вас или вашей команды еще нет процесса проверки кода или вас попросили выполнить проверку кода в качестве стороннего наблюдателя, вот 8 шагов, которые проведут вас через весь процесс.
1. Понять цель упражнения
Вы должны понимать, какова цель проверки кода. В большинстве случаев вы, наверное, знаете. Но если вы не уверены, спросите человека, который запросил код-ревью. Может быть много аспектов код-ревью.
- Низкоуровневая проверка кода (построчная проверка)
- Проверка кода высокого уровня (связанная с архитектурой и дизайном)
- Проверка кода с акцентом на рекомендации по безопасности
- Проверка кода с акцентом на рекомендации по производительности
- Проверка кода в соответствии с конкретными рекомендациями, предоставленными клиентом
Запишите цель этого упражнения в документе, который вы собираетесь подготовить. Когда вы будете знать точную цель упражнения, только тогда вы сможете придумать план, который оправдает ожидания. Подтвердите свое понимание целей с командой разработчиков/заявителем.
2. Определите формат документа проверки кода
В большинстве случаев у вас уже будет заранее определенный формат для таких упражнений. Под форматом документа я не имею в виду документы Word. Использование проверки кода на основе запросов на включение и добавление комментариев к проверке на GitHub также является форматом записи наблюдений.
На высоком уровне каждый комментарий проверки кода должен содержать следующую информацию:
- Идентификатор проблемы
- Наблюдение
- Файл/класс
- Предложения с примерами и/или ссылками
- Серьезность (высокая, средняя, низкая)
Но если у вас их нет, потратьте некоторое время на то, чтобы подумать о формате, в котором вы будете записывать свои наблюдения, просмотрите комментарии и предложения по решению проблемы. Получить этот формат для проверки заказчиком проверки кода. У них всегда будут какие-то важные предложения, которые вам могут понадобиться для рассмотрения, которые имеют смысл для них.
Принятие решения и согласование общего формата документа не только экономит ваше время, но и облегчает разработчикам понимание и быструю реализацию ваших предложений.
3. Соберите рекомендации и требования для конкретного проекта
У каждого проекта или команды могут быть разные рекомендации. Они могут отличаться от рекомендаций, с которыми вы работаете. Всегда уточняйте у команды разработчиков, есть ли у них следующие рекомендации:
- Рекомендации по написанию кода
- Рекомендации по стилю
- Требования безопасности
- Требования к производительности
- Требования к дизайну
- Другие нефункциональные требования
Если нет конкретных указаний по проекту, у вас все равно должна быть ваша версия этих документов, которую следует использовать во время этого упражнения.
4. Подготовьте контрольный список задач, которые необходимо выполнить
Контрольный список вещей, которые необходимо сделать в упражнении по проверке кода, очень пригодится во время фактического процесса проверки кода. Типичный контрольный список может выглядеть так (не полный список):
- Создание и запуск модульных тестов
- Проверьте время сборки и время выполнения модульного теста
- Запуск инструментов статического анализа
- Проверьте соблюдение правил кодирования и стиля
- Контрольный список запахов кода
- ….
- Конфиденциальные данные зашифрованы
- Все сетевые вызовы используют «https»
- Время загрузки экрана составляет менее 5 секунд
- ….
- ….
5. Используйте инструменты статического анализа
Проверка кода с помощью инструментов — это не проблема. Первый уровень проверки кода должен выполняться с использованием инструментов статического анализа. Некоторые из проблем могут быть неактуальны, но, по моему опыту, большинство наблюдений при проверке кода обнаруживаются с помощью инструментов статического анализа.
6. Выполните ручную проверку кода
После того, как вы просмотрели все проблемы, о которых сообщают инструменты статического анализа, и сопоставили их, вы можете перейти к ручной проверке.
Для этого также полезно иметь заранее определенный контрольный список вещей, которые вы хотите пройти. Возможно, не имеет смысла проходить весь код построчно. В некоторых случаях вам может понадобиться просмотреть только несколько файлов, отобранных из тысяч файлов. В принципе, вы должны знать, что именно вы будете искать.
Процесс проверки вручную утомителен и занимает много времени. Вот несколько советов, которые обычно помогают:
- Не просматривайте код дольше 60 минут
- Проверяйте не более 400 строк кода за раз
- Сверьте свои наблюдения с отраслевыми стандартами и аналогами
- Не сосредотачивайтесь только на коде. Такие вещи, как использование структур данных, правильное использование баз данных, сети и т. д., также следует пересмотреть
6(а). Используйте инструменты проверки кода на основе ИИ (необязательно)
Существует довольно много инструментов и сервисов, которые утверждают, что могут выполнять проверку кода на основе ИИ. Хотя я не проводил подробного анализа их эффективности, они кажутся многообещающими. Если не сразу, то через несколько лет они могут полностью заменить необходимость ручной проверки кода. Большинство из них предоставляют бесплатный уровень для проектов с открытым исходным кодом. Некоторые из них также предоставляют бесплатную пробную версию для оценки.
Несколько примеров:
7. Просмотрите и доработайте свой отчет
Пройдите свой окончательный отчет, просмотрев его самостоятельно хотя бы один раз. Если есть возможность, также проведите экспертную оценку.
Код-ревью не сводится к поиску ошибок. Предполагается, что это процесс обучения для всех участников, даже для вас как рецензента. В своих комментариях обязательно проверяйте тон предложений. Старайтесь давать конструктивную обратную связь.
8. Пройдитесь по комментариям обзора с командой разработчиков
Как рецензент, вы обязаны изложить свою точку зрения. Кроме того, вы также должны выслушать их точку зрения. Во время пошагового руководства может потребоваться несколько изменений. Будьте открыты для обсуждений и предложений. Если они актуальны, включите их в отчет.
Код-ревью не должен фокусироваться только на ошибках. Если вы заметили что-то хорошее, обязательно сообщите об этом команде разработчиков.
Вывод
В процессе код-ревью много аспектов. В этом посте я сосредоточился на важных шагах, которые вы должны предпринять, чтобы сделать этот процесс простым и эффективным. Дайте мне знать, если у вас есть какие-либо предложения в разделе комментариев. Буду рад добавить ваши предложения в этот пост.
Я также нашел несколько интересных статей на тему проверки кода. Я бы посоветовал вам их тоже пройти.
