Category: архитектура

Category was added automatically. Read all entries about "архитектура".

Об архитекторе

Небольшая заметка о том, что это за роль такая и кто это вообще должен быть такой, чтобы от него была польза. А то тоже проясняют уже лет 20, и все нихрена.

Вот в этом определении архитектуры...
*Архитектура* - это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.

...самое важное - это явный акцент на том, что суть архитектуры в правилах для людей. Предмет архитектуры, как таковой - не технологии, а люди, которые их делают, и именно они стоят в центре.

Архитектор несет непосредственную личную ответственность не "за систему", а за продуктивность всех членов команды в их повседневной работе. Его обязанность - усиливать людей, снабжая их необходимыми технологиями для выполнения повседневных задач по проектированию системы. И оказывать им всестороннюю поддержку, если у них будут с этими технологиями какие-либо сложности.

Именно так, и никак иначе. Не придумывать как делать систему под конкретные требования. А давать людям методику (набор правил), руководствуясь которым конкретные эти люди (а не какие-то там абстрактные) смогут проектировать эффективнее.

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

Я видел много людей с этим титулом. Настоящий архитектор не просто умеет писать код, он в состоянии исправить в этом коде вывернутый мистический баг, который приводит людей в суеверный трепет. Настоящий архитектор - он сцуко гуру и рыцарь без страха и упрека, к которому вы с этим багом придете, и скажете - "Обиван, ты наша последняя надежда".

Штука в том, что если он мудак - вы к нему просто не придете.

ЗЫ: А мудак - благодаря Стенфордскому профессору Бобу Саттону - теперь вполне научное понятие. Я лично считаю, вся наука организационного поведения давно к этому шла: https://en.wikipedia.org/wiki/The_No_Asshole_Rule

Часть 1. Об архитектуре и фреймворках

Для начала в очередной раз внесем ясность в вопрос, что же такое архитектура. Сколько десятилетий термин в ходу, и в него постоянно вносят ясность - без особого толка. Однако, коль скоро мы собираемся о ней говорить, это совершенно необходимо сделать в очередной раз. Иначе будет просто не понятно, о чем речь.




Архитектура* - это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.


Результат проектирования - это как правило некоторая высокоуровневая структура системы, которую тут же снова называют словом "архитектура" (ну вот мало у нас слов, и те все иностранные), а потом начинают ломать голову, чем же это отличается от "дизайна", и пр. И накидывать при этом кучу умняка. Мы не будем. Вместо этого:


  • Мы будем стараться использовать для обозначения нашего понимания термин "Common Design Principles".

  • Постараемся разобраться в определении, и как оно соотносится с фреймворками и структурами. Увидете, как только вы начнете думать об архитектуре как о правилах много встанет на свои места.

Collapse )

cartoon

Мой доклад на SoftwarePeople

Это будет доклад о том, что вы всегда хотели знать, но боялись спросить. Это доклад о проектировании. Главных тезиса два.

1) Хорошо организованная группа профессионалов всегда проектирует лучше, чем один мегаумный архитектор. Я собираюсь это настолько хорошо обосновать, что это близко к "доказать".
2) Менеджер может эффективно направлять и контролировать процесс проектирования, в том числе надежно отмечать его прогресс. Я собираюсь не просто это сказать, а наглядно и просто показать - как, так, что вы сможете это повторить. Ведь понимание требуется для действия - или нафиг оно не нужно, такое негодное понимание.

В сущности, без участия менеджера (руководителя группы, отдела, whatever) групповой процесс проектирования невозможен. Это не основная мысль, это то, что станет понятно по ходу изложения.

Да, доклад общеинженерный. Это обобщение. То есть, техника, и взгляд на процесс проектирования, представленные в докладе, не специфичны для программирования. Они одинаково хорошо работают на микроэлектронике (это разработка довольно-таки сложных микросхем), просто электронике (это разработка уровня печатных плат), и механическом дизайне (а это, в моем случае, серверные корпуса). Проверено.

P.S.: Мне повезло - в разные моменты жизни мне приходилось лично заниматься всеми из перечисленных, непохожими друг на друга, областями. :) При этом, мне не придется рассказывать вам про них, и пугать вас тем, в чем вы не разбираетесь.

Ну, например, такими страшными и ужасно авторитетными вещами, которых на деле толком никто не знает - типо как тойота делает свои машины, или как запускать в космос ацкие ракеты, или, например, как на самом деле делаются микросхемы (это знаю, но не скажу - не имеет значения). Ни грамма этого булшыта. Более чем достаточно той области, в которой вы разбираетесь лучше всего. Программирования.

