Дисклеймер: ниже заметки субъективных ключевых мест с краткостью записи для себя, оригинал видео рекомендуется к просмотру. Оригинал обсуждения здесь: https://www.youtube.com/watch?v=IDj3x__YZgE

Зачем код ревью

• Соответствует ли код требованиям в ТЗ
• Побочные эффекты. Проблемы в других функциях
• Читаемость. Странные именования
• Консистентность общему стилю
• Оптимальность
• Чистота
• Повторное использование существующего кода. Агрессивно DRY
• Соответствие архитектурного изменения
• Проверка сценариев тестирования

Плюсы:

• Уменьшение числа дефектов и увеличение качества кода
• Совместное владение кодом и бест практик

Проблемы

Дорого.

Отрицательная обратная связь. Система регулируемая ошибками. Очень дорого. На финальном этапе исправляем ошибки, которые были в начале.

Этапы проверки субъективные. Иллюзия что есть качество. Люди выдергиваются из процесса разработки на комментарии.

Пример большие 2-3 недели разработки. От 70-150 комментариев субъективизма. Человек может сказать спасибо что изнасиловали на код ревью, полезно. Человека затюкивают. Нарушение непрерывности решения задач. Time to market повышается.

Существует понятие достаточно хорошо. Стремление к совершенству по экспоненте. Улучшаем очень мало при больших временных затратах.

Мера недоверия программиста. Идеальных программистов проверять не надо. За плохими нужно проверять всё. Оптимум где-то посередине. Без кодревью не обойтись. Но снизить его влияние можно.

Исторически кодревью появился когда время программистов стоило дешевле времени машины и требовалось множество проверок.

Экономическая модель. Как страховка: платим всегда, выплачивается же по урону и редко. Постоянный налог, но не всегда случаются ошибки. За код ревью платят все, ошибки. Окупает ли это потенциальные баги? Тратится времени 15%. 15% кода багов это уже вредительство. Что за код такой, если такое происходит постоянно.

Человек не хочет писать плохой код. Есть сложность систем, которая не позволяет писать хорошо. Но ревьюверы пишут фи на код. Складывается система охотник – жертва. Ревьювер и тот кого ревьювят никогда не буду доверять друг другу до конца. Хотя можно вместе объединиться против сложности системы. Когда вместе, то жертвой становится система. Если вместе систему (жертву) не убьют, тогда останутся голодными.

Если бы был волшебный мир и то что мы узнали о том в чём проблема, то кодревью не нужен. На входе у исполнителя 20-25% информации. На входе у ревьювера 25-30% чуть другой информации. Правки исходят из неполной информации. В результате выходят проценты того что реально нужно. Дизайн ревью увеличивает процент.

Постановки задачи проходит через множество людей. Если на входе 10% информации, то и на выходе не будет лучше чем 10%. Тогда смысл кодревью?

Что можно делать

Как же без кодревью, мы же пропустим гавно на прод. Cадимся выяснять, а настолько ли гавно. Очень мало кода реально плохого кода с багами.

Обучение и кодревью разные процессы.

Илья Агеев статья на Хабре: “Кодревью вы делаете это неправильно”. Даже когда на кодревью сказали что сделали неправильно, то в голове всё равно осталось неправильное решение. Дизайн ревью это как план, исправление этого гораздо лучше ложится.

Обучение новичков отдельно. Не хватает знаний. Сажаем с другим программистом или отправляем на курсы. И не будешь волноваться что будешь систему делать неправильно.

Тяжело бороться с групповыми динамиками с ревью между людьми. Лучше бороться с системой. Улучшает атмосферу в команде.

Обучение новичков отдельно. Не хватает знаний. Сажаем с другим программистом или отправляем на курсы. И человек не будет волноваться, что будет делать систему неправильно.

Перенести как можно больше этапов раньше кодирования.

Дизайн ревью. Техзадание 1 абзац – 4 часа работы. Показывается тимлиду, архитектору. Можно составлять отдельный документ что точно нужно описывать, но потом. Можно асинхронно говорить: “вот этот кусочек почитаю, можешь делать остальное”.

Код-ревью экспертный. Многопоточность экспертов про многопоточность. Кусок 100 строчек отдельному человеку. Про базу данных отдельно. DBA могут быть отдельно от компании, например.

Чёткая цель зачем просить кодревью. Per problem optional code review. “Я не знаю правильно ли вышло или нет, посмотри, пожалуйста вот эту штуку” – совершенно другая мотивация у тот кто просит кодревью.

Асинхронное посткоммитное ревью. Чаечное кодревью. Как чайка менеджмент. Меньше времени, асинхронно. Лезем в старый код, ревьювим. Требуется разное качество кода в разных местах.

Опыт отмены кодревью. По циклу Шухарта. Качество кода не ухудшилось, пропали ночные инциденты. Все стали аккуратнее коммитится. Моментально исправить что угодно. Сопутствующие инструменты: blue green, canary, фича флаги.

Trunkbaseddevelopment даёт множество классных практик. Подстраховка со стороны продакшена. Больше вариантов оставаться на уровне качества. Ускоряем юзерфичи до продакшена. Нет блокирующих зависимостей и процедур.

Переворачиваем кодревью и хвалим за хороший код.

Note sharing. Рассказывать как оно работает можно позже. Командный час. Полчаса доклада на тему.

Для джунов в онбординге код-ревью много. А ещё лучше парное программирование. Сначала MRы. Дальше с ростом посткоммитное ревью. Потом отказываемся от обязательного код ревью всего, можно звать кодревью по кускам экспертной области. Если код не отклоняется от плана и можем доверять больше. То это уже мидл.

Заключение

Думать как делать кодревью как можно меньше при сохранении качество всего остального. Автоматические линтеры для трети вещей “зачем”. Все исходные цели реализовывать дорого, неэффективно или фиговые групповые динамики

Comments & email subscription

wholesystems.substack.com

I’m Alex, a software engineer with technical and engineering management experience from startups to middle-sized and big-tech companies. Loves to make effective and friendly team processes.

You can freely drop a message to [email protected] or linkedin.com/in/aptakhin to greet and ask questions about any topic.

I’m also mentoring pro bono at meander.so/m/aptakhin