Comments 66
Полностью согласен! Отличная статья.
Насчет архитекторов — все очень сильно зависит от того, что мы делаем. Производится ли in-house разработка или берутся готовые решения ("коробки"), а потом сшиваются вместе через интеграции.
Должна быть некая гибкость и баланс между обеими крайностями: когда каждая команда решает, что ей нужно и как ей быть, и полностью зарегулированной историей, когда сверху спускают 100500 регламентов, которые имеют взаимоисключающие параграфы (в частности — регламенты про используемый стек от ОСи до прикладного ПО, ИБ и пр. пр.).
Действительно — впереди разработки должно быть понимание бизнес-задачи, а перед ним — САМ бизнес-процесс, который мы как разработчики и будем воплощать в цифровой форме, а не наоборот.
Разумеется, «тогда» не было возможности всё сделать «как надо», и пришлось делать «как есть». Да.
Выделение роли архитектора, это применения принципа «разделяй и властвуй».
Т.е. вполне нормальная и очевидная вещь.
Т.к. «сложность» системы надо «есть по частям».
Например «сверху вниз», т.е. от общего (архитектуры) к частному (реализации).
Но в иерархических системах это стало просто еще одним способом «переноса ответственности» и бюрократизации.
Типа «У вас претензии к пуговицам есть?»
Программисты говорят что архитектура кривая, а архитекторы говорят, что реализация говно.
И у всех есть куча доводов в вою пользу.
Удовлетворенность клиента в кровавом Ынтырпрайзе определяется размером отката ЛПР. :-)
Сложностью можно управлять по разному.
Тот же самый кровавый Ынырпрайз с оверинжиниингом и кучей абстракций над абстракциями, таки делает свое дело.
И как то управляется.
А так в статье особо ничего нового не написано — не применяй паттерн или целую методологию проектирования просто потому что можешь, объясняй понятными словами.
Конечно, очень прибыльно продавать лычки XXX Architect и рисовать красивые картинки в рамках того или иного фреймворка. Но к реальной разработке это имеет очень опосредованное отношение.
Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковать
Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковать Тору проект по своему желанию и усмотрению.
Ну то есть вы считаете что можно на крупный проект посадить с десяток джунов клепать привычный и понятный им и большинству процедурный код и всё норм?
Если проекты дольше пары лет не живут — может и сойдёт, но последующие выводы что архитектура — удел теоретиков на OOPSLA(и такое встречается в интернете и на Хабре) скорее походят на психологическую защиту а не инженерное решение.
А по поводу пары-тройки избранных — есть методики распространения знаний в команде(Code Review, Pair programming). Уже пол века как есть.
По поводу статьи — если отбросить большую часть воды, единственный тезис что останется:
Старайтесь избегать сложности, которую неизбежно привносят в ваши системы более сложные архитектуры и формальные инструменты
Я согласен с ним в плане того что люди часто в простые проекты затаскивают излишне усложнённые решения, но это, опять же — из-за не понимания их ценности и собственных целей. И в такой ситуации действительно, самым правильным решением может оказаться делать «как умеем», только ориентироваться всё же не на самого слабого человека в команде, а подтягивать уровень команды насколько это возможно.
Конкретно архитектура — ограничения, с ростом проекта и количества разработчиков, нужно тщательно продумывать ограничения чтобы не превратить всё в кашу.
В-третьих, мы практически никогда не ссылались на распространенные архитектурные паттерны и другой общепринятый жаргон, который используется в популярной литературе по архитектуре ПО вроде руководства Мартина Фаулера. Не было упоминаний микросервисов, serverless-архитектуры, границ приложений, событийно-ориентированной архитектуры (event-driven architecture) и всего остального. Некоторые из этих терминов всплывали во время сессий мозгового штурма; однако, у нас не было никакой необходимости ссылаться на них самих в проектной документации.
Вот тут явно что-то не то, ибо в Убере как раз во всю используется event-driven-architecture, существуют чёткие границы между командами и т.п. (их блог — https://eng.uber.com/ )
Может быть они в свою техническую документацию копируют описание паттерна без его названия, иначе я этот абзац никак объяснить не могу )
То есть вместо весьма популярного подхода «вот этот паттерн очень хорош, давайте строить наш проект опираясь на него» предлагается мыслить в ключе «разложите вашу бизнес логику, рассмотрите несколько вариантов построения системы, скомпонуйте их в оптимальный. Вероятно он будет попадать под один или несколько шаблонов, ну и ок»
В общем стандартное «не надо паттернов ради паттернов»
19. Тайно вытаскивать хворост из-под котла другого
Ну то есть вы считаете что можно на крупный проект посадить с десяток джунов клепать привычный и понятный им и большинству процедурный код и всё норм
Разве я хоть одним словом намекнул, что на проекте должны работать одни джуны? И уж тем более привязывать стиль программирования к архитектуре вообще странно.
Можно в процедурном стиле писать качественно и ровно ту же самую архитектуру реализовать отвратительно с помощью механизмов ООП.
Я сказал ровно то, что хотел сказать — архитектура должна быть понятной разработчикам. Если архитектура как совокупность документов ни в какой своей части непонятна джуну, то это плохая архитектура.
Потому что архитектура призвана снижать сложность разработки путем упорядочивания прикладывания усилий. Естественно, инструменты слежения за не очень квалифицированными разработчиками должны быть.
Но если джун постоянно косячит против архитектуры, то это уже не проблема джуна, а ваша — либо вы приняли дебила на позицию, либо не смогли донести до него направление, в котором надо двигаться.
На крупном проекте вполне могут быть люди которые обладают большим количеством информации о проекте, и имеют лучшее представление как всё происходит на более высоком/низком уровне, лучшие познания в архитектуре, и могут могут предлагать лучшие архитектурные решения, которые могут быть не понятны какой-то части разработчиков. Возможно даже большей части, т.к. возможных решений много, а не типовых проектов не так уж.
И решением в данном случае будет совместное обсуждение предлагаемых решений( и принятие/отказ от них), и ввод в курс дела разработчиков которые не имели с ними дела, а не отказ от решения в пользу того что понятно большинству.
И мы опять приходим к тому, что вся сила в коммуникациях. Они должны быть регулярными и плодотворными. Есть же выражение, что тот продукт, который генерирует некая организация, является отражением ее оргструктуры (а следствие — и коммуникативных связей). И, напротив, если нужно сделать новый, качественный продукт — нужно менять структуру коммуникаций к лучшему.
Зафиксируйте его в виде простой документации с простыми диаграммами, основанными на том, что вы ранее объясняли при помощи вайтбординга. Сведите жаргон на минимум: вы хотите, чтобы даже джуниоры могли понять, о чем идёт речь.
Сведите жаргон на минимум.
Вайтбординг.
хм…
Далее по тексту разъясняется.
Нарисуйте на доске то, над чем вы работаете, и объясните смысл изображенного.
Если доски нет — займусь блокнотингом или тетрадингом. Думаю, что также сойдёт простой бумагинг или на-асфальте-мелинг.
На самом деле, наш подход принципиально не так уж сильно отличается от того, что описано в руководствах по архитектуре.
Потому что вы его уже знали. Это часть профессиональной деградации, когда тебе кажется, что все и так очевидно и просто, зачем об этом везде пишут.
Правила нарушают новички и эксперты, только результат у них разный, потому что нарушать правила можно по-разному. Правила это не концепции, которые являются единственно верными, это концепции, которые проверены временем и работают, но это не значит, что все остальное не работает. Проблема в том, что всего остального очень много и выбрать что-то не очень хорошо работающее из него при отсутствии компетенции вероятность крайне высокая.
в Skype/Mircrosoft нет штатных позиций для архитекторов ПО
Я частично согласен с мнением, что роль архитекторов переоценена, и достаточно тепло отношусь к компании Microsoft в целом, но не приводил бы в пример продукт под названием Skype в его нынешней инкарнации.
В ней призывается отказаться от архитекторов и описывается то, как работали архитекторы проекта. =)
Построение взаимодействия создателей проекта, применение/не применение паттернов, рисование где угодно, отказ от сложных решений (или наоборот их привнесение) — всё это задачи архитектора и автор статьи (или указанные им люди) именно этом и занимались. т.е. дефакто были архитекторами )
Может я что то не понимаю? )
Основной посыл: в современных IT-компаниях роль архитекторов выполняют разработчики, следовательно лучше говорить на понятном для них языке.
Основной посыл: в современных IT-компаниях роль архитекторов выполняют разработчики, следовательно лучше говорить на понятном для них языке.
Посыл хороший, плюсую)
Если так складывается что «архитекторы проекта» это часть людей которая сидит где-то у себя в кабинете и принимает решения которые аффектят всю команду, списывая им кучу страниц технической документации и правил по написанию кода, явно что-то идёт не так.
На мой взгляд, проблема этой статьи в том, что автор слишком уж фокусируется на тезисе «принимайте простые решения», дополняя это некоторой частью воды, и после прочтения, особенно после того как автор называет названия паттернов «жаргоном», «хайпом», складывается впечатление что делать нужно исключительно решения понятные даже студенту(вспомним Дядю Боба про «every 5 years the number of programmers doubles»).
Думаю что очень верно подметил комментатор выше про
Потому что вы его уже знали. Это часть профессиональной деградации, когда тебе кажется, что все и так очевидно и просто, зачем об этом везде пишут.
И «простые» для разработчиков Uber решения находятся далеко за границами известного в каком-нибудь средне-маленьком проекте. (Как, например, event-driven-architecture которую Uber активно используют, или микросервисы — https://eng.uber.com/building-tincup/).
Архитектура программного обеспечения переоценена, простой и понятный дизайн — недооценензаголовок статьи. И он противоречит сам себе, потому что простой и понятный дизайн — это тоже архитектура ) просто хорошая.
Честно говоря, за 10 лет в отрасли я встречал выделенных архитекторов только один раз — они делали gosuslugi.ru.
Ни в Яндексе, ни в Авито я их не встречал (хотя в Авито есть команда архитектуры, но занимаются они инфраструктуро
Если хочется вкорячить крутое решение — кто решает вкорячивать или нет? Тот и архитектор.
И он не обязательно должен быть выделенным. Более того — не обязательно он должен быть одним человеком. И необязательно, что он при этом сам не работает разработчиком. =)
Архитектор — это не обязательно личность. Это роль. И проект без этой роли — будет ужасен.
ЗЫ: у меня на одном месте работы была позиция у человека — архитектор. в других — эти функции исполняли тимлиды.
Так же — архитекторы бывают разного уровня — проекта, команды, продукта, всея структуры итп…
ЗЫЫ: в яндексе и авито каждый разработчик делает что хочет, пишет как хочет, внедряет любые решения? Думаю они всё-же это согласуют с кем то. Вот этот кто то — и есть архитектор. Или глас его )
Про роль согласен.
Про Яндекс и Авито: разработчик проекта всегда является его архитектором, по крайней мере так всегда было вокруг меня.
Нет, понятно, что когда проект из одного разработчика, то он сам выполняет роль архитектора… но это тоже не значит, что этой роли нет )
Если разработчиков целая команда, то роль архитектора обычно выполняет тот, кто дольше всех работает над этим проектом :)
Архитектор есть, его не может не быть.
Вопрос только в том, хороший он архитектор или плохой.
В статье рассматривают примеры хороших архитектурных подходов и не очень. Но и то и другое — это архитектура )
Подозреваю ответ, что все, но тогда это равнозначно, что его нет.
"Коллегиально" — это голосованием? Если двое новичков на проекте будут за одно решение, а двое опытных инженеров — за другое, что делать будете?
P.S. Такой подход не применим везде и всюду, есть люди которые не хотят принимать/предлагать никаких решений, следовательно для мест скопления таких людей архитектор нужен, иначе будет хаос. Хотя и с архитектором он может быть.
Но если проект на пару сотен человек, то посмотрю как это будет «коллегиально».
Не надо проект на пару сотен человек. Мы же понимаем, что эффективно может перформить только команда размером, что сможет съесть максимум две пиццы. Но это не отменяет того, что если уже есть десяток команд, то должен быть человек, который обладает видением и как всё это хозяйство будет развиваться дальше. Какие новые сервисы будут появляться, как будут изменяться существующие. А как его назвать, этого человека — вторично. Пускай будет архитектором предприятия. Или СТО. Или директором или замдира по айти.
Или если архитектора не называть архитектором — он не будет архитектором?
Как и использование паттернов, если их не называть паттернами, не считается использованием паттернов? )
Примерно это меня в статье очень смущает )
Просто в их культуре видимо укоренилось, что архитектор — это такой опытный человек, который только диаграммы рисует и бумажки пишет, т.е. несколько оторванный от реальности персонаж, поэтому предлагается никого архитекторами не называть, чтобы не переставал писать код.
Непростая у них была культура. (ака — просто у них был неудачный опыт архитектора))
Спасибо за концентрированные тезисы из статьи.
KISS >> DRY
Она формализована, просто никто кроме НАСА не хочет платить за такую формализацию.
Мое мнение — все зависит от размеров проекта и строгости требований. Если вы разрабатываете для НАСА, боюсь — выбора у вас нет. Если вы разрабатвыаете для военки — выбора нет. Если вы разрабатываете для медицины — выбора нет. Но если вы пилите высоконагруженную систему с высоким порогом допущения — то вам проще работать в менее формализованных требованиях, привлекая новых специалистов под этой или может быть довольно часто меняя подходы и проверяя то или иное решение.
Архитектура программного обеспечения переоценена, простой и понятный дизайн — недооценен