P.P.S.: На тот случай, если кто не знает, что такое SoftwarePeople. www.softwarepeople.ru. Регистируйтесь.
cartoon

Про трекеры, планирование, и agile

Жизнь проекта можно условно разделить на два этапа.

Сначала проблемы крупные, и их немного. Их не всегда легко понять, и нащупать к ним подход, но удержать в голове - легко. По мере продвижения, проблемы становятся все более мелкими, и специфичными.

И вот - наступает момент, когда проблемы становятся мелкими, разрозненными, их становится очень много, но - они становятся очень понятными и конретными. Они, при этом, уже не помещаются в голове, и для управления разработкой необходимо использовать тикет-трекер. Как для дефектов, так и фичреквестов.

То есть, трекер надо использовать не "потому, что надо", а потому, что с ним лучше, чем без него. Меньше путаницы. Проект, при этом, может быть еще далек от завершения.

Но это означает, что психологически важный первый этап, на котором ликвидируется основная неопределенность, пройден - и вы уже на финишной прямой. Наблюдать это - замечательно.

ЗЫ: Казалось бы, причем тут Agile. А при том, что управление разработкой через трекер - очень близко по духу к Scrum. По сути то же, только в профиль, и без ритуальной составляющей. Когда архитектура готова и проверена (работающим кодом проверена, и именно это описывается как фаза 2) - от скрам-подобных штук вреда не будет. А в приложениях, где критично юзабилити - будет прямая польза.

А вот чтобы была польза, и не было вреда - надо, ironically, как следует спланировать работу в начале, чтобы не заниматься на первом этапе ерундой, которую можно сделать на втором. Да-да, я опять про квадрат риск-приоритет Кантора. Наше все.
cartoon

MS P&P Summit

Случится 13 сентября. Это Майкрософтская конференция для менеджеров, архитекторов, и разработчиков. Она модная и дорогая. Стоит 20К руб.

Помимо ништяков (реально клевые рюкзаки + Microsoft Visual Studio for ISV + 20% скидка при указании ключевого слова gaperton при регистрации), о конференции можно сказать следующее:

Основная тема - облачные вычисления. Майкрософт присылает двух заграничных перцев:
- Крис Кайзер. Занимается разработкой практик внедрения SharePoint.
- Эухиньйо (!) Паче. Не кто-нибудь, а Senior Program Manager. Отвечает за построение приложений на Azure, и Windows Phone 7.

Полный список докладчиков:
http://pnpsummit.ru/speakers.aspx

Программа:
http://pnpsummit.ru/schedule.aspx

Про скидку 20% от себя я уже говорил? Точно, говорил - в разделе "ништяки" :).

Короче, вот. :)
cartoon

Пиши код

У нас в СQG существовала ежегодная процедура аттестаций. Раз в год вам выдают форму, заполнив которую, вы можете письменно рассказать компании, насколько вы круты, и как много сделали за отчетный период, а компания, во-первых - высказывает в вам в ответ (опять же письменно) свое мнение о вас, и во-вторых, пересматривает вам зарплату в сторону увеличения. Или нет. Ну, или еще что-нибудь делает. В общем, момент истины.

Короче говоря, была в CQG процедура аттестаций. В аттестации вы можете написать много чего, в том числе и наболевшее. Скажем, вы можете написать, помимо отчета о своих достижениях, что вас достало текущее положение вещей, и вы хотите что-то изменить. Как это и сделал однажды я. И смотрит ваши аттестации, в первую очередь, конечно, ваш начальник. А начальником моим, как вы может быть уже знаете, прочитав мою статью "Читай код [cука]", являлся замечательный человек и гениальный архитектор Тол Корин.

Я, прошедший, как мне уже казалось, огонь, канализацию, и медные трубы, и уже способный без постоянного код ревью от Тола вносить правки в центральный системный код (поначалу было страшно), не допуская пр этом глупых ошибок, желал более высокого полета. Я написал в очередной аттестации примерно следущее. Типо, у меня мысли (у меня, реально, дельные мысли были - дохренища). Мне нужно время, чтобы думать. И люди, чтобы реализовывать мои идеи, и освободить мне время для того, штоб были еще мысли. Больше мыслей.

