📝 о код-ревью (часть 2)

вижу тема ↑ код-ревью хорошо зашла — продолжаю накидывать


⌘ разные авторы — разные вопросы на ревью

+ во время онбордина на первые ревью обычно приходит тьма комментариев; чтобы проверить, что автор достаточно погрузился в новый проект, приходится спрашивать с самых банальностей: «почему тут за Т-2», «почему тут снепшото, а не апсёрт?» и т.д.

+ со временем у авторов набирается «репутация» — вопросы переходят на следующий уровень абстракций (или вовсе пропадают с типовых решений)


⌘ размер имеет значение

− гигантский ПР на 500+ строк кода, затрагивающий множество модулей, имеет шанс погрязнуть в процессе ревью (не говоря уже про увеличенную вероятность пропустить багульку в прод)

+ а вот маленький атомарный ПР легко читать и требует адекватного количества когнитивной энергии ревьюера — а значит не вызывает сопротивления и обычно сходится предсказуемо быстро


⌘ не всегда есть «правильный» ответ

+ иногда вопрос — это предложение к дискуссии или просто любопытство почему выбран именно такой подход

+ хочется проверить, что автор продумал основные кейсы в предлагаемом решении


⌘ проблемы код-ревью

− неконсистентность от ревью к ревью: даже один ревьюер может спросить разное, не говоря уже о нескольких

− код-ревью не случается само — оно занимает время и тратит когнитивную энергию; это буквально конвейер и его надо явно планировать в своём календаре (получается всем в команде)

− ну и в целом — растёт тайм-ту-маркет, в задачу надо закладывать время на схождение код-ревью


⌘ ожидания от код-ревью

+ код-ревью не должно быть узким горлышком — положительные эффекты складываются, когда вся команда ревьюит друг-друга (не только один тимлид по ночам и выходным)

+ LGTM — это тоже ответственность; если код падает прям сразу после релиза — вопросики будут как к автору, так и к ревьюеру;

+ всем в команде (включая ревьюера) потом поддерживать этот код — в общих интересах поддерживать кодовую базу в хорошем виде


⌘ пускай потеет машина

+ проверять синтаксис и опечатки должны машины, а не белковые мешки; поэтому эффективнее настроить линтеры, тесты, вот это всё

+ если команда уже сформировала код-стайл и обсудила архитектурные подходы, то будет проще формализовать и базовые проверки

+ а дальше пускай уже и аи-шные агенты ревьюят код помимо базовых линтеров и тестов — эти уже не только формально, но и по смыслу смогут накидать на вентилятор


---

тем временем мы продолжаем искать дата-коллег — ваши репосты нам очень помогут