Эффективное код ревью
и как сделать его лучше.

Практика код ревью используется на многих проектах, потому что это:
1. Обмен знаниями о проекте и технологиях внутри команды.
2. Повышение качество кода.
3. Способ найти оптимальное решение задачи.

В слаженных командах с утверждённым кодстайлом и схожим бэкграундом код ревью действительно даёт эти преимущества. А вот для новичка или в молодых командах код ревью часто приводит к конфликтам и непониманию.

Каждый проект уникален, но общие правила выглядят так:
1. Время автора кода и ревьюеров — ценный ресурс.
2. Код — это инструмент решение задачи, а не отражение личности разработчика.
3. Замечания должны быть конструктивны и понятны.

На верхнем уровне это все понимают, но чтобы на практике увеличить прозрачность и эффективность этого процесса, нужно обсудить и чётко обозначить:
1. Время, в течение которого ревьюеры обязаны посмотреть код.
2. Код-стайл команды — обычно в виде файла для настройки форматирования IDE
3. Приоритеты при решении задачи:
- производительность (высоконагруженные системы),
- чистота кода (open-source проекты),
- лёгкость понимания (проекты с большим количеством разработчиков),
- простота модификации (стартапы)
и тд.
4. Действия при разногласиях - чаще всего это предоставить решение третьей стороне конфликта

2 часа обсуждать имя переменной - это трата времени. Не надо так.

#soft_skills