Ну, короче, архитектор я уже был по всем пронятиям. Умел уже не только код писать, но и читать. Не только понимать мысль автора кода, но и продолжать ее. Мог обходиться минимумом правок в чужом коде, для того, чтобы достичь своей цели. Короче, наука Тола пошла впрок, я, наконец, действительно мог, и я осознавал то, что я мог. Я крут. И я прям так в аттестации и написал. И еще я сказал, что мне для успеха проекта надо выделить Бойца (это никнейм одного сотрудника), а не этого, пнимаешь-ли, неизвестного мне разработчика, которого мне уже планируют дать.

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

"Влад должен уметь и _хотеть_ работать не с теми людьми, с которыми ему хочется, а с теми, которых назначит менеджмент"

"Компания не видит возможности удовлетворить желание Влада, и освободить его от кодирования. Его требования недопустимы".

Короче говоря, я был близок у истерике (у меня была в те годы довольно тонкая душевная организация), я подозревал разного рода козни, но, довольно скоро Тол приехал в Москву, и окончательно разорвал мне мозг. Он сказал - "Влад, ответ на твою аттестацию написал я. Никто другой не приложил к нему руку".

- Тол?!
- Да, Влад, - спокойно говорит Тол, глядя мне в глаза.
- Но почему?!
- Влад, ты хорошо понимаешь, что имено ты написал в аттестации? Кажется, ты написал, что тебе нужны специальные люди для кодирования, или я неправильно тебя понял?
- Ну да! Тол, сейчас мы пректируем новую подсистему данных, и если я буду кодировать, у меня не останется время на продумывание всей подсистемы! Мне нужны люди!
- Это недопустимо.
- Тол, да как ты не понимаешь...
- ...Влад. Дай я скажу, - спокойно говорит Тол, - Я старше тебя, и наблюдал за свою жизнь много "архитекторов" и "дизайнеров", которые не пишут код. Влад, они очень быстро становятся очень полохими архитекторами и дизайнерами. Год или два - и все.
- Правда?
- Точно. Они довольно быстро теряют связь с реальностью. Когда ты не пишешь код, ты не получаешь обратной связи, ты не видишь, во что выливаются на практике твои мысли. Когда ты не правишь багов, и не сидишь на поддержке, ты лишаешь себя важнейшего элемента обратной связи - ты не видишь, какие решения оказались плохи, а какие хороши. А обратная связь - это сама суть инженерии. Ты ведь уже заметил, что наша база данных по дефектам содержит значительную часть требований? Это жизнь. Так всегда происходит. Твое желание иметь группу вполне понятно, но ты не должен переставать писать код и работать с ним.
- Конечно, Тол, как ты такое мог подумать? Конечно я не хочу совсем отказаться от написания кода, - поспешно и неискренне говорю я.
- То есть, я неправильно тебя понял, я ошибся, и ты совсем не имел в виду того, что ты перестанешь писать код и исправлять дефекты? Так?

Тол, задавая мне этот вопрос, внимательно смотрит мне в глаза. Я понимаю, что именно этого я на самом деле и хотел, и также я понимаю, что соврать сейчас не получится. Да и не могу я врать своему учителю, глядя в глаза. Надо думать, и принимать решение.

- Да, Тол. Я действительно не хочу переставать писать код, - с усилием говорю я, - я буду его писать.

- Отлично, Влад. - сказал Тол, откинувшись на спинку стула, и очень натурально сделав вид, что он на самом деле меня неправильно понял, хотя я был на сто процентов уверен, что он понял меня правильно, - Это я и хотел от тебя услышать. В самом деле, я рад что ошибся.

- Но я хочу работать с Бойцом! Что в этом плохого? А вы собираетесь дать мне черт знает кого! Я с ним уже работал, и у нас здорово получается! У нас синергия! Ты же видел результаты предыдущего проекта!
- Влад. Боец занят в другом проекте. Он нужен там. Мы даем тебе другого специалиста.
- Тол, но у меня отлично получается работать с Бойцом!
- Влад. По твоему, в чем проявляется профессионализм менеджера? Ведь ты становишься менеджером, когда у тебя появляется группа.
- В чем?
- Он должен уметь управляться с людьми, а не только с компьютерами. Причем, с теми людьми, которые есть в наличии, а вовсе не с теми, с которыми ему удобно, и которые ему нравятся. Это как широта ролевого диапазона у актеров. Хороший актер умеет играть разные роли, а не только те, которые подходят к его характеру. Влад, в жизни у тебя не будет возможности выбирать лучших и удобных. Учись обращаться с теми, кто есть. И я скажу тебе больше - люди не всегда такие, какими кажутся на первый взгляд. Возможно, ты откроешь в них новые грани. И делать это, теперь, когда у тебя будет группа - твоя работа.

