Комментарии 65

Полностью согласен! Отличная статья.
Насчет архитекторов — все очень сильно зависит от того, что мы делаем. Производится ли in-house разработка или берутся готовые решения ("коробки"), а потом сшиваются вместе через интеграции.
Должна быть некая гибкость и баланс между обеими крайностями: когда каждая команда решает, что ей нужно и как ей быть, и полностью зарегулированной историей, когда сверху спускают 100500 регламентов, которые имеют взаимоисключающие параграфы (в частности — регламенты про используемый стек от ОСи до прикладного ПО, ИБ и пр. пр.).


Действительно — впереди разработки должно быть понимание бизнес-задачи, а перед ним — САМ бизнес-процесс, который мы как разработчики и будем воплощать в цифровой форме, а не наоборот.

Статья хорошая, но что-то подобное я читал в книге, кажется, 1989 года о системном анализе. Иными словами, для меня представленное в тексте статьи не является чем-то новым, но вызывает удивление, что пришли к этому только сейчас.
Разумеется, «тогда» не было возможности всё сделать «как надо», и пришлось делать «как есть». Да.
Ну… Любая идея будет «извращена» до полной противоположности.
Выделение роли архитектора, это применения принципа «разделяй и властвуй».
Т.е. вполне нормальная и очевидная вещь.
Т.к. «сложность» системы надо «есть по частям».
Например «сверху вниз», т.е. от общего (архитектуры) к частному (реализации).

Но в иерархических системах это стало просто еще одним способом «переноса ответственности» и бюрократизации.
Типа «У вас претензии к пуговицам есть?»

Программисты говорят что архитектура кривая, а архитекторы говорят, что реализация говно.
И у всех есть куча доводов в вою пользу.
Те и другие могут говорить что угодно. Конечная оценка все равно произойдет по удовлетворенности клиента, кем бы он ни был. Продукты, которые мы считаем хорошими или близкими к идеальным, это те продукты, команды которых научились управлять сложностью. А не рисовать красивые семислойные архитектуры. Или даже их имплементировать.
Кровавый Ынтыпрайз смеётся над вашей наивностью.
Удовлетворенность клиента в кровавом Ынтырпрайзе определяется размером отката ЛПР. :-)
Как будто этот «клиент» не знает, что то, за что получен откат, это унылое говно. Нет, не так. УНЫЛОЕ ПОЛНОСТЬЮ НЕРАБОТОСПОСОБНОЕ ГОВНО. Мое высказывание было не про таких «клиентов», а про сложность и управление ею.
Может и не знать. Т.к. «клиент» и ЛПР это могут быть разные люди.

Сложностью можно управлять по разному.
Тот же самый кровавый Ынырпрайз с оверинжиниингом и кучей абстракций над абстракциями, таки делает свое дело.
И как то управляется.
Хреново он управляется. Не буду приводить стопитцот примеров, только один. Если в энтерпрайзе имеются куски кода на Коболе, то с большой долей вероятности эти куски — лучшее что там есть. Все остальные навороты, декораторы и фасады чем дальше, тем ситуацию все более ухудшают. Брукс свой «Мифический человеко-месяц» написал в 1969, если что. С тех пор мало что изменилось.
Ну хреново/не хреново это дело вкуса.
Но программы работают, иногда изменяются.
Проблема бывает когда стоимость изменений сравнима с переписыванием с нуля, но так обычно очень редко бывает.
Думаю, всё просто сильно зависит от размера продукта. Когда продукт разрабатывают тысячи разработчиков, то им приходится соблюдать архитектурные гайдлайны, вводить некоторые практики и т.п. Но потом многие небольшие проекты начинают использовать эти слишком сложные инструменты (как например, «микросервисность в каждый дом» или «фабрика на каждую ответственность»), и в итоге получают необходимость в поддержки этой сложной инфраструктуры. Но потом опять появляются разумные люди, вспоминают про KISS и говорят, что пора вернуться собственно к проблеме вместо использования всех хайповых практик — и появляется новая хорошая статья.

Он и на Linux и на Android такой прям «норм»… С каждой версией все хуже, и думаешь: «Если оно при рождении было ужасно, то каким станет еще через несколько лет?..»

вот тогда и возникает вопрос: а стоит ли доверять автору статьи? или автор не виноват — это майкрософт уже всё портит?

Не знаю, возможно, они специально для Linux его кривым делают. Windows не пользуюсь. К тому же, Microsoft большой — уверен, что в разных командах разные подходы.

Под windows его душит их же ms teams. Скайп же стал ужаснее и нестабильнее с каждым новым релизом.

Поправьте, если не прав.


Discord тоже на Electron, но работает вполне хорошо. Может быть дело все таки не в Electron?

