Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 19
В защиту чистой архитектуры и любой другой.
Да, есть проблемы. Бывают, забивают, бывает, следуют слишком фанатично, игнорируя здравый смысл.
Но архитектура, которую все знают — полезна. Она даёт начальную точку от которой можно начинать обсуждение. Она даёт ориентир, для тех, кто только погружается в проект. Готовая архитектура — общий язык, для тех кто хочет рассказать или понять как оно тут всё устроено.
Лучше пусть будет и все будут знать, чем не знать. А применять или нет и как применять — вопрос инженерного выбора.
После заголовка можно дальше не читать, там трюизмы типа "масло масляное, а вода водяная"
А могли бы привести примеры из своей практики?
Примеры чего?
Вот, Вы написали код. Приходит некто, и код приходится дописывать/переписывать...
Да, так бывает. И что?
Я не понимаю, что от меня требуется. Каких примеров Вы хотите?
К тому же, львиная доля моего кода написана в рамках NDA, и я не смогу рассказать подробностей.
Всегда есть возможность пустить в дело метафоры и аллегории.
P.S. Кстати. Это пресловутое NDA... Что это NDA защищает? Какой в этом смысл?
Повторюсь, я не понимаю, что Вы от меня хотите.
Если рассказать, как я планировал архитектуру решения, а потом исправлял чужой говнокод из-за новых требований, то это будет эквивалентно написанию за автора нормальной статьи. Не хочу. Чтобы это была нормальная статья, а не набор баек в стиле "а вот у нас в деревне случай был...", надо много чего вспоминать, анализировать, обобщать, аналогии и метафоры придумывать. Короче, работать за бесплатно. Увольте. К тому же, уже есть немало книг по теме, если Вы действительно интересуетесь вопросом, поищите, почитайте.
И вот в этом балансе, как ни странно, и проявляется настоящая инженерия — не в следовании догмам, а в умении принимать взвешенные решения в условиях ограничений.
В том то и дело, что решения только выглядят взвешенными (работает же!). Но за это приходится расплачиваться позже, да и сама расплата растягивается на годы.
Если же говорить про само программирование, то, когда приходит требование реализовать новую "фичу", всегда возникает три следующих вопроса:
Можно ли было предусмотреть необходимость этой "фичи" в самом начале реализации проекта?
Можно ли было в самом начале реализации проекта сделать некую обобщённую библиотеку, чтобы с лёгкостью подключать новые "фичи"?
Можно ли было в самом начале реализации проекта дать клиенту генератор "фич", то есть — такое приложение, где клиент сам мог бы нарисовать нужный ему интерфейс?
Сейчас, конечно, имеется ИИ. Который. как говорят, заменит программистов. И он постоянно улучшается. Но и тут не ясно, что у него "под капотом" и какого качества код на выходе. Хотя, вопросы остаются те же самые.
Сроки ставят мечтатели. И вообще, кто на еом стоял. Работодатеои ищут терпил, которые за них будкт грязную рабтту за копецки делать, или они хотят развивать бизнес, привлекая свежую крлвь и ижеи. Тогда они нп о том мобеседуют, нужно ввбрасывать нафиг этих хантеров, от рих только вред (из-за некомпетентности в сфере оуенки квалификации, картонки нередко вреда больше приносят, или они дипломированные психиатры?))
Автор:
Что бы сказать? Может, ничего не сказать, тогда бить не будут?
Будут! Обязательно будут! За потраченное время на чтение.
А, вообще, хотелось бы промоделировать ситуацию.
Вот у нас есть некий программный код. Или, как говорят матёрые разработчики, кодовая база. Приходит клиент и говорит, что ему нужно что-то новое? С точки зрения мифической чистой архитектуры, тут ситуация такая — оно из двух: либо программный код изначально должен быть построен так, чтобы допускать минимальные добавления/исправления в существующей базе при поступлении новых требований (идеальный вариант — это создание нового компонента, который подключается к приложению штатными средствами), либо такой ситуации не должно быть в природе, ибо все такие привходящие требования вполне можно выявить и зафиксировать на бумаге ещё на этапе проектирования системы (ну, неужели, нельзя было догадаться, что такую "фичу" придётся делать!).
С точки зрения мифической чистой архитектуры, тут ситуация такая — оно из двух: либо программный код изначально должен быть построен так, чтобы допускать минимальные добавления/исправления в существующей базе при поступлении новых требований (идеальный вариант — это создание нового компонента, который подключается к приложению штатными средствами), либо такой ситуации не должно быть в природе
Сорян, но создается впечатление, что вы взяли какие-то внешние признаки Clean Code, добавили в них фанатизма и догматичности, и теперь боретесь с этим чудовищем, утверждая что это и есть Clean Code.
Я вам больше скажу. Азбука и арифметика, которые вы проходили в школе - бесполезные вещи. Когда вы пишете код, за вас всё-равно IDE все описки поправит. Да и не на русском же языке код то. А на созвонах вас и так поймут, без правильно расставленных запятых и прочей грамматики. Ну и арифметику давно никто в уме не считает, есть же компьютеры. Так что я считаю, давно пора выкинуть всё это из обучения, да и школу саму отменить. Всё-равно даже те, кто этому всему учились, делают периодически ошибки, а значит ничего это не работает и не нужно вообще.
При чём здесь вообще бизнес?
Не в силах человеческих для достаточно сложного проекта создать идеальную архитектуру, не написав ни строчки кода, а потом в коде эту архитектуру реализовать.
Как бы вы не старались, в процессе реализации вылезут нюансы, которые вы изначально не учли и в принципе не могли учесть, потому, что у вас не было достаточного понимания предметной области, не было достаточного опыта разработки именно этого проекта (даже если был опыт разработки похожих проектов) и т.п.
В любом случае, программный продукт делается итеративно. Ваша изначальная архитектура будет изменяться по мере разработки, даже если требования не менялись.
Это просто факт, к которому надо быть готовым. И, в частности, не рвать на себе волосы, когда выяснится, что изначальная архитектура, которая казалась такой удачной, тоже нуждается в доработке.
Что то я надеялся после заголовка на какую то более информативную статью
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чистая архитектура — красивая сказка для собеседований