Комментарии 30
А архитектура всегда важна в отличие от поведения, поэтому она более приоритетна.
Что, простите?
'вот Вам почтовый клиент, писем отправлять нельзя, зато архитектура — огонь!'
Сейчас ситуация такова, что важнее не повторять старые мантры о том как мы все сделаем грамотно по книгам (а по факту все-равно «все переписывать» каждые 2-3 года), а стремиться гибко и осознанно подходить и к фичас и к архитектуре.
Сейчас ситуация такова, что важнее не повторять старые мантры о том как мы все сделаем грамотно по книгам (а по факту все-равно «все переписывать» каждые 2-3 года), а стремиться гибко и осознанно подходить и к фичас и к архитектуре.
Насколько я могу судить, что сейчас принцип разработки, все больше склоняется х-х и в продакшен. По крайней мере в бекенде веба. О другом говорить мне сложно.
Недавно общался с коллегой из Европы с которым собираюсь сотрудничать. Когда зашел вопрос об архитектуре и инструментах, тут меня конечно немного удивило, что смысла пилить качественный код нет. Куда выгоднее, с материальной точки зрения, сделать быстро трэш и потом его долго и нудно допиливать.
Я не беру во внимание сейчас enterprise сегмент. Хотя возможно там картина не лучше.
Все так. Зп разработчиков таковы, что это давит на экономику компаний поэтому да х-х ив продакшн.
Но! Вот тут и проявляется настоящее мастерство, когда:
1) совместно с бизнесом делите всю систему на части с разной степенью критичности ошибок.
2) критические части делаете тщательно и без суеты с кучей тестов и qa в несколько слоев
3) некритичные — хх, максимально частый деплой, максимально дешёвая архитектура: лишние обобщения скорее вредны. Изменилась предметная область? Не жалко выкинуть и снова сделать быстро. Опирается на ядро из п 2.
Это позволяет и двигаться быстрее и экономить бюджет и явно управлять качеством, а если баг -сорян, у нас лапки, за счёт частого деплояпопрпвим и выложим через 30 минут
Сразу говорю, пишу только то, что виду из своей песочницы и чуть-чуть за ней.
Мне сдается, все сдвинулось в сторону продажи не продукта, а сервисов. Второй момент это даже не доход, а оборот компании. Чем красивее цифирки в отчетах — тем лучше. По этому, бизнесу глубоко пофиг на код. Если в этом году циферки красивее — значит все ок. Если нет, то будет применять все известные инструменты для того, чтоб улучшить циферки в отчетах. Если дешевле закрыть контору, то так и будет.
Более страшный график – это возрастание стоимости одной строки кода в ~40 раз. Т.е. продуктивность упала со 100% практически до нуля. Программисты работают усердно во всю силу, но по сути ничего не могут сделать.На правах сарказма:
Это хорошо что они еще оптимизировать и избавляться от лишних строк не начали!
Но программисты должны считать наоборот, что важнее архитектура.
«Программист» тут слишком широкое понятие.
Это в идеальных представлениях, если за архитектуру программисту платят.
Архитектура важнее для архитектора ПО, для обычного программиста же зачастую это не его область деятельности.
Программист должен бороться за архитектуру. Программист – это тоже участник бизнеса. Архитектура – это его ответственность.
Архитектура должна быть ответственностью все же архитектора. Программист — «участник бизнеса» лишь формально, в большинстве случаев это наемное лицо.
Прежде чем «бороться за архитектуру» следует согласовать это с менеджментом, поскольку «борьба за архитектуру» требует отдельных усилий, это иной класс в разработке.
Не забываем об этом.
А также не забываем о том, что у товарищей типа Robert C. Martin свои специфические интересы и взгляд по-своему специфично деформирован.
Также, все сильно зависит от сегмента ПО и от проекта.
Архитектура важнее для архитектора ПО, для обычного программиста же зачастую это не его область деятельности.
Понимать и соблюдать архитектуру должны как раз обычные программисты. Архитектор отвечает за создание и развитие архитектуры, а ревьювить все PR на предмет не обратился ли кто-то из компонента A в компонент B напрямую (что запрещено архитектурой) ни у какого архитектора времени не хватит физически.
Но Вы правы в том, что многие программисты не хотят об этом думать, их устроит любой рабочий вариант реализации фичи, вне зависимости от того, насколько он соответствует требованиям архитектуры. Что характерно, не соответствующий нередко написать проще и быстрее, так что…
Именно по этой причине выстрелила микросервисная архитектура: не смотря на все дополнительные проблемы и накладные расходы связанные с сетевым I/O между компонентами приложения и усложнение деплоя у неё есть киллер-фича — программисты физически не могут нарушить архитектуру (а, точнее, нарушать становится намного дольше и дороже, т.к. требуется вносить странные изменения в API "чужих" сервисов, что требует дополнительной коммуникации с их разработчиками… в общем, становится проще писать используя доступный API, т.е. в рамках ограничений наложенных текущей архитектурой).
Никто не мешает обратиться в нарушение архтектуры сразу к сервису А
Мешает отсутствие нужного API или данных, необходимых для вызова этого API. В этом суть архитектуры в случае микросервисов — не надо проектировать API так, чтобы появилась возможность нарушить архитектуру штатными вызовами API. Если такая возможность есть — значит архитектор облажался, не более того.
Ну, например, в приложении (допустим, не клиент-сервер, а обычное локальное на sqlite) в обработке OnClick я не должен обращаться к DAL в обход слоя логики. Но никто, кроме review, не запрещает взять и подключить/использовать ту зависимость, которую использует слой логики.
Аналогично с микросервисами: если договорились, что сервис Б обязан быть фронтом для сервиса А и кешировать его ответы, разработчику может быть лениво создавать в Б загрузку/кеширование некоторой новой сущности и он напрямую залезет за ней в сервис А.
В этой ситуации все сервисы кроме Б просто не должны знать endpoint сервиса A либо не должны иметь токен дающий доступ к A. Но лично я бы просто не разделял A и Б на два сервиса, если всё-равно все обязаны обращаться к A только через Б.
В этой ситуации все сервисы кроме Б просто не должны знать endpoint сервиса A
Это всё хорошо, когда сервисов 3-4, а когда их в проекте 50? Получается примерно то же самое, как с подключением библиотек: все разработчики могут подключать зависимости, а за правомерностью подключений кто-то должен следить.
Да нет же, следить надо не за правомерностью подключений, а за тем, к чему возможно подключаться в принципе — т.е. за API. Не надо выставлять в API одного из этих 50 сервисов то, чем какой-то из оставшихся 49 сервисов может воспользоваться неправильным способом (т.е. так, чтобы поломать кого-то помимо самого себя).
Вот по архитектуре новый модуль должен идти в сервис Б, который обращается к сервису А в свою очередь. Вместо этого там скопипащен кусок сервиса Б и в новом модуле появляется прямое обращение к А (через те API, которые должен был использовать Б).
В микросервисной архитектуре нет никаких слоёв. Если сервис А выставил наружу некоторое API, то это значит, что любой сервис имеет право это API дёргать и ничего (в сервисе А) от этого не поломается. Если сервис Б предоставляет кеширование для А, и рекомендован к использованию вместо А для остальных сервисов, то это просто рекомендация, если её кто-то проигнорирует, то беды не случится, просто этот кто-то будет работать немного медленнее.
Если сервис А предоставляет API, которое можно использовать некорректным образом, что сломает сервис А, и для решения этой проблемы написан сервис Б, который гарантирует корректное использование API сервиса А, в связи с чем всем остальным запрещено использовать А — то в этом случае А нужно целиком заменить сервисом с корректным API (т.е. Б).
Если у Вас так сложилось, что API сервиса А имеет право дёргать только сервис Б — это уже плохо, и нужно это безобразие как-то гарантировать: например, реализовать авторизацию в API сервиса А, и дать ключ доступ только сервису Б, чтобы остальные сервисы не смогли вызывать API сервиса А т.к. у них нет этого ключа доступа. Или поместите сервисы А и Б в общую изолированную подсеть, чтобы остальные сервисы вообще доступа по сети к А не имели.
это просто рекомендация, если её кто-то проигнорирует, то беды не случитсяДа и в обычной программе беды не случится, будет просто код постепенно превращаться в лапшу. Я хочу лишь отметить, что микросервисы сами по себе не гарантируют
киллер-фича — программисты физически не могут нарушить архитектуру (а, точнее, нарушать становится намного дольше и дороже, т.к. требуется вносить странные изменения в API «чужих» сервисовПросто проблема может вылезти другим профилем.
Это разные проблемы. Микросервисы гарантируют, что изменения в одном не сломают другой. По сути весь интернет — кучка сервисов, как микро так и не очень микро, и только благодаря этому он вообще работает.
Например, есть сервис гуглмапс, у него есть API, и, что бы мы не вытворяли в своём сервисе, использующем сервис гуглмапс — гуглмапс от этого не сломается. Равно как и что бы не вытворяли разработчики гуглмапс — наш сервис это не сломает (ну, предполагая что они, как это принято, сохраняют совместимость API). Про разные части монолита такое сказать нельзя, между ними обычно более сильные связи, разработчики одной нередко вносят изменения в код другой, и в результате незначительные изменения одной могут нечаянно поломать вторую.
Боб Мартин дорогостоящий архитектор/консультант, и он не очень-то задумывается, о том, что то, что применимо к нему и к крупным организациям, может привести к проблемам у простых смертных. И многие не слишком разумные могут подорваться, и начать пылко исполнять то, что говорят им такие как Роберт Мартин. А если задуматься о том что он предлагает — то он предлагает программистам работать над архитектурой БЕСПЛАТНО. Что не слишком разумный менеджмент и программистов приведет в нехорошие ситуации. Потому что в реальности ничего никогда «бесплатно» не бывает и это аукнется временем, а затем и деньгами. Хорошая архитектура — это не бесплатно во всех смыслах.
Если программист занимается разработкой архитектуры, или от него «требуют архитектуру» — за это должны доплачивать как архитектору. Логично? Если программист это не понимает — он сам себе злобный Буратино. Ну или может быть молодой, пылкий и не очень разумный.
Менеджмент, в свою очередь, должен понимать, что когда х-х и в продакшн, это быстро и дёшево. Но потом не поддерживаемо. Долго, растет стоимость, или всё переписывать. Хотя в некоторых проектах «х-х и в продакшн» это единственный разумный способ разработки, просто потому что сами эти проекты по своей сути представляют собой одноразовое «д в фантике».
По моему мнению, вот это:
Что важнее – поведение или архитектура? Менеджеры считают, что важнее, чтобы система работала. Но программисты должны считать наоборот, что важнее архитектура.
Матрица Эйзенхауэра говорит, что важное и несрочное имеет более высокий приоритет, чем срочное и неважное. А архитектура всегда важна в отличие от поведения, поэтому она более приоритетна.
Программист должен бороться за архитектуру. Программист – это тоже участник бизнеса. Архитектура – это его ответственность.
— «Архитектурный хайп». Не всё тут верно.
Если этому следовать бездумно — будут проблемы.
Если программист это не понимает — он сам себе злобный Буратино. Ну или может быть молодой, пылкийА что он должен делать? Говнокод?
Каждый пишет в меру своих способностей. Но если способности оплачиваются неадекватно — это уже другой вопрос и не повод ухудшать качество.
А если задуматься о том что он предлагает — то он предлагает программистам работать над архитектурой БЕСПЛАТНО.
Это примерно настолько же правда, как и то, что программисты должны БЕСПЛАТНО настраивать и запускать IDE/редактор, БЕСПЛАТНО рефакторить большую функцию на мелкие… любая "сопутствующая" активность не являющаяся обязательной для реализации новой фичи с этой "точки зрения высокого уровня" является потенциальной проблемой, которая может отрицательно сказаться на сроках и/или бюджете проекта.
По сути, хорошая архитектура нужна, в первую очередь, самим программистам — она позволяет им избежать экспоненциального замедления разработки проекта, т.е. даёт им возможность добавлять новые фичи с более-менее константной скоростью, что увеличивает их собственную удовлетворённость от работы, и избавляет от необходимости выслушивать постоянные упрёки менеджеров в том, что всё делается неприемлемо медленно и/или некачественно. Поэтому, да, все программисты должны стараться поддерживать текущую архитектуру, а для этого необходимо её понимать.
Ещё один нюанс заключается в том, что хотя названия архитектурных подходов на низком/среднем/высоком уровнях архитектуры разные, но суть у них очень похожа, поэтому понимание этих принципов необходимо программистам не только для того, чтобы поддерживать архитектуру всего проекта, но и для того, чтобы лучше разделять код по классам/функциям и упрощать тестирование кода в своей области ответственности.
Хорошая архитектура — это не бесплатно во всех смыслах.
О, да! Но Вы упускаете из виду, что отсутствие архитектуры или плохая архитектура — это тоже ни разу ни бесплатно во всех смыслах. Правильно ставить вопрос иначе: что обойдётся дороже для проекта, отсутствующая/плохая архитектура, или хорошая. И ответ на этот вопрос сильно зависит от того, сколько ресурсов планируется тратить на поддержку и развитие проекта.
Программист должен бороться за архитектуру. Программист – это тоже участник бизнеса. Архитектура – это его ответственность.
— «Архитектурный хайп». Не всё тут верно.
А по-моему здесь всё верно: если программист воспринимает себя участником бизнеса, то он ответственно решит обойтись без архитектуры в проекте-прототипе, у которого время жизни пара месяцев… и ровно так же ответственно решит, что без нормальной архитектуры писать проект нельзя (даже если менеджмент настаивает на «х-х и в продакшн»), если этот проект планируется долго поддерживать и развивать.
Одна из причин моего возражения заключена в том, что миллениалы готовы смотреть в рот Р.Мартину, а я его ровесник. С соответствующим опытом. И то что с апломбом несёт этот товарищ, я воспринимаю критически.
Например, вот что находит у меня возражение. Тенденция настоящего времени — нарастающий хаос, который миллениалы и поколение Z воспринимают как естественное положение вещей. В действительности, отдельными вопросами, такими как архитектурные, должны заниматься отдельные люди. И точно — не все подряд, не безликие «программисты» по Р. Мартину. Хотя бы потому что часто это ведет к тому что невозможно выяснить; кто, зачем и почему придумал такую «архитектуру». В условиях когда каждый программист сам себе свободный архитектор рождаются архитектурные монстры. Проверено.
Очень много потерялось в сокращениях и незаконченности, от этого многие комментаторы решили, что в интернете кто-то неправ — при том, что книга не противоречит здравому смыслу, в том числе в части, относящейся к их апелляции.
К примеру, функциональность и архитектура в книге описаны как "первая" и "наибольшая" ценности — приложение которое работает правильно, если его невозможно (можно читать как "слишком дорого") переделать при изменении требований, теряет ценность, если требования меняются (с. 37). Если работает неправильно, но это можно исправить — это лучше. Но лучше всего — когда и работает, как надо, и изменить при необходимости можно. В сравнении плохих вариантов об этом не сказано, но давайте предположим, что читатель адекватен, ладно?
Очевидно, что это имеет существенное значение именно тогда, когда требуется гибкость. Об этом идёт речь, когда заканчивается последовательное введение в тему — с 15 главы (книга вообще философская и сентиментальная, хотя в некоторых вопросах вполне конкретная). При этом дядя Боб не продаёт универсальную таблетку — та же 15 глава говорит о цели и предназначении архитектуры. Сопоставив это с целями, которые мы ставим себе при разработке ПО, мы можем судить о целесообразности, которая (мой вывод) выражается в соотношении ценности функциональности и архитектуры (а не так, что архитектуру вперёд, а цели по боку). Далее, например, в 17 главе, говорящей об архитектурных границах, уже явно обсуждается оверинжиниринг в свете стоимости архитектурных границ.
Если вы верите, что существует экономически обоснованный допустимый уровень говнокода, книга этого не опровергает. Однако, в историческом экскурсе приводятся примеры недостаточного абстрагирования, из-за которых опытный разработчик посмотрел на молодого ещё тогда автора и его команду "как на инопланетян". Есть всё-таки, уровень (сильно зависящий от ожидаемого жизненного цикла продукта, но всегда есть), который надо понимать и соблюдать хотя бы в гигиенических целях.
Если же Вы нуждаетесь в улучшении навыков понимания и построения хорошей архитектуры вообще и архитектурных границ в частности, или, к примеру, хотите понять наконец, что же именно, зачем и как инвертируется при инверсии зависимости — книга будет Вам полезна. А если понравится полуфилософский стиль с уклоном в историю — то ещё и доставит удовольствие.
Я видел много разочарованных отзывов про эту книжку когда её заказывал: народ ждал новых откровений, и, не узнав из книги ничего нового, сильно расстраивался. А мне она, наоборот, очень понравилась: да, ничего нового в ней нет, зато всё старое описано очень целостно, показана общая картина, с наглядным объяснением зачем и в каких ситуациях нужен каждый элемент архитектуры. И исторические экскурсы там вовсе не лишние, без них целостную картину увидеть сложнее.
Всегда есть люди, для которых самые "общеизвестные" истины окажутся откровением. Лично для меня уровень понимания темы здорово приподнялся — и за счёт целостности, и за счёт повторения основ теории на более, чем ста страницах (да ещё и с хорошим осмыслением, погружением в суть и развенчанием мифов), и за счёт наглядности и хороших примеров по основной теме.
Это оказалось для меня продвинутым знанием с подробным разбором от самых основ, собранным в одном месте — самодостаточность книги из-за этого на высоте, достаточно не забывать о том самом здравом смысле, и иметь представление об организационных вопросах в обсуждаемой области.
И да, истории там действительно к месту. Главное, что тут имеет место в некотором роде инверсия истории — вместо классического "при нас-то трава была зеленее" они о том, что "Раньше мы многого не знали, а теперь наш опыт может помочь вам".
Чистая архитектура. Часть I — Введение