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