А что такое это ваш «хороший код»?

Чтобы агенты выдавали «хороший код», критерии хорошести нужно сформулировать и выписать на бумажку (внезапно)

Звучит просто, но спросите трёх разработчиков и получите три разных ответа. И на поверку окажется, что большинство будет бездумно называть какие-то фреймворки, паттерны и аббревиатуры. Но это не критерии. Это способы обеспечить свойства, которыми должен обладать софт

Так какими же свойствами обладает хороший код? 1. Дёшево расширять. Средний разработчик разбирается без боли, вносит изменение, чинит баг. Для этого: понятная структура, доменная семантика в названиях, единая ответственность, комментарии отвечают «зачем», а не «что», низкая когнитивная сложность. 2. Легко эксплуатировать. Ошибки не проглатываются: ожидаемые исключения нормализуются, остальные отправляются в Sentry 3. Просто отлаживать. Можно запустить в разных конфигурациях, подменить провайдеры, воспроизвести состояние и ошибку, заглянуть в кишки 4. Удобно тестировать. У модулей чёткие границы и контракты, зависимости ослаблены через интерфейсы и фасады. Каждый модуль тестируется изолированно, внешние зависимости легко мокируются. Есть пирамида тестов, тулинг и правила покрытия

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

А что на самом деле определяет требования к коду, так это ответ на вопрос: "Что это за проект и какие вызовы его ждут?" • Лендинг для регистрации на мероприятие? Его выкинут сразу после? Пишите хоть ногами, лишь бы не весил тонну и работала регистрация. Каждый час, вложенный в архитектуру, тут потерян. • Нагруженный сервис? Он станет центральной шиной для оформления заказов в крупнейшем маркетплейсе страны? Упарываемся в надёжность и масштабируемость, даже если каждая фича будет стоить втрое дороже. Час простоя исчисляется многомиллионными потерями, а нестабильность за пару месяцев уведёт аудиторию к конкуренту. • Прошивка марсохода? Он полетит на другую планету, где нельзя подойти и передёрнуть питание? Откажемся от половины конструкций языка и будем дублировать системы. Любой отказ или ошибка вычисления из-за высокоэнергетического излучения превращает его в очень дорогой кирпич.

Три проекта, три разных «хороших кода». Список свойств один и тот же, разные только веса. И расставляет их не вкус разработчика, а будущее проекта

Именно это мы и должны сделать: разобраться, что за проект и какое будущее его ждёт, и из этого вывести архитектурные требования. А дальше запустить туда агентов, кожаных или ИИ-шных, уже не важно. Агенты тут ничего не изменили, они лишь заставили выписать то, что раньше жило в голове у сеньора

А какие требования к архитектуре и коду вы выдвигаете агентам у себя в проектах?