#автоматизация #код_ревью
На небе только и разговоров, что о код-ревью...
Одна из вечных тем в кругу автоматизаторов-разработчиков - это код-ревью. Спорят о том, как, когда, как долго, кто... Но почти все сходятся на том, что ревьюить нужно.
Ответы на многие базовые вопросы по теме вы сможете найти в этом докладе: Код-ревью с уважением (Ангелина Купцова)
И буквально ещё несколько моментов добавлю от себя:
✔️ софт-часть
* не заставляй долго ждать твоего ревью:
- подай знак, если уже смотришь МР,
- сориентируй, сколько тебе понадобится времени,
- честно скажи, что не успеваешь, и в этот раз тебя лучше заменить (это правда ок)
* ревьюить нужно так, как если бы через месяц тебе пришлось дебажить этот код и пояснять за него (посвящается всем, кто дежурит по автотестам)
✅ хард-часть
* если что-то можно проверить линтером и/или поправить форматером, отдай это на откуп машине (а не жди от внимательного ревьюера)
* используй шаблон МРа в Гитлаб, чтобы добавить чек-лист/чит-лист для автора МРа с ключевыми моментами, которые стоит учесть в коде
* на чёртовы опечатки правда стоит обращать внимание (вспомнишь об этом, когда потребуется найти что-то в огромном новом для тебя репозитории)
* не оставляй "мёртвый код", "код на всякий случай" (если вдруг у вас в команде нет иной договорённости). Код есть документация, а документация должна быть актуальной
* понятные названия переменных, читабельный и красивый код, отсутствие магических чисел по-прежнему много значат
Ещё некоторое количество полезного по теме вы сможете найти в докладе "Записки код-ревьюера: мыслим выше, чем пробелы и табуляция" с недавнего Гейза (пока нет в общем доступе).
На небе только и разговоров, что о код-ревью...
Одна из вечных тем в кругу автоматизаторов-разработчиков - это код-ревью. Спорят о том, как, когда, как долго, кто... Но почти все сходятся на том, что ревьюить нужно.
Ответы на многие базовые вопросы по теме вы сможете найти в этом докладе: Код-ревью с уважением (Ангелина Купцова)
И буквально ещё несколько моментов добавлю от себя:
* не заставляй долго ждать твоего ревью:
- подай знак, если уже смотришь МР,
- сориентируй, сколько тебе понадобится времени,
- честно скажи, что не успеваешь, и в этот раз тебя лучше заменить (это правда ок)
* ревьюить нужно так, как если бы через месяц тебе пришлось дебажить этот код и пояснять за него (посвящается всем, кто дежурит по автотестам)
* если что-то можно проверить линтером и/или поправить форматером, отдай это на откуп машине (а не жди от внимательного ревьюера)
* используй шаблон МРа в Гитлаб, чтобы добавить чек-лист/чит-лист для автора МРа с ключевыми моментами, которые стоит учесть в коде
* на чёртовы опечатки правда стоит обращать внимание (вспомнишь об этом, когда потребуется найти что-то в огромном новом для тебя репозитории)
* не оставляй "мёртвый код", "код на всякий случай" (если вдруг у вас в команде нет иной договорённости). Код есть документация, а документация должна быть актуальной
* понятные названия переменных, читабельный и красивый код, отсутствие магических чисел по-прежнему много значат
Ещё некоторое количество полезного по теме вы сможете найти в докладе "Записки код-ревьюера: мыслим выше, чем пробелы и табуляция" с недавнего Гейза (пока нет в общем доступе).