Дисклеймер: статья написана лично мной и затем отредактирована с помощью нейросети — для исправления ошибок и улучшения стиля.
В процессе поиска работы я изучил множество вакансий, и в подавляющем большинстве среди обязательных требований значились знание паттернов проектирования, принципов SOLID и прочих «столпов» правильной архитектуры.
На собеседованиях меня нередко просили не просто рассказать о SOLID, а буквально расшифровать каждую букву и объяснить её смысл.
Всё это формирует у кандидата вполне логичное ожидание: раз требования такие высокие, значит и кодовая база у работодателя должна быть аккуратной, продуманной и соответствующей этим принципам. Однако в реальности это часто оказывается иллюзией.
На практике обычно встречаются две крайности.
Первая — полностью хаотичная архитектура, где каждый писал «как чувствовал», без единых договорённостей и понимания общей картины.
Вторая — не менее болезненная: кодовая база, перегруженная паттернами и абстракциями ради самих паттернов. Когда простая задача — например, прокинуть новое поле из пункта А в пункт Б — превращается в квест с правками десятка DTO, мапперов, интерфейсов и сервисов. А затем ещё приходится тратить час, чтобы понять, в каком именно месте ты забыл внести изменение и почему данные так и не добрались до нужной точки.
Ирония в том, что и в первом, и во втором случае страдает одно и то же — здравый смысл.
Со временем начинаешь задаваться вопросом: а существует ли она вообще вне презентаций и докладов на конференциях?
Идеальная «чистая архитектура» часто выглядит как красивая концепция, но в реальной жизни почти недостижима. Причина проста — бизнесу, по большому счёту, безразлично, насколько элегантно устроен код под капотом. Ему важно, чтобы конкретная фича была реализована в срок и приносила результат.
Бизнес редко готов ждать, пока команда доведёт архитектуру до абстрактного идеала или аккуратно встроит новую функциональность в заранее продуманную схему, если эта схема внезапно начинает трещать под требованиями рынка.
В итоге разработка почти всегда становится компромиссом между «как правильно» и «как успеть».
И вот в этом балансе, как ни странно, и проявляется настоящая инженерия — не в следовании догмам, а в умении принимать взвешенные решения в условиях ограничений.
А вам доводилось видеть ту самую легендарную «чистую архитектуру»?
Комментарии (21)
wl2776
03.03.2026 06:43После заголовка можно дальше не читать, там трюизмы типа "масло масляное, а вода водяная"
OlegZH
03.03.2026 06:43А могли бы привести примеры из своей практики?
wl2776
03.03.2026 06:43Примеры чего?
OlegZH
03.03.2026 06:43Вот, Вы написали код. Приходит некто, и код приходится дописывать/переписывать...
wl2776
03.03.2026 06:43Да, так бывает. И что?
Я не понимаю, что от меня требуется. Каких примеров Вы хотите?
К тому же, львиная доля моего кода написана в рамках NDA, и я не смогу рассказать подробностей.
OlegZH
03.03.2026 06:43Всегда есть возможность пустить в дело метафоры и аллегории.
P.S. Кстати. Это пресловутое NDA... Что это NDA защищает? Какой в этом смысл?
wl2776
03.03.2026 06:43Повторюсь, я не понимаю, что Вы от меня хотите.
Если рассказать, как я планировал архитектуру решения, а потом исправлял чужой говнокод из-за новых требований, то это будет эквивалентно написанию за автора нормальной статьи. Не хочу. Чтобы это была нормальная статья, а не набор баек в стиле "а вот у нас в деревне случай был...", надо много чего вспоминать, анализировать, обобщать, аналогии и метафоры придумывать. Короче, работать за бесплатно. Увольте. К тому же, уже есть немало книг по теме, если Вы действительно интересуетесь вопросом, поищите, почитайте.
OlegZH
03.03.2026 06:43И вот в этом балансе, как ни странно, и проявляется настоящая инженерия — не в следовании догмам, а в умении принимать взвешенные решения в условиях ограничений.
В том то и дело, что решения только выглядят взвешенными (работает же!). Но за это приходится расплачиваться позже, да и сама расплата растягивается на годы.
Если же говорить про само программирование, то, когда приходит требование реализовать новую "фичу", всегда возникает три следующих вопроса:
Можно ли было предусмотреть необходимость этой "фичи" в самом начале реализации проекта?
Можно ли было в самом начале реализации проекта сделать некую обобщённую библиотеку, чтобы с лёгкостью подключать новые "фичи"?
Можно ли было в самом начале реализации проекта дать клиенту генератор "фич", то есть — такое приложение, где клиент сам мог бы нарисовать нужный ему интерфейс?
Сейчас, конечно, имеется ИИ. Который. как говорят, заменит программистов. И он постоянно улучшается. Но и тут не ясно, что у него "под капотом" и какого качества код на выходе. Хотя, вопросы остаются те же самые.
kostjaden
03.03.2026 06:43Сроки ставят мечтатели. И вообще, кто на еом стоял. Работодатеои ищут терпил, которые за них будкт грязную рабтту за копецки делать, или они хотят развивать бизнес, привлекая свежую крлвь и ижеи. Тогда они нп о том мобеседуют, нужно ввбрасывать нафиг этих хантеров, от рих только вред (из-за некомпетентности в сфере оуенки квалификации, картонки нередко вреда больше приносят, или они дипломированные психиатры?))
Dhwtj
03.03.2026 06:43Автор:
Что бы сказать? Может, ничего не сказать, тогда бить не будут?
Будут! Обязательно будут! За потраченное время на чтение.
OlegZH
03.03.2026 06:43А почему бы не взглянуть на собственный опыт разработки и не проанализировать, что и как было сделано. И задать себе простой вопрос: можно ли было с самого начала действовать так, чтобы оптимальнее решить те же проблемы, которые пришлось решать трудно, затратно и разного рода "передрягами"?
OlegZH
03.03.2026 06:43А, вообще, хотелось бы промоделировать ситуацию.
Вот у нас есть некий программный код. Или, как говорят матёрые разработчики, кодовая база. Приходит клиент и говорит, что ему нужно что-то новое? С точки зрения мифической чистой архитектуры, тут ситуация такая — оно из двух: либо программный код изначально должен быть построен так, чтобы допускать минимальные добавления/исправления в существующей базе при поступлении новых требований (идеальный вариант — это создание нового компонента, который подключается к приложению штатными средствами), либо такой ситуации не должно быть в природе, ибо все такие привходящие требования вполне можно выявить и зафиксировать на бумаге ещё на этапе проектирования системы (ну, неужели, нельзя было догадаться, что такую "фичу" придётся делать!).
holgw
03.03.2026 06:43С точки зрения мифической чистой архитектуры, тут ситуация такая — оно из двух: либо программный код изначально должен быть построен так, чтобы допускать минимальные добавления/исправления в существующей базе при поступлении новых требований (идеальный вариант — это создание нового компонента, который подключается к приложению штатными средствами), либо такой ситуации не должно быть в природе
Сорян, но создается впечатление, что вы взяли какие-то внешние признаки Clean Code, добавили в них фанатизма и догматичности, и теперь боретесь с этим чудовищем, утверждая что это и есть Clean Code.
CrazyElf
03.03.2026 06:43Я вам больше скажу. Азбука и арифметика, которые вы проходили в школе - бесполезные вещи. Когда вы пишете код, за вас всё-равно IDE все описки поправит. Да и не на русском же языке код то. А на созвонах вас и так поймут, без правильно расставленных запятых и прочей грамматики. Ну и арифметику давно никто в уме не считает, есть же компьютеры. Так что я считаю, давно пора выкинуть всё это из обучения, да и школу саму отменить. Всё-равно даже те, кто этому всему учились, делают периодически ошибки, а значит ничего это не работает и не нужно вообще.
apevzner
03.03.2026 06:43При чём здесь вообще бизнес?
Не в силах человеческих для достаточно сложного проекта создать идеальную архитектуру, не написав ни строчки кода, а потом в коде эту архитектуру реализовать.
Как бы вы не старались, в процессе реализации вылезут нюансы, которые вы изначально не учли и в принципе не могли учесть, потому, что у вас не было достаточного понимания предметной области, не было достаточного опыта разработки именно этого проекта (даже если был опыт разработки похожих проектов) и т.п.
В любом случае, программный продукт делается итеративно. Ваша изначальная архитектура будет изменяться по мере разработки, даже если требования не менялись.
Это просто факт, к которому надо быть готовым. И, в частности, не рвать на себе волосы, когда выяснится, что изначальная архитектура, которая казалась такой удачной, тоже нуждается в доработке.
shadowphoenix
03.03.2026 06:43
С чистой архитектурой должен быть чистый код. А вот тут проблемы. Чистоту вводят и контролируют разные люди.Одно дело нарисовать три картинки с кубиками и совсем другое - отрефачить 1к файлов в "микро" сервисе.
Gromilo
В защиту чистой архитектуры и любой другой.
Да, есть проблемы. Бывают, забивают, бывает, следуют слишком фанатично, игнорируя здравый смысл.
Но архитектура, которую все знают — полезна. Она даёт начальную точку от которой можно начинать обсуждение. Она даёт ориентир, для тех, кто только погружается в проект. Готовая архитектура — общий язык, для тех кто хочет рассказать или понять как оно тут всё устроено.
Лучше пусть будет и все будут знать, чем не знать. А применять или нет и как применять — вопрос инженерного выбора.