Больше кодишь или ревьюишь на работе?

Соотношение зависит от проекта, фазы разработки и роли, но в среднем стремится к балансу, например, 60% кодинга и 40% ревью и смежной деятельности.

Фазы, где больше кодинга:

• Старт нового проекта или фичи: Активная фаза реализации, прототипирования.
• Исправление критических багов: Требует быстрого погружения и написания кода.

Фазы, где больше ревью и планирования:

• Стабилизация перед релизом: Фокус смещается на проверку пулл-реквестов (PR) коллег, поиск узких мест и рефакторинг.
• Планирование спринта/архитектуры: Обсуждение дизайна API, разбиение задач, оценка.

Ценность code review: Это не просто поиск опечаток, а ключевой процесс для:

1. Передачи знаний: Младшие разработчики учатся у старших, и наоборот.
2. Обнаружения архитектурных проблем: Раннее выявление нарушений принципов SOLID, проблем с производительностью или тестируемостью.
3. Поддержания стиля кода: Единообразие кодовой базы.

Пример полезного комментария в ревью:

// Вместо комментария "тут можно лучше":
// Рассмотри возможность вынести эту проверку в отдельный метод.
// Сейчас она дублируется в методах ProcessOrder() и ValidateCart().
// Это улучшит поддерживаемость и упростит unit-тестирование логики проверки.
if (user.IsPremium && user.SubscriptionEnd > DateTime.UtcNow && order.Total > 1000) { ... }
// Предложение:
if (UserHasDiscountEligibility(user, order)) { ... }

Эффективная команда понимает, что качественное ревью — это такая же важная инвестиция в продукт, как и написание нового кода.