Что? Почему оно здесь?
Во-первых, ревью чужого кода, как это не парадоксально прозвучит, происходит уже на поздних этапах разработки. Вы смотрите код, или смотрят ваш код - не важно. Когда с результатом ознакамливаются коллеги, это уже последний этап написания кода.
Во-вторых, когда код написан, это значит, что уже большинство других активностей завершено: с продуктом вы обсудили функциональность, с лидом обсудили реализацию, с доменом ознакомились, задача прочитана, тесты написаны. TODO ссылку
В-третьих, прочтение и анализ написанного кода другими коллегами, а так же получения апрува на мерж - первая капелька из всех остальных оставшихся активностей в общем процессе разработки, а именно - эксплуатации и поддержании кода.
Ревью или легаси
Чем отличается код-ревью, от прочтения уже написанного кода? От написанного кода сильно сложнее отказаться. Не попавший в основную ветку код ещё может быть легко переделан. И из-за этой легкости, можно сильно проще накидать автору замечаний, которые ему не очень долго поправить.
Код, который уже в продакшне, править намного сложнее. Например, схема базы данных которая в проде меняется намного сложнее и больнее. В табличках уже могут быть данные – нужно подготовить ещё и миграцию данных. Приложение уже пользуются колонками – удаление одной из них требует специального релиза, в котором код разучится смотреть в указанную табличку. И будет очень грустно, если на эту колонку была завязана специфичная бизнес логика.
Бесплатное обучение
Процесс код ревью можно с легкостью использовать как часть обучения.
Если ты новенький - код ревью без спроса у других коллег помогает разобраться в текущих задачах команды, наводит на вопросы по домену, рассказывает о местной культуре коммуникации. Все это помогает влиться в коллектив и процессы.
Когда не понятно, каким скилам обучаться целенаправленно. Когда интересно посмотреть на другие активности коллег, но не уверены что хотите брать их задачи полноценно. Врыв в треды под изменениями в реквесте - ваш выход.
Код ревью это очень простой и дешевый способ прокачиваться свои и хард и софт навыки, не отвлекаясь на рутину. Алгоритм достаточно прост в применении, а так же позволяет самостоятельно решать на сколько вам интересен вопрос, по своему настроению.
Мотивация такого алгоритма достаточно проста. Можно самостоятельно, у себя в голове, решать интересные вам задачи, что как раз всесторонне прокачивает вас. В голове прокручивать все этапы процесса разработки, но не взаимодействуя напрямую с задачей. Понимать на каком вы уровне относительно остальных, сравнивая ваше виртуальное решение с решением коллеги.
И при этом, вы экономите колоссальное количество времени, по сравнению с обучением на разработке реальных задач. Вам не нужно печатать буковки и составлять из них комплирующийся код. Вам не нужно ждать пока пайплайны и джобы в CI/CD прокрутятся в десятый раз. Не нужно запускать тесты, что бы отловить баг. Не нужно общаться с бизнесом, аналитиками или менеджерами. А ещё, в конце, можно и набросить странный вопрос автору кода, с которым ему придется разбираться, если у вас игривое настроение.
Раскрывая мысль, получается примерно следующая идея этого процесса.
- Сначала открываем мерж и определяем к каким задачам, фичам, проектам он относится или решает.
- Читаем задачу, знакомимся с доменами.
- Читаем связанные треды.
- Думаем, как бы мы сами решали эту задачу.
И как раз на этапе этих дум можно и контролировать собственный порог входа. Только ознакомиться с доменом. Или посмотреть технические детали решения. Или узнать как разработчик решил какую-то проблему в бизнес логике, которая у вас возникла в мыслях при прочтении ТЗ.
Что проверять
Правильно проводить ревью нужно в том же порядке, как мы ведем разработку.
Сначала разбираемся или вспоминаем домен. Читаем и осознаем задачу, и что она меняет в этом домене. Смотрим бизнес логику, её соответствие изменениям и тому варианту решения, если бы вы делали эту задачу.
Ищем в изменениях стандартные или локально принятые паттеры: процессы, названия, структуру кода. Анализируем все места, в которых идет расхождение от этих паттернов. А в местах где паттернов не видно - прикидываем варианты реализации той же части задачи, но уже с использованием стандартов. Проверяем прокомментированность (TODO ссылку) всех частей кода, которые отходят от обычного флоу выполнения.
Смотрим на тесты и вообще тестируемость кода. Намного круче когда в CI/CD происходит тестирование изменений функциональности, а не воздуха. И очень переживаем, когда большой объем изменений в основном коде не ломает уже написанные тесты.
На этом этапе уже можно сформулировать десяток другой замечаний в направлении неподготовленного разработчика.
Далее, после формулировке замечаний по домену, уже можно ревьювить правильность использования инструментов.
К сожалению, обычно код ревью проводится только на уровне использования инструментов. Во-первых, это потому что разработчикам нравится взаимодействовать с тем, что им ближе - а не с бизнесом или доменом. Хотя корректность доменного слоя в продуктовой разработке идет наравне с корректностью остального кода. А во-вторых, сегодня достаточно бессмысленно лично проводить ревью использования большинства инструментов.
Уже придуманы и хорошо описаны, а в больших корпорациях внедрены, автоматизации код ревью множества вопросов с инструментами. Начиная с простых: линтеров, анализаторов кода, форматтеров.
Из чуть более сложных - это общие скрипты по генерации кода, код ковередж, секьюрити анализаторы, фаззеры и property-based тестирование (schemathesis).
Нагрузочные тестирования проверяют производительность кода и можно сильно не париться за написанный код, но это работает только когда нагрузку готовят до вывода фичи в продакшн.
Следующий уровень, который актуален уже только для больших корпораций - это внутренняя экосистема компании:
- утвержденный список библиотек, может быть форки опенсорсных
- разрешенные языки программирования
- список проверенных баз данных, кешей, брокеров, да и вообще всех инфраструктурных компонетов системы
В общем, есть очень много автоматики, которая не пропустит коллегу с совсем не правильным кодом. Поэтому, если вы пришли посмотреть на правильность синтаксиса в мерже, проверить табами или пробелами пользуется разработчик - не тратьте свое время. Роботы, причем даже не ИИ, вас уже заменили. Просто поставьте лайк. А время потратьте на погружение в домен и обучение решать задачи.
Но иногда есть сложные вопросы, касаемые использования инструментов в связке с бизнес логикой. Можно проверить на качественное использование особенностей базы данных. Как используются транзакции в коде, например не открывается ли внутри транзакции другая транзакция. Или может быть делается поход во внешнюю систему.
После можно посмотреть на адаптеры и хендлеры, консьюмеры и кроны. Посмотреть на их наличие и изменения в них. Тут мы проверяем коллегу на качественно проделанный этап коммуникации: договорились ли с фронтами о новом АПИ; узнали у разработчиков используемого сервиса как правильно пользоваться их АПИ; в каком формате аналитики хотят видеть данные у себя, а дата-инженеры смогут подключиться к вашему стриму данных. Можно узнать как мы будем тестироваться на бою.
Бесплатное обучение со стоимостью
Есть ещё один источник бесплатного самообучения, но он сильно сложнее. Хотелось бы упомянуть его здесь.
Активно можно пользоваться аджайловыми активностями, если они есть у вас в команде. Участвовать в планированиях, грумингах, ретрах и остальных созвонах, на которые у менеджеров хватит фантазии.
Сложнее это обучение будет даваться по нескольким причинам.
Первая, очевидно, - это прямой контакт с другими людьми. Ревью кода можно проводить асинхронно, а вот планирование - нет. И ещё люди произносят слова сильно медленнее, чем читают или воспринимают на слух. Видео можно смотреть на х1.25, х1.50, а кто-то и на х2 в состоянии воспринимать информацию. А вот говорить человек быстро не умеет.
Вторая это то, что первые этапы анализа, знания домена, ознакомления с ТЗ или кодом или сильно ограничены, или вообще не возможны в установленный срок встречи. А ещё нужно прикинуть, какими инструментами воспользоваться.
Поэтому не рекомендую заниматься такой практикой новичкам в команде. Можно очень сильно перегреть свой мозг.
Можно немного упростить себе жизнь, если с тобой есть коллега-наставник. Возникшие вопросы можно записать. И потом спросить и уточнить у него все интересующие моменты, которые не успели обсудить на очной встрече.