- Хорошо, Тол, - пристыженно сказал я. Тол понимал меня лучше, чем я сам пронимал себя. Может быть, потому, что в молодости он был таким же? - Ты, как всегда, оказался прав, черт возьми. Я буду писать код, Я буду учится. Но, таки, получается, что основная просьба моей аттестации будут удовлетворена? У меня будет группа?

- Ну конечно, Влад. Скажу честно - мне нравится с тобой работать, и я рад, что мы поняли друг друга. Главное - не переставай писать код.
cartoon

Читай код

Эту статью я написал по просьбе организаторов специально для сайта конференции software people. Опубликована здесь: http://www.softwarepeople.ru/press/articles/09/

Когда я заступил на работу в компанию CQG в конце 1999 года, у меня уже был, как мне казалось, достаточно большой опыт в разработке ПО – три года создания корпоративных приложений БД под заказ. Мне уже казалось, что я очень много знаю и умею, и я был крайне самоуверен. Однако, возникла некоторая загвоздка – CQG не являлось приложением баз данных, основанном на комбинации готовых сторонних технологий, таких как MS SQL сервер, Visual Basic, Delphi, JavaScript, и 1C – к которым я привык. Меня потряс объем приложения – почти 50 мегабайт основных исходников, не считая свистулек, прибамбасов, разного рода служебных и системных штук, по размеру почему-то превосходящих размер основных исходников.

Collapse )
cartoon

Gaperton on Software Architecture

Что такое архитектура ПО, чем она отличается от "дизайна", и что же все-таки является входными данными для разработки архитектуры. Дискуссия на РСДН по данному вопросу была изумительна.

Оказывается, распространено мнение, что мол принципиальных отличий между "архитектурой" и "дизайном" нет. Некоторые идут дальше, и заявляют, что "архитектура" целиком подчинена [текущим] требованиям проекта, причем - функциональным требованиям. Наиболее радикальная точка зрения - архитектура ваще определяется пользовательским интерфейсом, или - внешним интерфейсом. Отдельная группа товарищей аппелирует к тяжелым определениям из мануалов и методологий, пытаясь найти истину в них.

Надо расставить точки над i по крайней мере в моей позиции. Надо для начала определить, что такое "архитектура", и разобрать это определение на конкретных примерах. То, чего, почему-то, сильно не любит публика на РСДН. Странно, но по факту оказывается так. Ок, essense of software architecture минут за 10.

Collapse )
cartoon

И снова об архитектуре

На самом деле, довольно спорная тема. На которую серьезно говорить не получается :) Потому, что люди жгут.

http://rsdn.ru/forum/message/3306259.1.aspx
Комментируем тезис:
"Функция от требований — UI. Функция от всех аспектов UI — архитектура."

G>>Что мы будем делать с этим определением "всем известного понятия" в случае, когда у приложения либо нет UI в традиционном понимании, или он, этот UI, играет совершенно второстепенную роль, а вот зато архитектура — есть? Возьмем к примеру сервер IP-телефонии. Сервер колл-центра. Сервер базы данных. Веб-сервер.
A>Заменим UI на внешний интерфейс системы. И все опять становиться на свои места.

Делаем медицинский диагностический прибор. Внешний интерфейс — электрические присоски, цепляющиеся на человека, плюс принтер, печатающий диагноз. Диагноз — plain text. Прибор запускается одной кнопкой. Все, внешний интерфейс системы я описал — спроектируйте архитектуру системы пожалуйста. Она у нас прямое следствие внешнего интерфейса.

A>А если заняться словоблудием, то UI = User Interface, а юзер это не только человек, но и IP-телефон, коммутатор, приложение использующее БД, броузер.

Конечно. Вы мне прям глаза на мир открыли — я раньше был слеп. Оказывается, юзер АТС — это телефон, юзер телевизора — это инфракрасный пульт, юзер DVD-диска — это DVD проигрыватель, а юзеры компьютера — это мышка и клавиатура. А юзер раутера — страшно сказать — Сам Интернет, да не будет его имя помянуто всуе. Всего этого безусловно достаточно, чтобы спроектировать архитектуру всех перечисленных устройств и их встроенного ПО. Интересно только, кто юзер микросхемы, стоящей в DVD-проигрывателе. Есть у нее архитектура, или нет?! Значит и юзер должон быть!! То-ли встроенное ПО, то-ли разработчики DVD-плеера, то-ли злополучный пульт дистанционного управления, то-ли печатная плата, то-ли микросхема памяти с блоком питания, теперь уж не поймешь. Я, как Ваш ярый последователь, больше склоняюсь к печатной плате.
cartoon

