#вопросответ Как ускорить код ревью?
В чате задали интересный вопрос: Проводил код ревью в своей команде. Приходилось смотреть множество модулей на NestJS. Но занимает много времени. Есть какой-то способ проводить ревью с меньшими затратами по времени?
Вот пара советов, как сократить время на код ревью:
- Lint – все вопросы по стилю кода, форматированию и прочему должны однозначно закрываться линтерами. При этом проверка lint должна возникать перед PR в pipeline CI/CD, чтобы PR, которые не прошёл все проверки по стилям, не доходил до ревью.
- Стиль кода – нужно создать документ, который будет описывать все соглашения, не покрывающиеся линтером. Как называть переменные? Сколько максимум аргументов у функции? (часть из этого можно всё-равно покрыть линтерами). При возникновении ошибки на код ревью вы просто оставляете ссылку на документы и всё.
- Тесты – позволяют детально не проверять, что бизнес логика не сломалась. При этом PR должен быть покрыт тестами с определённым порогом coverage. Если он не достигается, то снова нельзя поставить PR.
- Чек-лист – в сообщение PR добавляется чек-лист, который нужно пройти, чтобы убедиться, что всё готово для ревью: поправлена документация, сделаны все нужные изменения в dev среде и так далее.
- Предварительное обсуждение архитектуры – чтобы после окончания задачи не было бы ситуаций, в которых нужно переписать всё, так как архитектурно сделано на так как принято или подразумевалось, нужно перед стартом потратить 5-10 минут на совместное обсуждение архитектуры будущего решения.
- Разборы код ревью – 1 раз в неделю / две, нужно собираться с командой и обсуждать самые частые ошибки и разбирать примеры код ревью. Это позволит всем оставаться на одной волне и не повторять ошибок.
Это конечно идеальный случай, но если вы внедрите хотя бы часть этих советов, то процесс код ревью станет для вас более простым.
В чате задали интересный вопрос: Проводил код ревью в своей команде. Приходилось смотреть множество модулей на NestJS. Но занимает много времени. Есть какой-то способ проводить ревью с меньшими затратами по времени?
Вот пара советов, как сократить время на код ревью:
- Lint – все вопросы по стилю кода, форматированию и прочему должны однозначно закрываться линтерами. При этом проверка lint должна возникать перед PR в pipeline CI/CD, чтобы PR, которые не прошёл все проверки по стилям, не доходил до ревью.
- Стиль кода – нужно создать документ, который будет описывать все соглашения, не покрывающиеся линтером. Как называть переменные? Сколько максимум аргументов у функции? (часть из этого можно всё-равно покрыть линтерами). При возникновении ошибки на код ревью вы просто оставляете ссылку на документы и всё.
- Тесты – позволяют детально не проверять, что бизнес логика не сломалась. При этом PR должен быть покрыт тестами с определённым порогом coverage. Если он не достигается, то снова нельзя поставить PR.
- Чек-лист – в сообщение PR добавляется чек-лист, который нужно пройти, чтобы убедиться, что всё готово для ревью: поправлена документация, сделаны все нужные изменения в dev среде и так далее.
- Предварительное обсуждение архитектуры – чтобы после окончания задачи не было бы ситуаций, в которых нужно переписать всё, так как архитектурно сделано на так как принято или подразумевалось, нужно перед стартом потратить 5-10 минут на совместное обсуждение архитектуры будущего решения.
- Разборы код ревью – 1 раз в неделю / две, нужно собираться с командой и обсуждать самые частые ошибки и разбирать примеры код ревью. Это позволит всем оставаться на одной волне и не повторять ошибок.
Это конечно идеальный случай, но если вы внедрите хотя бы часть этих советов, то процесс код ревью станет для вас более простым.