В агентскую эпоху не все архитектуры кода одинаково полезны

[panzerfaust]

Ниже проанализированы различные архитектуры кода — TDD (разработка через тестирование), OOP (объектно-ориентированное программирование, ООП), FP (функциональное программирование, ФП), MVC (модель-представление-контроллер), MVVM (модель-представление-модель представления), микросервисы, событийно-ориентированная архитектура, CQRS (раздельная обработка команд и запросов), гексагональная архитектура, разработка через поведение (BDD), предметно-ориентированное проектирование (DDD)

Как говорится, и эти люди запрещают мне ковыряться в носу. Типичный уровень ИИ-визионера. В голове каша такая, что ложка стоит, - зато профессор всех наук.

[sibirier]

Ниже проанализированы различные архитектуры кода — TDD (разработка через тестирование), OOP (объектно-ориентированное программирование, ООП), FP (функциональное программирование, ФП), MVC (модель-представление-контроллер), MVVM (модель-представление-модель представления), микросервисы, событийно-ориентированная архитектура, CQRS (раздельная обработка команд и запросов), гексагональная архитектура, разработка через поведение (BDD), предметно-ориентированное проектирование (DDD). Они отсортированы по показателю прикладной полезности в условиях, когда программирует не человек, а агент.

Спасибо, что подвох сразу в начале статьи - сэкономили время (вижу, что перевод; но дальнейший текст всё ещё применим - почему-то же эта "статья" прошла ценз автора публикации).
TDD, DDD, OOP и MVC (например) - понятия из разных категорий и их спокойно можно использовать в одном проекте на одном участке кода.
Судя по тому, что про эти понятия продолжаются какие-либо сравнения (то есть прикладывают одну "линейку"), ценза качества (хоть сколько-то разобраться в вопросе, для начала) не было ни у автора-человека, ни у нейросети, которая это генерировала.

Короткая (необязательно точная) справка:
TDD - методология процесса разработки, при котором проверка качества реализации (и в целом "уже готово или ещё делать") производится автотестами сразу. Это добавляет некоторые бонусы в стиль кода: контракты функций становятся более специализированными (чтобы тесты не превращались в месиво), раньше всплывают признаки антипаттернов (god object, например, когда попарных тестов - несколько десятков на один объект). И как можно раньше обнаруживаются ошибки. Ещё и требования к программистам тоже выше, что в целом повышает культуру разработки и эффективность работы.

DDD - это о том, какую ментальную модель выбрать/сконструировать, чтобы было проще и реализовать в коде, и представить пользователям, и приоритизировать важность свойств, чтобы более критичным обеспечились более надёжные условия существования во времени. Это даже больше философия с практическими применениями, нежели что-то про непосредственно про код изначально.
Из бонусов: когда модель подобрана, на её основе можно сделать шаблоны и прописать строгие ограничения, которые и дадут те границы модулей, в рамках которых уже проще думать. Тут идея (как я понимаю) в том, чтобы максимально упростить (для понимания, но и сложность как таковую) контракт домена, чтобы уменьшить его сложность и уменьшить вероятность ошибок, особенно неявных/скрытых.

OOP - про полиморфизм и изоляцию реализации от потребителя (не перекладывать часть контракта/сложности на потребителя) на уровне объектов. Тоже для простоты работы с объектами/структурами/данными - "объект отвечает за себя сам". Поэтому их рекомендуют делать как можно более специфичными - чтобы не терять контроль за поведением, требуя от внешних условий (относительно объекта) подстраиваться под него. То есть это о том, что "если есть интерфейс на входе функции, то я могу послать туда любой подходящий объект и я буду знать как он работает и что сделает".
Хотя тут сложная тема. OOP очень обширен, чтобы вот так легко его было сократить удачно. Но это не архитектура (чертёж завода), а способ крепежа кирпичей и балок друг с другом. Что, несомненно, между собой соприкасается (влияет друг на друга), но это точно не одна категория понятий.

MVC - техника контроля фокуса внимания между объектами и, как следствие, сложности (трудоёмкости, с учётом переделок/доделок) реализации. Ну и полиморфизм там рядом тоже несложно встраивается.

