Очень у меня смешанное отношение к архитекторам (естественно софтверным).
С одной стороны, без них как-бы тяжко… Особенно, когда проект становится большим, все программисты погрязают в каких-то деталях своих частей проекта и нужен кто-нибудь, кто взглянет на это все сверху и скажет…. э… как у вас все запущенно, а давай-те выделим три системы, введем новый тип объектов и тогда наступит всем счастье.
Но, вот, что меня убивает на корню, когда архитектор простейшую операцию а-ля “почистить зубы” начинают обсмаковывать. А ведь можно почистить не только зубы, да и зубы можно не только почистить но и прополоскать. Итого, давайте введет объект действия и тип действия. Да, а ведь еще есть и цель действия. Тоже, для обобщения введем ее туда. И все эти действия объект может делать над субъектом. Итого, получаем эдак 3-4 разных сущности, которые посылают друг другу сообщения. Ну и само собой, все это может быть распределенным, если например дантист чистит чужую вставную челюсть, так что все это построим на базе SOA.
Почему космические архитекторы? Да потому, что если обычные архитекторы смотрят сверху вниз на код, с высоты многоэтажки, то эти настолько абстрагируются от всего, что уходят в какие-то занебесные космические области, по абстрагированию.
Да, это другая крайность.
Именно поэтому я считаю, что все архитекторы должны выделять какой-то кусок собственного времени – и программировать реальный проект.
А чувство необходимого уровня абстракции есть не всех, это да.
Да, работа над реальным проектом “подрезает” полет мысли
Хотя все равно частенько у них это выплескивается в вопросах организации работы и т.п.
У Джоэла (Joel Spolsky) тоже на эту тему была заметка.
http://www.joelonsoftware.com/items/2008/05/01.html
Тю, все хорошее до меня написано… Я из третих рук услышал эту фразу и мне она понравилась, так что решил употребить.
Удивительно, но на эту статью я никогда не попадал, хотя в свое время прочем кучу того, что он написал.
Есть, конечно, крайности наверно, но вообще, если архитектор не посмотрит на проект абстрагируясь от кода изначально, то потом именно и получается “э… как у вас все запущенно, а давай-те выделим три системы, введем новый тип объектов и тогда наступит всем счастье”. А ведь если запланировать архитектуру и предусмотреть все масштабируемые задачи изначально, то последствий закапывания в свой код у программистов можно избежать.
, всё что надо сделать архитектору изначально(или же руководителю проекта) это определить нужно делать эту операцию масштабируемой или же это не нужно и не может понадобиться.
Зубы можно почистить одному человеку или же 10..1000, а у каждого человека может быть от 1 до 35 зубов
в общем, крайности это плохо, конечно, но если не абстрагироваться от кода, то как правило потом жизнь заставит “взглянуть сверху” и будет мучительно больно от осознания как всё запущено и сколько надо переписать
>. А ведь если запланировать архитектуру и предусмотреть все масштабируемые задачи >изначально, то последствий закапывания в свой код у программистов можно избежать.
Вот это лучший метод угробить свой проект. Как только идет попытка предусмотреть все, то результатом этого становится бесконечное планирование.
Всё предусмотреть никому ещё не удавалось
просто обычно получается так, что не предусматривают вообще _ничего_ и тогда доработка и масштабирование становится pain in the ass для всех.
должна быть какая-то золотая середина, потому что любая крайность опасна
С такой постановкой вопроса согласен. Хотя я сейчас склонен ближе к agile стороне, то есть решать проблемы по мере их поступления.
Хотя безусловно, если четко видишь, что роешь себе яму, то стоит это решать таки заранее.
Плагиат Джоэла спольски ?
Выражение “космические архитекторы” уже давно стало нарицательным. Благодаря Спольски.
А вообще этот вопрос из разряда тех, которые нужно периодически поднимать. И я не вижу в этом ничего плохого.
Чуть вышен написал. Удивительно, но я до этого его не слышал и пришло через третии руки ко мне, я даже не подозревал что оно настолько нарицательное.
Век живи – век учись!
А вообще приятно, когда собственный блог помогает узнавать много нового.
Безусловно.
Вообще, во многом мне нравиться “обкатать” какие-то идеи и мысли в блоге.
Как мне кажется, архитектор не должен думать на уровне объектов и сущностей.
Его уровень – системы и подсистемы.
Спорно. Скажем так, зависит от размера продукта.
Естественно какой-нибудь главный архитектор в Microsoft должен думать на уровне продуктовых линеек и как они должны с друг другом взаимодействовать.
Но архитектор в средней фирме, о сущностях таки должен дома.
Я так себе представляю, что архитектор – это прежде всего функциональная роль, а не конкретный человек. Если в “средней” фирме он совмещает несколько ролей – это другое дело.
Конечно, из-за разного понимания термина “архитектура” можно приписывать разные обязанности архитектору. Но я так понимаю, что проектирование структуры приложения (классы и сущности, паттерны и прочее) – это немного другое. Архитектор определяет состав подсистем (подсистема работы с документами, подсистема печати, подсистема экспорта/импорта, подсистема журналирования и т.п.), все остальное (как это реализовать) – дело техники.
Что касается продуктовых линеек – не думаю, что термин архитектор тут уместен в том контексте, как его принято понимать у девелоперов. Хотя, Билл Гейтс был (остается?) “архитектором” в MS
Черт его знает… уж очень общий термин.
В wikipedia там целый список написан:
http://ru.wikipedia.org/wiki/%D0%90%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D0%BE%D1%80_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D1%8F
То, что там написано таки ближе к вашему, чем к моему определению.
С таким же толком обозвать архитектором можно не только софтверных менеджеров. Тут и Президент подойдет и Премьер, и директора и менеджеры любой фирмы. Как ни называй, главное что-бы результат от их работы был хороший. А дураки всюду попадаються. Без различия в должностях. Тут уж ничего не попишешь.
Так везде сейчас предлагают. Попросишь сделать стрижку, так тебе и брови хотят красить. На их взгляд они не такие красивые, как они могли бы сделать. А мне это не надо, мне нравится так, как есть… Ставим конкретную задачу.