Ответ
Соотношение зависит от проекта, фазы разработки и роли, но в среднем стремится к балансу, например, 60% кодинга и 40% ревью и смежной деятельности.
Фазы, где больше кодинга:
- Старт нового проекта или фичи: Активная фаза реализации, прототипирования.
- Исправление критических багов: Требует быстрого погружения и написания кода.
Фазы, где больше ревью и планирования:
- Стабилизация перед релизом: Фокус смещается на проверку пулл-реквестов (PR) коллег, поиск узких мест и рефакторинг.
- Планирование спринта/архитектуры: Обсуждение дизайна API, разбиение задач, оценка.
Ценность code review: Это не просто поиск опечаток, а ключевой процесс для:
- Передачи знаний: Младшие разработчики учатся у старших, и наоборот.
- Обнаружения архитектурных проблем: Раннее выявление нарушений принципов SOLID, проблем с производительностью или тестируемостью.
- Поддержания стиля кода: Единообразие кодовой базы.
Пример полезного комментария в ревью:
// Вместо комментария "тут можно лучше":
// Рассмотри возможность вынести эту проверку в отдельный метод.
// Сейчас она дублируется в методах ProcessOrder() и ValidateCart().
// Это улучшит поддерживаемость и упростит unit-тестирование логики проверки.
if (user.IsPremium && user.SubscriptionEnd > DateTime.UtcNow && order.Total > 1000) { ... }
// Предложение:
if (UserHasDiscountEligibility(user, order)) { ... }Эффективная команда понимает, что качественное ревью — это такая же важная инвестиция в продукт, как и написание нового кода.
Ответ 18+ 🔞
Давай я тебе на пальцах объясню, как это всё на самом деле работает, а то цифры эти средние — они как прогноз погоды: вроде красиво, а на деле хрен знает.
Вот смотри. Всё зависит от того, в каком дерьме проект сейчас плавает.
Когда ты просто пашешь как проклятый (больше кодинга):
- Только начали новую фичу или проект. Тут всё просто: задача есть, ты её ебешь. Сидишь, пишешь, прототипируешь, мозг кипит. Ревью? Какое нахуй ревью, у нас тут дедлайн вчера был!
- Вылез критический баг, продакшн горит. Тут уж не до философий. Все мозги в кучу, ищешь причину, пишешь костыль или фикс, выкатываешь. Потом уже, когда пожар потушат, будешь разбираться, кто насрал в код.
А вот когда начинается интересное (больше ревью и болтовни):
- Стабилизация перед релизом. О, это моя любимая пора. Новый код писать уже страшно, а делать что-то надо. Вот и сидишь, пялишься в пулл-реквесты коллег, ищешь, к чему бы придраться. "А тут, Васек, у тебя потенциальный нулл может быть, ёпта? А это что за магическое число? Вынеси в константу, а то потом ебнешься!" Фактически превращаешься в занудного надзирателя, и это, блядь, полезно.
- Планирование или переписывание старого говнокода. Тут вообще кода ноль. Сплошные разговоры: "А давайте вот тут сделаем так... А как это тестировать будем? А если нагрузка вырастет?" Сидишь, диаграммы рисуешь, как идиот.
А теперь про ценность ревью, потому что многие думают, что это просто придирки — "запятую забыл, мудак".
Это пиздеж. Настоящее ревью — это:
- Передача знаний, ебать. Младший смотрит, как старший пишет — учится. Старший смотрит код младшего — видит, какие новые подходы щас модные (или, наоборот, какой дикий костыль молодёжь умудряется придумать). Все в плюсе.
- Поимка архитектурного пиздеца. Один человек в азарте мог нагородить такую хуйню, что потом десять лет расхлёбывать. А свежий взгляд со стороны крикнет: "Стоять! А у нас тут, блядь, нарушение принципа единой ответственности! И завтра мы это тестировать не сможем!" Спасение проекта, в общем.
- Поддержание порядка в казарме. Чтобы код выглядел так, будто его один человек писал, а не сборище мартышлюшек с разными тараканами в голове.
Вот, например, как выглядит нормальный комментарий в ревью, а не просто "фигня":
// Вместо того чтобы написать "код говно" (хотя он и есть):
// Слушай, эта проверка на скидку у тебя тут и в ValidateCart() скопипащена один в один.
// Представь, завтра поменяются условия — и ты будешь бегать, как угорелый, исправлять в десяти местах.
// Давай вынесем её в отдельный метод, типа UserHasDiscountEligibility(). И тестить удобнее, и дублирования не будет.
if (user.IsPremium && user.SubscriptionEnd > DateTime.UtcNow && order.Total > 1000) { ... }
// Будет просто и красиво:
if (UserHasDiscountEligibility(user, order)) { ... }Короче, эффективная команда понимает простую вещь: качественное ревью — это не потеря времени, а страховка от будущего пиздеца. Это такая же инвестиция, как и написание кода, просто отдача не сразу видна. Пока не наступишь на грабли, конечно.