Архитектура в любом случае будет какая-то. И задача подбора нужных практик в том, чтобы она давала наибольшие плюшки. И большинство из них, кмк, про контроль сложности (чтобы люди допускали меньше ошибок, меньше порог входа, шире набор людей, которые могут решить проблему; ну и производительность в простом коде тоже проще прибавить) во времени. Что достигается практиками в разных слоях и разных углах обзора. Но сравнивать их как одинаковые - нельзя.
Пример: и дорога влияет на качество жизни, и отопление. Но ставить вопрос "дорога лучше, чем отопление" - весьма сомнительно, хоть и "ну это же оба про качество жизни".

Реализовать что-то сложное и работающее в принципе - возможно и без особо умных техник. Но сделать это расширяемым, ремонтопригодным, надёжным и переиспользуемым - сложно. Но эта сложность - для людей; у которых ограничен контекст и фокус внимания. У машин он, по идее, больше, но сложность/многосоставность/многоконтекстуальность мыслей у них ниже/нулевая, из-за чего "ИИ" лишь подкидывают очередную "головоломку" (впихнуть в него цель "сделать читаемость для людей, но скорость реализации как у машины; а ещё под капотом будет обучаемая вероятностная модель, но требовать от неё будем реализации строгих правил; чтобы и результат был стабилен во времени), а не закрывают класс проблем.

Отсюда и рассуждения вида "что лучше подходит для написания инструкции к колбасе: амфибрахий или гипербола" - нелепы в своей изначальной идее и в попытке сравнивать несравниваемое (хоть и одинаково применимы к текстам и идее "ну это же всё про текст и про людей, а значит можно сранивать"). Да, и гиперборла, и MVC, и рифмы, и статистика встречаемости букв - это всё про тексты, понимаемость людьми, про усвоение информации. Но это же не значит, что их вот так уравнивать и сравнивать можно. У них у всех разные задачи (или нет?).

[akardapolov]

Ниже проанализированы различные архитектуры кода — TDD (разработка через тестирование), OOP (объектно-ориентированное программирование, ООП), FP (функциональное программирование, ФП), MVC (модель-представление-контроллер), MVVM (модель-представление-модель представления), микросервисы, событийно-ориентированная архитектура, CQRS (раздельная обработка команд и запросов), гексагональная архитектура, разработка через поведение (BDD), предметно-ориентированное проектирование (DDD).

Точнее такое разделение, КМВ

Software Engineering Atlas

[Ra2007]

Полгода в продакшене с Claude Code, и главная боль именно здесь. Агент понимает что написано, но зачем принято конкретное решение, не видит совсем. Тесты зелёные, код компилируется, а архитектурное намерение растворилось. Нас выручил CLAUDE.md на уровне каждого модуля, туда писали не документацию, а буквально запреты: вот это нельзя вынести наружу, вот это нельзя обобщить, потому что тут бизнес-инвариант. По TDD согласен, это реально единственная честная обратная связь для агента, красный или зелёный, без интерпретации. Ещё от себя: DDD с чёткими bounded contexts работает лучше чем ожидал, агент редко лезет за границы контекста если они явно прописаны.

[nin-jin]

Так и не понял, почему статья не размещена в хабе $mol.

[nin-jin]

Для товарища, со смертью мозга не выкупившего мета-иронию: https://habr.com/ru/articles/1033462/#comment_29952206

[mvv-rus]

Ваша метаирония рассчитана на тех, кто читает хаб $mol. Ну, или на тех, кто читает статьи по поп-физике.
А я вот в их число не вхожу, поскольку я – задовик по специализации (т.е. $mol мне не интересен), а ещё – физик по образованию (и меня ещё в нашем физкультурном техникуме г.Долгопрудного МО научили, что сколько поле не квантуй, всё равно получишь поле). Потому метоирония ваша меня не затронула.

PS Минус к вашим комментариям, правда, я так и не поставил: за первый комментраий там не за что, а за второй, за смерть мозга - поленился: кто то уже успел до меня.