TG Telegram Group & Channel
Short QA ideas | United States America (US)
Create: Update:

#автоматизация #код_ревью
На небе только и разговоров, что о код-ревью...

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

Ответы на многие базовые вопросы по теме вы сможете найти в этом докладе: Код-ревью с уважением (Ангелина Купцова)

И буквально ещё несколько моментов добавлю от себя:

✔️софт-часть

* не заставляй долго ждать твоего ревью:
- подай знак, если уже смотришь МР,
- сориентируй, сколько тебе понадобится времени,
- честно скажи, что не успеваешь, и в этот раз тебя лучше заменить (это правда ок)

* ревьюить нужно так, как если бы через месяц тебе пришлось дебажить этот код и пояснять за него (посвящается всем, кто дежурит по автотестам)


хард-часть

* если что-то можно проверить линтером и/или поправить форматером, отдай это на откуп машине (а не жди от внимательного ревьюера)

* используй шаблон МРа в Гитлаб, чтобы добавить чек-лист/чит-лист для автора МРа с ключевыми моментами, которые стоит учесть в коде

* на чёртовы опечатки правда стоит обращать внимание (вспомнишь об этом, когда потребуется найти что-то в огромном новом для тебя репозитории)

* не оставляй "мёртвый код", "код на всякий случай" (если вдруг у вас в команде нет иной договорённости). Код есть документация, а документация должна быть актуальной

* понятные названия переменных, читабельный и красивый код, отсутствие магических чисел по-прежнему много значат


Ещё некоторое количество полезного по теме вы сможете найти в докладе "Записки код-ревьюера: мыслим выше, чем пробелы и табуляция" с недавнего Гейза (пока нет в общем доступе).

#автоматизация #код_ревью
На небе только и разговоров, что о код-ревью...

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

Ответы на многие базовые вопросы по теме вы сможете найти в этом докладе: Код-ревью с уважением (Ангелина Купцова)

И буквально ещё несколько моментов добавлю от себя:

✔️софт-часть

* не заставляй долго ждать твоего ревью:
- подай знак, если уже смотришь МР,
- сориентируй, сколько тебе понадобится времени,
- честно скажи, что не успеваешь, и в этот раз тебя лучше заменить (это правда ок)

* ревьюить нужно так, как если бы через месяц тебе пришлось дебажить этот код и пояснять за него (посвящается всем, кто дежурит по автотестам)


хард-часть

* если что-то можно проверить линтером и/или поправить форматером, отдай это на откуп машине (а не жди от внимательного ревьюера)

* используй шаблон МРа в Гитлаб, чтобы добавить чек-лист/чит-лист для автора МРа с ключевыми моментами, которые стоит учесть в коде

* на чёртовы опечатки правда стоит обращать внимание (вспомнишь об этом, когда потребуется найти что-то в огромном новом для тебя репозитории)

* не оставляй "мёртвый код", "код на всякий случай" (если вдруг у вас в команде нет иной договорённости). Код есть документация, а документация должна быть актуальной

* понятные названия переменных, читабельный и красивый код, отсутствие магических чисел по-прежнему много значат


Ещё некоторое количество полезного по теме вы сможете найти в докладе "Записки код-ревьюера: мыслим выше, чем пробелы и табуляция" с недавнего Гейза (пока нет в общем доступе).
Please open Telegram to view this post
VIEW IN TELEGRAM


>>Click here to continue<<

Short QA ideas




Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)