Comments 66
Полностью согласен! Отличная статья.
Насчет архитекторов — все очень сильно зависит от того, что мы делаем. Производится ли in-house разработка или берутся готовые решения ("коробки"), а потом сшиваются вместе через интеграции.
Должна быть некая гибкость и баланс между обеими крайностями: когда каждая команда решает, что ей нужно и как ей быть, и полностью зарегулированной историей, когда сверху спускают 100500 регламентов, которые имеют взаимоисключающие параграфы (в частности — регламенты про используемый стек от ОСи до прикладного ПО, ИБ и пр. пр.).
Действительно — впереди разработки должно быть понимание бизнес-задачи, а перед ним — САМ бизнес-процесс, который мы как разработчики и будем воплощать в цифровой форме, а не наоборот.
Статья хорошая, но что-то подобное я читал в книге, кажется, 1989 года о системном анализе. Иными словами, для меня представленное в тексте статьи не является чем-то новым, но вызывает удивление, что пришли к этому только сейчас.
Разумеется, «тогда» не было возможности всё сделать «как надо», и пришлось делать «как есть». Да.
Разумеется, «тогда» не было возможности всё сделать «как надо», и пришлось делать «как есть». Да.
Ну… Любая идея будет «извращена» до полной противоположности.
Выделение роли архитектора, это применения принципа «разделяй и властвуй».
Т.е. вполне нормальная и очевидная вещь.
Т.к. «сложность» системы надо «есть по частям».
Например «сверху вниз», т.е. от общего (архитектуры) к частному (реализации).
Но в иерархических системах это стало просто еще одним способом «переноса ответственности» и бюрократизации.
Типа «У вас претензии к пуговицам есть?»
Программисты говорят что архитектура кривая, а архитекторы говорят, что реализация говно.
И у всех есть куча доводов в вою пользу.
Выделение роли архитектора, это применения принципа «разделяй и властвуй».
Т.е. вполне нормальная и очевидная вещь.
Т.к. «сложность» системы надо «есть по частям».
Например «сверху вниз», т.е. от общего (архитектуры) к частному (реализации).
Но в иерархических системах это стало просто еще одним способом «переноса ответственности» и бюрократизации.
Типа «У вас претензии к пуговицам есть?»
Программисты говорят что архитектура кривая, а архитекторы говорят, что реализация говно.
И у всех есть куча доводов в вою пользу.
Те и другие могут говорить что угодно. Конечная оценка все равно произойдет по удовлетворенности клиента, кем бы он ни был. Продукты, которые мы считаем хорошими или близкими к идеальным, это те продукты, команды которых научились управлять сложностью. А не рисовать красивые семислойные архитектуры. Или даже их имплементировать.
Кровавый Ынтыпрайз смеётся над вашей наивностью.
Удовлетворенность клиента в кровавом Ынтырпрайзе определяется размером отката ЛПР. :-)
Удовлетворенность клиента в кровавом Ынтырпрайзе определяется размером отката ЛПР. :-)
Как будто этот «клиент» не знает, что то, за что получен откат, это унылое говно. Нет, не так. УНЫЛОЕ ПОЛНОСТЬЮ НЕРАБОТОСПОСОБНОЕ ГОВНО. Мое высказывание было не про таких «клиентов», а про сложность и управление ею.
Может и не знать. Т.к. «клиент» и ЛПР это могут быть разные люди.
Сложностью можно управлять по разному.
Тот же самый кровавый Ынырпрайз с оверинжиниингом и кучей абстракций над абстракциями, таки делает свое дело.
И как то управляется.
Сложностью можно управлять по разному.
Тот же самый кровавый Ынырпрайз с оверинжиниингом и кучей абстракций над абстракциями, таки делает свое дело.
И как то управляется.
Хреново он управляется. Не буду приводить стопитцот примеров, только один. Если в энтерпрайзе имеются куски кода на Коболе, то с большой долей вероятности эти куски — лучшее что там есть. Все остальные навороты, декораторы и фасады чем дальше, тем ситуацию все более ухудшают. Брукс свой «Мифический человеко-месяц» написал в 1969, если что. С тех пор мало что изменилось.
Думаю, всё просто сильно зависит от размера продукта. Когда продукт разрабатывают тысячи разработчиков, то им приходится соблюдать архитектурные гайдлайны, вводить некоторые практики и т.п. Но потом многие небольшие проекты начинают использовать эти слишком сложные инструменты (как например, «микросервисность в каждый дом» или «фабрика на каждую ответственность»), и в итоге получают необходимость в поддержки этой сложной инфраструктуры. Но потом опять появляются разумные люди, вспоминают про KISS и говорят, что пора вернуться собственно к проблеме вместо использования всех хайповых практик — и появляется новая хорошая статья.
Скажите, а Skype на Xbox One таки получился норм?
UFO just landed and posted this here
Вот что Electron животворящий делает. :-)
вот тогда и возникает вопрос: а стоит ли доверять автору статьи? или автор не виноват — это майкрософт уже всё портит?
UFO just landed and posted this here
Что то мне подсказывает, что Skype это не только клиентская часть. И судя по деятельности автора в Uber, переписывал(или писал) он серверные части, возможно тоже про платежи.
А так в статье особо ничего нового не написано — не применяй паттерн или целую методологию проектирования просто потому что можешь, объясняй понятными словами.
А так в статье особо ничего нового не написано — не применяй паттерн или целую методологию проектирования просто потому что можешь, объясняй понятными словами.
Да он и на винде «норм». Поиск работает на месяц назад, просмотр истории на целых три месяца…
UFO just landed and posted this here
Наконец то кто то громко озвучил то, как это происходит в реальной жизни.
Конечно, очень прибыльно продавать лычки XXX Architect и рисовать красивые картинки в рамках того или иного фреймворка. Но к реальной разработке это имеет очень опосредованное отношение.
Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковатьТору проект по своему желанию и усмотрению.
Конечно, очень прибыльно продавать лычки XXX Architect и рисовать красивые картинки в рамках того или иного фреймворка. Но к реальной разработке это имеет очень опосредованное отношение.
Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковать
Разработке нужна архитектура понятная каждому разработчику, а не паре тройке избранных, которые будут толковать Тору проект по своему желанию и усмотрению.
Ну то есть вы считаете что можно на крупный проект посадить с десяток джунов клепать привычный и понятный им и большинству процедурный код и всё норм?
Если проекты дольше пары лет не живут — может и сойдёт, но последующие выводы что архитектура — удел теоретиков на OOPSLA(и такое встречается в интернете и на Хабре) скорее походят на психологическую защиту а не инженерное решение.
А по поводу пары-тройки избранных — есть методики распространения знаний в команде(Code Review, Pair programming). Уже пол века как есть.
По поводу статьи — если отбросить большую часть воды, единственный тезис что останется:
Старайтесь избегать сложности, которую неизбежно привносят в ваши системы более сложные архитектуры и формальные инструменты
Я согласен с ним в плане того что люди часто в простые проекты затаскивают излишне усложнённые решения, но это, опять же — из-за не понимания их ценности и собственных целей. И в такой ситуации действительно, самым правильным решением может оказаться делать «как умеем», только ориентироваться всё же не на самого слабого человека в команде, а подтягивать уровень команды насколько это возможно.
Конкретно архитектура — ограничения, с ростом проекта и количества разработчиков, нужно тщательно продумывать ограничения чтобы не превратить всё в кашу.
P.S.
Вот тут явно что-то не то, ибо в Убере как раз во всю используется event-driven-architecture, существуют чёткие границы между командами и т.п. (их блог — https://eng.uber.com/ )
Может быть они в свою техническую документацию копируют описание паттерна без его названия, иначе я этот абзац никак объяснить не могу )
В-третьих, мы практически никогда не ссылались на распространенные архитектурные паттерны и другой общепринятый жаргон, который используется в популярной литературе по архитектуре ПО вроде руководства Мартина Фаулера. Не было упоминаний микросервисов, serverless-архитектуры, границ приложений, событийно-ориентированной архитектуры (event-driven architecture) и всего остального. Некоторые из этих терминов всплывали во время сессий мозгового штурма; однако, у нас не было никакой необходимости ссылаться на них самих в проектной документации.
Вот тут явно что-то не то, ибо в Убере как раз во всю используется event-driven-architecture, существуют чёткие границы между командами и т.п. (их блог — https://eng.uber.com/ )
Может быть они в свою техническую документацию копируют описание паттерна без его названия, иначе я этот абзац никак объяснить не могу )
Ну насколько я понимаю, акцент не на отказ от стандартных архитектурных паттернов, а на изменение причины и следствия.
То есть вместо весьма популярного подхода «вот этот паттерн очень хорош, давайте строить наш проект опираясь на него» предлагается мыслить в ключе «разложите вашу бизнес логику, рассмотрите несколько вариантов построения системы, скомпонуйте их в оптимальный. Вероятно он будет попадать под один или несколько шаблонов, ну и ок»
В общем стандартное «не надо паттернов ради паттернов»
То есть вместо весьма популярного подхода «вот этот паттерн очень хорош, давайте строить наш проект опираясь на него» предлагается мыслить в ключе «разложите вашу бизнес логику, рассмотрите несколько вариантов построения системы, скомпонуйте их в оптимальный. Вероятно он будет попадать под один или несколько шаблонов, ну и ок»
В общем стандартное «не надо паттернов ради паттернов»
Текст для конкурентов, чтобы они разогнали своих архитекторов.
19. Тайно вытаскивать хворост из-под котла другого
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. Такой подход не применим везде и всюду, есть люди которые не хотят принимать/предлагать никаких решений, следовательно для мест скопления таких людей архитектор нужен, иначе будет хаос. Хотя и с архитектором он может быть.
P.S. Такой подход не применим везде и всюду, есть люди которые не хотят принимать/предлагать никаких решений, следовательно для мест скопления таких людей архитектор нужен, иначе будет хаос. Хотя и с архитектором он может быть.
Тогда роль архитектора выполняет коллегия.
Но если проект на пару сотен человек, то посмотрю как это будет «коллегиально».
Но если проект на пару сотен человек, то посмотрю как это будет «коллегиально».
Не надо проект на пару сотен человек. Мы же понимаем, что эффективно может перформить только команда размером, что сможет съесть максимум две пиццы. Но это не отменяет того, что если уже есть десяток команд, то должен быть человек, который обладает видением и как всё это хозяйство будет развиваться дальше. Какие новые сервисы будут появляться, как будут изменяться существующие. А как его назвать, этого человека — вторично. Пускай будет архитектором предприятия. Или СТО. Или директором или замдира по айти.
Ну, по сути он архитектором и будет. =)
Или если архитектора не называть архитектором — он не будет архитектором?
Как и использование паттернов, если их не называть паттернами, не считается использованием паттернов? )
Примерно это меня в статье очень смущает )
Или если архитектора не называть архитектором — он не будет архитектором?
Как и использование паттернов, если их не называть паттернами, не считается использованием паттернов? )
Примерно это меня в статье очень смущает )
На мой взгляд грань между архитектором и разработчиком довольно тонкая и в разных компаниях разная. И вообще это не очень конструктивный спор о терминологии. Одно из соображений в статье — «архитектор» должен писать код, не должен принимать авторитарных решений, которые могут быть не понятны разработчикам и все решения должны проходить этап обсуждения с как можно большим числом разработчиков. Просто в их культуре видимо укоренилось, что архитектор — это такой опытный человек, который только диаграммы рисует и бумажки пишет, т.е. несколько оторванный от реальности персонаж, поэтому предлагается никого архитекторами не называть, чтобы не переставал писать код.
Просто в их культуре видимо укоренилось, что архитектор — это такой опытный человек, который только диаграммы рисует и бумажки пишет, т.е. несколько оторванный от реальности персонаж, поэтому предлагается никого архитекторами не называть, чтобы не переставал писать код.
Непростая у них была культура. (ака — просто у них был неудачный опыт архитектора))
Спасибо за концентрированные тезисы из статьи.
Является ли повторяющийся код — чистым кодом?
Если повторяется два раза — вполне может являться чистым, так как повторение может быть обусловлено случайностью, а не общей природой частей, и в дальнейшем при добавоении фич эти участки будут различаться. Так же дублирование кода является одним из способов бороться со связанностью, пусть и не самым безупречным. Поэтому однозначного ответа тут нет.
повторяющийся код не чистый, но простой. Не следует устранять повторение переусложняя.
KISS >> DRY
KISS >> DRY
Нужно знать меру во всём, а то джуниоры начитаются таких статей и будут писать лапшевидный код, ссылаясь на то, что Орос сказал не тратить время на архитектуру.
Создавать большие работающие устойчивые системы — это искусство. Если бы эта деятельность могла быть формализована — она уже была бы формализована.
Она формализована, просто никто кроме НАСА не хочет платить за такую формализацию.
А еще есть ISO, IEEE. В стандартах описано все, чтоб строить отличные большие устойчивые системы.
Если бы этот процесс был формализован, то этот метод можно было применить к любой другой проблемной области. )) За метод нужно платить только один раз.
UFO just landed and posted this here
Перевод статьи из ссылки: kholeg.wordpress.com/2006/11/20/они-пишут-правильную-вещь
Скрытый текст
Точно помню, что читал это где-то ещё, но найти смог только этот.
Keep It Simple, Stupid!
UFO just landed and posted this here
Архитектурные подходы идут по спирали: на одном витке преобладают формальные подходы(uml, паттерны, формализованный подход), на другом витке — неформальные(к которым можно отнести вариаци tdd, user story map знаменитого Jeff Patton). В конечном итоге, как мне кажется, архитектура и в самом деле подбирается под команду(чтобы не переучивать всех на очередной язык разметки unm, bpmn & etc), либо же команда подбирается со знанием нужных архитектурных подходов.
Мое мнение — все зависит от размеров проекта и строгости требований. Если вы разрабатываете для НАСА, боюсь — выбора у вас нет. Если вы разрабатвыаете для военки — выбора нет. Если вы разрабатываете для медицины — выбора нет. Но если вы пилите высоконагруженную систему с высоким порогом допущения — то вам проще работать в менее формализованных требованиях, привлекая новых специалистов под этой или может быть довольно часто меняя подходы и проверяя то или иное решение.
Мое мнение — все зависит от размеров проекта и строгости требований. Если вы разрабатываете для НАСА, боюсь — выбора у вас нет. Если вы разрабатвыаете для военки — выбора нет. Если вы разрабатываете для медицины — выбора нет. Но если вы пилите высоконагруженную систему с высоким порогом допущения — то вам проще работать в менее формализованных требованиях, привлекая новых специалистов под этой или может быть довольно часто меняя подходы и проверяя то или иное решение.
Sign up to leave a comment.
Архитектура программного обеспечения переоценена, простой и понятный дизайн — недооценен