Прообраз code review появился в 60-х годах прошлого столетия, когда программы писали на перфокартах. Главной проблемой тогда было преобразование программного кода в машинный — компиляция. Это сложный процесс, чувствительный к ошибкам и структуре написанного кода. Если в процессе генерации всплывала одна незначительная ошибка, приходилось начинать процесс заново: набирать, проверять и занимать очередь доступа к системе, которая могла длиться месяцами из-за большого количества желающих воспользоваться компьютером. Из-за высокой цены ошибки программисты досконально проверяли перфокарты друг за другом.
Сегодня ошибки в информационных системах по-прежнему стоят недешево, хоть исправлять их попроще. Проверка кода одним программистом за другим получила широкое распространение и сегодня известна как практика code review.
Набор преимуществ
Еще 20 лет назад мало кто знал о code review, 5 лет назад инженеры-разработчики не представляли как без него обойтись, а сегодня ищут альтернативные методы. В своей работе в 90% случаях мы прибегаем к code review, потому что плюсы подхода очевидны:
Экономия времени и бюджета
Много ошибок в бизнес-логике, архитектуре и алгоритмах можно отловить как раз на этапе code review. Если баг будет обнаружен в момент ручного тестирования, то тестировщику нужно пойти к инженеру и указать на ошибку. Инженер в это время занят уже другим контекстом и чтобы внести исправления, ему надо оставить текущую задачу и вернуться к прежней. На этапе code review на корректировку уходит меньше времени. Когда же ошибки всплывают на этапе продакшена, это может привести к финансовым потерям.
Универсальный код
Все инженеры пишут по-разному, у каждого свое понимание чистоты кода. И то, что напишет один, не всегда может правильно прочитать второй. Проблема решается за счет внедрения правил написания кода в команде в начале работы. Но на практике визуальные составляющие кода отлавливаются и исправляются именно на code review.
Снижение bus-фактора
Термин «bus-фактор» (фактор автобуса) появился из вопроса: «Сколько членов команды должен сбить автобус, чтобы провалить проект?». Если в кодовой базе есть блок, которым владеет только один инженер, то bus-фактор равен единице. С инженером может что-то случится (заболеет, уволится, незапланированный отпуск) и тогда другим будет проблематично разобрать блок с нуля. Чем тут помогает code review: если инженер проверяет код, который написал исполнитель, то в процессе вникает в структуру, что в будущем поможет внести правки в отсутствии первого инженера.
Неформальное обучение
В процессе проведения code review возникает синергия: разбираясь с готовой работой, люди видят разные подходы, у них появляются новые идеи, их можно использовать в дальнейшем.
Обратная сторона медали
Безусловно, споры о целесообразности применения code review ведутся не просто так, у практики есть существенные недостатки:
Организация процесса
По опыту, на организацию проверки кода уходит от 20 до 50% от времени разработки: инженеру требуется поменять контекст, вникнуть в суть задачи, провести ревью, оставить комментарии, потратить время на урегулирование споров и все это время прогресс по основной задаче проверяющего стоит на месте.
Это можно решить, просто регламентируя время. Например, мы в команде разработки взяли за правило, что задача по code review ставится в Jira, тогда она должна быть выполнена в течение одного рабочего дня. Если вопрос срочный, задачу можно кинуть исполнителю уже лично, даже просто в сообщениях, тогда результат можно получить совсем быстро.
Ментальные сложности или потеря мотивации
Очень реальная ситуация: исполнитель старался, делал блок кода, а после получил от коллеги 20 комментариев из серии: «Нужно все переписать». В этот момент снижается самооценка, вместе с ней интерес к работе, а иногда и отношения с коллегами. Тут как минимум стоит отдельное внимание в команде уделить тактичным формулировкам в комментариях к ошибкам, выработать общие правила.
Сложно найти ответственных
При проведении code review сложно назначить ответственного за результат. Например: Вася написал блок кода, Петя провел code review, QA-инженер Витя проверил, не нашел замечаний, а на продакшене всплыл баг. Кто в этой цепочке несет за него ответственность? Вася, Петя, Витя, а может тимлид Николай? Или все вместе? Правильного ответа нет. Если назначить ответственным исполнителя, то ревьюер может сделать работу тяп-ляп — цель code review теряется. Если отвечает ревьюер, то исполнитель может писать неаккуратно. И так по кругу.
Чем можно заменить code review
Меняем «code» на «design»
Наиболее прогрессивная практика сегодня, на мой взгляд, — design review. Исполнитель получает задачу и перед тем как приступить к выполнению, продумывает работу и описывает техническую реализацию: какие функции планирует прописать, как они будут связаны друг с другом, какие будут интерфейсы, и прочее. Тимлид или технический координатор проверяют этот текст, дают советы по улучшению, возвращают исполнителю и тот приступает к задаче.
Метод design review пока широкого распространения не получил. Во-первых, потому что многие идеи появляются лишь в процессе работы над задачей, заранее спланировать их сложно. Кроме того, есть мнение, что подготовительная работа не связана с качеством кода. На мой взгляд, это не так — созданные документы дисциплинируют писать четко по инструкции, что минимизирует ошибки. Плюс, когда инженер двигается по плану, ему проще вернуться к задаче. Однако у метода есть ряд сложностей внедрения: все новое обычно вызывает дискомфорт, страх полностью заменить code review и допустить ошибки, многие команды отказываются писать какие-то документы. С подготовкой описания связана проблема идеального объема — формирование мыслей в сжатой форме — это навык, которому нужно учиться, а у инженеров иногда получаются подробные и абстрактные рассуждения.
Парное программирование
Практика парного программирования распространена больше, чем design review, но как полноценную замену code review её рассматривают редко. Суть заключается в том, что два разработчика одновременно делают одну задачу (рядом или во время созвона) и в процессе проверяют друг друга.
Плюсы:
баги ловятся быстрее — две пары глаз лучше одной;
созданный код понятен минимум двоим и высока вероятность, что и другие смогут разобраться в его структуре;
bus-фактор равен двум;
обмен знаниями в парной работе.
А главный минус — эффективность. Есть исследования, которые подтверждают, что, когда два человека делают одну задачу, скорость выполнения увеличивается на 40-50%. Но с другой стороны, если два человека будут делать каждый свою задачу, то времени затрачивается меньше, чем при парном выполнении сначала одной задачи, потом другой. К тому же не всех разработчиков можно посадить рядом.
Метод единичной ответственности инженера
Недавно узнал о новом подходе — человек, который проводит code review, не просто смотрит код, а скачивает его, запускает на машине и проверяет работу задачи. В этом случае ответственность лежит полностью на ревьюере, QA-инженер не нужен вовсе. Подобный процесс пока подходит только для смелых ценителей, так как у него много ограничений.
Во-первых, компания тратит в 1,5-2 раза больше денег на ревью и тестирование, так как инженер-разработчик попросту стоит дороже QA-инженера. Во-вторых, есть ментальные ловушки: тот кто, провел code review, знает, какие куски кода были изменены, а какие нет, и иногда ревьюер убежден — то, что не менялось, не может сломаться. Но проекты большие и охватить их полностью сложно. Могут быть ситуации, когда ревьюер подумал, что раз часть кода не менялась, то ошибок не будет и пропускает ее, а изменения эту часть все-таки затронули и в итоге всё ломается. В случае, когда на проекте есть QA-инженер, который ничего не знает про изменение кода, подобной ловушки нет — он проверяет всё.
Подведем итоги
В своей работе я пока не нашел полноценной замены code review. Иногда совмещаем практики: design review проводим при сложной задаче, проверяем в том ли направлении мыслим, а парное программирование используем при выявлении сложного бага. Но это лишь 10 случаев из 100.
Когда в команду приходит новый человек, при выполнении первой задачи он может сделать много ошибок, так как еще не погружен в контекст. За счет code review адаптация происходит быстрее. В design review велика вероятность что-то упустить. В парном программировании теряем эффективность. Так что альтернативы для погружения в контекст без отвлечения других людей на сегодняшний день, думаю, пока нет.
Ещё по теме:
Доклад Филиппа Дельгядо: Одна голова хорошо, а две — лучше (YouTube)
Code review — долго, плохо, дорого -- sharovatov.github.io
Максим Быстров
CTO SaaS-платформы TYMY