Несколько лет назад, уже в эпоху МС, скайп для Linux поддерживался одним! человеком, и это был не единственный его проект. Говорили, о том, чтобы закрыть его вообще. Как сейчас, не знаю.
Что то мне подсказывает, что Skype это не только клиентская часть. И судя по деятельности автора в Uber, переписывал(или писал) он серверные части, возможно тоже про платежи.
А так в статье особо ничего нового не написано — не применяй паттерн или целую методологию проектирования просто потому что можешь, объясняй понятными словами.
Да он и на винде «норм». Поиск работает на месяц назад, просмотр истории на целых три месяца…
Вообще не понимаю, как им теперь на Винде пользоваться можно. Сообщения показывает только тогда, когда его принудительно запустишь, хотя в трее исправно висит и ресурсы жрет. Для подгрузки истории сообщений требует реально заметного глазу времени. Ну и самый важный аргумент — с таким качеством связи вообще его как средство связи нельзя использовать, уж не знаю, с чем это связано, но я ни заниматься с преподавателем по скайпу не могу, постоянный гул с эхом, ни на работе использовать — связь рвется стабильно. Такого даже в бородатые нулевые с ним не было на куда менее мощной технике и модемном соединении. Даже не знаю, как у них вышло так улучшить систему.
Там от скайпа только иконка осталась. Давно все переписано на Lync движок.
Наконец то кто то громко озвучил то, как это происходит в реальной жизни.

Конечно, очень прибыльно продавать лычки XXX Architect и рисовать красивые картинки в рамках того или иного фреймворка. Но к реальной разработке это имеет очень опосредованное отношение.

Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковать Тору проект по своему желанию и усмотрению.
Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковать Тору проект по своему желанию и усмотрению.

Ну то есть вы считаете что можно на крупный проект посадить с десяток джунов клепать привычный и понятный им и большинству процедурный код и всё норм?

Если проекты дольше пары лет не живут — может и сойдёт, но последующие выводы что архитектура — удел теоретиков на OOPSLA(и такое встречается в интернете и на Хабре) скорее походят на психологическую защиту а не инженерное решение.

А по поводу пары-тройки избранных — есть методики распространения знаний в команде(Code Review, Pair programming). Уже пол века как есть.

По поводу статьи — если отбросить большую часть воды, единственный тезис что останется:
Старайтесь избегать сложности, которую неизбежно привносят в ваши системы более сложные архитектуры и формальные инструменты

Я согласен с ним в плане того что люди часто в простые проекты затаскивают излишне усложнённые решения, но это, опять же — из-за не понимания их ценности и собственных целей. И в такой ситуации действительно, самым правильным решением может оказаться делать «как умеем», только ориентироваться всё же не на самого слабого человека в команде, а подтягивать уровень команды насколько это возможно.

Конкретно архитектура — ограничения, с ростом проекта и количества разработчиков, нужно тщательно продумывать ограничения чтобы не превратить всё в кашу.
P.S.
В-третьих, мы практически никогда не ссылались на распространенные архитектурные паттерны и другой общепринятый жаргон, который используется в популярной литературе по архитектуре ПО вроде руководства Мартина Фаулера. Не было упоминаний микросервисов, 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
Нужно знать меру во всём, а то джуниоры начитаются таких статей и будут писать лапшевидный код, ссылаясь на то, что Орос сказал не тратить время на архитектуру.
Создавать большие работающие устойчивые системы — это искусство. Если бы эта деятельность могла быть формализована — она уже была бы формализована.
А еще есть ISO, IEEE. В стандартах описано все, чтоб строить отличные большие устойчивые системы.
Если бы этот процесс был формализован, то этот метод можно было применить к любой другой проблемной области. )) За метод нужно платить только один раз.

За этот метод вообще ничего не надо платить, он, в принципе, описан прямо в статье по ссылке. Ему очень дорого следовать.

Инутитивно кажется, что формализовать это — все равно, что формализовать написание интересных книг. Теоретически вроде и можно, но:
1) не каждый, кто следует правилам, сможет написать интересную книгу
2) парадоксально, но самые интересные книги будут большинство этих правил нарушать

Возможно, дело в дидактике. Когда в 2001ом я прочитал «Design Patterns», описанные там паттерны я и сам изобрёл и пользовал. Но «Бандиты» концептуализировали эту работу, помогли выделить практику создания типичных дизайнов и видеть её в коде. Это помогло. Другое дело, что UML-представления малополезны для передачи этого знания и обучения ему. В начале нулевых вышло несколько книг с адовым количеством разных красивых паттернов, это был полный трэшак.

Пока не уткнёшся в реальную инженерную проблему, а точнее — в ряд типичных проблем, не увидишь, как они типично решаются и не освоишь это в виде инженерного рефлекса, все эти диаграммы — пустое. Паттерны проектирования — не пустое, их нужно осваивать или даже выращивать в себе, как навык. Про них можно разговаривать; не знаю, что там у автора, в моих командах не так уж редко рассуждали в терминах паттернов: «сделай из этого синглтон», «похоже, тут у Майкрософта фабрика» или «какую либу возьмём для DI».

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