Что такое архитектура

Интересная дискуссия на РСДН.

Тред дискуссии с моим участием:
http://rsdn.ru/forum/message/3288567.1.aspx
Но и вокруг интересно.

Здравствуйте, Sinix, Вы писали:

S>Пока из общения с товарищами выходит что проектирование чисто от требований — нормальный подход. Смущает две вещи — то, что требования направлены на решение текущих задач и строить на их основе архитектуру системы — как то не того...
S>и то, что эти вопросы в принципе не подымаются в "тру" методологиях — такие вопросы отдаются на откуп архитекторам (если он есть) или обходятся кучей методик (не будем о DDD — про неё даже Эванс не может уверенно сказать что оно такое, куда уж простым смертным )

"Учителя разных школ психотерапии имеют больше общего между собой, чем их ученики — с ними". Слишком много придаете значения методологиям и букве. Они на самом деле все об одном, фундаментальной разницы между ними нет.

Первое — что такое "архитектура". Нет единого понимания данного термина, что служит поводом для спекуляций.

Определяем три термина. Архитектура, дизайн, детальный дизайн.

Детальный дизайн — алгоритмы и структуры данных.
Дизайн — разбиение функциональности по компонентам, модулям, или классам.
Архитектура — то, что не перечисленное. Комплекс базовых технологий, на которые опирается решение, плюс — идиом или паттернов проектирования, заложенных в "ядро", "фреймворк", или философию построения системы. Если перечисленное вообще есть. Скажем, вы решили, что сериализация объектов у вас будет всегда в XML — это архитектурное решение.

Дизайн и архитектуру часто путают.

S>Это я дурак и что-то упустил или это такая модель бизнеса — "Сделаем всё за деньги. Не понравилось — платите, не можете сформулировать хотелки — платите, ошиблись — платите"? Потому что я не могу больше придумать доводов, зачем так опровергать тот факт, что архитектура не может быть построена на информации о сиюминутных целях.

Разумеется, надо принимать во внимание как требования, так и технические ограничения, так и ваши возможности (знаем Java — архитектура будет базироваться на Java а не дотнет). Будущие требования тоже имеют значение. Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли?

И следующий пост - плюс ответ на него.
_________________________________
S>Ок. Принято. Вопрос: должен ли дизайн (с архитектурой вроде всем ясно) проектироваться исключительно на основе требований? (Вопрос провокационный, больше чтобы было от чего идти). Если нет, как можно компенсировать перекос дизайна из-за учёта только актуальных требований?

Да должен. Уточню определение, чтобы избежать множественного толкования.

Архитектура — есть набор ограничений для дизайна. Именно ограничений, в чем они выражены — в виде существования некоторого кода, возможностями которого надо пользоваться, или же правил, которым надо следовать — неважно.

Архитектура реализует класс требований. Это — "стратегический дизайн", цель которого — выигрышь в долговременной перспективе, а не в контексте данного проекта с данными требованиями.

Дизайн — исходит их текущих требований, плюс ограничения, диктуемые архитектурой. Если ограничения нам сильно прям мешают, можно внести правку архитектуры. Целесообразность правки решается по месту по критерию riskk-value-cost.

S>Интересно также ваше мнение про модель бизнеса — я не могу придумать других рациональных объясенений такой агрессивной пропаганде решений "здесь и сейчас". Или это только моя мнительность и кто-то кроме вас говорил о "надо принимать во внимание как требования, так и технические ограничения, так и ваши возможности" и "Будущие требования тоже имеют значение"?

По моему это простой здравый смысл. Любой реалистичный план исходит в первую очередь из ваших возможностей. Если в эти возможности не входит снятие технических ограничений — надо учитывать и их. Потому, что вложение в технологию — дорогостоящая штука, это стратегическое решение. Как впрочем и ее разработка. А что требований — так нафига делать то, что никому не нужно? Архитетура — это стратегический дизайн, который по сути есть набор ограничений для тактического дизайна. Этим все сказано ИМХО.

Другими словами, я понимаю архитектуру как результат и основной составной элемент процесса стратегического планирования. Составной элемент — потому, что этот процесс непрерывен, и архитектура должна корректироваться по ходу времени, отражая представление о будущем, угрозах, рисках, и возможностях. Текущая архитектура может отличаться от "эталонной", которая отражает текущие представления, и ничего страшного в этом нет — работы по рефакторингу привязываются к плану текущих работ, диктуемых текущими требованиями, но — вектор направления в дизайне всегда в сторону "эталонной" архитектуры.