🚐 лайфхаки ревью

В стартапе где я работаю нет тестировщиков, от слова вообще. Мы, конечно же, сами тестим наш код, а еще код тестируется другим разработчиком на этапе ревью, но будем честны, разработчики не очень любят, хотят, могут, умеют, +100500 других отмазок, заниматься этим делом, нам бы кода побольше написать. Поэтому качество этих проверок особого доверия не вызывает... Все вышесказанное означает что код-ревью, это один из основных механизмов для выявления багов до того, как они попали на прод, и к нему нужно подходить ответственно и проверять не только на код-стайл и сомнительные техники, а также понимать что и для чего было изменено, как изменения затронут остальные части системы, и т.д. Все усугубляется тем, что у нас стартап и разработка ведется очень активно, стабильно пару раз в месяц прилетаю PRы на тысячи(а то и десятки тысяч) изменений и сотни файлов (из последнего что смотрел: 524 файла, ~12,5K изменений). Проводить ревью такого PR очень сложно, нужно держать в голове много информации и то, как все изменения связанны между собой. Поэтому для себя вывел несколько техник для упрощения процесса ревью:

- в огромных PRах часть изменений вообще никак не связаны с фичей: рефакторинг(js в ts, перевод класс компонента на функциональный, и тд), новые утилиты, обновление/замена пакетов, новые компоненты или их состояния(новый вариант кнопки, поддержка экспорта в пдф). Все это можно и нужно разбивать на более мелкие PRы, даже если какая-то часть пока-что не будет использоваться(добавьте TODO с ссылкой на PR где это юзается). Это уменьшит дифф, а значит и сложность ревью основного PR и позволит сосредоточится только на изменениях в системе.

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

- следующим шагом проверяю самый верхний компонент системы который был изменен (компонент страницы, какой-то контекст, роутер, контроллер, и тд) и иду вглубь изменений дерева файлов. В таком случае проще понять основную идею PRа, и, продвигаясь вглубь, разобраться в деталях реализации. Если делать наоборот, то иногда не совсем понятно почему тот или иной компонент (где-то внутри системы) был изменен именно таким образом и придется искать как он используется, а это значит переключение фокуса и потеря контекста.

- бывают такие случаи, когда изменения, это просто перенос кода из одного файла в другой, при этом исходный файл не удаляется. В таких случаях идеально подходят тулы для нахождения диффов в тексте, просто скармливаете "до" и "после", если диффов нет - то и в коде разбираться не нужно. Кстати эта фича есть в VS Code.

- иногда Github не может подсветить нормально изменения или алгоритм нахождения диффов ломается. В таких случаях я пользуюсь GitKraken(GUI клиент к гиту, к сожалению он платный) - у него диффы отображаются более корректно и наглядно, но для этого код нужно склонить. В целом это же можно сделать и в VS Code.

- мы также практикуем следующее: человек который создает PR, сам же его просматривает и оставляет комментарии в каких-то неочевидных местах. Зачем была обновлена/заменена либа, почему был создан такой-то метод, если есть похожий и тд. Благодаря таким комментам ревьюить огромные PR намного проще.

- а еще у меня есть парочка хром экстеншенов которые прям очень помогают в ревью да и в целом улучшают взаимодействие с гитхабом

Экстеншены в первом коменте...
Читать в ноушен: https://bit.ly/3p69ehk

#review #pr