⚡️ Хаос в проекте начинается задолго до плохого кода Когда над продуктом работает большая команда и фичи летят параллельно, качество кода перестаёт быть личной ответственностью. Оно становится вопросом процессов. Ревью лечит симптомы. Архитектурные договорённости убирают причину болезни. Но без регулярных осмотров даже здоровый организм начинает сбоить. Таким образом, ревью помогает ловить баги и спорные решения, но всегда после того, как код уже написан. Договорённости про архитектуру, наоборот, снимают проблемы заранее. Правда, без постоянного контроля они постепенно размываются. Можно ли сильным ревью компенсировать отсутствие договорённостей? Частично. Но тогда каждое обсуждение превращается в пересборку архитектуры на уровне отдельного PR. Это дорого и нестабильно. Можно ли архитектурой компенсировать слабое ревью? Тоже лишь на старте. Без постоянной проверки рамка постепенно размывается, и это особенно видно в масштабе. ▶️ В Альфе мы фиксируем архитектурные решения до начала разработки, а на ревью проверяем не только качество кода, но и попадание в эти решения. Если что-то выходит за границы, обсуждаем не конкретный PR, а саму договорённость. Это позволяет держать систему управляемой даже на масштабе десятков команд. Где, по вашему опыту, происходит первый сбой, когда проект начинает деградировать ❓