97 Этюдов Для Архитекторов Программных Систем

7/18/2019 97 Этюдов Для Архитекторов Программных Систем

http://slidepdf.com/reader/full/97-55cf9755550346d033910ebd 1/218







97 этюдов

для архитекторовпрограммных систем

Опыт ведущих экспертов

Нил Форд, Майкл Хайгард, Билл де Ора и др.

Санкт-Петербург – Москва 2010



Серия «Профессионально»

Нил Форд, Майкл Хайгард, Билл де Ора и др.

97 этюдов для архитекторовпрограммных систем

Перевод Е. МатвееваГлавный редактор А. ГалуновЗав. редакцией Н. МакароваНаучный редактор С. ТепляковРедакторы В. Подобед, Е. ТульсановаКорректор О. МакароваВерстка Д. Орлова

Форд Н., Хайгард М., де Ора Б.

97 этюдов для архитекторов программных систем. – Пер. с англ. – СПб.:Символ-Плюс, 2010. – 224 с., ил.

ISBN 978-5-93286-176-9

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

Архитектор ПО выполняет роль посредника между командой разработчикови бизнес-руководством компании, поэтому чтобы добиться успеха в этой про-фессии, необходимо не только овладеть различными технологиями, но и обе-спечить работу над проектом в соответствии с бизнес-целями. В книге более 50

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

ISBN 978-5-93286-176-9ISBN 978-0-596-52269-8 (англ)

© Издательство Символ-Плюс, 2010Authorized translation of the English edition © 2009 O’Reilly Media Inc. This trans-

lation is published and sold by permission of O’Reilly Media Inc., the owner of all rightsto publish and sell the same.

Все права на данное издание защищены Законодательством РФ, включая право на полное или час-тичное воспроизведение в любой форме. Все товарные знаки или зарегистрированные товарные зна-ки, упоминаемые в настоящем издании, являются собственностью соответствующих фирм.

Издательство «Символ-Плюс». 199034, Санкт-Петербург, 16 линия, 7,тел. (812) 324-5353, www.symbol.ru. Лицензия ЛП N 000054 от 25.12.98.

Подписано в печать 30.03.2010. Формат 70×90 1/16. Печать офсетная.Объем 14 печ. л. Тираж1600 экз. Заказ №

Отпечатано с готовых диапозитивов в ГУП «Типография «Наука»199034, Санкт-Петербург, 9 линия, 12.



Оглавление

Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Не ставьте свое резюме выше интересов клиента . . . . . . . . . . . . . . . . . . . . . . . 16

Íèòèí Áîðâàíêàð

Снижайте неотъемлемую сложность,устраняйте второстепенную сложность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Íèë Ôîðä

Возможно, ваша главная проблема не в технологиях . . . . . . . . . . . . . . . . . . . .20

Ìàðê Ðýìì

Общение – король, ясность и лидерство – его верные слуги . . . . . . . . . . . . . . .22

Ìàðê Ðè÷àðäñ

Производительность приложения определяется его архитектурой . . . . . . . . .24

Ðýíäè Ñòàôôîðä

Ищите истинный смысл требований . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Ýéíàð Ëàíäðå

Встаньте! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Óäè Äàõàí

Сбои неизбежны . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Ìàéêë Íàéãàðä

Вы ведете переговоры чаще, чем вам кажется . . . . . . . . . . . . . . . . . . . . . . . . . .32Ìàéêë Íàéãàðä

Используйте количественные критерии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Êåéò Áðàéòóýéò

Одна строка рабочего кода стоит 500 строк спецификации . . . . . . . . . . . . . . . 36

Ýëëèñîí Ðýíäàë



6 Оглавление

Решений на все случаи жизни не существует . . . . . . . . . . . . . . . . . . . . . . . . . . 38


Думать о производительности никогда не рано . . . . . . . . . . . . . . . . . . . . . . . . . .40

Ðåáåêêà Ïàðñîíñ

Создание архитектуры как искусство баланса . . . . . . . . . . . . . . . . . . . . . . . . . 42


Сделать наспех и сбежать – преступление . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Íèêëàñ Íèëüññîí

Решений может быть несколько . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46


Всем заправляет бизнес . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

Äýéâ Ìóðõåä

Простота лучше универсальности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Êåâëèí Õåííè

Архитектор должен быть практиком . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

Äæîí Äýâèñ

Обеспечьте непрерывную интеграцию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Äýâèä Áàðòëåòò

Старайтесь не нарушать график . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

Íîðìàí Êàðíîâåéë

Архитектурные компромиссы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58


База данных как Крепость . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Äýí ×àê

Руководствуйтесь неопределенностью . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62


Проблемы могут быть больше, чем их отражение в зеркале . . . . . . . . . . . . . . .64 Äýéâ Êóèê

Повторное использование зависит не только от архитектуры . . . . . . . . . . . . . 66

Äæåðåìè Ìåéåð

«Я» в архитектуре не существует . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

Äýéâ Êóèê



7Оглавление

Посмотрите с высоты 300 метров . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Ýðèê Äîðíåíáóðã

Пробуйте, прежде чем сделать выбор . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72


Разберитесь в предметной области . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


Программирование – это часть процесса проектирования . . . . . . . . . . . . . . . . 76


Предоставьте разработчикам независимость . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Ôèëèï Íåëüñîí

Время меняет все . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80


«Архитектор программного обеспечения» пишется со строчной буквы . . . . . 82

Áàððè Õîêèíñ

Масштаб – враг успеха . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Äýéâ Êóèê

Ответственное руководство важнее внешнего впечатления . . . . . . . . . . . . . . . 86


У программной архитектуры есть этические аспекты . . . . . . . . . . . . . . . . . . . 88


Небоскребы не масштабируются . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90


Неоднородность побеждает . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

Ýäâàðä Ãàðñîí

Не забывайте о производительности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

Êðåéã Ðàññåë

Проектирование в пустоте . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96Ìàéêë Íàéãàðä

Изучите профессиональный жаргон . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98


Правила диктует контекст . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100





Гномы, эльфы, волшебники и короли . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Ýâàí Êîôñêè

Учитесь у архитекторов зданий . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104


Боритесь с повторениями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106


Добро пожаловать в реальный мир . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108

Ãðåãîð Õîï

Не контролируйте – наблюдайте . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Ãðåãîð Õîï

Архитектор Янус . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112


В центре внимания архитектора – границы и интерфейсы . . . . . . . . . . . . . . 114


Поддерживайте разработчиков . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116

Òèìîòè Õàé

Записывайте свои обоснования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118

Òèìîòè Õàé

Сомневайтесь в допущениях – особенно в собственных . . . . . . . . . . . . . . . . . 120

Òèìîòè Õàé

Делитесь знаниями и опытом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Ïîë Ó. Õîìåð

Патология шаблонов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

×åä Ëàâèíü

Не увлекайтесь архитектурными метафорами . . . . . . . . . . . . . . . . . . . . . . . . . .126

Äýâèä Èíã

Уделяйте пристальное внимание поддержке и сопровождению . . . . . . . . . . .128Ìí÷åäèçè Êàñïåð

Приготовьтесь выбрать два из трех . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Áèëë äå Îðà

Принципы, аксиомы и аналогииважнее личных мнений и предпочтений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Ìàéêë Õàðìåð




Начните с ходячего скелета . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Êëèíò Øåíê

В основе всего – данные . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136


Простое должно быть простым . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

×åä Ëàâèíü

Архитектор – прежде всего разработчик . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Ìàéê Áðàóí

Окупаемость как фактор проектирования . . . . . . . . . . . . . . . . . . . . . . . . . . . .142

Äæîðäæ Ìàëàìèäèñ

Ваша система станет унаследованной –

учитывайте это при проектировании . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144 Äåéâ Àíäåðñîí

Когда видите единственное решение, спросите других . . . . . . . . . . . . . . . . . .146

Òèìîòè Õàé

Осознавайте последствия изменений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Äóã Êðîóôîðä

Архитектор должен разбираться в оборудовании . . . . . . . . . . . . . . . . . . . . . . . 150

Êàìàë Âèêðàìàíàÿêå

«Срезание углов» сейчас обойдется слишком дорого потом . . . . . . . . . . . . . . 152

Ñêîò Ìàêôè

Лучшее – враг хорошего . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Ãðåã Íàéáåðã

Остерегайтесь «хороших идей» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156


Хороший контент порождает хорошие системы . . . . . . . . . . . . . . . . . . . . . . . . 158

Çóáèí Âàäüÿ

Бизнес и недовольный архитектор . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160

×åä Ëàâèíü

Проверяйте решения на прочность по ключевым характеристикам . . . . . . . 162

Ñòèâåí Äæîíñ

Проектируйте только то, что можете запрограммировать . . . . . . . . . . . . . . . . . 164

Ìàéê Áðàóí




«Что значит имя?», или Как роза превращается в капусту . . . . . . . . . . . . . . . . .166

Ñýì Ãàðäèíåð

Четко определенные задачи решаются качественно . . . . . . . . . . . . . . . . . . . .168


Необходимо усердие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Áðàéàí Õàðò

Отвечайте за свои решения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

È ×æîó

Не мудрствуйте . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Ýáåí Õüþèò

Выбирайте оружие тщательно и не спешите его менять . . . . . . . . . . . . . . . . .176

×åä Ëàâèíü

Ваш клиент – не ваш клиент . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178

Ýáåí Õüþèò

Все будет не так, как задумано . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Ïèòåð Ãèëëàðä-Ìîññ

Выбирайте инфраструктуры, хорошо сочетающиеся с другими . . . . . . . . . . 182

Ýðèê Ãîòîðí

Подготовьте убедительное экономическое обоснование . . . . . . . . . . . . . . . . . 184

È ×æîó

Управляйте не только кодом, но и данными . . . . . . . . . . . . . . . . . . . . . . . . . . 186

×åä Ëàâèíü

Расплатитесь по техническим кредитам . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Áåðêõàðäò Õàôíàãåëü

Не спешите решать задачи . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Ýáåí Õüþèò

Стройте zuhanden-системы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Êåéò Áðàéòóýéò

Найдите и удерживайте энтузиастов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

×åä Ëàâèíü

Программы на самом деле не существуют . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

×åä Ëàâèíü




Освойте новый язык . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198


Не создавайте решения «на перспективу» . . . . . . . . . . . . . . . . . . . . . . . . . . . .200

Ðè÷àðä Ìîíñîí-Õåéôåë

Проблема пользовательского признания . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202


О важности консоме . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204

Ýáåí Õüþèò

Для пользователя интерфейс – это и есть система . . . . . . . . . . . . . . . . . . . . . . .206

Âèíàÿê Õåäæä

Лучшие программы не строят – их выращивают . . . . . . . . . . . . . . . . . . . . . . 208


Алфавитный указатель . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210



Предисловие

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

Перед вами сборник советов от архитекторов ПО со всего света. Их советы за-трагивают широкий круг тем – от предотвращения распространенных оши-бок до создания выдающихся проектных команд. В сущности, это «сборнаясолянка» из рекомендаций признанных архитекторов ПО для других архи-текторов и тех, кто хочет стать архитектором.

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

Книга «97 этюдов для архитекторов программных систем» очень сильноотличается от всех прочих книг, которые вам доводилось читать. Она быласоздана совместными усилиями более чем полусотни авторов; все они щед-

ро делились своими мыслями и советами в области проектирования архи-тектуры программного обеспечения без денежного вознаграждения. Можносказать, что эта книга следует принципам продуктов с открытым исходнымкодом в их истинном смысле. Каждый автор внес свой вклад, написав однуили несколько статей, которые затем были тщательно проработаны и отре-цензированы. Лучшие статьи были отобраны для публикации. В этом отно-шении книга похожа на программный проект с открытым исходным кодом,только здесь вклад участников – не программный код, а знания и мудрость.



13Предисловие

Разрешение на использование материалов

Использование всех материалов этой книги также осуществляется на усло-виях, сходных с условиями распространения ПО с открытым исходным ко-дом. Каждая статья находится в свободном доступе на условиях лицензииCreative Commons, Attribution 3; это означает, что вы можете использоватьотдельные статьи в своей работе, если упоминаете их авторов. Попытки пуб-ликации книг в соответствии с принципами распространения продуктовс открытым исходным кодом совершались и прежде, но все они (за немного-численными исключениями) окончились неудачей. Вероятно, это объясня-ется трудностями координации вкладов отдельных участников, если проектне имеет четкого модульного разделения. Именно модульность обеспечилауспех этой книги. Каждая статья существует независимо от других статейи ценна как в контексте сборника в целом, так и сама по себе.

Как с нами связаться

Пожалуйста, со всеми комментариями и вопросами, касающимися этойкниги, обращайтесь к издателю:

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938 (США или Канада)

707-829-0515 (международные или местные звонки)707 829-0104 (факс)

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

http://www.oreilly.com/catalog/9780596522698

Сопроводительный сайт книги, на котором размещены все тексты и полныебиографии авторов, доступен по адресу:

http://97-things.near-time.netС комментариями и техническими вопросами по поводу книги обращайтесьпо электронной почте:

[email protected]

Дополнительную информацию о книгах, конференциях, ресурсах и O’ReillyNetwork вы можете найти на сайте издательства O’Reilly:

http://www.oreilly.com



14 Предисловие

Safari® Enabled

Логотип Safari® Enabled на обложке вашей любимой книги,посвященной какой-либо технологии, означает, что книгадоступна через O’Reilly Network Safari Bookshelf.

Система Safari превосходит обычные электронные книги. Это целая вир-Safari превосходит обычные электронные книги. Это целая вир-превосходит обычные электронные книги. Это целая вир-туальная библиотека, позволяющая выполнять поиск по тысячам лучшихтехнических книг, копировать примеры кода, загружать главы и быстро на-ходить ответы, когда вам потребуется самая точная и актуальная информа-ция. Safari можно бесплатно опробовать на сайте http://safari.oreilly.com.

Благодарности

Идея книги «97 этюдов для архитекторов программных систем» родилась

не на пустом месте. Множество людей заслуживают благодарности за идеюэтой книги и ее исполнение. Я хочу поблагодарить Джея Циммермана (JayZimmerman), предложившего мне провести презентацию «10 вещей, ко-), предложившего мне провести презентацию «10 вещей, ко-торые должен знать каждый архитектор программного обеспечения» насимпозиуме «No Fluff, Just Stuff»; Брюса Эккеля (Bruce Eckel) за ведениесписка рассылки, на базе которого зародилась идея этой книги; ДжеремиМейера (Jeremy Meyer) за предложение написать книгу по материалам прос-той слайдовой презентации; Нитина Борванкара (Nitin Borwankar), пред-Nitin Borwankar), пред-Borwankar), пред-Borwankar), пред-), пред-ложившего создать общедоступный вики-сайт, чтобы все желающие моглипринять участие; участников списка рассылки Брюса, которые, не имея

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

Я благодарен также издательству O’Reilly, которое без предубеждения вос-O’Reilly, которое без предубеждения вос-’Reilly, которое без предубеждения вос-Reilly, которое без предубеждения вос-, которое без предубеждения вос-приняло идею и поддержало этот никем прежде не опробованный метод рабо-

ты над книгой. O’Reilly заслуживает благодарности и за согласие лицензиро-O’Reilly заслуживает благодарности и за согласие лицензиро-’Reilly заслуживает благодарности и за согласие лицензиро-Reilly заслуживает благодарности и за согласие лицензиро-заслуживает благодарности и за согласие лицензиро-вать весь материал на условиях продуктов с открытым исходным кодом (ли-цензия Creative Commons, Attribution 3) и предоставить свободный доступк содержимому на веб-сайте. Среди сотрудников O’Reilly мне хотелось быособо поблагодарить Майка Лукидеса (Mike Loukides), Майка Хендриксона(Mike Hendrickson), Лору Пейнтер (Laura Painter) и Лорел Экерман (LaurelAckerman). Без их помощи и поддержки этот проект был бы невозможен.



15Предисловие

В настоящее время мы (O’Reilly и я) работаем над другими проектами новойуникальной серии «97 hings», которая позволяет воспользоваться коллек-hings», которая позволяет воспользоваться коллек-», которая позволяет воспользоваться коллек-тивным разумом экспертов в различных практических областях. Управле-ние проектами, разработка программного обеспечения, архитектура дан-

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

С наилучшими пожеланиями,

Ричард Монсон-Хейфел,редактор серии «97 hings»



Не ставьте свое резюмевыше интересов клиента

Íèòèí Áîðâàíêàð

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

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

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

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

При правильно выбранном решении вы получаете довольную команду и удов-летворенного клиента, а общая напряженность работы над проектом заметно



17Не ставьте свое резюме выше интересов клиента

снижается. Часто это позволяет вам глубже изучить уже знакомую техно-логию или заняться освоением новинки в свободное время. А может быть,у вас даже высвободится время для посещения курсов живописи, о которыхвы всегда мечтали. Ваши близкие это тоже оценят – они заметят разницу

в вашем состоянии, когда вы приходите домой после работы.Всегда ставьте долгосрочные потребности клиента над своими собственны-ми краткосрочными потребностями, – и вы не ошибетесь.

В начале 1990-х Нитин Борванкар (Nitin Borwankar) работал в Ingresи Sybase, где создавал первые веб-приложения на базе SybPerl и OraPerl,а вскоре после этого – на базе ранних версий Enterprise Java. Он такжебыл активным участником New-EDI – процесса IETF-стандартизации1 EDI в Интернете. С 1994 года работал независимым консультантом и ис-

следователем в области организации и интеграции данных в масштабахпредприятия, а также обмена сообщениями. В настоящее время занимает-ся схемами баз данных для приложений c фолксономической2 организациейконтента в системах масштаба предприятия, а также проблемами сопро-вождения БД в социальных сетях, находящих практическое применениев коммерческих отраслях. Входит в Policy Group проекта Data Portability,где занимается подготовкой лицензионных соглашений и вопросами правпользователя на владение данными. Помимо этого пишет о базах данных

на сайте GigaOm.com и ведет блог http://tagschema.com. Является вла-дельцем патента в области передачи сообщений через границы доверия

(trust boundaries).

1 IEF (Internet Engineering ask Force) – рабочая группа по развитию Интернета. –Примеч. перев.

2 Фолксономия (folksonomy) – «народная классификация» – выполняемая силамипользователей организация информационного контента посредством назначенияспециальных меток (тегов). Часто противопоставляется таксономии как прин-ципу иерархической категоризации информации. – Примеч. науч. ред.



Снижайте неотъемлемуюсложность, устраняйтевторостепенную сложность

Íèë Ôîðä

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

ходится пересматривать.С другой стороны, второстепенная сложность (accidental complexity) обу-словлена теми задачами, которые, как нам кажется, необходимо решить дляснижения неотъемлемой сложности. Примером второстепенной сложностиможет служить устаревшая система управления полетами, используемая посей день. Система проектировалась для решения сложной проблемы управ-ления движением тысяч самолетов, но это решение порождает свои соб-ственные проблемы. Современные системы управления полетами настолькосложны, что само их обновление становится трудным, если не невозможным

делом. Почти во всем мире управление полетами осуществляется по техно-логиям более чем 30-летней давности.

«Синдром второстепенной сложности» проявляется во многих инфраструк-турах (framework) и фирменных «решениях». Инфраструктуры для реше-ния узких, конкретных задач приносят реальную пользу; чрезмерно слож-ные инфраструктуры создают больше трудностей, чем устраняют.



19Снижайте неотъемлемую сложность, устраняйте второстепенную сложность

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

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

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

Обязанность архитектора – решать проблемы, лежащие в плоскости неотъ-емлемой сложности, без введения второстепенной сложности.

Нил Форд (Neal Ford) – архитектор программного обеспечения и «мемовод»1 из ThoughtWorks, международного консалтингового агентства, специали-зирующегося на разработке и поставке комплексных решений. Он являетсясоздателем многих приложений, учебных материалов, компьютерных учеб-

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

лить на сайте http://www.nealford.com .

1 Термин «мемовод» (meme wrangler) придумал сам Нил Форд. Он считает, что«…это гораздо лучше обесценившегося термина “архитектор”. Очень жаль, чтоиз-за отсутствия отраслевой системы сертификации эту (номинально самуювысокую) должность присваивают себе люди, полностью утратившие связьс реальностью». – Примеч. перев.



Возможно, ваша главнаяпроблема не в технологиях

Ìàðê Ðýìì

Прямо сейчас где-то терпит бедствие очередной проект системы расчета зар-платы… А скорее всего, и не один.

Почему это случилось? Потому что разработчики выбрали Ruby вместо Javaили Python вместо Smalltalk? Потому что решили использовать Postgres,а не Oracle? Или потому что предпочли платформу Windows, хотя следова-ло выбрать Linux? Как известно, во всех неудачах проектов обычно виняттехнологию. Но действительно ли ваша задача была настолько сложна, чтовозможностей Java оказалось для нее недостаточно?

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

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

При этом простого владения приемами общения как технологией недоста-

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

Конечно, дело этим отнюдь не исчерпывается, но несколько простых советовсущественно повысят эффективность вашего общения с подчиненными:

Смотрите на обсуждение проблем как на конструктивный диалог, а не•

как на конфликтную ситуацию.



21Возможно, ваша главная проблема не в технологиях

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

Приступайте к беседе только в подходящем для общения настроении.•

Если вы рассержены, раздражены, расстроены и вообще выведены из ду-шевного равновесия, ваш собеседник, скорее всего, истолкует ваши не-вербальные проявления как признак нападения.

Используйте такие ситуации как возможность достичь взаимной выгоды.•

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

Если вы сосредоточены на общей цели, рассматриваете «проблемы» своихсобеседников как возможность чему-то научиться, управляете своими эмо-циями, то вы не только повысите свою эффективность, но и будете каждыйраз узнавать что-то новое.

Марк Рэмм (Mark Ramm) – «великодушный пожизненный диктатор»1 для

TurboGears 2, страстный поклонник Python и, вообще говоря, совершенносумасбродный парень. Он перепробовал все мыслимые и немыслимые видыдеятельности – от архитектора программного обеспечения и сетевогоадминистратора до ловца лобстеров и уборщика в баре для байкеров. Егоосновное увлечение – разработка инструментов, повышающих производи-тельность труда программистов (как профессионалов, так и любителей).

1 «Великодушный пожизненный диктатор» (Benevolent Dictator For Life, BDFL) –шутливый термин в области разработки свободного ПО, которым именуют главуили основателя проекта, сохраняющего за собой право принимать окончательныерешения (см. http://ru.wikipedia.org/wiki/BDFL). – Примеч. перев.



Общение – король,ясность и лидерство –его верные слуги


Слишком часто архитекторы программного обеспечения обитают в башняхиз слоновой кости, спуская оттуда разработчикам спецификации и навязы-вая им технологии и направления. Сплошь и рядом это приводит к раздо-рам, за которыми быстро следует «народное восстание». В итоге появляетсяпрограммный продукт, который не имеет ничего общего с исходными тре-бованиями. Каждый архитектор программного обеспечения должен уметьобъяснять своим коллегам цели и задачи программного проекта. Ключамик эффективному общению являются ясность и лидерство.

Ясность характеризует процесс общения. Никто в вашей группе не станет

читать 100-страничный документ с обоснованием ваших архитектурных ре-шений. Умение четко и ясно выражать свои мысли жизненно важно для успе-ха любого программного проекта. С самого начала работы над проектом при-держивайтесь простых объяснений и ни в коем случае не начинайте состав-лять длинные описания в Word. Используйте такие инструменты, как Visio,для создания простых диаграмм, поясняющих ваши идеи. Диаграммы долж-ны быть простыми, потому что они почти наверняка будут часто изменяться.Еще одним эффективным средством распространения информации являютсянеформальные встречи. Лучший способ донести вашу мысль до участников

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



23Общение – король, ясность и лидерство – его верные слуги

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

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

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

Если «общение – король», то ясность и лидерство – его верные слуги.

Марк Ричардс (Mark Richards) – директор и ведущий архитектор в фирмеCollaborative Consulting, LLC, где он занимается разработкой архитекту- ры и проектированием крупномасштабных сервис-ориентированных реше-ний на базе J2EE и других технологий главным образом в области финан-

совых операций. Работает в программной отрасли с 1984 года, обладаетзначительным опытом проектирования и разработки на J2EE, объектно-ориентированного проектирования и разработки, а также опытом сис-темной интеграции.



Производительностьприложения определяетсяего архитектурой


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

за 3 миллисекунды, а конкурирующий продукт – за 4 миллисекунды, заяв-ленные 25% (одна миллисекунда) значат очень мало на фоне общей низкойпроизводительности, уходящей корнями в неэффективность архитектуры.

Помимо ИТ-менеджеров и команд тестирования производительности естьи другие группы людей, например служба поддержки фирмы-разработчикаи авторы книг по управлению производительностью приложений, которыерекомендуют заняться тонкой настройкой инфраструктуры приложения:поиграть с операциями выделения памяти, размерами пулов подключений,размерами пулов потоков и так далее. Но если приложение спроектировано

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

В конечном счете за фасадом продукта любого производителя и архитектурылюбого приложения действуют одни и те же фундаментальные принципы рас-пределенной обработки данных и физические закономерности: приложения



25Производительность приложения определяется его архитектурой

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

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

Рэнди Стаффорд (Randy Stafford) – профессионал в области создания про-граммного обеспечения, обладающий 20-летним опытом работы в качестве разработчика, аналитика, архитектора, менеджера, консультанта и ав-

тора/лектора.В настоящее время занимается разработкой промежуточного (middleware)программного обеспечения в составе группы A-Team фирмы Oracle, а такжеучаствует в концептуальных проектах, занимается оценкой архитек-ту ры и помогает устранять кризисы производства различным организа-циям во всем мире. Основные области его специализации – сервис-ориен-тированные архитектуры, производительность, высокая доступностьи JEE/ORM.



Ищите истинный смыслтребований


Заказчики и конечные пользователи часто под видом требования выдвига-ют то, что им кажется эффективным решением некоторой задачи. Класси-ческий пример такого рода приводит Гарри Хиллейкер (Harry Hillaker),ведущий конструктор истребителя F-16 Falcon. Перед его группой былапоставлена цель спроектировать самолет, развивающий скорость M2–2,5,что было (и вероятно, остается) весьма нетривиальной задачей, особенноесли сопутствующая цель состоит в создании «дешевого» легкого самолета.Учтите, что сила, необходимая для преодоления сопротивления воздуха,при удвоении скорости полета возрастает вчетверо, и представьте себе, как

это обстоятельство влияет на вес самолета.Когда конструкторская группа спросила заказчиков из ВВС, зачем им нужнаскорость M2–2,5, те ответили: «Чтобы самолет мог при необходимости вый-ти из боя». Когда настоящая потребность стала очевидной, конструкторысмогли решить главную проблему и представить работоспособное решение:подвижный самолет с высокой тяговооруженностью, обеспечивающей хоро-шее ускорение и маневренность вместо высокой максимальной скорости.

Выводы из этого урока в равной степени справедливы и в области разработ-ки программного обеспечения. Узнав у заказчика истинный смысл запра-

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

Как же следует действовать? В манифесте гибкой (agile) разработки есть прин-цип, который ко многим случаям подходит очень хорошо: «Сотрудничество



27Ищите истинный смысл требований

важнее контракта». С практической точки зрения это подразумевает про-ведение семинаров и встреч, на которых архитекторы анализируют потреб-ности заказчика, помогая ему ответить на вопрос «Почему?». Учтите, чтопоиск ответа на этот вопрос может оказаться весьма непростой задачей, по-

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

Эйнар Ландре (Einar Landre) – профессионал в области программного обе-спечения с 25-летним опытом работы в качестве разработчика, архитек-тора, менеджера, консультанта и автора/лектора.

В настоящее время работает в группе коммерческих приложений фирмы

StatoilHydro, где занимается разработкой приложений, критических длябизнеса, оценкой архитектуры и оптимизацией процессов разработки.Основные сферы его интересов – сервис-ориентированные архитектуры,проектирование на основе предметной области (domain-driven design),применение мультиагентов и проектирование интенсивно используемыхкрупномасштабных сетевых систем.



Встаньте!

Óäè Äàõàí

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

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

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

но, где вы при этом находитесь – на официальном анализе проекта системыили неформальном обсуждении пары диаграмм. Встаньте – особенно есливсе остальные сидят.

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



29Встаньте!

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

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

Хотите повысить эффективность передачи своих идей в процессе общенияболее чем вдвое? Это очень просто: встаньте.

Уди Дахан (Udi Dahan) – Шаман от Программирования; его заслуги бы-

ли признаны корпорацией Microsoft и в течение трех лет оценивалисьпрестижным званием «Наиболее ценного специалиста» (Most ValuableProfessional) в области архитектуры решений. В качестве советника покоммуникационным технологиям Уди работает с компанией Microsoft надWCF, WF и Oslo. Он также участвует в работе консультативных комите-тов Microsoft Software Factories Initiative и проекта Prism группы Patterns& Practices. Он оказывает консультации в области современных архитек-тур и обучает клиентов по всему миру. Его основной специальностью яв-ляется проектирование сервис-ориентированных, масштабируемых и без-опасных архитектур на базе платформы .NET.



Сбои неизбежны


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

Программный код тоже подвержен сбоям. Наши приложения строятся на

основе программного кода, а значит, они тоже уязвимы. Мы реализуем сред-

ства мониторинга, сообщающие о сбоях приложения, однако в основе этих

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

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

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

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

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



31Сбои неизбежны

сервера на рабочий, но теперь при капризах кластерной сети возникает риск«расщепления мощностей»1.

Стоит напомнить, что авария на Тримайл-Айленд2 произошла в основном из-за клапана сброса давления – механизма безопасности, который должен был

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

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

пассивной защиты пассажиров), вы можете спроектировать защитные ре-жимы сбоев, которые будут изолировать повреждения и защищать осталь-ные компоненты системы.

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

Майкл Найгард (Michael Nygard) написал книгу «Release It! Design andDeploy Production-Ready Software» (Выпускаем в свет! Разработка и вне-дрение ПО, готового к выпуску) (Pragmatic Bookshelf), получившую премиюJolt Productivity в 2008 году. Другие его публикации можно найти по адресу

http://www.michaelnygard.com/blog .

1 Ситуация, при которой каждая сторона убеждена в полной неработоспособностидругой стороны и продолжает захватывать ресурсы так, как если бы другойстороне никакие ресурсы не принадлежали. – Примеч. перев.

2 Крупнейшая авария в ядерной энергетике США, сопровождавшаяся частичнымрасплавлением активной зоны реактора. – Примеч. перев.



Вы ведете переговоры чаще,чем вам кажется


Все мы попадали в «бюджетектурные» переделки, когда разумные технологиче-

ские решения «хоронятся» ради экономии. Разговор проходит примерно так:

«Нам действительно так необходимы X?» – спрашивает спонсор проекта.

На место X можно подставить практически всё жизненно необходимое дляработы системы: лицензии на программные продукты, избыточные серверы,внешние резервные копии или источники питания. Вопрос всегда задаетсяотеческим тоном, словно вы спускаете все карманные деньги на комиксыи жвачку, тогда как серьезным взрослым людям нужно думать о покупке

новых ведер, в которых они будут таскать свою будущую прибыль.Правильный ответ на этот вопрос звучит так: «Да. Абсолютно необходимы».Но так почему-то почти никто не отвечает.

В конце концов, у нас техническое образование, а любая техническая дис-циплина – это искусство компромисса. Понятно, что экзотика вроде источ-ников питания никому не будет нужна, если поставить в центре обработкиданных несколько беличьих колес и запустить в них практикантов. И вмес-то того чтобы сказать «Да, абсолютно необходимы», мы говорим что-товроде: «Вообще-то без второго сервера можно обойтись, если вы согласны

смириться с простоями из-за профилактики и при каждом сбое памяти.Хотя если мы купим память с автоматическим контролем четности, то и этупроблему можно обойти. Так что остаются только сбои операционной систе-мы в среднем через каждые 3,9 дня, а значит, по ночам сервер придется пере-загружать, но это вполне могут делать практиканты, когда устанут крутитьколеса».

И все это может быть совершенно справедливо, но говорить так ни в коем слу-чае не следует. Спонсор перестает вас слушать уже после слов «вообще-то».



33Вы ведете переговоры чаще, чем вам кажется

Проблема в том, что вы рассматриваете происходящее с технической точкизрения, а ваш спонсор четко понимает, что он ведет переговоры. Вы зани-маетесь совместным поиском решения, тогда как он проводит тактическийманевр типа «выйдет/не выйдет». А в любых переговорах ни в коем случае

не следует делать уступки по первому требованию. Правильный ответ на во-прос «Нам действительно так необходимы X?» звучит примерно так:

«Без второго сервера вся система будет «падать» примерно три раза в день,особенно в периоды максимальной нагрузки и при демонстрации на собра-нии совета директоров. На самом деле нам нужно четыре сервера, чтобы однанезависимая пара обеспечивала сохранение 100-процентной работоспособ-ности, даже если другая пара неожиданно перестанет работать».

Конечно, вы прекрасно знаете, что третий и четвертый серверы на самом де-ле не нужны. Это тактический гамбит, который заставит вашего спонсора

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

Биография автора приведена на стр. 31.



Используйтеколичественные критерии


«Быстрый» не может быть требованием. Как и «обладающий хорошим вре-менем отклика». Или, скажем, «расширяемый». Главная причина заклю-чается в отсутствии объективных критериев выполнения таких требований.Но пользователям эти характеристики все равно нужны. Задача архитек-тора – позаботиться о том, чтобы система обладала необходимыми каче-ствами, а также сбалансировать неизбежные противоречия, возникающиемежду ними. Без объективных критериев архитектор зависит от капризовзаказчика («Нет, я не могу принять программу – она работает недостаточ-но быстро») и разработчиков, одержимых навязчивыми идеями («Нет, про-

грамма еще не готова – она работает недостаточно быстро»).Обычно мы стараемся записать все подобные пожелания, как и любые дру-гие требования. Но эта запись очень часто выглядит как набор туманныхэпитетов: «гибкий», «удобный в сопровождении» и так далее. Однако всекритерии такого рода (при достаточном усердии даже «удобство использо-вания») могут измеряться в числовых величинах, для которых можно уста-новить пороговые значения. Если этого не сделать, пользователи лишатсяобъективных оснований для принятия системы, разработчики потеряют по-лезные ориентиры, которыми они могут руководствоваться во время рабо-

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



35Используйте количественные критерии

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

Нечеткие количественные критерии должны задаваться в виде диапазона:

минимум, норма, максимум. Если задать такой интервал невозможно, зна-чит, непонятно, какое поведение требуется от системы. В ходе работы надархитектурой можно проверять систему на соответствие этим критериям,чтобы узнать, находится ли она (все еще) в пределах допустимых отклоне-ний. Отклонения в степени соответствия некоторым критериям, происходя-щие с течением времени, дают полезную обратную связь. Определение этихинтервалов и проверка системы на соответствие – дело трудоемкое и доро-гостоящее. Если никто не беспокоится о производительности системы (нио самой характеристике, ни о смысле термина) настолько, чтобы платить затестирование производительности, скорее всего, этот показатель вообще неявляется существенным. Сосредоточьтесь при создании архитектуры на техаспектах системы, которые стоят потраченных усилий.

«Система должна реагировать на входные данные пользователя не более чемза 1500 мс. При стандартной нагрузке (определяемой как…) среднее время от-клика должно лежать в интервале от 750 до 1250 мс. Время отклика менее500 мс не воспринимается пользователями, поэтому его падение ниже этогопорога оплачиваться не будет.» А вот это уже можно назвать требованием.

Кейту Брайтуэйту (Keith Braithwaite) впервые заплатили за разработкупрограммного обеспечения в 1996 году, хотя до этого он много лет занимал-ся программированием на любительском уровне. После первого проекта –сопровождения компилятора, написанного с использованием lex и yacc, – онзанялся сначала моделированием распространения микроволн для планиро-вания сетей GSM, а затем расчетом на C++ сезонных колебаний спроса навоздушные перевозки. Перейдя на должность консультанта (и одновремен-но на язык Java), он познакомился с CORBA и EJB, а потом и с тем, чтотогда называлось «электронной коммерцией». В настоящее время Кейт работает ведущим консультантом в фирме Zuhlke, где возглавляет Центр

гибкой разработки.



Одна строка рабочего кодастоит 500 строк спецификации

Ýëëèñîí Ðýíäàë

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

К сожалению, архитекторы часто увлекаются процессом проектирования,попадая под очарование архитектурных абстракций. Однако сами по себе

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

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

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



37Одна строка рабочего кода стоит 500 строк спецификации

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

как сами попробуете вдохнуть жизнь в свое творение.

Эллисон Рэндал (Allison Randal) – главный архитектор и ведущий разра-ботчик проекта с открытым исходным кодом Parrot. За свою 25-летнююкарьеру она разрабатывала буквально все – от игр до средств лингвистиче-ского анализа, сайтов электронной коммерции, систем контроля достав-ки, компиляторов и систем репликации баз данных. Ей довелось побыватьпроектировщиком языков программирования, руководителем проектов,организатором конференций, редактором и консультантом. Эллисон была

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



Решений на все случаи жизнине существует


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

Броское выражение «контекстное чутье» впервые использовал (с содер-жательным описанием его смысла) Эберхардт Рехтин (Eberhardt Rechtin)в своей книге «Systems Architecting: Creating & Building Complex Systems»(Системная архитектура: создание и построение сложных систем) (PrenticeHall, 1991):

«Чтобы узнать основные принципы “эвристического подхода” к про-ектированию сложных систем, спросите опытного архитектора, чтоон делает, когда сталкивается с особенно сложной задачей. Его ответ,скорее всего, будет таким: «Просто использую здравый смысл». <…>Вместо термина «здравый смысл» лучше было бы использовать вы-ражение «контекстное чутье»1 – знание о том, что является разум-ным в данном контексте. Образование, полученный опыт и изучениепримеров позволяют архитектору-практику набрать значительнуюмощь контекстного чутья к тому моменту, когда ему доверяетсярешение проблемы системного уровня, – обычно на это уходит лет

десять.»

1 Английское слово sense в зависимости от ситуации может переводиться и как«смысл», и как «чувство, чутье», поэтому в английском тексте перекличкатерминов (common sense – «здравый смысл» и contextual sense – «контекстноечутье») выглядит более явной. – Примеч. ред.



39Решений на все случаи жизни не существует

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

ного роста; не исключено, что исчезновение этой проблемы можно будетсчитать признаком зрелости отрасли.

Я часто сталкиваюсь с проявлениями этой проблемы в своей работе кон-сультанта. Вот характерные примеры: отказ от проектирования на основепредметной области (domain-driven design)1 там, где оно было бы уместным;утрата прагматического взгляда на вещи и чрезмерное увлечение проекти-рованием программного решения, когда речь идет о задаче, не терпящей от-лагательств; необоснованные или не имеющие отношения к делу предложе-ния в тот момент, когда работы по оптимизации быстродействия системызаходят в тупик.

Самое важное, что необходимо знать о программных шаблонах, – то, когдаих следует и когда не следует применять. То же самое верно в отношениигипотез о глубинных причинах проблемы и соответствующих корректиру-ющих действий. В обеих ситуациях – при создании архитектуры системыи при анализе проблемы – универсального решения «на все случаи жизни»не существует по определению; архитектор должен развивать и тренироватьсвое контекстное чутье, формулируя архитектурные решения, а также вы-являя и устраняя их недостатки.


1 См. Эрик Эванс (Eric Evans) «Domain-Driven Design: ackling Complexity in theHeart of Software» (Проектирование на основе предметной области: как совладатьс присущей программам сложностью) (Addison-Wesley Professional).



Думать о производительностиникогда не рано

Ðåáåêêà Ïàðñîíñ

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

Эта ошибка встречается намного чаще, чем следовало бы. В ее основе могутлежать различные причины. Забота о быстроте и гибкости программы, ко-

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

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

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

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



41Думать о производительности никогда не рано

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

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

Этот подход позволяет также проверять решения, принятые в ходе проекти-рования и работы над архитектурой системы, в контексте реальных требо-ваний к производительности. Если к системе предъявляются жесткие требо-вания, такая ранняя проверка особенно важна для своевременной поставки

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

Доктор Ребекка Парсонс (Rebecca Parsons) – технический директорThoughtWorks. Она обладает более чем 20-летним опытом разработки при-ложений в различных отраслях, от телекоммуникаций до новых интернет-сервисов. Ребекка имеет печатные публикации по языкам программирова-ния и искусственному интеллекту, работала в ряде комитетов в областипрограммирования и написала множество журнальных статей. У нее естьобширный опыт в области создания крупномасштабных распределенныхобъектных приложений и интеграции разнородных систем.





43Создание архитектуры как искусство баланса

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

Работа архитектора состоит не в том, чтобы просто создать функциональ-

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

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

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

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




Сделать наспех и сбежать –преступление


Время близится к вечеру. Команда дружно корпит над новой функционально-стью, запланированной для текущей итерации; кажется, даже воздух в ком-нате пульсирует в рабочем ритме. Однако Джон немного спешит: его ждетсвидание. Впрочем, он успевает дописать свою часть кода, компилирует ее,регистрирует в системе управления исходным кодом – и поспешно уходит.Несколько минут спустя загорается «красный свет»: сборка приложения на-рушена. У Джона не было времени на автоматизированные тесты, поэтомуон поступил по принципу «сделать наспех и сбежать», из-за чего застопори-лась работа всей команды.

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

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

Это печально распространенный среди разработчиков способ сэкономитьнемного времени лично для себя, в итоге потратив впустую чужое время,что служит проявлением прямого неуважения к другим людям. И все же этопроисходит повсеместно. Почему? Обычно потому, что полноценная сборкасистемы или проведение тестов занимает слишком много времени.

Здесь в игру вступаете вы – архитектор. Вы тратите массу усилий на соз-дание гибкой архитектуры, обучаете разработчиков гибким методам разра-



45Сделать наспех и сбежать – преступление

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

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

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

Никлас Нильссон (Niclas Nilsson) – консультант и преподаватель в облас-ти разработки программного обеспечения, а также писатель, глубоко увле-ченный искусством программирования, ценитель хорошей архитектурыи дизайна. Является одним из соучредителей factor10 и редактором мате- риалов в сообществе архитектуров ПО на сайте InfoQ.



Решений может бытьнесколько


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

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

ешь верить» (Филип К. Дик), и по мере развития бизнеса проблемы всегдавозвращаются. Так возникают команды, занимающиеся корпоративнымиданными и тому подобным, которые тратят все свое (очень дорогое) времяна обуздание экзистенциального ужаса посредством жонглирования DD1.

1 DD (Document ype Definition) – определение типа документа – преамбуладокумента, определяющая в языках структурной разметки данных (SGML,XML) состав и структуру документа. – Примеч. ред.



47Решений может быть несколько

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

Почему бы не принять реальность непоследовательного мира и не допуститьсуществование нескольких несогласованных, перекрывающихся представ-

лений, служб, решений? Да, технический специалист в каждом из нас, услы-шав такое предложение, съеживается от ужаса. Мы сразу представляем себекошмарные сценарии: несогласованные обновления, лишние затраты на со-провождение, клубки зависимостей, которыми приходится управлять… Нодавайте позаимствуем полезный опыт из мира хранения данных. Витриныданных (data marts) часто денормализуются (в реляционном смысле), в нихпроизвольно смешиваются импортированные и вычисленные значения,а представления данных сильно отличаются от представлений данных в ис-ходных базах данных. И при этом от наличия у витрины данных нефунк-циональных свойств никакой катастрофы не происходит. На границе двухсовершенно разных миров – как правило, операций с данными и аналитиче-ской обработки с характерными для них различиями в частоте обновленияи выборки, в пропускной способности, в периодичности изменений струк-туры и, возможно, даже в объемах – находится EL-процесс1. В этом ключк задаче: достаточно сильные различия в нефункциональных свойствах сис-темы формируют границу, через которую удается организовать практиче-ское управление несогласованными представлениями.

Конечно, не стоит дублировать представления или создавать альтернатив-ные транспортные механизмы просто ради развлечения. Но вы всегда долж-

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


1 EL (Extract, ransform, Load – извлечение, преобразование, загрузка) – один изосновных процессов в управлении хранилищами данных (см. http://ru.wikipedia.org/wiki/ETL). – Примеч. ред.



Всем заправляет бизнес

Äýéâ Ìóðõåä

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

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

окупаемости инвестиций (ROI – Return on Investment). Архитектор долженпринять этот показатель и вытекающие из него ограничения ценности созда-ваемого продукта для компании. Это поможет избежать таких техническихрешений, которые способны привести к перерасходу средств. Показательокупаемости должен служить важным компонентом целевого контекста какпри общении с руководством (в ходе поиска компромисса между ценностьютой или иной функции и затратами на ее реализацию), так и при обсужде-нии технической архитектуры и реализации с командой разработчиков.В частности, перед командой разработки архитектор должен представлять

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

Одна из сложных задач, возникающих, когда всем заправляет бизнес, – предо-ставлять достаточный объем сведений качественного характера о том, как дви-жется разработка продукта, чтобы бизнес-руководство могло принимать обо-снованные деловые решения. Здесь важнейшую роль играет прозрачность. Ар-хитектор вместе с руководством проекта должен создать и усовершенствовать



49Всем заправляет бизнес

средства получения регулярной, оперативной обратной связи. Этой целиможно достичь, применяя различные приемы бережливой разработки ПО(lean software development): большие, заметные диаграммы, непрерывнаяинтеграция, частые выпуски рабочих версий продукта и их передача бизнес-

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

В долгосрочной перспективе интересы команды разработки лучше всего со-

блюдаются тогда, когда у руля стоит бизнес.

Дэйв Мурхед (Dave Muirhead) – ветеран в области искусства программи- рования и бизнес-технологий, владелец и ведущий консультант Blue RiverSystems Group, LLC (BRSG) – расположенной в Денвере компании, оказыва-ющей консультационные услуги в сфере бережливой разработки программ-ного обеспечения и технических стратегий.



Простота лучшеуниверсальности


Типичная проблема многих компонентных инфраструктур (framework),библиотек классов, базовых сервисов и прочего инфраструктурного кодазаключается в том, что они проектируются с расчетом на универсальноеприменение, без привязки к конкретным приложениям. В результате мыполучаем ошеломляющий набор возможностей и настроек, которые частоне используются вообще или используются не по назначению, а то и попро-сту оказываются бесполезными. Большинство разработчиков работает надконкретными системами, и стремление к неограниченной универсальностиредко способно сослужить им хорошую службу. Лучший путь к универсаль-

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

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

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

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



51Простота лучше универсальности

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

Обобщение иногда позволяет привести задачу к более фундаментальному

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

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

сков параметров, бескрайних интерфейсов и неправомерных абстракций.В стремлении к абстрактной гибкости часто (случайно или намеренно) утра-чиваются ценные свойства альтернативных, более простых решений.

Кевлин Хенни (Kevlin Henney) – независимый консультант и преподава-тель. Он специализируется на шаблонах и архитектуре, методах и языкахпрограммирования, процессах и практике разработки. Является соавто- ром книг «A Pattern Language for Distributed Computing» (Язык шаблоновдля распределенных компьютерных систем) и «On Patterns and Pattern

Languages» (О шаблонах и языках шаблонов) – обе книги опубликованы из-дательством Wiley.



Архитектор должен бытьпрактиком

Äæîí Äýâèñ

Хороший архитектор должен подавать личный пример другим. Он долженбыть способен заменить любого члена своей команды и выполнить любуюработу – от прокладки сети и настройки процесса сборки до написания мо-дульных тестов и выполнения тестов производительности. Без хорошегопонимания всего диапазона технологий архитектор мало чем отличается отобычного руководителя проекта. Члены команды могут обладать более глу-бокими знаниями в своих узких областях – это совершенно нормально, – новряд ли они смогут доверять своему архитектору, если тот не разбираетсяв используемых технологиях. Как уже было сказано, архитектор – это ин-

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

Работа архитектора сродни работе пилота самолета: он может не выглядетьзанятым, но в действительности использует десятилетия накопленногоопыта для постоянного наблюдения за ситуацией и немедленно вмешивает-

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

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



53Архитектор должен быть практиком

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

тор при этом направляет ход обсуждения и определяет правильный подход.Архитекторам следует присоединяться к команде уже на самых ранних ста-диях проекта; они должны не сидеть в башне из слоновой кости, указываяоттуда путь вперед, а работать «в поле» вместе со всеми остальными. Вопро-сы выбора стратегического направления или технологии не следует превра-щать в самостоятельные исследования или новые проекты – к ним надо под-ходить прагматически, разыскивая ответ в ходе практической работы илиобращаясь за советом к коллегам-архитекторам (все хорошие архитекторызнают друг друга).

Хороший архитектор обязан на уровне эксперта владеть как минимум од-ним из инструментов своей профессии, например интегрированной средойразработки (IDE); помните, что архитектор должен быть практиком. Впол-не логично, что архитектору ПО следует хорошо знать IDE, архитекторубаз данных – инструментарий построения диаграмм «сущность–связь»(ER-диаграмм), а информационному архитектору – инструменты XML-моделирования. Однако ведущий архитектор обязан уметь применять ин-струменты всех уровней, от контроля сетевого трафика с использованиемWireshark до моделирования сложных финансовых сообщений в XMLSpy, –для него не существует слишком низких или слишком высоких уровней.

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

Джон Дэвис (John Davies) в настоящее время является ведущим архитек-тором в фирме Revolution Money (США). Недавно основал новую компаниюIncept5.



Обеспечьтенепрерывную интеграцию


Сборка давно перестала играть роль «Большого взрыва» в разработке проек-тов. И архитекторы (как уровня приложения, так и корпоративного уровня)должны поощрять использование методов и инструментов непрерывной ин-теграции в каждом проекте.

Термин непрерывная интеграция (CI, Continuous Integration) впервые былпредложен Мартином Фаулером в качестве шаблона проектирования. Онозначает совокупность методов и инструментов, обеспечивающих регуляр-ную автоматическую сборку и тестирование приложения через короткиепромежутки времени (как правило, на интеграционном сервере, специально

созданном для выполнения этих операций). Для любого современного про-граммного проекта практика непрерывной интеграции, комбинирующаяметоды и инструменты модульного тестирования с инструментами автома-тизированной сборки, становится обязательной.

Непрерывная интеграция воздействует на неотъемлемый элемент процессаразработки ПО – точку преобразования исходного кода в работающее при-ложение. В этой точке происходит объединение и тестирование составныхчастей проекта. Вам, вероятно, доводилось слышать принцип «Выполняйтесборку рано и часто» («Build early and often»); когда-то этот принцип служил

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

Самой известной частью практики непрерывной интеграции является сбор-ка, которая обычно автоматизирована. Возможность ручной сборки остается,



55Обеспечьте непрерывную интеграцию

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

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

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

Дэйв Бартлетт (Dave Bartlett) – увлеченный своим делом профессионал. За

25 с лишним лет он успел побывать программистом, разработчиком, архи-тектором, руководителем, консультантом и преподавателем. В настоя-щее время он выполняет работы для клиентов Commotion Technologies, Inc.(частная консалтинговая компания), а также читает лекции в Высшейтехнической школе Пенсильванского университета. Его основные теку-щие проекты связаны с Федеральным резервным банком в Филадельфии, ко-торому он помогает проектировать и создавать веб-приложения, порталыи комплексные приложения для взаимодействия с Федеральной резервнойсистемой и Казначейством США.



Старайтесьне нарушать график


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

Идея о том, что путем сокращения графика можно снизить расходы илиускорить сдачу продукта, является очень распространенным заблуждени-ем. Обычно для более быстрой сдачи продукта или для расширения функ-циональности без изменения срока сдачи прибегают к сверхурочной работеили жертвуют «менее важными задачами» (такими как модульное тестиро-вание). Избегайте такого сценария любой ценой. Напомните тем, кто требу-ет от вас подобных мер, следующие факты:

Сокращение сроков проектирования приводит к некачественному ди-•

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

вателем.Сокращение сроков кодирования или сдачи напрямую связано с количе-напрямую связано с количе-напрямую связано с количе-•

ством ошибок в конечном продукте.

Сокращение сроков тестирования ведет к появлению плохо протестиро-•

ванного кода и напрямую связано с количеством проблем при тестиро-вании.



57Старайтесь не нарушать график

Все перечисленное влечет за собой проблемы на этапе эксплуатации,•

а устранение таких проблем обходится намного дороже.

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

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

Норман Карновейл (Norman Carnovale) – IT-архитектор проектов, свя-занных с национальной безопасностью, выполняющий работу для LockheedMartin Professional Services. Ранее работал консультантом в областипрограммного обеспечения, преподавателем и архитектором в компании

Davalen, LLC (http://www.davalen.com), которая является ведущимбизнес-партнером IBM и специализируется на проектах WebSphere PortletFactory, WebSphere Portal и Lotus Domino.



Архитектурные компромиссы


Каждый архитектор программного обеспечения должен знать и понимать,что нельзя получить все сразу. На практике невозможно спроектироватьархитектуру, одновременно обладающую высокой производительностью,высокой доступностью, высоким уровнем безопасности и высоким уровнемабстракции. Существует одна реальная история, которую архитекторы про-граммного обеспечения должны знать, понимать и рассказывать своим кли-ентам и коллегам. Я имею в виду историю корабля «Ваза».

В 1620 году шла война между Швецией и Польшей. Желая побыстрее за-вершить эту дорогостоящую войну, король Швеции приказал построить га-леон, который назывался «Ваза». Это был необычный корабль. Требованияк нему были не похожи на требования к любому другому кораблю того вре-мени. Он должен был иметь длину более 60 метров, нести 64 пушки на двухбатарейных палубах, а также брать на борт 300 солдат за раз для безопаснойдоставки в Польшу по морю. Время поджимало, денег не хватало (звучитзнакомо, да?). Занимавшийся этим судном кораблестроитель еще никогдане проектировал такие корабли. Он специализировался на меньших, одно-палубных судах. Тем не менее он взялся за проектирование и постройку«Вазы», полагаясь на свой прежний опыт. В итоге корабль, соответствую-

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

Проблема «Вазы» была очевидной; каждый, кто хоть раз видел палубубольшого боевого корабля XVII века, знает, что палубы таких кораблей бы-ли переполнены и небезопасны, особенно во время сражения. Постройкакорабля, который служил бы одновременно боевым и транспортным, было



59Архитектурные компромиссы

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

Архитектор ПО может почерпнуть из этой истории много полезного и учестьэтот печальный опыт при проектировании архитектуры программных про-

дуктов. Попытка выполнить все требования сразу (как в случае с «Вазой»)создает неустойчивую архитектуру, которая не решает толком ни одну изпоставленных задач. Хороший пример такого рода – требование заставитьсервис-ориентированную архитектуру (SOA, service-oriented architecture)заодно функционировать в качестве решения «точка–точка». Обычно этовынуждает обходить различные уровни абстракции, создаваемые подходомSOA, и в результате возникает архитектура, напоминающая блюдо спагеттииз итальянского ресторана. В распоряжении архитектора имеется несколь-ко инструментов для определения тех компромиссов, на которые приходит-ся идти при проектировании архитектур. Два популярных метода такогорода – AAM (Architecture radeoff Analysis Method) и CBAM (Cost BenefitAnalysis Method). Дополнительную информацию об AAM и CBAM можнонайти на сайте SEI (Software Engineering Institute).




База данных как Крепость

Äýí ×àê

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

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

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

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

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

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



61База данных как Крепость

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

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

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

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

ложить на него ответственность за перехват ошибок с других уровней при-ложения – и он вас не разочарует.

Дэн Чак (Dan Chak) – директор по разработке ПО в CourseAdvisor Inc.,компании Washington Post. Является автором книги «Enterprise Rails»(O’Reilly).



Руководствуйтесьнеопределенностью


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

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

Одно из самых простых и конструктивных определений архитектуры далГради Буч (Grady Booch): «Любая архитектура является результатом про-ектирования, но не любое проектирование направлено на создание архитек-туры. Архитектура служит представлением важных проектировочных ре-шений, формирующих систему, причем важность здесь определяется стои-мостью изменений». Отсюда следует, что эффективной является та архитек-тура, которая в общем случае снижает важность решений, принятых в ходе

проектирования. Неэффективная архитектура эту важность увеличивает.Если проектировочное решение может повести по одному из двух путей,архитектор должен отступить на шаг. Вместо того чтобы выбирать междувариантами А и Б, он должен подумать над другим вопросом: «Как спроек-тировать решение, чтобы снизить важность выбора между А и Б?». В этойситуации интересен не выбор между А и Б, а сам факт существования этоговыбора (а также то, что правильный выбор необязательно очевиден или не-изменен).



63Руководствуйтесь неопределенностью

Иногда архитектору приходится ходить кругами, прежде чем его озарит и онраспознает возникшую дихотомию. Вы стоите у доски, обсуждая (весьмаэнергично) разные варианты с коллегой? Вы задумчиво бормочете «М-м-м»и «Э-э-э» над кодом, бесконечно перебирая возможные реализации? Когда

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

Часто возникает искушение принять «решение ради решения». В таких си-туациях вам поможет опционное мышление1. Если существует неопределен-ность относительно различных путей, по которым может пойти разработкасистемы, примите решение не принимать решение. Отложите конкретноерешение до того момента, когда его можно будет принять более ответственнона основании реальных знаний, но не слишком надолго, чтобы не попасть вситуацию, когда эти знания уже бесполезны.

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

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


1 Опционное мышление (options thinking) – подход к оценке эффективностипроектов с точки зрения концепции реальных опционов (см. http://ru.wikipedia.org/wiki/Реальный_опцион), представляющий собой поиск дополнительныхвозможностей, не учитываемых при традиционном анализе. Опционное мыш-ление применимо к широкому спектру проектов: слияния и поглощения,банковское кредитование, инновационные проекты и т. п. – Примеч. ред.



Проблемы могут быть больше,чем их отражение в зеркале1

Äýéâ Êóèê

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

Это случается по разным причинам:

Проблемы, которые кажутся тривиальными на ранней стадии проекта,•

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

про сварившуюся лягушку, вероятно, является преувеличением, однако

она прекрасно иллюстрирует то, что творится во многих проектах.

Некоторые сотрудники часто сталкиваются с сопротивлением в тех слу-•

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

Большинство разработчиков – оптимисты• . Горький жизненный опытучит нас умерять свой оптимизм, но неофиты склонны смотреть на мироптимистично. Люди, от природы пессимистичные, в командах обыч-но непопулярны, даже если раз за разом оказываются правы. Мало кто

1 Автор обыгрывает стандартное предупреждение, размещаемое на выпуклыхавтомобильных зеркалах заднего вида: «Предметы находятся ближе, чем ихотражение в зеркале». – Примеч. ред.



65Проблемы могут быть больше, чем их отражение в зеркале

захочет рисковать своей репутацией и пойдет против большинства безочень серьезных оснований. Многим из нас знакомо ощущение «не нра-вится мне все это, но не могу объяснить почему», однако оно редко стано-вится действенным доводом в споре.

У всех членов команды есть собственное мнение о том, что важно, а что•

нет. При этом их внимание сфокусировано на том, за что они отвечаютлично, а не на целях проекта.

У каждого из нас есть свои «слепые пятна» – слабости и недостатки, ко-•

торые нам трудно осознать или принять.

Вот возможные стратегии противодействия этим факторам:

Выработайте организованный подход к• управлению рисками. Одно изсамых простых решений – следить за рисками так же, как вы это делае-те с программными ошибками. Кто угодно может выявить какой-либо

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

Выступая против большинства, подумайте, как помочь другим участни-•

кам команды понять вас. В любой команде, членом которой вы являе-тесь, поощряйте свободу мнений и старайтесь максимально спокойнообсуждать спорные темы.

Предчувствия типа «не нравится мне все это» заслуживают пристально-•

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

Постоянно соотносите свое видение системы с представлениями команды•

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

Увидеть свои «слепые пятна» трудно по определению. Люди, от которых•

вы готовы услышать неприятную правду, когда она вам нужна, – ваш

драгоценный ресурс.

Дэйв Куик (Dave Quick) – владелец, главный архитектор, уборщик и един-ственный работник Thoughtful Arts. Эта фирма разрабатывает програм-мы для музыкантов и предоставляет консультации в области проектиро-вания ПО компаниям, выпускающим программные продукты для созданиямузыки или произведений изобразительного искусства.



Повторное использованиезависит не толькоот архитектуры

Äæåðåìè Ìåéåð

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

…знают об их существовании

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

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

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



67Повторное использование зависит не только от архитектуры

…умеют ими пользоваться

Умение повторно использовать элементы зависит от навыков и квалифика-ции. Конечно, существуют люди, способные (по выражению Дональда Кнута(Donald Knuth)) «попадать в резонанс» с программированием и проектиро-ванием. Все мы работали с такими людьми – одаренными разработчикамии архитекторами, которые обладают впечатляющей (и даже пугающей)скоростью и глубиной усвоения информации. Но такие люди встречаютсяредко. Остальные члены команды, вероятно, просто хорошие, надежные,разумные разработчики и проектировщики. Их необходимо учить.

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

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

…считают, что это лучше, чем сделать заново самим

Многие люди – и особенно разработчики – предпочитают решать проблемысамостоятельно, вместо того чтобы обращаться за помощью. Спрашиватьо том, как что-то работает, кажется им признаком слабости или даже прояв-лением невежества. Во многом это зависит от уровня зрелости и склада лич-

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

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

Джереми Мейер (Jeremy Meyer) занимается проектированием и разработ-кой программного обеспечения, а также преподаванием в течение почти20 лет. В настоящее время он является ведущим консультантом BorlandSoftware в области моделирования и проектирования.



«Я» в архитектурене существует

Äýéâ Êóèê

На самом деле «я» в архитектуре, конечно, существует. Но это не заглавное«Я», привлекающее к себе внимание и доминирующее во всех обсуждениях.Строчной буквы вполне достаточно.

Как это относится к нам – архитекторам программных продуктов? Наше эгоподчас оказывается нашим самым опасным врагом. Кто из нас не встречалархитекторов, которые:

считают, что они понимают требования лучше заказчиков,•

рассматривают разработчиков как ресурс, нанятый для реализации их•

идей,в штыки воспринимают любые сомнения в своих идеях или игнорируют•

идеи других?

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

Почему это происходит?

Мы уже добивались успеха.• Успех и опыт развивают уверенность в себе

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

Люди нас уважают.• Решение сложных вопросов проектирования созда-ет кредит доверия – своего рода «страховочную сетку». Наша собствен-ная нетерпимость, самонадеянность или стремление полагаться только



69«Я» в архитектуре не существует

на личный опыт могут привести к тому, что мы упустим из вида важныевопросы проектирования.

Все мы люди.• Архитектор вкладывает в каждую архитектуру частицу са-мого себя. Критика ваших творений воспринимается как нападки лично

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

Как этого избежать?

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

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

Сосредоточьтесь на своей команде.• Члены команды – это не просто ресурс;

это ваши помощники по проектированию и ваша «страховочная сетка».

Из людей, которые чувствуют себя недооцененными, обычно получается

плохая «подстраховка». Архитектура формируется командой, а не лично

вами. Вы даете указания, но трудную работу выполняют все вместе. Их

помощь нужна вам в не меньшей степени, чем им – ваша.

Проверяйте свою работу• . Модель – не архитектура, а всего лишь ваше

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

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

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

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




Посмотрите с высоты300 метров


Нам, архитекторам, хочется знать, насколько хороша та программа, над кото-рой мы работаем. Качество программы имеет очевидный внешний аспект –программа должна представлять ценность для пользоватей, – но у него естьи более тонкий внутренний аспект, относящийся к ясности дизайна, – к то-му, насколько легко нам понимать, сопровождать и расширять программ-ный продукт. Если от нас настойчиво требуют определения качества, обыч-но мы в конце концов говорим: «Я узнаю это, когда увижу». Но как можноувидеть качество?

Маленькие квадратики на архитектурных диаграммах представляют целые

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

«Вид с высоты 300 метров» предоставляет информацию на нужном уров-не. Он объединяет большие объемы данных и различные метрики (ко-личество методов, количество зависимостей1, цикломатическая слож-

1 Количество зависимостей (class fan out) определяется количеством классов, накоторых основана реализация данного класса. Квадрат этой величины определя-ет стоимость поддержки текущей функциональности. – Примеч. науч. ред.



71Посмотрите с высоты 300 метров

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

значений.Создавать такие представления вручную и поддерживать их синхрониза-цию с программой – безнадежное занятие. Нужны инструменты, которыеспособны создавать такие представления на основе единственного надежно-го источника информации – исходного кода. Для некоторых представлений,скажем для структурной матрицы решений (design structure matrix), суще-ствуют коммерческие инструменты, однако специализированные представ-ления на удивление легко создаются посредством объединения небольшихинструментов, извлекающих данные и метрики, с общими пакетами визуа-лизации. Простой пример: вывод Checkstyle (по сути, набор метрик уровняклассов и методов) загружается в электронную таблицу для построения диа-грамм. Те же метрики могут отображаться и в формате reeMap с использо-ванием инструментария InfoViz. Отличным инструментом для отображенияграфов сложных зависимостей является также GraphViz.

Как только подходящее представление найдено, качество программного про-

дукта начинает восприниматься менее субъективно. Появляется возможность

сравнивать разрабатываемый продукт с другими подобными системами. Срав-

нение разных версий одной системы позволяет выявлять тенденции, а сравне-

ние представлений различных подсистем способно выявить резкие отклонения

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

лансированное дерево, вероятно, отражает удачную иерархию классов; гар-

моничный набор прямоугольников может изображать код, организованный

в виде классов правильного размера. В большинстве случаев работает весьма

простой принцип: то, что хорошо выглядит, скорее всего, хорошо устроено.

Эрик Дорненбург (Erik Doernenburg) – технический директор компанииThoughtWorks, Inc.; он помогает клиентам в проектировании и реализациикрупномасштабных систем уровня предприятия.

1 Цикломатическая сложность (cyclomatic complexity) определяется путем подсчетаусловных и логических операторов, циклов, операторов switch, блоков обработкиисключений и т. д. в телах всех методов для определения минимального числапутей выполнения программы. Этот показатель определяет сложность покрытиякода тестами. Значение этого показателя, превышающее 10 (в общем случае),означает срочную потребность в рефакторинге кода. – Примеч. науч. ред.



Пробуйте, прежде чемсделать выбор


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

В своем труде, посвященном бережливой разработке (lean development), Мэ-

ри и Том Поппендик (Mary и om Poppendieck) описывают методику приня-тия решений. Они считают, что принятие окончательного решения следуетоткладывать до самого ответственного момента – той точки, когда отсут-ствие у команды решения приведет к тому, что решение будет принято занее, а бездействие повлечет за собой необратимые (или труднообратимые)последстия. И это разумно: ведь чем позднее принимается решение, тембольше информации для его принятия. Однако во многих случаях «большеинформации» не равносильно «достаточно информации», а лучшие реше-ния, как всем хорошо известно, принимаются «задним числом». Что этоозначает для хорошего архитектора?

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



73Пробуйте, прежде чем сделать выбор

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

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

тору не приходится принимать решение – он просто дирижирует процессомего принятия.

Этот подход применим как к простым, так и к серьезным задачам. С его по-мощью команда может решить, стоит ли использовать шаблоны Hibernate,предоставляемые инфраструктурой Spring, но с таким же успехом он помо-жет ответить на вопрос, какую инфраструктуру JavaScript следует выбратьдля проекта. Разумеется, время созревания решения очень сильно зависитот сложности задачи.

Чтобы опробовать два и более решения одной задачи, нужно больше усилий,

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




Разберитесьв предметной области


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

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

ны следует применять, как планировать будущие расширения и как учестьтенденции развития отрасли, чтобы лучше подготовиться к изменениям.Например, для одних предметных областей (скажем, для страхового биз-неса) хорошо подходят сервис-ориентированные архитектурные решения(service-oriented architecture), а для других (например, для финансовыхрынков) – архитектурные решения на основе бизнес-правил (workflow-basedarchitecture). Знание предметной области помогает решить, какие архитек-турные шаблоны лучше всего отвечают конкретным потребностям органи-зации.

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



75Разберитесь в предметной области

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

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

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

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




Программирование – это частьпроцесса проектирования


Кристен Нигаард (Kristen Nygaard), отец объектно-ориентированного про-граммирования и языка программирования Simula, говорил, что программи-

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

Например, в 1987 году Фредерик Брукс (Frederick Brooks, Jr.) в «Отчетеоперативной группы Научного совета Министерства обороны по военномупрограммному обеспечению» утверждал, что документно-ориентированныйподход по принципу «сначала спецификация, потом разработка» лежитв основе многих проблем программного обеспечения.

Откуда же индустрия разработки программного обеспечения может черпатьпрактические идеи для совершенствования своих методик? Как насчет от-раслей производства сложных товаров массового производства: автомоби-: автомоби-автомоби-лей, лекарств, полупроводников?

Возьмем автомобилестроение. Планирование новой модели начинаетсяс выбора концепции или прототипа. Это в первую очередь механизм архи-тектурного позиционирования. BMW X6 – пример новой концепции, объ-BMW X6 – пример новой концепции, объ-X6 – пример новой концепции, объ-X6 – пример новой концепции, объ-6 – пример новой концепции, объ-единяющей свойства внедорожника и купе, которую BMW называет sportsactivity coupe. Прежде чем вы получили возможность приобрести новый X6,BMW потратила тысячи часов и миллионы долларов на проектирование ма-потратила тысячи часов и миллионы долларов на проектирование ма-шины и процесса ее производства. Когда BMW получает ваш заказ, одна из



77Программирование – это часть процесса проектирования

сборочных линий переключается и выдает версию X6, выполненную по ва-X6, выполненную по ва-6, выполненную по ва-шему личному заказу.

Чему можно научиться на примере этого сценария? Здесь важно то, чтопроизводство новой машины состоит из двух процессов. Первый из них –

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

В своей статье «Как проектировать ПО?»1 Джек Ривз (Jack Reeves) высказы-Jack Reeves) высказы-Reeves) высказы-Reeves) высказы-) высказы-вает мнение, что единственным артефактом разработки ПО, действительноописывающим дизайн (в том смысле, как понимается и используется это по-нятие в классических инженерных дисциплинах), является исходный код.

Собственно производство ПО автоматизировано и обеспечивается сценария-ми компиляции, сборки и тестирования.

Соглашаясь с тем, что создание исходного кода является частью проектиро-вания, а не производства, мы получаем возможность применить полезныеметоды управления, работоспособность которых была проверена временем.Это методы управления творческой и непрогнозируемой работой, такой какразработка новой машины, нового лекарственного препарата или новой ком-пьютерной игры. Речь идет о методах гибкого (agile) управления и бережли-вого (lean) производства (например, SCRUM). Эти методы направлены на то,чтобы максимизировать эффективность вложений с позиций ценности дляпотребителя.

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


1 Журнал «Компьютерра», опубликовавший русский перевод этой статьи и автор-ское послесловие к ней, сделал ее темой номера («Компьютерра», №17 (589), 5 мая2005 г., http://offline.computerra.ru/2005/589/). – Примеч. ред.



Предоставьте разработчикамнезависимость


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

У разработчика редко находится время для того, чтобы откинуться в креслеи подумать над тем, насколько слаженной является работа системы в целом.В то же время все внимание архитектора должно быть сосредоточено имен-но на этом. Пока разработчики во весь опор создают классы, методы, тесты,интерфейсы и базы данных, вы следите за тем, как эти компоненты работа-ют в сочетании друг с другом. Ищите «узкие места» и пытайтесь устранитьих. У ваших людей возникают проблемы с написанием тестов? Улучшитеинтерфейсы и ограничьте зависимости. Непонятно, где абстракция действи-тельно необходима, а где можно обойтись без нее? Добейтесь лучшего пони-

мания предметной области. Не знаете, в каком порядке создавать компонен-ты системы? Составьте план проекта. Разработчики повторяют одни и те жеошибки при использовании спроектированного вами API? Сделайте дизайнболее понятным. Разработчики плохо понимают ваш дизайн? Пообщайтесьс ними и все подробно разъясните. Вы сами плохо понимаете, где масштаби-рование уместно, а где нет? Поработайте с заказчиками и разберитесь в ихбизнес-модели.



79Предоставьте разработчикам независимость

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

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

Филип Нельсон (Philip Nelson) – технический специалист широкого профи-ля. На заре своей карьеры он имел дело с аппаратным обеспечением компью-

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



Время меняет все


Многие годы одним из самых ярких развлечений для меня было наблюдениеза тем, что выжило, а что нет. Шаблоны, инфраструктуры, сдвиги пара-дигм, алгоритмы – их было так много, умные люди так страстно обсужда-ли их, думали о долгосрочных перспективах, старались сбалансировать всеизвестные аспекты, но в конечном счете они ушли в небытие. Почему? Чтоистория пытается сказать нам?

Выбирайте достойную задачу

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

Будьте проще

Мы часто говорим себе: будь проще1. Говорим – но не делаем. А не делаемпотому, что это необязательно. Ведь мы такие умные, мы без труда управ-

1 В оригинале здесь расшифровка хорошо известного англоязычным разработчи-кам акронима KISS – Keep It Simple, Stupid. – Примеч. ред.



81Время меняет все

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

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

Будьте довольны сделанным

Архитекторы любят искать «единственный истинный путь» – методологию

или философию, способную привнести столь желанную предсказуемостьи открыть наконец те ясные ответы, которые, как им кажется, находятсягде-то совсем рядом. Проблема в том, что ориентиры, которыми вы руковод-ствуетесь сейчас, вряд ли останутся теми же через пару лет, не говоря ужео десятилетиях. Оглядываясь назад, вы всегда видите результаты, не соот-ветствующие вашему нынешнему уровню притязаний. Научитесь прини-мать свои прежние достижения и боритесь с искушением попытаться вер-нуться и «исправить» их. Соответствовало ли решение поставленной задаче?Удовлетворяло ли оно требованиям? Используйте эти вопросы как критерииоценки – и у вас будет радостнее на душе.




«Архитектор программногообеспечения» пишетсясо строчной буквы


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

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

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



83«Архитектор программного обеспечения» пишется со строчной буквы

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

на том, что архитектор программного обеспечения должен стоять на однойступени с Адвокатом, Доктором и Зодчим.

Должность «архитектор программного обеспечения» пишется со строчнойбуквы «а»; осознайте этот факт и примите его.

Барри Хокинс (Barry Hawkins) за свою 13-летнюю карьеру в области созда-ния ПО испробовал различные амплуа – от разработчика-одиночки до ру-ководителя команды и инструктора по методологиям гибкой разработки.В настоящее время Барри занимается преподаванием методологий гибкой

разработки и проектирования на основе предметной области.



Масштаб – враг успеха

Äýéâ Êóèê

Границы проекта характеризуют его масштаб. Сколько времени, усилий и ре-сурсов необходимо для его реализации? Какую функциональность и с какимуровнем качества требуется получить? Насколько сложно сдать продукт к за-данному сроку? Какова степень риска? Какие имеются ограничения? Ответына эти вопросы определяют границы проекта. Архитекторам программногообеспечения больше нравится тот вызов, который им бросают большие, слож-ные проекты. Потенциальные выгоды даже искушают людей искусственнораздувать размеры проекта для повышения его кажущейся важности. Одна-ко расширение границ – враг успеха, потому что вероятность неудачи рас-тет быстрее, чем можно ожидать. Увеличение масштаба проекта вдвое частоприводит к тому, что вероятность провала возрастает на порядок.

Почему так происходит? Рассмотрим несколько примеров.

Интуиция подсказывает нам выделить вдвое больше времени или ресур-•

сов, чтобы удвоить объем работы. Однако история показывает1, что связьмежду ними не такая линейная, как утверждает интуиция. Например,в команде из четырех человек затраты времени на взаимодействия воз-растают более чем вдвое по сравнению с командой из двух человек.

Наши оценки – отнюдь не точная наука. Кто из нас не попадал в ситуа-•

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

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

1 См. книгу Фредерика Брукса «Мифический человеко-месяц, или как создаютсяпрограммные системы» (СПб: Символ-Плюс, 2000).



85Масштаб – враг успеха

текстовым редактором. Какие же стратегии помогают управлять границамив реальных проектах?

Узнайте реальные потребности.• Реализация проекта должна обеспе-чивать выполнение набора требований. Требования определяют функ-

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

«Разделяй и властвуй»• . Ищите возможности разделить работу на мень-шие независимые фрагменты. Управлять несколькими небольшими не-зависимыми проектами проще, чем одним большим проектом с взаимо-связанными частями.

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

Демонстрируйте результаты как можно скорее• . Люди редко понима-ют, что им нужно, пока не получат какой-нибудь результат. В известномкомиксе1 представлена эволюция проекта детских качелей: что сказалзаказчик и как его требования поняли участники проекта, выполняю-щие те или иные роли. В итоге получается хитроумное сооружение,

лишь отдаленно напоминающее качели. А на последнем рисунке под на-званием «Чего хотел заказчик» изображены простейшие качели из ав-томобильной покрышки на веревке. Когда у заказчика есть что-то, чтоон может самолично испытать, решение порой оказывается проще, чемпредполагалось. При первоочередной реализации самых важных функ-ций вы в качестве обратной связи получаете самую важную информациюна ранней стадии, когда она нужна больше всего.

Сторонники гибких методологий увещевают нас строить «самое простое, чтобудет работать»2. Неудачи проектов со сложной архитектурой происходятнамного чаще, чем с простой. Сокращение границ проекта часто приводит

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


1 См. http://www.businessballs.com/treeswing.htm. – Примеч. перев.

2 См. книгу Кента Бека (Kent Beck) «eXtreme Programming eXplained: EmbraceChange» (Addison-Wesley Professional, 2004).



Ответственное руководствоважнее внешнего впечатления


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

Умение произвести впечатление на аудиторию играет важную роль в мар-

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

Ответственное руководство – вот достойная роль для архитектора. Архитек-тор должен действовать в интересах заказчика, а не потворствовать капри-зам своего эго.

Деятельность архитектора программного обеспечения направлена на удов-летворение потребностей пользователей чаще всего на основании указаний

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



87Ответственное руководство важнее внешнего впечатления

Время и затрачиваемые усилия – ресурсы, принадлежащие компании; ар-хитектор должен управлять ими добросовестно, без скрытых попыток реа-лизовать собственные цели. Чрезмерно сложные системы на базе новомод-ных инфраструктур или технологий редко обходятся без дополнительных

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

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




У программной архитектурыесть этические аспекты


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

Каждый раз, когда я принимаю решение относительно поведения програм-мы, я в действительности решаю, что смогут и что не смогут делать ее поль-

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

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

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

Представьте себе, что вы должны принять решение относительно некото-рой функции. Есть два варианта реализации: простой, требующий одно-го дня работы, и сложный, который отнимет неделю. В простом варианте



89У программной архитектуры есть этические аспекты

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

Обязательные поля выглядят довольно безобидно, но с ними вы навязываете

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

Рассмотрим такую аналогию: допустим, мне нужно прикрепить на зданиевывеску. Можно ли смонтировать ее на высоте 1,8 м, заставляя тем самымпешеходов нырять под нее или обходить ее стороной? Конечно, мне будетпроще обойтись без лестниц и строительных лесов, при этом вывеска даже

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

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




Небоскребыне масштабируются


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

Самая трудная часть строительства не проектирование здания, которое бу-дет стоять на своем месте после завершения, а проработка процесса строи-тельства. Этот процесс начнется с пустой площадки и завершится готовымзданием. За это время каждый рабочий должен иметь возможность при-менить свои профессиональные навыки, а частично возведенное строениедолжно оставаться устойчивым. Мы можем извлечь из этой аналогии по-

лезный урок в том, что касается развертывания больших интегрирован-ных систем. (А к категории «интегрированных» относятся практически всекорпоративные и веб-приложения!) Традиционное развертывание по схеме«Большого взрыва» выглядит так, словно вы привезли на пустырь груду ба-лок и брусьев, подбросили их в воздух и ожидаете, что они сами сложатсяв форме здания.

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

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



91Небоскребы не масштабируются

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

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

С другой стороны, в ряде важных аспектов аналогия со строительствомне работает. В частности, материальность реального мира усиливает рольпредварительного планирования, заставляя нас использовать метод «водо-пада». В конце концов, никто не начинает строить небоскреб, не зная зара-нее, сколько места он займет и сколько этажей в нем будет. Добавлять этажик существующему зданию слишком дорого и рискованно, поэтому мы стара-емся избегать таких крайностей. Местонахождение или высота единождыспроектированного небоскреба уже не должны изменяться. Небоскребы немасштабируются.

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

практике чем раньше вы выпустите свое приложение, тем выше будет чис-тая стоимость итогового продукта.

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

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




Неоднородность побеждает


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

Концепция многоязыкового программирования не нова; характерным при-мером из прошлого служат системы, в которых клиентская часть написанана Visual Basic и использует серверную часть на базе объектов COM, написан-Visual Basic и использует серверную часть на базе объектов COM, написан-Basic и использует серверную часть на базе объектов COM, написан-Basic и использует серверную часть на базе объектов COM, написан-и использует серверную часть на базе объектов COM, написан-COM, написан-, написан-ных на C��. По сути дела эта архитектура эффективно использовала силь-C��. По сути дела эта архитектура эффективно использовала силь-��. По сути дела эта архитектура эффективно использовала силь-ные стороны каждого из упомянутых языков в зените их популярности.

Какие же перемены возродили интерес к многоязыковому программированию?

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

сте с веб-службами на базе XML/SOAP и продолжает развиваться в направ-XML/SOAP и продолжает развиваться в направ-/SOAP и продолжает развиваться в направ-SOAP и продолжает развиваться в направ-и продолжает развиваться в направ-лении архитектурных стилей RES и других вспомогательных (но не менееважных) протоколов типа Atom и XMPP.

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



93Неоднородность побеждает

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

Теперь архитекторы могут объединять специализированные мощные ин-струменты, позволяющие вести речь уже не о способности применить под-

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

Эффект этих изменений уже виден в комбинаторном увеличении сложности

архитектурной топологии современных программных систем. Этот аспект –не столько отражение присущей им разнородности, сколько признак новыхвозможностей.

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

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

Эдвард Гарсон (Edward Garson) стал страстным энтузиастом програм-мирования еще с тех времен, когда учился программировать на Logo на ком-Logo на ком-на ком-пьютере Apple II. В настоящее время он работает архитектором программ- Apple II. В настоящее время он работает архитектором программ-II. В настоящее время он работает архитектором программ-II. В настоящее время он работает архитектором программ-. В настоящее время он работает архитектором программ-ного обеспечения в Центре гибких методологий программирования в ZuhlkeEngineering – одной из ведущих швейцарских технологических компаний.

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

2 См. статью «he Free Lunch is Over» Герба Саттера (Herb Sutter) по адресу http://www.gotw.ca/publications/concurrency-ddj.htm.



Не забывайтео производительности

Êðåéã Ðàññåë

Представьте себе автомобиль – просторный, удобный, экономичный, недо-рогой и утилизируемый на 98%. Хотите такой? Конечно. Кто угодно захо-чет. Ах, да, единственная проблема: его максимальная скорость составляет10 км/ч. Не передумали? Этот маленький пример наглядно показывает, чтопроизводительность так же важна, как и любой другой критерий.

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

быстродействия, обо всем позаботится закон Мура. Однако скорость работыоборудования – лишь один из аспектов системы.

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

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



95Не забывайте о производительности

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

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

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

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

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

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

Крейг Рассел (Craig Russell) – практикующий архитектор программногообеспечения, специализирующийся на персистентности объектов (object persistence) и распределенных системах. В настоящее время работает ве-) и распределенных системах. В настоящее время работает ве-дущим специалистом в компании Sun Microsystems.



Проектирование в пустоте


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

Одна маленькая стрелка может означать: «Синхронный запрос/ответ в фор-мате SOAP-XML через HP». Для одного элемента диаграммы получаетсяслишком много информации. Места для полной записи обычно не хватает,поэтому мы помечаем стрелку надписью «XML через HP» (с точки зрения

внутренней реализации) или «Поиск по коду товара» (с точки зрения внеш-них пользователей).

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

Сетевые карты•

Сетевые коммутаторы•

Брандмауэры•

Системы обнаружения и предотвращения вторжений (IDS/IPS)•

Брокеры или очереди сообщений•

Механизмы преобразования XML•

Серверы FP•

Зонные таблицы•

Кольца SoNE•



97Проектирование в пустоте

Шлюзы MPLS•

Магистральные линии•

Океаны•

Рыболовные траулеры, повреждающие донные кабели•

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

Однажды я видел стрелку с надписью «Исполнение». Один сервер был уста-новлен в компании моего клиента, второй находился совершенно в другомместе. Эта жизненно важная для клиента стрелка запускала цепочку собы-тий, которая больше напоминала игру «Мышеловка», нежели единый ин-терфейс. Сообщения передавались брокерам, сохраняющим их в файлах,которые периодически запускаемыми заданиями загружались на FP…и т. д. Этот «интерфейс» включал в себя более 20 этапов.

Необходимо хорошо понимать, какая статическая и динамическая нагрузкаложится на каждую стрелку. Рядом с «SOAP-XML через HP» около стрел-SOAP-XML через HP» около стрел--XML через HP» около стрел-XML через HP» около стрел-через HP» около стрел-HP» около стрел-» около стрел-ки стоило бы написать также: «С каждым запросом HP принимается однообращение, с каждым ответом HP возвращается один ответ. Ожидаетсядо 100 запросов в секунду, ответ в 99,999% случаев должен выдаваться ме-нее чем за 250 мс».

Но и это еще не все, что необходимо знать об этой стрелке:

Что если вызывающая сторона обращается по ней слишком часто? Как•

должен действовать получатель – игнорировать запросы, вежливо отка-зывать или по возможности стараться их обработать?

Что делать вызывающей стороне, если обработка запроса заняла более•

250 мс? Повторить попытку? Немного подождать? Решить, что на сторо-не получателя произошел сбой, и продолжить работу без этой функции?

Что произойдет, если вызывающая сторона отправила запрос по прото-•

колу версии 1.0, а получила ответ в версии 1.1? А если вместо XML былполучен код HML? Или файл в формате MP3 вместо XML-файла?

Что произойдет, если одна из сторон интерфейса станет временно недо-•

ступной?

Ответы на эти вопросы представляют собой суть проектирования «в пустомпространстве» диаграмм.




Изучитепрофессиональный жаргон


В любой профессии существует свой жаргон, повышающий эффективностьобщения представителей этой профессии. Адвокаты говорят друг с другомо Habeas Corpus, Voir Dire и Venire, плотники – о соединениях встык и вна-хлест и о пропитках, а архитекторы ПО – о ROA, двухэтапном представле-ROA, двухэтапном представле-, двухэтапном представле-нии и супертипах уровней …Минуточку… о чем, простите?..

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

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

Архитектурные шаблоны и шаблоны проектирования можно разделить начетыре основные категории: шаблоны корпоративного уровня, шаблоныуровня приложения, шаблоны интеграции и шаблоны проектирования. Этикатегории обычно определяются уровнем абстракции шаблона в общей ар-хитектуре. Шаблоны корпоративного уровня относятся к высокоуровневойархитектуре, тогда как шаблоны проектирования относятся к структуре

и поведению отдельных компонентов общей архитектуры.Шаблоны корпоративного уровня определяют «каркас» высокоуровневойархитектуры. К числу самых распространенных архитектурных шаблоновотносятся архитектура, управляемая событиями (EDA, Event-Driven Archi-, Event-Driven Archi-Event-Driven Archi--Driven Archi-Driven Archi-Archi-Archi-tecture), сервис-ориентированная архитектура (SOA, Service-Oriented Archi-, Service-Oriented Archi-Service-Oriented Archi--Oriented Archi-Oriented Archi-Archi-Archi-tecture), ресурсно-ориентированная архитектура (ROA, Resource-OrientedArchitecture) и конвейерная архитектура (pipeline architecture).



99Изучите профессиональный жаргон

Шаблоны уровня приложения описывают дизайн приложения или подсис-темы в контексте более крупной корпоративной архитектуры. К этой катего-рии относятся хорошо известные шаблоны J2EE (например, Session Facade(фасад сессии) и ransfer Object (объект перемещения)), а также шаблоны,

описанные в книге Мартина Фаулера (Martin Fowler) «Patterns of EnterpriseApplication Architecture»1 (Addison-Wesley Professional).

Шаблоны интеграции играют важную роль в проектировании и описанииконцепций, связанных тем, как компоненты, приложения и подсистемы со-вместно используют информацию и функциональность. Вот некоторые при-меры шаблонов интеграции: общий доступ к файлам, удаленные вызовыпроцедур, различные шаблоны передачи сообщений. Описания этих шабло-нов см. http://www.enterpriseintegrationpatterns.com/eaipatterns.html.

Знание основных шаблонов из книги «банды четырех» «Design Patterns:

Elements of Reusable Object-Oriented Software»2

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

Архитектор должен также знать и понимать суть различных антипаттернов. Антипаттерны (термин введен Эндрю Кенигом (Andrew Koenig)) представ-ляют собой повторяемые процессы, приводящие к неэффективным резуль-татам. Вот хорошо известные примеры антипаттернов: Analysis Paralysis(аналитический паралич), Design By Committee (разработка комитетом),Mushroom Management (управление грибами), Death March (путь камикад-зе3). Знание этих шаблонов поможет вам избежать многих типичных оши-бок. Список распространенных антипаттернов приведен по адресу http://ru.wikipedia.org/wiki/Анти-паттерн.

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


1 Фаулер М. и др. «Шаблоны корпоративных приложений». – М.: Вильямс, 2010.

2 Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. «Приемы объектно-ориенти-рованного проектирования. Паттерны проектирования». – СПб: Питер, 2007.«Бандой четырех» часто называют группу авторов этой книги. – Примеч. ред.

3 Название этого антипаттерна явно перекликается с книгой «Death March»(Йордон Э. «Путь камикадзе». – М.: Лори, 2008). – Примеч. ред.



Правила диктует контекст


Мне видится здесь некоторая ирония: разговор об идеалах архитектуры я на-чинаю с заявления о том, что идеалов, по сути дела, не существует. Ну, а еслиих нет, то и писать, видимо, больше не о чем… Налицо явное противоречие,и попытки продолжать в том же духе могут, чего доброго, привести к гибелиВселенной или чему-нибудь еще в этом роде – как знать?

Но увы, ceci n’est pas une pipe1.

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

смысле это означает, что контекст – единственная сила, превосходящая про-стоту при принятии архитектурных решений.

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

Из чего состоит хорошая архитектура? Она является продуктом решений,которые принимаются в контексте противоречивых задач с различными

приоритетами. Это означает, что самые важные решения иногда связаны нес тем, что следует включить в систему, а с тем, что из нее следует исключить.Ценность хорошей архитектуры заключается в умелом принятии решений(а ее продукт всего лишь отражает ваши намерения).

1 «Это не трубка» (фр.). Подпись под курительной трубкой на картине сюрреалистаРене Магритта «Вероломство образов». – Примеч. перев.



101Правила диктует контекст

История предлагает нам немало интересных примеров влияния контекстана архитектуру. Мой любимый пример – выбор базы данных для программ-ного обеспечения современного танка1. (Обычно выбор базы данных не име-ет существенного значения для архитектуры системы; этот пример приво-

дится лишь для пояснения.)Когда пришло время выбирать базу данных, команда занялась изучениемразличных вариантов. Большинство баз данных оказалось способным обе-спечить уровень производительности, необходимый для систем навигациии наведения на цель при быстром движении танка по пересеченной местно-сти. Но потом команда неожиданно выяснила, что выстрел из орудия созда-ет сильный электромагнитный импульс, который вызывает сбой бортовыхсистем – и, конечно, базы данных! На современном поле боя танк с нера-ботающим программным обеспечением буквально теряет связь с внешниммиром. В этом контексте решающим фактором при выборе базы данных ста-ло время восстановления, и лучшими показателями в этом отношении об-ладала на тот момент InterBase, поэтому для танка M1 Abrams была в итогевыбрана именно эта база данных2.

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

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


1 Несмотря на свое в высшей степени сомнительное предназначение, танк остаетсячудом технической мысли.

2 Интересно отметить, что вследствие особенностей архитектуры InterBase базаданных в процессе записи на диск всегда находится в согласованном состоянии.Это один из факторов, которые обусловливают столь быстрое восстановлениебазы при сбоях оборудования.



Гномы, эльфы,волшебники и короли

Ýâàí Êîôñêè

В романе Нила Стивенсона «Cryptonomicon»1 Рэнди Уотерхауз излагает своюклассификацию рас, с которыми ему доводилось встречаться. Гномы – тру-дяги, корпящие над произведениями искусства во мраке своих пещер. Ониповелевают огромными силами, способными перемещать горы и преобра-жать ландшафт, и славятся своим мастерством. Эльфы отличаются изы-сканностью и высочайшей культурой; они проводят свои дни за созданиемновых прекрасных волшебных предметов. Они до такой степени талантли-вы, что даже не сознают, насколько сверхъестественными представляютсяэти предметы другим расам. Волшебники наделены огромной силой, но,

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

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

1 Нил Стивенсон «Криптономикон» (АC, 2006, 2007).



103Гномы, эльфы, волшебники и короли

Хороший король ведет все «расы» подданных к великой цели и помогает имтрудиться бок о бок, чтобы достичь ее. Без великой цели у команды не будетв дения, а ее работа в конечном итоге превратится в партизанские вылазки.Без представителей всех «рас» команда сможет решать проблемы только

одного типа и остановится у первой же преграды, не соответствующей этомурешению.

Архитектор указывает цель, принимая в расчет особенности всех «рас».Тогда архитектура становится руководством по поиску таких задач, которы-ми смогут заниматься члены команды из разных «рас», пока будут большеузнавать друг о друге. Когда проект столкнется со сложностями, командауже будет знать, как подходить к их преодолению, потому что архитектурадала команде возможность стать одним целым.

Эван Кофски (Evan Cofsky) – программист, музыкант-любитель и заядлыймотоциклист. Он увлекся музыкой и компьютерами в колледже и продол-жает увлеченно заниматься ими до сих пор. В настоящее время являет-ся штатным экспертом по языку Python в компании Virgin Charter, гдев должности ведущего разработчика возглавляет команду исключительноталантливых и разносторонних людей.



Учитесь у архитекторовзданий


Архитектура – социальный акт и материальный театр человече-ской активности.

Спиро Костоф (Spiro Kostof)

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

Архитектор становится великим благодаря не столько уму, сколькочистому, чуткому сердцу.

Фрэнк Ллойд Райт (Frank Lloyd Wright)

Что в большей степени присуще архитекторам вашей организации: необуз-данная интеллектуальная мощь и способность помнить мельчайшие тех-нические детали или хороший вкус, изысканность и душевная щедрость?В какой атмосфере предпочли бы работать вы сами?

Врач может похоронить свою ошибку, архитектор – разве что обса-

дить стены плющом. Фрэнк Ллойд Райт

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



105Учитесь у архитекторов зданий

Архитекторы не только верят, что сидят по правую руку от Бога,

но и считают, что если Бог встанет, то они займут его место.

Карен Мойер (Karen Moyer)

Замените «Бог» на «заказчик».

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

ство, Прочность и Эстетичность.

Генри Уоттон (Henry Watton)

Когда вам в последний раз попадался на глаза программный продукт, ар-хитектура которого доставила вам эстетическое удовольствие? А вы самистремитесь к тому, чтобы ваши работы были эстетичными?

Человек, не являющийся великим скульптором или художником, неможет быть архитектором. Если он не скульптор, не художник, то

сможет быть только строителем.

Джон Раскин (John Ruskin)

Занимает ли эстетика достойное место в вашей архитектуре? Движет ли ва-ми в ходе объединения компонентов при построении систем художествен-ный интерес к формам и текстурам, скульптурное чувство баланса и стрем-ление к передаче движения либо ощущение важности отрицательного про-странства?

И наконец, высказывание, не требующее комментариев, – верное средствоот самого разрушительного синдрома в работе архитектора:

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

может быть действительно великой.

Джон Раскин




Боритесь с повторениями


Приходится ли вашим разработчикам выполнять однообразные задания, надкоторыми почти не нужно думать? Попадаются ли в коде почти одинако-вые фрагменты? Замечаете ли вы код, написанный методом «скопировать-вставить-изменить»? Если ответы положительные, то ваша команда работа-ет медленнее, чем могла бы, и, как ни странно, причиной тому можете бытьименно вы.

Прежде чем пускаться в объяснения, давайте договоримся о двух истинах,касающихся разработки программного обеспечения:

Дублирование – это зло.•

Повторяющаяся работа замедляет разработку.•

Вы как архитектор задаете тон. Вы лучше всех представляете себе системув целом, и, скорее всего, именно вы задали направление работы, создав пол-ный вертикальный срез системы – пример, который к настоящему моментубыл неоднократно скопирован. Каждая операция копирования (копируетли разработчик несколько строк кода, XML-файл или класс) свидетельству-XML-файл или класс) свидетельству--файл или класс) свидетельству-ет о том, что в системе что-то можно упростить или выкинуть. Чаще всегокопируется не логика предметной области, а инфраструктурный код, обе-

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



107Боритесь с повторениями

В вашей системе такого не происходит, правда? А теперь взгляните на этотконфигурационный файл: что потребует изменения, если применить егок другой части системы, а что останется прежним? Или возьмите типичныйметод уровня бизнес-логики: нет ли в нем шаблона, который проявляется

и в других методах с такими операциями, как обработка транзакций, логи-рование, аутентификация или аудит? А как насчет уровня доступа к дан-ным? Часто ли встречаются одинаковые фрагменты, отличающиеся толькоименами сущностей и полей? Смотрите на вещи шире. Попадаются ли вамдве-три строки кода, которые всегда идут рядом и воспринимаются как одноцелое, хотя и работают с разными объектами? Все это примеры повторения.Со временем разработчики учатся отсеивать и игнорировать повторения причтении кода, обращая внимание лишь на интересные отличия. Но даже приналичии такого навыка чтение кода тормозится. Такой код подходит длявыполнения компьютером, но не для чтения разработчиками.

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

И этот кто-то – вы.




Добро пожаловатьв реальный мир

Ãðåãîð Õîï

Технари любят точность – особенно программисты, живущие в мире нулейи единиц. Они привыкли работать с двоичными решениями: один/ноль, ис-тина/ложь, да/нет. Всё четко и последовательно, от неожиданностей защи-щают ограничения внешних ключей, атомарные транзакции и контрольныесуммы.

К сожалению, реальный мир не столь упорядочен. Клиенты оформляют за-казы, а через секунду отменяют их. Чеки отклоняются, письма теряются,платежи задерживаются, а обещания нарушаются. Ошибки ввода данныхпроисходят чаще, чем нам хотелось бы. Пользователи предпочитают «пло-ские» («shallow») интерфейсы, которые предоставляют одновременный до-shallow») интерфейсы, которые предоставляют одновременный до-) интерфейсы, которые предоставляют одновременный до-ступ ко многим функциям, а не длинный и узкий коридор «процесса» вво-да данных, который проще реализуется и кажется многим разработчикамболее «логичным». Ходом выполнения программы управляет уже не стеквызовов, а пользователь.

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

вопрос уже не в том, произойдет ли сбой, а в том, когда он произойдет. Такиесистемы обладают слабой связанностью (loosely coupled), асинхронностьюи параллелизмом и не соответствуют традиционной транзакционной семан-тике… Не желаете принять синюю таблетку?!

Дивный новый мир компьютерных технологий трещит по швам – так что женам делать? Как это часто бывает, осознание проблемы становится первымважным шагом к ее решению.



109Добро пожаловать в реальный мир

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

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

Звучит слишком устрашающе? Вы на такое не рассчитывали? К счастью,в реальном мире с похожими проблемами имеют дело уже давно: задерж-ки писем, нарушенные обещания, перепутанные сообщения, платежи не нате счета – примеров не счесть. Соответственно люди вынуждены посылатьписьма заново, списывать некорректные заказы и игнорировать напомина-ния об уже произведенных платежах. Не вините реальный мир в своих про-блемах – лучше используйте его, чтобы подсмотреть решения. В конце кон-цов, Starbucks тоже не использует протокол двухфазной фиксации1. Добропожаловать в реальный мир!

Грегор Хоп (Gregor Hohpe) – архитектор ПО в компании Google, Inc. Грегорявляется общепризнанным экспертом в области асинхронных архитектурдля систем обмена сообщениями и сервис-ориентированных архитектур.Он является соавтором книги «Enterprise Integration Patterns»2 (Addison-Wesley Professional), регулярно выступает на технических конференцияхпо всему миру.

1 См. http://www.eaipatterns.com/ramblings/18_starbucks.html.

2 Хоп Г., Вульф Б. «Шаблоны интеграции корпоративных приложений». – М.: Вильямс, 2007.



Не контролируйте –наблюдайте

Ãðåãîð Õîï

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

Итак, стремление создать систему гибкую и способную развиваться со вре-

менем – дело хорошее. Но это означает также, что наша система будет посте-пенно изменяться. Другими словами, «сегодня система уже не та, какой бы-ла вчера». К сожалению, это заметно усложняет документирование системы.Все знают, что документация устаревает в момент печати, но в постоянно из-меняющейся системе дела могут обстоять еще хуже. Более того, построениегибкой системы обычно усложняет архитектуру, и получить пресловутую«общую картину» становится еще труднее. Например, если все компонентысистемы обмениваются информацией по логическим, настраиваемым кана-лам, то, чтобы получить представление о происходящем, необходимо взгля-

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

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



111Не контролируйте – наблюдайте

какие приборы есть в нашем распоряжении? Вообще-то их более чем доста-точно. Современные языки программирования поддерживают рефлексию(reflection), и почти все платформы предоставляют динамические метрикивремени выполнения. По мере того как система становится более настраи-

ваемой, ее текущая конфигурация сама становится отличным источникоминформации. Так как разобраться в слишком большом объеме низкоуровне-вых данных довольно трудно, создайте на их основе модель. Например, ког-да станет ясно, какие компоненты отправляют сообщения по тем или инымлогическим каналам и какие компоненты ожидают поступления сообщенийпо этим каналам, вы сможете построить граф передачи данных между ком-понентами. Эту процедуру можно производить каждые несколько минутили часов, создавая точную и оперативную картину системы в ходе ее разви-тия. Считайте это своего рода «MDA наоборот»1: вместо модели, управляю-щей архитектурой, вы строите гибкую архитектуру и формируете модель на

основании текущего состояния системы.Во многих случаях модель можно легко визуализировать, построив действи-тельно «общую картину». Однако боритесь с соблазном заполнить квадрати-ками и линиями полотно 3 × 5 метров в стремлении изобразить все классывашей системы. Такая картина сойдет за произведение современного искус-ства, но ее не назовешь полезной программной моделью. Вместо этого луч-ше использовать «вид с высоты 300 метров», как рекомендует Эрик Дорнен-бург, – тот уровень абстракции, который содержит действительно полезнуюинформацию. Вдобавок вы сможете проследить за тем, чтобы в модели не

было нарушений простейших правил корректности – циклических ссылокв графе зависимостей или отправки сообщений по непрослушиваемым логи-ческим каналам.

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


1 MDA (Model-Driven Architecture) – архитектура, управляемая моделями.



Архитектор Янус


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

Способность Януса смотреть вперед и назад, видеть прошлое и будущее яв-ляется исключительно ценным навыком как для архитектора программногообеспечения, так и для архитектора-строителя. Архитектор стремится объ-единить реальность со своим представлением о ней, прошлые достижения –с планами на будущее, ожидания руководства – с ограничениями разработ-ки. Наведение таких мостов – важнейшая часть работы архитектора. Частоу архитектора возникает чувство, что в своем стремлении довести проект дозавершения ему приходится преодолевать пропасти, которые созданы воз-действием сил, направленных в противоположные стороны. Это могут быть,например, простота в использовании и безопасность или соответствие теку-щим бизнес-процессам и ориентация на перспективу, обрисованную руко-водством. У хорошего архитектора должно быть «две головы», способныеудерживать две разные идеи или концепции, две разные цели или точки зре-

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

Обратите внимание: у Януса две головы, а не просто два лица. Иначе гово-ря, он обладает дополнительной парой ушей и глаз, что повышает его осве-домленность и восприимчивость. Хороший I-архитектор должен бытьпревосходным слушателем и аналитиком. Понимание причин, по кото-рым осуществляются инвестиции, жизненно важно для определения целейи представлений руководства о будущем организации. Умение оценивать



113Архитектор Янус

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

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

Некоторые начальники ожидают от своих архитекторов едва ли не божест-венных способностей, но это не то, что я имел в виду, сравнивая архитекторас божеством. Хороший архитектор открыт для новых идей, инструментови способов проектирования, способствующих прогрессу проекта, развитиюкоманды или профессиональному совершенствованию; он не желает тратитьбольшую часть своего времени на совещания с руководством или собственно-ручное написание кода; он должен распознавать ценные идеи и создавать ат-мосферу, способствующую их созреванию. Успеха в проектировании можетдобиться только подлинно открытый ум – ум, способный в ходе выполненияпроекта находить точку равновесия множества противоборствующих сил.Каждый архитектор стремится завершить свой проект и обеспечить успехсвоей команды. Лучшие из архитекторов создают системы, которые выдер-живают проверку временем, поскольку способны сохранять работоспособ-ность и развиваться по мере роста организации и изменений в технологи-ях. Такие архитекторы прислушиваются к мнениям других, анализируют

и перерабатывают свои процессы, методы и подходы к проектированию; ониприлагают особые усилия, чтобы их продукты устояли перед неизбежнымиизменениями и переходами.

К такому образу мышления должны стремиться мы, архитекторы. Это легческазать, чем сделать. Подобно Янусу, архитектор должен стать хранителемдверей и проходов, прокладывать мосты между старым и новым; он долженобъединять творческий подход с надежным техническим фундаментом, что-бы, выполняя сегодняшние требования, быть готовым к завтрашним пере-менам.




В центре внимания архитектора –границы и интерфейсы


С тех пор как лорд Нельсон уничтожил французский и испанский флоты приТрафальгаре в 1805 году, принцип «разделяй и властвуй» стал главной мант-рой для решения сложных, комплексных задач. Другой, более знакомыйтермин с таким же смыслом – разделение ответственности (separation ofconcern). Разделение ответственности ведет к инкапсуляции, а инкапсуля-ция способствует выделению границ и интерфейсов.

Если смотреть на задачу глазами архитектора, наиболее сложная ее часть –поиск естественных мест для формирования границ и определение подходя-щих интерфейсов, нужных для создания работоспособной системы. Это осо-бенно трудно сделать в крупных корпоративных системах, где естественныхграниц зачастую очень мало, а различные предметные области тесно пере-плетены. В подобных ситуациях отчасти помогают традиционные принци-пы вроде «Минимизируй связанность, увеличивай сцепление» (minimizecoupling, maximize cohesion) и «Не разрезай там, где нужен интенсивныйобмен информацией», однако они ничего не говорят о том, как простым пу-тем донести информацию о задачах и потенциальных решениях до заинте-

ресованных сторон.Здесь на помощь приходит концепция ограниченных контекстов и карт кон-текстов, описанная Эриком Эвансом в книге «Domain-Driven Design» (Про-ектирование на основе предметной области) (Addison-Wesley Professional).Ограниченным контекстом (bounded context) называется область уникаль-ного определения модели или понятия; на диаграммах она изображаетсяв виде «облачка» с содержательным именем, определяющим его роль илизадачу в предметной области. Например, система транспортировки может



115В центре внимания архитектора – границы и интерфейсы

содержать такие контексты, как «Отгрузка», «Планирование отгрузки»и «Перемещения в пределах порта». В других предметных областях возник-нут другие имена.

После того как вы выделили ограниченные контексты и нанесли их на до-

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

Карта контекстов становится в руках архитектора полезным инструментом,который помогает сосредоточиться на том, какие компоненты следует дер-жать вместе, а какие необходимо отделить друг от друга; другими словами,наглядно реализуется принцип «разделяй и властвуй». Эта техника можетбыть с легкостью использована как для документирования и анализа теку-

щей ситуации, так и для перепроектирования с целью создания системы,обладающей слабой связанностью, высоким сцеплением и четко определен-ными интерфейсами.




Поддерживайтеразработчиков

Òèìîòè Õàé

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

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

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

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

лификации. Если вы располагаете достаточными средствами, отправляйтесвою команду на технические презентации и конференции. Если нет – под-ключите команду к техническим спискам рассылки и следите за бесплат-ными мероприятиями в своем городе. По возможности участвуйте такжев процессе отбора разработчиков. Ищите тех, кто жаждет учиться, у когоесть «искра» технической одаренности (но убедитесь в том, что они способ-ны работать в команде…). Трудно добиться чего-то выдающегося от группыбезликих работяг.



117Поддерживайте разработчиков

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

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

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

Тимоти Хай (Timothy High) – архитектор программного обеспечения, у ко-Timothy High) – архитектор программного обеспечения, у ко-High) – архитектор программного обеспечения, у ко-High) – архитектор программного обеспечения, у ко-) – архитектор программного обеспечения, у ко-торого за плечами более чем 15-летний опыт разработки с использовани-ем веб-технологий, создания многоуровневых клиент–серверных системи применения технологий интеграции приложений. В настоящее время работает архитектором программного обеспечения в компании SakonnetTechnologies, которая является лидером в области создания программ дляуправления сделками и рисками в сфере энергетики (ETRM – Energy Trad-ETRM – Energy Trad-– Energy Trad-Energy Trad-Trad-Trad-

ing and Risk Management).



Записывайтесвои обоснования

Òèìîòè Õàé

В сообществе разработчиков существует немало разногласий по поводу цен-ности документации, особенно в том, что касается архитектуры программ-ного продукта. Разногласия эти обычно связаны с субъективными взгляда-ми на ценность «тщательного предварительного проектирования» и темисложностями, которые возникают при постоянном обновлении проектнойдокументации в соответствии с изменениями в базе кода.

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

объясняет Марк Ричардс в этюде «Архитектурные компромиссы», созданиеархитектуры программного продукта по сути сводится к поиску разумныхкомпромиссов между различными характеристиками качества, затратами,временем и другими факторами. Вам, руководству, разработчикам и другимзаинтересованным в проекте сторонам должно быть абсолютно ясно, почемуодному решению отдано предпочтение перед другим и к каким компромис-сам это привело. (Вы пожертвовали горизонтальной масштабируемостьюради сокращения затрат на оборудование и лицензии? Проблемы безопас-ности настолько серьезны, что оправдывают увеличение времени откликаради шифрования данных?)

Формат такой документации зависит от специфики проекта и может варьи-роваться от кратких заметок в текстовом документе, вики или блоге доформальных шаблонов, отражающих все аспекты каждого архитектурногорешения. Независимо от вида и формата этот документ должен отвечать наследующие основные вопросы: «В чем суть принятого решения?» и «Почемумы приняли такое решение?». Еще один частый вопрос, ответ на которыйследует там отразить: «Какие альтернативные решения рассматривались



119Записывайте свои обоснования

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

Такая документация может быть полезна во многих ситуациях:Чтобы проинформировать разработчиков о важных архитектурных•

принципах, которые должны соблюдаться в работе.

Чтобы создать у членов команды единое ви• дение проекта (и даже предот-вратить бунт), когда разработчики ставят под сомнение логику архитек-туры (а возможно, покорно принять критику, если решение действи-тельно оказалось несостоятельным при ближайшем рассмотрении).

Чтобы продемонстрировать руководству и заинтересованным сторонам•

те причины, в силу которых программный продукт строится именно так,а не иначе (например, почему необходимо какое-нибудь дорогостоящееоборудование или программный компонент).

Чтобы передать проект новому архитектору (сколько раз, получая в на-•

следство программный продукт, вы пытались понять, почему архитек-торы поступили именно ТАК?).

Однако самые важные преимущества этой практики состоят в следующем:

Она заставляет вас явным образом формулировать свои доводы, прове-•

ряя их надежность (см. следующий этюд «Сомневайтесь в допущениях –

особенно в собственных»).Она дает отправную точку для переоценки решений в случае изменения•

условий, от которых эти решения зависят.

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




Сомневайтесь в допущениях –особенно в собственных

Òèìîòè Õàé

Закон отложенных решений Уэзерна гласит: «Допущения – корень всех про-валов». Конечно, формулировка не очень серьезная, но когда предположе-ния обходятся вам в несколько тысяч (а то и миллионов) долларов, стано-вится не до смеха.

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

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

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

1 Информация или публикация, недостойная доверия, либо событие сомнительнойистинности, повсеместно принимаемое за правду. Термин введен американскимписателем Н. Мейлером в 1973 году. – Примеч. перев.



121Сомневайтесь в допущениях – особенно в собственных

этих допущений лежат «исторические причины», субъективные мнения,предубеждения разработчиков, опасения и сомнения1 и даже слухи:

«Продукты с открытым исходным кодом ненадежны».•

«От индексов на основе битовых карт больше хлопот, чем пользы».•

«Заказчик никогда не примет страницу, которая грузится по пять се-•

кунд».

«I-директор согласится покупать продукты только у крупных вендоров».•

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

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

Обратите внимание на слово «актуальный». То, что было справедливо длястарой версии вашей программы, может стать недействительным сегодня.Производительность индексов на основе битовых карт может различатьсяв разных версиях Oracle. Дыры в безопасности старой версии библиотеки мо-Oracle. Дыры в безопасности старой версии библиотеки мо-. Дыры в безопасности старой версии библиотеки мо-гут быть уже исправлены в новой версии. Старый надежный производительили поставщик может быть на последнем издыхании в финансовом отноше-нии. Технологический ландшафт изменяется каждый день, меняются и лю-ди. Кто знает, может, ваш I-директор стал тайным поклонником Linux?

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


1 В оригинале FUD (Fear, Uncertaintу, Doubts – опасение, неуверенность, сомне-ния) – используемое в электронной переписке сокращение, возникшее согласнолегенде в стенах компании IBM, менеджерам которой рекомендовалось в пере-писке с клиентами не критиковать продукцию конкурентов явным образом,а «высказывать FUD». – Примеч. ред.



Делитесь знаниями и опытом


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

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

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

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

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

Процесс обсуждения всегда помогает выявить слабости обсуждаемого пред-мета. Нельзя сказать, что вы что-то понимаете, если вы не можете это «что-то» легко объяснить. Только когда мы излагаем свои объяснения и обсужда-ем их с другими, наш опыт преобразуется в знания.



123Делитесь знаниями и опытом

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

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

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

Делясь обретенными знаниями и опытом, мы способствуем движению на-

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

Пол У. Хомер (Paul W. Homer) – программист, писатель и фотограф-любитель. Занялся разработкой программного обеспечения несколько деся-

тилетий назад и с тех пор неустанно работает над построением все болеесложных систем.



Патология шаблонов

×åä Ëàâèíü

Шаблоны проектирования – один из самых полезных инструментов в арсена-ле архитектора программного обеспечения. Использование шаблонов позво-ляет создавать типовые решения, которые проще понять и объяснить дру-гим. Сама идея шаблонов напрямую ассоциируется с качественным проек-тированием. Из-за этого у нас часто возникает соблазн продемонстрироватьсвою искушенность, включив в проект большое количество шаблонов. Есливы поймали себя на том, что упорно втискиваете свои любимые шаблоныв пространство задачи, где они неуместны, то не исключено, что вы сталижертвой патологии шаблонов.

Многие проекты страдают от такого положения дел. Глядя на них, так и ви-дишь, как архитектор проекта поднимает взгляд от последней страницысборника шаблонов, потирает руки и произносит: «Так, с какого шаблонаначнем?..». Этот образ действий отчасти сродни подходу разработчика, на-чинающего писать класс с мысли: «Хм, от какого бы класса мне унасле-довать?..». Шаблоны проектирования – отличный инструмент снижениянеотъемлемой сложности, но, как и любой другой инструмент, его можноиспользовать неправильно. Есть известная пословица: «Человек с молоткомвезде видит гвозди»; когда в роли такого молотка оказываются шаблоныпроектирования, проблемы неизбежны. Следите за тем, чтобы ваша любовьк шаблонам не превратилась в манию, которая приведет к реализации болеесложных решений, чем это действительно необходимо.

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



125Патология шаблонов

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

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

Чед Лавинь (Chad LaVigne) – архитектор программных решений и вне-штатный технический специалист фирмы TEKSystems, Inc. (Балтимор).Работает в основном в Миннеаполисе, занимается проектированием и реа-лизацией решений на базе технологий Enterprise Java.



Не увлекайтесьархитектурными метафорами

Äýâèä Èíã

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

Обычно все начинается хорошо: собеседники находят общий язык, и кажет-ся, что все идет в нужном направлении. Метафора развивается и растет дотех пор, пока не начинает жить собственной жизнью. Люди относятся к ней

благосклонно – прогресс налицо!

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

Ваша метафора начинает нравиться заказчику больше, чем сама разра-•

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

Пример: «Мы строим транспортную систему по принципу перемещения ко-рабля между несколькими причалами».

Вы представляете себе контейнеровоз, бороздящий просторы Тихого океа-на, – я же имел в виду гребную лодку в бассейне, притом с одним веслом.

Команда разработчиков начинает считать метафору более весомой по•

сравнению с реальной бизнес-задачей. А вы из любви к своей метафореначинаете оправдывать странные решения.



127Не увлекайтесь архитектурными метафорами

Пример: «Мы сказали, что система будет похожа на картотечный шкаф, по-этому нам придется выводить данные в алфавитном порядке. Я знаю, что этотшкаф имеет шесть измерений, бесконечную длину и встроенные часы, но мыуже сделали иконку – а картотека должна вести себя как картотека…».

В системе попадаются названия из старых, давно забытых метафор – ар-•

хеологические реликты концепций, давно отправленных в утиль.

Пример: «А почему объект Billing Factory1 создает Port Channel для системыRowing boat?.. И он в самом деле должен возвращать для Hub Bus представле-boat?.. И он в самом деле должен возвращать для Hub Bus представле-boat?.. И он в самом деле должен возвращать для Hub Bus представле-?.. И он в самом деле должен возвращать для Hub Bus представле-ние Pomegranate?.. Ну да, я действительно работаю здесь недавно, а что?»

Итак, не влюбляйтесь в метафору, представляющую вашу систему, используй-

те ее в целях исследований и разъяснения, но не попадайте под ее влияние.

Дэвид Инг (David Ing) – архитектор программного обеспечения, живущийи работающий в Ванкувере. Родился в Великобритании, но переехал подаль-ше от дождей (хотя сейчас считает, что был обманут лживой литерату- рой для туристов).

Подчиняясь требованиям моды, сейчас Дэвид работает в компании Taglo-city, специализирующейся на Web 2.0; здесь он пытается привести систе-, специализирующейся на Web 2.0; здесь он пытается привести систе-Web 2.0; здесь он пытается привести систе-2.0; здесь он пытается привести систе-мы электронной почты «к цивилизованному виду», а заодно понять, чтоже такое Web 2.0.

1 Billing Factory – фабрика счетов («Фабрика» – один из шаблонов проектирова-

ния); port channel – агрегирование каналов (технология, позволяющая объеди-нить несколько физических каналов в один логический, в данном случае – отве-чающий за это программный объект); rowing boat – гребная лодка; hub bus –концентратор шины; pomegranate – гранат. (Поскольку программные объектыобычно имеют английские названия, то в российской компании подобный раз-говор происходил бы именно так – на смеси русского и английского. Поэтому мысочли правильным привести переводы и дать пояснения в сноске, а не напрямуюв тексте.) – Примеч. ред.



Уделяйте пристальноевнимание поддержкеи сопровождению

Ìí÷åäèçè Êàñïåð

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

В ходе проектирования приложения перед внутренним взором архитекто-

ров находятся главным образом разработчики, вооруженные интегрирован-ными средами и отладчиками. Если что-то идет не так, искусные програм-мисты переключаются в режим отладки и находят ошибку. Такая картинавполне естественна, поскольку большинство архитекторов основную частьсвоей жизни проводят в роли разработчиков, а не администраторов систе-мы. К сожалению, разработчик и специалист службы поддержки обладаютразными навыками – аналогично тому, как среда разработки/тестированияи рабочая среда (production environment) служат разным целям.

Вот примеры проблем, с которыми сталкивается администратор системы:

Администратор не может заново отправить запрос, чтобы воспроизвести•

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

Когда приложение находится в рабочей среде, требования исправить ошиб-•

ки исходят от пользователей и начальства, а не от руководителя проекта

и группы тестирования – а разгневанное начальство гораздо опаснее.



129Уделяйте пристальное внимание поддержке и сопровождению

В рабочей среде нет отладчика.•

В рабочей среде процесс развертывания планируется и координируется•

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

В среде разработки журналы сообщений обычно содержат гораздо более•

подробную информацию, чем в рабочей среде.

Некоторые из симптомов недостаточного планирования поддержки выгля-дят так:

Большинство проблем требует привлечения разработчика.•

Отношения между командой разработчиков и службой поддержки весь-•

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

Служба поддержки ненавидит новое приложение.•

Команды архитекторов и разработчиков проводят много времени в рабо-•

чей среде.

Приложение часто перезапускается для решения возникших проблем.•

Администраторам вечно не хватает времени для нормальной настройки•

системы, потому что они постоянно занимаются «тушением пожаров».

Чтобы ваше приложение успешно работало после того, как выйдет из рукразработчиков, вы должны:

Понять, что разработка и поддержка требуют разных навыков.•

Как можно раньше вовлечь в проект руководителя службы технической•

поддержки.

Сделать руководителя службы технической поддержки одной из цент-•

ральных фигур проектной команды.

Привлечь руководителя службы технической поддержки к планирова-•

нию поддержки приложения.

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

играют в сопровождении чрезвычайно важную роль. Когда довольны админи-страторы системы, все остальные тоже довольны (особенно ваш начальник).

Мнчедизи Каспер (Mncedisi Kasper) – директор по технологии и страте-Mncedisi Kasper) – директор по технологии и страте-Kasper) – директор по технологии и страте-Kasper) – директор по технологии и страте-) – директор по технологии и страте-гии в Open �cellence ICT Solutions, южноафриканской компании, специали-Open �cellence ICT Solutions, южноафриканской компании, специали-�cellence ICT Solutions, южноафриканской компании, специали-�cellence ICT Solutions, южноафриканской компании, специали-ICT Solutions, южноафриканской компании, специали-ICT Solutions, южноафриканской компании, специали-Solutions, южноафриканской компании, специали-Solutions, южноафриканской компании, специали-, южноафриканской компании, специали-зирующейся на интеграции корпоративных приложений и консультацияхв области SAP (ABAP/�I).



Приготовьтесь выбратьдва из трех


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

Знаменитый пример такого рода – теорема Брюэра, которая гласит, что дляраспределенной системы желательными являются три свойства – целост-ность (Consistency), доступность (Availability) и устойчивость к разделению(Partitioning tolerance) – и что достичь всех трех целей сразу невозможно.

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

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



131Приготовьтесь выбрать два из трех

уходим в обсуждение отклонений архитектуры от идеала и начинаем путатьдогматизм с качественным управлением. Вместо этого следует задать вопро-сы: Почему эти свойства так необходимы? Какие преимущества они прино-сят? Когда они желательны? Как разбить систему на части для достижения

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

Билл де Ора (Bill de hÓra) – ведущий архитектор в компании NewBay Soft-) – ведущий архитектор в компании NewBay Soft-– ведущий архитектор в компании NewBay Soft-– ведущий архитектор в компании NewBay Soft-NewBay Soft-Soft-Soft-ware, где он работает над крупномасштабными веб-системами и система-, где он работает над крупномасштабными веб-системами и система-ми для мобильных устройств. Является соредактором Atom Publishing Pro- Atom Publishing Pro-Publishing Pro-Publishing Pro-Pro-Pro-tocol, ранее участвовал в работе группы W3C RDF Working Group. Признан-, ранее участвовал в работе группы W3C RDF Working Group. Признан-W3C RDF Working Group. Признан-3C RDF Working Group. Признан-C RDF Working Group. Признан-RDF Working Group. Признан-RDF Working Group. Признан-Working Group. Признан-Working Group. Признан-Group. Признан-Group. Признан-. Признан-ный эксперт в области REST и архитектур на основе передачи сообщений,а также проектирования протоколов.



Принципы, аксиомы и аналогииважнее личных мненийи предпочтений

Ìàéêë Õàðìåð

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

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

ние окажет бесценную помощь начинающим архитекторам, которые будутработать с вашей архитектурой.

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

Реализовать и адаптировать архитектуру•

Расширить архитектуру на смежные предметные области•

Модифицировать архитектуру для реализации с использованием новых•

технологий

Подробно проработать граничные случаи•

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



133Принципы, аксиомы и аналогии важнее личных мнений и предпочтений

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

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

часто становится серьезной проблемой, особенно в крупных системах, охва-тывающих несколько технологий и существующих в течение многих лет.Четко сформулированные архитектурные принципы помогут человеку, не-знакомому с конкретной технологией или компонентом, быстрее разобрать-ся в новой области и понять ее.

Майкл Хармер (Michael Harmer) занимается разработкой программногообеспечения уже 16 лет. Он был рядовым разработчиком, руководителемгруппы, архитектором, ведущим специалистом и руководителем направ-

ления.



Начните с ходячего скелета

Êëèíò Øåíê

Чрезвычайно полезная стратегия реализации, проверки и совершенствова-ния архитектуры приложения – начать с того, что Алистер Коберн (AlistairCockburn) называет ходячим скелетом. Речь идет о минимальной реализа-ции системы «от начала до конца», связывающей воедино все основные ар-хитектурные компоненты. Начав с минимума – с рабочей системы, содержа-– с рабочей системы, содержа-– с рабочей системы, содержа-щей все коммуникационные каналы, – вы можете быть уверены в том, чтодвижетесь в правильном направлении.

Когда скелет будет готов, можно переходить к наращиванию плоти, то естьпостепенному, пошаговому добавлению конечной функциональности. Ваша

цель – сохранять работоспособность системы, пока скелет обрастает мясом.

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

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



135Начните с ходячего скелета

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

Начните со скелета, заставьте его ходить, а затем постепенно наращивайтена него плоть.

Клинт Шенк (Clint Shank) – разработчик, консультант и преподавательиз Sphere of Influence, Inc., компании, предоставляющей услуги по проекти-Sphere of Influence, Inc., компании, предоставляющей услуги по проекти-of Influence, Inc., компании, предоставляющей услуги по проекти-of Influence, Inc., компании, предоставляющей услуги по проекти-Influence, Inc., компании, предоставляющей услуги по проекти-Influence, Inc., компании, предоставляющей услуги по проекти-, Inc., компании, предоставляющей услуги по проекти-Inc., компании, предоставляющей услуги по проекти-., компании, предоставляющей услуги по проекти- рованию и производству программных продуктов коммерческим и прави-тельственным организациям.



В основе всего – данные


Мы, разработчики, изначально воспринимаем программное обеспечение каксистему команд, функций и алгоритмов. Такое «командно-ориентированное»представление помогает нам освоить построение ПО, но оно же начинает ме-шать, когда мы пытаемся создавать более масштабные системы.

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

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

В ходе выполнения кода на компьютере состояние данных непрерывно изме-

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

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



137В основе всего – данные

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

Данные находятся в центре большинства задач. Задачи, относящиесяк предметной области, проникают в код через данные. Большинство клю-

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

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

правильные данные в правильное время? Кто должен иметь возможностьпросматривать или изменять эти данные? Если данные уже существуют, на-сколько они качественны и как быстро растет их объем? Если данных поканет, то какова их структура, откуда они поступят и насколько надежен ихисточник? А когда данные окажутся в системе, останется еще один вопрос:есть ли способ просмотра и/или редактирования конкретных данных илиего необходимо добавить в систему?

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




Простое должно бытьпростым

×åä Ëàâèíü

Архитекторы программного обеспечения решают множество очень сложныхзадач, но наряду с ними встречаются и относительно простые. А вот чего мыстремимся избежать, так это решения простых задач сложными методами.Каким бы очевидным ни казался этот совет, следовать ему порой нелегко.Проектировщики программного обеспечения – умные, очень умные люди.Однако весьма легко попасть в ловушку «простая задача – сложное реше-ние», потому что все мы любим демонстрировать свои знания. Если вы по-чувствовали, что проектируете решение настолько умное, что оно со време-нем, того и гляди, проявит искру самосознания, остановитесь и подумайте.

Соответствует ли такое решение поставленной задаче? При отрицательномответе рассмотрите заново варианты дизайна системы. Простое должно бытьпростым. У вас будет масса возможностей продемонстрировать свой талант,когда вы столкнетесь со сложными задачами, а это непременно случится.

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

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



139Простое должно быть простым

требований, спросите себя, насколько сложно будет отказаться от этого ре-шения после его реализации.

Впрочем, затраты не ограничиваются реализацией и сопровождением упо-мянутого решения. Если вы потратите на простую задачу больше времени,

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

Часто возникает сильное желание оправдать решения предполагаемой вы-годой или прогнозируемыми требованиями. Запомните: когда вы пытаетесьугадать будущие требования, в 50% случаев вы ошибаетесь, а в 49% – очень-очень сильно ошибаетесь. Решайте проблемы по мере их поступления. Сдай-

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




Архитектор –прежде всего разработчик

Ìàéê Áðàóí

Вы когда-нибудь слышали о судье, который не был бы юристом, или о заведу-ющем хирургическим отделением, который не был бы хирургом? Даже до-стигнув того, что может считаться венцом их карьеры, люди, занимающиетакие должности, продолжают осваивать новые разработки в своей области.Мы, архитекторы программного обеспечения, обязаны соответствовать темже стандартам.

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

уважение и доверие. Всем известно, как проще всего завоевать доверие раз-работчика: ваш код – ваша «визитная карточка». Если разработчики будутзнать, что вы не какой-то абстрактный мечтатель, не способный написать нистрочки кода, они будут меньше ворчать по поводу ухищрений, на которыевы «заставляете» их идти для отображения данных на странице, ведь выспособны с полным на то основанием сказать: «Можно сделать проще, всеголишь привязав датасет к гриду», – и им будет нечего возразить.

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

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



141Архитектор – прежде всего разработчик

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

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

Майк Браун (Mike Brown) – ведущий разработчик в компании Software En-Mike Brown) – ведущий разработчик в компании Software En-Brown) – ведущий разработчик в компании Software En-Brown) – ведущий разработчик в компании Software En-) – ведущий разработчик в компании Software En-– ведущий разработчик в компании Software En-– ведущий разработчик в компании Software En-Software En-En-En-gineering Professionals, Inc. (http://www.sep.com). Обладает 13-летним опы-Professionals, Inc. (http://www.sep.com). Обладает 13-летним опы-Professionals, Inc. (http://www.sep.com). Обладает 13-летним опы-, Inc. (http://www.sep.com). Обладает 13-летним опы-Inc. (http://www.sep.com). Обладает 13-летним опы-. (http://www.sep.com). Обладает 13-летним опы-http://www.sep.com). Обладает 13-летним опы-://www.sep.com). Обладает 13-летним опы-www.sep.com). Обладает 13-летним опы-.sep.com). Обладает 13-летним опы-sep.com). Обладает 13-летним опы-.com). Обладает 13-летним опы-com). Обладает 13-летним опы-). Обладает 13-летним опы-том работы в сфере информационных технологий, включая 8 лет разра-лет разра-лет разра-ботки корпоративных решений для разнообразных вертикальных рынков.Является учредителем группы пользователей Indianapolis Alt.NET, соучре-Indianapolis Alt.NET, соучре- Alt.NET, соучре- Alt.NET, соучре-.NET, соучре-NET, соучре-, соучре-дителем WPF Disciples, а также организатором группы профессиональных

пользователей Indy Arc.



Окупаемость как факторпроектирования

Äæîðäæ Ìàëàìèäèñ

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

ложения, ожидая, что это принесет выгоду в долгосрочной перспективе.Одним из показателей успешности инвестиций является окупаемость (ROI,Return on Investment). Например: мы предполагаем, что дополнительныезатраты времени на создание тестов уменьшат количество ошибок в следую-щем выпуске приложения. Размер инвестиций в этом случае определяетсявременем, потраченным на написание тестов, а прибыль – это время, сэко-номленное на исправлении ошибок в будущем, плюс удовлетворение клиен-тов, работающих с более качественной программой. Допустим, в настоящеевремя 10 из 40 рабочих часов в неделю тратятся на исправление ошибок.

По нашим оценкам, выделив 4 часа в неделю на тестирование, мы сократимзатраты времени на исправление ошибок до 2 часов в неделю, фактическиполучив 8 свободных часов, которые можно вложить во что-то другое. Про-гнозируемая окупаемость составляет 200%1 (8 часов, сэкономленных на ис-правлении ошибок, делим на 4 часа, потраченных на тестирование).

1 В действительности эффект будет не настолько сильным: переключение междузадачами само по себе отнимает у разработчика существенное время, тем самымснижая его продуктивность. – Примеч. науч. ред.



143Окупаемость как фактор проектирования

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

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

Рассматривайте архитектурные решения как инвестиции и анализируйтесвязанную с ними окупаемость; это полезный метод оценки реалистичностии практичности имеющихся вариантов.

Джордж Маламидис (George Malamidis) – разработчик программногообеспечения в компании TrafficBroker (Лондон). До этого был ведущимконсультантом и ведущим техническим специалистом в ThoughtWorks.Участвовал в разработке и внедрении критических приложений в разныхобластях, от сетевых и финансовых приложений до Web 2.0.



Ваша система станетунаследованной – учитывайтеэто при проектировании

Äåéâ Àíäåðñîí

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

Ясность: должно быть сразу понятно, какую роль играет тот или иной•

компонент или класс.

Удобство тестирования: насколько легко проверить вашу систему?•

Корректность: работает ли система так, как было задумано? Исключите•

исправления, вносимые на скорую руку.

Трассируемость: сможет ли специалист-«пожарник», никогда прежде•

не видевший ваш код, диагностировать ошибку в работающей системеи исправить ее? Или же на то, чтобы войти в суть дела, ему потребуютсядва месяца?

Попробуйте представить себе, что будет, если какая-то другая команда от-

кроет вашу базу кода и попытается в нем разобраться. Это наиважнейшийаспект хорошей архитектуры. Систему необязательно чрезмерно упрощатьили документировать до мельчайших подробностей; хороший дизайн во мно-гих отношениях документирует сам себя. Кроме того, дизайн может прояв-лять себя в поведении системы во время эксплуатации. Например, системас «разросшейся» архитектурой, опутанной уродливыми зависимостями,в эксплуатации часто ведет себя, как зверь в клетке. Подумайте о других



145Ваша система станет унаследованной – учитывайте это при проектировании

(обычно менее опытных) разработчиках, которым придется исправлятьошибки в вашей программе и отлаживать код.

В кругах разработчиков не любят термин «унаследованный», но на самомделе этот ярлык несет на себе любая программная система. И в этом нет ни-

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

Дейв Андерсон (Dave Anderson) – главный специалист по разработке ПОв компании Liberty IT (Белфаст), которая поставляет IT-решения длякомпании Liberty Mutual, входящей в список Fortune 100. Дейв обладает

более чем 10-летним опытом разработки ПО для многих ведущих IT-компаний в разных отраслях и странах.



Когда видите единственноерешение, спросите других

Òèìîòè Õàé

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

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

Если вы видите только одно решение текущей проблемы, это означает, чтоу вас отсутствует свобода выбора для поиска таких компромиссов. Вполне воз-можно, что это единственное решение окажется неудовлетворительным длянекоторых заинтересованных в проекте сторон. Это означает также, что присмене приоритетов, обусловленной изменениями бизнес-окружения, у вашейсистемы не будет возможности адаптироваться к новым требованиям.

Такая ситуация крайне редко возникает из-за реального отсутствия аль-тернатив. Гораздо более вероятное объяснение – неопытность архитекторав предметной области конкретной задачи. Если вы знаете, что это относится

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

Другое, более коварное проявление этой проблемы встречается при проек-тировании архитектуры «по привычке». Архитектор может иметь богатыйопыт применения одного архитектурного стиля (например, трехуровневаясистема типа клиент–сервер), но ему не хватает знаний, чтобы определить,когда этот стиль неуместен. Если вы оказались в ситуации, когда решение



147Когда видите единственное решение, спросите других

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

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

Начальник спросил его:

– Что мы можем сделать для улучшения производительности?

У моего друга уже был готов ответ:

– Купить более мощную машину!– А что еще?

– М-м-м… Насколько я знаю, ничего.

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




Осознавайтепоследствия изменений

Äóã Êðîóôîðä

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

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

Изменения могут проявляться в разных формах:

Изменения функциональных требований•

Ужесточение требований к масштабируемости•

Модификация интерфейсов системы•

Приход и уход членов команды•

и так далее…•

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

ствие или нет, в большой степени зависит от архитектора.Задача архитектора – не столько управлять изменениями, сколько позабо-титься об их управляемости.

Для примера возьмем распределенное решение, в котором задействованонесколько приложений, объединенных различным промежуточным про-граммным обеспечением (middleware). Если набор зависимостей невер-но определен или неточно представлен в визуальной модели, изменения



149Осознавайте последствия изменений

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

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

К счастью, существует целый ряд инструментов и методов, позволяющихсмягчить воздействие изменений:

Вносите небольшие, поэтапные изменения•

Создавайте воспроизводимые тестовые сценарии и часто запускайте их•

Упрощайте построение тестовых сценариев•

Отслеживайте зависимости•

Действуйте и реагируйте систематично•

Автоматизируйте повторяющиеся задачи•

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

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

Дуг Кроуфорд (Doug Crawford) руководит командой разработчиков проме-жуточного программного обеспечения для телекоммуникационной компа-нии в Южной Африке. Последние 10 лет он с успехом совмещал несовмести-мое и принимал самое непосредственное участие в проектах по интеграцииприложений в разнообразных отраслях: рекламе, банковском обслуживаниикрупного бизнеса, страховании и образовании.



Архитектор долженразбираться в оборудовании

Êàìàë Âèêðàìàíàÿêå

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

Главная причина заключается в том, что мы полностью концентрируемся напрограммной стороне и игнорируем аппаратные требования. Вдобавок язы-ки высокого уровня и программные инфраструктуры (software frameworks)естественным образом изолируют нас от оборудования.

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

Без знания оборудования прогнозирование аппаратной конфигурации раз-

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



151Архитектор должен разбираться в оборудовании

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

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

Например, вам может пригодиться прошлый опыт. Если вы прежде уже за-нимались реализацией систем, то у вас имеется некоторое представлениео планировании аппаратной мощности – хотя бы на основании ретроспек-тивного анализа. Вы можете также обсудить эту тему со своим клиентоми убедить его выделить средства на планирование мощности оборудования.Финансирование такой деятельности часто оказывается намного выгоднеепокупки оборудования сверх реально необходимого. В этом случае ключе-вая роль отводится горизонтальной масштабируемости1: оборудование до-бавляется по мере надобности вместо избыточных закупок в самом начале.Чтобы «горизонтальная стратегия» работала, архитектор ПО должен посто-янно проводить измерения вычислительной мощности и изолировать про-граммные компоненты для запуска в среде с прогнозируемыми показателя-ми производительности.

Планирование вычислительной мощности не менее важно, чем архитек-

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

Камал Викраманаяке (Kamal Wickramanayake) – архитектор аппаратно-го и программного обеспечения, живет на Шри-Ланке. Является обладате-

лем сертификата TOGAF от The Open Group.

1 Горизонтальная масштабируемость – разбиение системы на более мелкие струк-турные компоненты и разнесение их по отдельным физическим машинам либоувеличение количества серверов, параллельно выполняющих одну и ту жефункцию. Вертикальная масштабируемость – увеличение производительностикаждого компонента системы с целью повышения общей производительности.(См. http://ru.wikipedia.org/wiki/Масштабируемость.) – Примеч. ред.



«Срезание углов» сейчасобойдется слишкомдорого потом

Ñêîò Ìàêôè

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

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

ручного тестирования, что приведет к нестабильности и росту затрат насопровождение, а получившийся дизайн нельзя будет назвать полностьютестируемым (не говоря уже о соответствии принципу «опережающеготестирования»1).

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

1 Здесь подразумевается одна из гибких методик разработки, получившая названиеDD (est-Drived Design, проектирование, направляемое тестами). В этой мето-дике отправной точкой процесса проектирования является не моделированиедиаграмм, а написание тестов. – Примеч. науч. ред.

2 BPEL (Business Process Execution Language) – основанный на XML язык формаль-ного описания бизнес-процессов и протоколов их взаимодействия (см. http://ru.wikipedia.org/wiki/BPEL). – Примеч. ред.



153«Срезание углов» сейчас обойдется слишком дорого потом

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

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

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

Например, если вы поняли, что выбранные библиотеки плохо подходят для

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

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

Скот Макфи (Scot Mcphee) – австралийский разработчик и архитекторс 15-летним опытом программирования и проектирования приложений. По-следние 8 лет работал главным образом с технологиями семейства J2EE.



Лучшее – враг хорошего


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

ют о преобразовании их в веб-службы. Запросы требуют внимания, жалуясьна буферизацию и неуникальные индексы.

Мой совет: не поддавайтесь искушению довести дизайн или реализациюсистемы до совершенства! Ориентируйтесь на отметку «достаточно хорошо»и остановитесь, когда вы доберетесь до нее.

«Что именно означает “достаточно хорошо”?» – спросите вы. Это означает,что оставшиеся недочеты не оказывают сколько-нибудь заметного влиянияна функциональность, удобство сопровождения или производительностьсистемы. Архитектура и дизайн идут рука об руку. Реализованная система

работает и соответствует требованиям к производительности. Программныйкод понятен, лаконичен и хорошо документирован. Можно ли сделать луч-ше? Конечно, но и так достаточно хорошо – поэтому остановитесь. Заявитео своей победе и переходите к следующей задаче.

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



155Лучшее – враг хорошего

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

не для устранения субъективных несовершенств в более простом варианте?Помните, что разработка приложений – не конкурс красоты. Перестаньтевыискивать недочеты и тратить время на поиски совершенства.

Грег Найберг (Greg Nyberg) – независимый консультант в области J2EEс 18-летним опытом проектирования, построения, тестирования и развер-тывания крупномасштабных транзакционных приложений, таких как сис-темы оформления предварительных заказов, центры приема звонков и по-требительские веб-сайты. Является автором справочника «WebLogic 6.1

Server Workbook for Enterprise JavaBeans, 3-е издание» (O’Reilly) и ведущимавтором книги «Mastering WebLogic Server» (Wiley).



Остерегайтесь «хороших идей»


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

Вы знаете, о каких хороших идеях я говорю: соблазнительные, очевидные,абсолютно безвредные на первый взгляд – «ничего-страшного-не-будет-если-мы-попробуем». Обычно они приходят в голову кому-либо в командегде-то в середине жизненного цикла проекта, когда все вроде бы идет хоро-шо. Работа движется в бодром темпе, начальное тестирование проходит какположено, дата выпуска выглядит непоколебимой – жизнь прекрасна.

Тут у кого-то появляется «хорошая идея», вы с ней соглашаетесь – и вот выуже переделываете проект под свежую версию Hibernate, чтобы воспользо-Hibernate, чтобы воспользо-, чтобы воспользо-ваться ее новейшими возможностями, или используете AJAX на некоторыхвеб-страницах, потому что разработчик показал пользователям, как крутоэто смотрится, или пересматриваете архитектуру базы данных, чтобы за-действовать те возможности по работе с XML, которые предлагает СУБД. Выговорите руководителю проекта, что для реализации этой «хорошей идеи»понадобится еще несколько недель, однако изменения затрагивают боль-ший объем кода, чем предполагалось, и график начинает трещать по швам.

Вдобавок, приняв первую «хорошую идею», вы, как в поговорке, «выпусти-ли джинна из бутылки»: вскоре на свет появляются новые «хорошие идеи»,а вам уже гораздо труднее отказать (а джинн тем временем уже выглядываетиз всех щелей).

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



157Остерегайтесь «хороших идей»

а также требуя лишних усилий на включение в приложение того, что ненужно для достижения бизнес-целей.

Вот несколько ключевых фраз, свидетельствующих об опасности:

«Разве не круто будет, если…». На самом деле сигналом тревоги может•

быть любое предложение со словом «круто».

«Только что вышла версия XXX библиотеки YYY. Нам надо перейти на•

новую версию!»

«Знаешь, раз уж мы работаем над ZZZ, нам стоит заодно переработать•

XXX…»

«XXX – действительно мощная технология! Возможно, мы сможем при-•

менить ее в…»

«Послушай,• <здесь_ваше_имя>, я тут размышлял о дизайне нашей си-

стемы – и мне пришла в голову мысль…»Хорошо, хорошо – возможно, в последнем пункте я перегибаю палку. Но вывсе равно должны остерегаться «хороших идей», которые способны убитьваш проект.




Хороший контентпорождает хорошие системы

Çóáèí Âàäüÿ

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

Контент – король. Контент – сеть. Контент – интерфейс. В современном ми-ре, пронизанном многочисленными информационными связями, качествоконтента все чаще определяет успех или неудачу. FaceBook против Orkut,Google против Cuil, NetFlix против BlockbusterOnline… список сражений,выигранных и проигранных на поле контента, можно продолжать до бес-конечности. Кто-то может возразить, что аспекты, касающиеся контента,не относятся к проблематике архитектора ПО, но я считаю, что следующеедесятилетие докажет обратное.

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

Проанализируйте весь доступный контент и оцените его значимость по сле-дующим критериям:

Достаточно ли доступного количества контента? Если нет, как получить•

«критическую массу»?

Достаточно ли актуальна содержащаяся в нем информация? Если нет,•

как улучшить скорость поступления?



159Хороший контент порождает хорошие системы

Все ли возможные каналы распространения контента изучены? RSS-•

трансляции, электронная почта, бумажные бланки – все это являетсявозможными каналами.

Созданы ли эффективные входные потоки, упрощающие непрерывное•

поступление контента в систему? Одно дело – выявить ценный контент,и совсем другое – организовать его регулярное получение.

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

порождает хорошие системы.

Зубин Вадья (Zubin Wadia) – генеральный директор RedRock IT Solutionsи технический директор ImageWork Technologies. Обладает разносторон-ImageWork Technologies. Обладает разносторон-Technologies. Обладает разносторон-Technologies. Обладает разносторон-. Обладает разносторон-ней квалификацией в области программирования, владеет языками Basic,C, C++, Perl, Java, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-, C++, Perl, Java, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-C++, Perl, Java, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-++, Perl, Java, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-Perl, Java, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-, Java, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-Java, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-, JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-JSP, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-, JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-JSF, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-, JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-JavaScript, Erlang, Scala, Eiffel и Ruby. Спе-, Erlang, Scala, Eiffel и Ruby. Спе-Erlang, Scala, Eiffel и Ruby. Спе-, Scala, Eiffel и Ruby. Спе-Scala, Eiffel и Ruby. Спе-, Eiffel и Ruby. Спе-Eiffel и Ruby. Спе-и Ruby. Спе-Ruby. Спе-. Спе-циализируется на разработке решений из области автоматизации бизнес-процессов для компаний из списка Fortune Global 500 и правительственныхучреждений США.



Бизнес и недовольныйархитектор

×åä Ëàâèíü

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

обычно сопровождается цинизмом, нетерпимостью и гневом по отношениюк тем «низшим умам», которые смеют оспаривать ваше выдающееся пони-мание всех вопросов – технических и прочих.

В худшем своем проявлении самонадеянность просачивается в сферу дело-вых отношений. Это отличная возможность навсегда загубить свою карьеру.Именно бизнес оправдывает само наше существование. Возможно, нам не-сколько неприятно сознавать этот факт, но все же не стоит упускать его извиду. Мы живем для того, чтобы служить потребностям бизнеса, а не наобо-рот. Умение слушать представителей бизнеса, которые нанимают нас длярешения своих задач, и понимать эти задачи – один из самых важных на-ших навыков. Вам когда-нибудь доводилось нетерпеливо дожидаться, покабизнес-аналитик закончит говорить, чтобы приступить к изложению своейпозиции? Скорее всего, его точку зрения вы при этом не восприняли. Отно-ситесь к экспертам в предметной области с тем уважением, которое хотелибы видеть по отношению к себе; крайне нежелательно, чтобы они считаливас непробиваемым упрямцем. Если они начнут избегать вас, вы станете ка-тализатором нарушения информационного обмена и по сути выроете могилу



161Бизнес и недовольный архитектор

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

Слушая, мы часто не соглашаемся с услышанным по поводу ведения биз-

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




Проверяйте решенияна прочность по ключевымхарактеристикам

Ñòèâåí Äæîíñ

Изначально архитектура приложения формируется на основании заданныхбизнес-требований, выбранных или уже применяемых технологий, диа-пазона производительности, ожидаемых объемов данных и финансовыхресурсов, выделенных для построения, развертывания и управления систе-мой. Решение, каким бы оно ни было, должно соответствовать требованиямиз этого набора либо превосходить их – и при этом успешно работать в совре-менных условиях (иначе это попросту не решение).

Теперь возьмите свое решение и посмотрите, какие проблемы появятся, ес-ли «растянуть» ключевые характеристики.

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

«Растяжение» ключевых характеристик поможет вам:

Понять, выдержит ли запланированная инфраструктура такие измене-•

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



163Проверяйте решения на прочность по ключевым характеристикам

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

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

нагрузка снижается, лишено будущего.Убедиться в том, что механизмы доступа к данным останутся работо-•

способными при масштабировании системы. Решение, работающее с не-дельным объемом данных, может не справиться с объемом, накоплен-ным за полгода.

Проверить, как при повышении рабочей нагрузки приложение распре-•

делит ее на дополнительное оборудование (если оно потребуется), и про-анализировать пути перехода при повышении нагрузки. Анализ пере-ходных путей перед развертыванием приложения может повлиять на

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

сбоев при возрастании объема данных и/или разделении данных в преде-лах расширенной инфраструктуры.

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

Стивен Джонс (Stephen Jones) проектирует решения для Tier-1Telco Bill-Tier-1Telco Bill--1Telco Bill-Telco Bill-Bill-Bill-ing и сопутствующие крупномасштабные процессы для таких компаний,как Telstra и Optus (Австралия), а также AT&T (США). В частности, онзанимался исходной реализацией систем тарификации Telco, перепроекти-Telco, перепроекти-, перепроекти- рованием системы опротестования счетов и борьбы с фальсификациямии более двух лет управлял службой круглосуточной поддержки Telstra.



Проектируйте только то,что можете запрограммировать

Ìàéê Áðàóí

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

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

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

Вы не представляете себе кривую обучения, которую предстоит одолеть•

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

зации.

Вы не знаете, какие «ловушки» могут подстерегать вас при использова-•

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



165Проектируйте только то, что можете запрограммировать

Вы лишитесь доверия своих разработчиков. Если вы не можете уверенно•

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

Вы подвергаетесь излишнему риску; нехватка знаний ставит жирный•

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

Как же архитектор должен подходить к освоению новых инфраструктур,шаблонов и серверных платформ? Об этом вам расскажет этюд «Архитек-тор –прежде всего разработчик».




«Что значит имя?», или Как розапревращается в капусту


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

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

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

нормального кода имена уже менялись трижды. Сначала было выбраноимя ClientAPI (причем под «клиентом» имелся в виду заказчик, а не кли-ент в контексте модели «клиент–сервер»), а последняя версия называласьClientBusinessObjects. Воистину замечательное имя: туманное, предельноширокое и сбивающее с толку.

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



167«Что значит имя?», или Как роза превращается в капусту

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

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

После продолжительных развлечений с компьютерами (от написания игрна Basic на компьютере BBC до применения Pascal, Mathematica и LabVIEWдля обработки экспериментальных данных, которые хранились в «базеданных» из скрепленных скотчем папок) Сэм Гардинер (Sam Gardiner)

перешел к профессиональной разработке ПО. Он работает в сфере програм-ПО. Он работает в сфере програм-ПО. Он работает в сфере програм-мирования на протяжении шести лет.



Четко определенные задачирешаются качественно


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

Архитектор вникает в мешанину концепций, данных и процессов и разби-вает их на меньшие фрагменты. Важнейшим качеством таких фрагментов

является четкая определенность задачи, что позволяет решить их закончен-ными и четко определенными фрагментами системы. Основные свойствафрагментов задачи таковы:

Внутренняя связность: фрагмент является концептуально цельным, то•

есть все его задачи, данные и функциональные возможности связаныдруг с другом.

Изолированность: фрагменты концептуально нормализованы, то есть•

практически не перекрываются друг с другом.

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



169Четко определенные задачи решаются качественно

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

Здесь интересно то, что решение четко определенной задачи неизменно. Воз-можно, через пять лет к нему будет приделан веб-интерфейс, а через пять-десят – телепатический, но ядро системы изменять не понадобится. Системастабильна, потому что четко определена решаемая с ее помощью задача.

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

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

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




Необходимо усердие

Áðàéàí Õàðò

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

Усердие идет рука об руку с практичностью. Успешная практическая рабо-та архитектора во многом обыденна. Эффективные архитекторы часто ведут

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

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

часто оказываются весьма разнородными и охватывают широкий диапазонограничений и ожиданий. Примеры:

Соблюдение финансовых и временных ограничений заказчика.•

Выполнение всей работы, которая делает архитектора эффективным (а не•

только той, которая ему нравится).

Использование конкретных процессов/методологий.•

Принятие ответственности.•



171Необходимо усердие

Вот что говорит Атул Гаванде (Atul Gawande) в своей замечательной книге«Better: A Surgeon’s Notes on Performance» (Быть лучше: записки хирургао профессиональном мастерстве) (Metropolitan Books) об усердии в медицин-ском сообществе:

«Добиться истинного успеха в медицине нелегко. Это требует силыволи, внимания к мелочам и творческого подхода. Но из своего пре-бывания в Индии я вынес урок: это может сделать кто угодно и гдеугодно. Найдется очень мало мест с еще более трудными условиями.Но и там встречались поразительные успехи… Я понял, что статьлучше всегда возможно. Для этого не обязательна гениальность.Необходимо усердие. Необходимы моральные принципы. Необходимаизобретательность. И самое главное – желание попытаться.»

Брайан Харт (Brian Hart) – ведущий консультант по CGI, специалист в об-CGI, специалист в об-, специалист в об-ласти информационных технологий и бизнес-процессов. Брайан участвовалв проектировании приложений J2EE, главным образом в государственномсекторе и на уровне местных властей. В сфере разработки программногообеспечения работает с 1997 года.



Отвечайте за свои решения

È ×æîó

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

Как стать ответственным архитектором, принимающим эффективные архи-

тектурные решения?

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

Решение изложено в письменном виде, поскольку архитектурные реше-•

ния редко бывают тривиальными. Они должны быть четко обоснованны-ми и отслеживаемыми вплоть до источника.

Информация о решении передана исполнителям, а также тем людям, ко-•

торых оно затронет (прямо или косвенно). Передача информации форми-рует единое для всех понимание сути решения.

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



173Отвечайте за свои решения

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

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

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

И Чжоу (Yi Zhou) в настоящее время работает главным архитекто- ром программного обеспечения в широко известной биотехнологическойкомпании, где проектирует программные платформы для медицинскихустройств и персонализации управления ходом заболевания. Он обладаетпочти 20-летним опытом, охватывающим все стадии цикла разработкиПО, и специализируется на согласовании бизнеса и технологий, страте-гическом планировании, совершенствовании процессов, проектировании

архитектур и инфраструктур, создании проектных команд и управленииими, а также на консультировании.



Не мудрствуйте

Ýáåí Õüþèò

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

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

победить в споре.

Умные программы обходятся дорого, сложны в сопровождении и ненадеж-ны. Не мудрствуйте. Постарайтесь быть как можно примитивнее, но соз-дайте при этом подходящий дизайн. Самый подходящий дизайн никогда небывает умным. Если вам кажется, что без ухищрений не обойтись, значит,задача неправильно структурирована, – проанализируйте ее заново. Пере-сматривайте постановку задачи до тех пор, пока вы не сможете снова дей-ствовать примитивно. Работайте на уровне грубых набросков; придержи-вайтесь общих решений. Забудьте о новомодных веяниях. Умный архитек-

тор должен действовать как можно примитивнее.Именно изощренность ума позволяет нам «обмануть» нежизнеспособнуюсистему и заставить ее работать. Не становитесь адвокатом, который своимкрасноречием «спасает» программу на техническом суде. Вы не Руб Голдберг



175Не мудрствуйте

и не Макгайвер1, готовый в любой момент построить умопомрачительнуюконструкцию из скрепок, жевательной резинки и динамитной шашки. Вы-киньте все лишнее из головы; подойдите к решению задачи без своих обшир-ных познаний в области замыканий, обобщений и управления поколениями

объектов в «куче». Иногда, конечно, все перечисленное действительно нуж-но для решения задачи, но намного реже, чем кажется на первый взгляд.

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

Эбен Хьюит (Eben Hewitt) возглавляет группу архитекторов в националь-ной компании розничной торговли с миллиардным оборотом, где в настоящеевремя занимается проектированием и реализацией сервис-ориентированнойархитектуры (SOA). Он является автором книги «Java SOA Cookbook», ко-Java SOA Cookbook», ко-SOA Cookbook», ко-SOA Cookbook», ко-Cookbook», ко-Cookbook», ко-», ко-торая будет скоро опубликована издательством O’Reilly.

1 Руб Голдберг (Rube Goldberg) – американский карикатурист, скульптор, писа-тель и изобретатель, широко известный серией комиксов, где изображались

очень сложные устройства для выполнения простых задач (получившие название«машины Руба Голдберга»). Ангус Макгайвер (Angus MacGyver) – персонаж одно-именного американского телесериала, секретный агент, отличительная чертакоторого – умение применять обширные научные познания для изобретательногоиспользования обыденных вещей в критической ситуации. – Примеч. ред.



Выбирайте оружие тщательнои не спешите его менять

×åä Ëàâèíü

Любой архитектор, будучи закаленным ветераном проектирования и реализа-ции, обладает целым арсеналом «оружия», которое он раз за разом успешноприменяет в своей работе. По тем или иным причинам эти технологии за-воевали наше расположение и сумели подняться на первые позиции в на-шем личном списке предпочтений. Скорее всего, они заслужили свое местов арсенале, победив в ходе ожесточенной конкуренции. Однако, несмотряна это, их положению постоянно угрожают многочисленные новые техноло-гии. У нас часто возникает соблазн отложить свое испытанное оружие, что-бы опробовать новые альтернативы… но не стоит торопиться. Отказываться

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

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

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



177Выбирайте оружие тщательно и не спешите его менять

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

Еще одним важным фактором являются затраты, обусловленные недостат-ками новой технологии. Эти затраты могут быть довольно высокими и пло-хо прогнозируемыми. Работая со знакомыми технологиями, вы хорошопредставляете себе их больные места. Наивно было бы полагать, что новаятехнология избавлена от «ловушек». Возникновение проблем, с которымивы ранее не сталкивались, разрушит все ваши оценки. О затратах, связан-ных с реализацией решений на базе знакомых технологий, вы осведомленыгораздо лучше.

Наконец, необходимо также учесть перспективность новой технологии. Бы-

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

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




Ваш клиент – не ваш клиент

Ýáåí Õüþèò

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

Ваш клиент – не ваш клиент. Вашим клиентом является клиент вашегоклиента. Если выигрывает клиент вашего клиента, то выигрывает и вашклиент. А это означает, что выигрываете вы.

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

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

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

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



179Ваш клиент – не ваш клиент

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

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

Как и многое в жизни, сказанное лучше всего иллюстрируется стихами.В 1649 году Ричард Лавлейс написал стихотворение «Лукасте по поводу ухо-да на войну». Оно заканчивается строками: «Ведь если бы я предал честь,я предал бы тебя».

Мы предаем наших клиентов, когда игнорируем интересы их клиентов.




Все будет не так, как задумано

Ïèòåð Ãèëëàðä-Ìîññ

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

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

от того, каким вы его себе представляли. Что-нибудь непременно произой-дет – и в дизайн вмешается какой-либо внешний фактор: неверная информа-ция, ограничение, странное поведение чужого кода… А может быть, вы где-то ошибетесь: упущение, неверное предположение, какой-то пропущенныйнюанс… Или что-нибудь изменится – требования, технология, – или кто-тонайдет лучшее решение™.

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

гу. Вы решаете, что проблема требует более тщательного, более подробно-го проектирования, усердно трудитесь – и добиваетесь более четкого, болееглубокого и более совершенного видения.

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



181Все будет не так, как задумано

в конечном итоге только разваливают его окончательно. И вы восклицаете:«Конечно же, ошибки будут – ведь система для этого не предназначалась!»

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

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

Питер Гиллард-Мосс (Peter Gillard-Moss) – сотрудник ThoughtWorks и ме-ThoughtWorks и ме-и ме-меолог широкого профиля из США. Работает в сфере информационных тех-

нологий с 2000 года; участвовал во многих проектах, от общедоступныхмедиасайтов и электронной коммерции до банковских приложений и корпо- ративных интрасетей.



Выбирайте инфраструктуры,хорошо сочетающиесяс другими

Ýðèê Ãîòîðí

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

Лучше всего, если каждая инфраструктура или сторонняя библиотека будет

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

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

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

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



183Выбирайте инфраструктуры, хорошо сочетающиеся с другими

а балласт – то, насколько инфраструктура стремится охватить все что можнои решить все задачи на свете. Требует ли инфраструктура смешивать управ-ление данными и их представление? Как сильно ее модель данных или наборпакетов/классов выходят за пределы того, что необходимо вашей системе?

Придется ли вам присягнуть ей на верность и впредь ограничить выбор ин-фраструктур теми, что соответствуют ее рамкам? Ограничивает ли ее избы-точная сложность возможности взаимодействия? Если уж инфраструктураотягощена большим количеством балласта, она должна обеспечивать хотябы 75% необходимой функциональности проекта.

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

Эрик Готорн (Eric Hawthorne) профессионально занимается созданием ар-

хитектуры, проектированием и разработкой объектно-ориентированныхпрограмм и распределенных систем с 1998 года. Первые 10 лет его карьерыпрошли в Macdonald Dettwiler – канадской системотехнической компании,где среди прочего он имел возможность поучиться архитектурным тонко-стям у самого Филиппа Крачтена (Philippe Kruchten).



Подготовьте убедительноеэкономическое обоснование

È ×æîó

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

граммированием, где заинтересованные стороны обычно очень слабо разби-раются в программных технологиях.

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

На протяжении своей карьеры я неоднократно применял следующий про-цесс из пяти шагов для успешного продвижения своих архитектурных ре-шений:

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



185Подготовьте убедительное экономическое обоснование

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

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

Увяжите свои данные с традиционными бизнес-метриками.3. Будет пре-восходно, если вы сумеете напрямую представить результаты техниче-

ского анализа в денежном выражении. В конце концов, единственнымнеизменным параметром в традиционных бизнес-метриках являютсяденьги. Если вы недостаточно хорошо разбираетесь в финансовых тон-костях, возьмите себе в помощники бизнес-аналитика.

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

Выберите подходящий момент.5. Даже если вы выполните четыре пред-ыдущих рекомендации и подготовите хорошее экономическое обоснова-ние, ваша идея может провалиться из-за неудачного выбора момента ееподачи. Помню, одно из моих предложений долгое время не получалоподдержки – до тех пор, пока другой проект не завершился полным кра-хом из-за плохой архитектуры. Разумно подходите к выбору момента.




Управляйте не только кодом,но и данными

×åä Ëàâèíü

Управление исходным кодом и непрерывная интеграция – замечательные ин-струменты для управления процессами сборки и развертывания приложе-ний. Однако изменения в схеме и в данных часто являются существеннойчастью этого процесса наравне с изменениями в исходном коде и требуютаналогичного управления. Если ваш процесс сборки и развертывания си-стемы содержит список сложных операций, необходимых для обновленияданных, берегитесь. Подобные списки всегда являются тревожным знаком.Выглядят они примерно так:

Вы создаете список сценариев, которые необходимо выполнить в задан-1.

ном порядке.1.

Вы отправляете сценарии конкретному администратору базы данных по2.электронной почте.

Администратор копирует сценарии в каталог, из которого они должны3.запускаться заданием cron.

Вы проверяете журнал выполнения сценариев и молитесь, чтобы все сце-4.нарии выполнились успешно, потому что не знаете точно, что произой-дет при их повторном выполнении.

Вы запускаете сценарии проверки и осуществляете выборочную провер-5.ку данных.

Вы проводите регрессионное тестирование приложения и смотрите, что6.перестало работать.

Вы пишете сценарии для вставки отсутствующих данных и исправления7.ошибок.

Вы повторяете шаги с 1 по 7.8.



187Управляйте не только кодом, но и данными

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

те появляется ненадежный, выполняемый вручную процесс, состряпанныйзадним числом.

Сложная, запутанная процедура открывает много возможностей для сбоев.Ситуация усугубляется тем, что ошибки, вызванные изменениями схем илиданных, не всегда обнаруживаются модульными тестами, которые являют-ся частью ночной сборки. Эти ошибки любят заявлять о себе громко и эф-фектно сразу же после миграции. Решения проблем в базах данных сложнеепроверить на правильность, а ручной «откат» базы данных – операция весь-ма трудоемкая. Ценность полностью автоматизированного процесса сборки,способного вернуть базу данных в известное состояние, становится особенноочевидной, когда вы используете его для исправления очень явных ошибок.Если вы не можете удалить базу данных и восстановить ее состояние, совме-стимое с конкретной сборкой приложения, вы сталкиваетесь с теми же про-блемами, что и при невозможности быстрого восстановления кода.

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

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




Расплатитесьпо техническим кредитам


В жизни любого проекта, находящегося в стадии эксплуатации (то есть имею-щего активных пользователей), наступает момент, когда требуется внестиизменения – исправить ошибку либо добавить новую функцию. Возможныдва пути: либо вы не пожалеете времени и сделаете все «как положено», ли-бо начнете «срезать углы», чтобы решить задачу побыстрее.

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

менений, прежде чем продукт будет отправлен клиентам.

Вам как архитектору проекта предстоит решить, какой путь более разумен,а затем убедить лиц, принимающих решения, последовать вашему совету;как в большинстве архитектурных вопросов, здесь необходим разумныйкомпромисс. Если вы считаете, что система достаточно стабильна, воз-можно, стоит поработать «на скорую руку» и внести изменения как можнобыстрее. В принципе, это нормально, но учтите, что при этом проект берет«технический кредит», который позже придется выплачивать. В нашемслучае «выплата» означает, что вам все равно придется вернуться и внести

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

Тогда почему мы беспокоимся о том, когда следует внести добросовестныеизменения – сейчас или потом? Потому что изменения «на скорую руку» со-пряжены со скрытыми расходами. В финансовой сфере такие скрытые рас-ходы на кредит называются процентами; любой владелец кредитной картызнает, как дорого может обходиться простая выплата процентов по кредиту.



189Расплатитесь по техническим кредитам

Для технических долгов «проценты» принимают обличие нестабильностисистемы и повышенных затрат на сопровождение, обусловленных топор-ным внесением изменений и отсутствием должного проектирования, до-кументации и/или тестов. Причем, как и в финансовом случае, проценты

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

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

Как только исправление попадет в работающую систему, добейтесь того,

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

Берк Хафнагель (Burk Hufnagel) создает пользовательские приложенияс 1978 года. В настоящее время работает ведущим архитектором ПО

в LexisNexis.



Не спешите решать задачи

Ýáåí Õüþèò

Практически все архитекторы когда-то были разработчиками. Разработчикамплатят за решение задач из области программирования, менее масштабныхпо сравнению с архитектурными задачами. Как правило, это мелкие каверз-ные алгоритмические задачи. Они часто представлены в книгах и учебныхкурсах так, словно существуют в отрыве от реальности, а их каверзностьвыглядит весьма вызывающе и соблазнительно. Со временем мы начинаемвоспринимать такие задачи как данность – мы не спрашиваем, насколькоосмысленна задача, интересна ли она, полезна, этична и так далее. Нам неплатят за анализ роли задачи в более широком контексте. Мы приучены

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

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

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



191Не спешите решать задачи

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

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

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

Вместо того чтобы немедленно приступать к решению задачи в том виде,в котором вы ее получили, подумайте, нельзя ли изменить саму задачу.Спросите себя: как бы выглядела архитектура, если бы этой задачи простоне было? Такой подход может дать в итоге более элегантное и сбалансиро-ванное решение. Бизнес-задачу все равно придется решать, но, возможно,не так, как казалось изначально.

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




Стройте zuhanden-системы


Мы создаем инструменты. Создаваемые нами системы служат единственнойцели (не считая того, что нам за них платят) – помогать кому-то (обычнокому-то другому) что-либо делать.

Мартин Хайдеггер (Martin Heidegger), известный немецкий философ XX ве-XX ве-ве-ка, исследовал, как люди воспринимают инструменты (и вообще «оборудова-ние»). Человек использует инструмент для достижения определенной цели,причем сам инструмент является всего лишь вспомогательным средством.

Для успешного применения инструмент должен быть zuhanden («подруч-

ным», то есть «ложащимся в руку»). Иначе говоря, такой инструмент вос-принимается непосредственно, он используется инстинктивно, без размыш-лений и полемики. Мы просто берем инструмент и используем его для до-стижения нашей цели. В ходе такого использования инструмент исчезает,он фактически становится продолжением нашего тела и не воспринимаетсякак нечто отдельное. Одним из признаков zuhanden-инструмента являетсято, что он становится как бы невидимым, неосязаемым, незаметным.

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

Возможна и другая ситуация (обычно она свидетельствует о возникшихпроблемах): пользователь воспринимает инструмент как vorhanden («на-личествующий», то есть «находящийся в руке»). Инструмент отделяетсяот цели; он находится перед вами, требуя вашего внимания. Он становитсяобъектом отдельного исследования. Пользователь уже не может двигать-ся к цели; он должен разобраться с инструментом, прежде чем тот сможетхоть как-то приблизить его к ней. Нам как техническим специалистам



193Стройте zuhanden-системы

свойственно воспринимать создаваемые нами для пользователей системыкак vorhanden-инструменты – и в ходе работы над ними, и позднее, когдамы получаем сообщения о дефектах. Инструмент вполне закономерно явля-ется для нас объектом рассмотрения, предметом размышлений, исследова-

тельской задачей. Это нечто требующее изучения.Однако (и это очень важно!) пользователи смогут добиться успеха, применяянаш продукт, только в том случае, если для них это zuhanden-инструмент.Спроектированы ли ваши системы так, чтобы становиться «невидимыми»при использовании? Насколько естественно «ложится в руку» пользова-тельский интерфейс? Или же ваша система постоянно требует внимания,отвлекая пользователя от его цели?




Найдите и удерживайтеэнтузиастов

×åä Ëàâèíü

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

Вероятно, большинство читателей согласится с тем, что поиск первокласс-ных разработчиков требует проведения основательного технического собе-седования. Но что следует понимать под «основательным»? Это вовсе неозначает, что кандидат должен ответить на трудные вопросы о малоизвест-

ных технических нюансах. Разумеется, проверка конкретных техническихнавыков является частью процесса, но превращение собеседования в серти-фикационный экзамен не гарантирует успеха. Вам нужны разработчики-энтузиасты, обладающие навыком поиска решений. Инструменты, которыевы используете сейчас, наверняка изменятся; вам нужны люди, способныеуспешно пойти на штурм задачи независимо от доступных технологий. Дажеесли человек может наизусть перечислить все методы API, это практическиничего не скажет вам о его склонностях и о его стремлении решать задачи.

С другой стороны, если вы попросите человека объяснить свой подход к диа-

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



195Найдите и удерживайте энтузиастов

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

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

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

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




Программы на самом делене существуют

×åä Ëàâèíü

Разработку программного обеспечения часто сравнивают с такими устояв-шимися дисциплинами, как гражданское строительство. Однако у подоб-ных аналогий имеется серьезный недостаток: в отличие от материальныхпродуктов, создаваемых в ходе строительства, программы в реальности несуществуют – по крайней мере, в традиционном смысле слова. Обитателимира нулей и единиц не связаны физическими законами, которые накла-дывают ограничения на классические инженерные парадигмы. Хотя в фазепроектирования ПО применение инженерных принципов дает достаточнохороший результат, предположение о том, что вы сможете воплотить соз-

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

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

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



197Программы на самом деле не существуют

В инженерных проектах физического характера гораздо проще реализоватьпринцип «сначала план работ, потом работы по плану». К построению про-граммных продуктов обычно приходится подходить по принципу «сначалаплан работ, потом подгонки плана».

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

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

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

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




Освойте новый язык


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

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

Бизнесмен около минуты говорит о необходимости относительно просто-•

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

Пока он говорит, архитектор начинает рисовать в блокноте какие-то мис-•

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

Наконец бизнесмен завершает свою речь и выжидательно смотрит на ар-•

хитектора.

Архитектор заканчивает перешептываться, выходит к доске и прини-•

мается рисовать сложные диаграммы с несколькими представлениямисуществующей системы, попутно объясняя (в сложных технических



199Освойте новый язык

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

Бизнесмены (которые мало что поняли в диаграммах и еще меньше•

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

Тем временем архитектор и программисты в свою очередь поражают-•

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

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

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

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

Я не утверждаю, что изучение нескольких языков решит все ваши пробле-

мы. И все же оно поможет предотвратить недопонимание, порождающеепроблемы.

Тем читателям, кто находит эту точку зрения разумной, я желаю успеха наих пути. Или, как говорят клингоны, – Qapla!1


1 Клингоны – вымышленная цивилизация из сериала «Star rek» («Звездныйпуть»). Слово «qapla» в клингонском языке является пожеланием успеха. –Примеч. ред.



Не создавайте решения«на перспективу»

Ðè÷àðä Ìîíñîí-Õåéôåë

Сегодняшнее решение становится завтрашней проблемой

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

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

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



201Не создавайте решения «на перспективу»

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

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

Ричард Монсон-Хейфел (Richard Monson-Haefel) – независимый разработ-чик ПО, соавтор всех пяти изданий «Enterprise JavaBeans» и обоих изданий«Java Message Service» (все книги опубликованы издательством O’Reilly).

Занимается проектированием и разработкой multitouch-интерфейсов, явля-multitouch-интерфейсов, явля--интерфейсов, явля-ется ведущим специалистом в области корпоративной обработки данных.



Проблема пользовательскогопризнания


Люди не всегда рады появлению новых систем или крупным обновлениям.Это может поставить под угрозу успешное завершение проекта.

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

Вы как архитектор должны знать о проблеме с признанием системы пользо-вателями, понимать текущий уровень ее опасности и принимать меры к ее

устранению. Для этого вам необходимо понимать суть проблемы и причины,ее порождающие. Вот наиболее распространенные причины:

Люди могут иметь свои соображения о необходимости внедрения новой•

системы (и сопутствующего вывода из эксплуатации старой). В частно-сти, они могут опасаться утратить ценную функциональность или поте-рять свое влияние в компании из-за перераспределения ролей.

Люди боятся новых (непроверенных) технологий.•

Люди стараются избежать дополнительных затрат.•

Люди просто не любят изменения.•

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



203Проблема пользовательского признания

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

Наличие у проекта сторонников также помогает решить проблему призна-

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




О важности консоме

Ýáåí Õüþèò

Консоме – осветленный бульон, который обычно готовится из говядины илителятины и подается как деликатесный суп. Правильно приготовленныйконсоме идеально прозрачен. Его приготовление считается сложным и тру-доемким делом, потому что существует только один способ удаления жираи других примесей и достижения абсолютной прозрачности, необходимойдля этого блюда: многократно, раз за разом тщательно процеживать бульон.Усердная очистка путем многократной фильтрации отвара создает чрезвы-чайно богатый вкус. Пробуя консоме, вы как будто ощущаете саму сущностьбульона. Собственно, для этого и делается такое блюдо.

В американских кулинарных школах среди начинающих шеф-поваров, го-товящих консоме, проводится простое испытание: преподаватель бросаетв янтарный бульон десятицентовую монетку. Если можно прочитать датучеканки на монетке, лежащей на дне миски, испытание пройдено. Еслинет – попытка считается неудачной.

Архитектор программного обеспечения должен постоянно избавлять мыслиот примесей, многократно фильтровать свои идеи, пока не будет выявленасущность каждого требования к системе. Словно Гамлет, держащий черепЙорика, мы спрашиваем себя: что представляет собой данная возможность?

Каковы ее свойства? Ее связи? Мы проясняем свои концепции, чтобы отноше-ния в архитектуре поддавались проверке и были внутренне согласованными.

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



205О важности консоме

в алиби, подмечайте все новое, любые различия и противоречия. Фильтруй-те снова и снова.

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

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

Проверяйте утверждения, спрашивая: «Останется ли это утверждение спра-ведливым, если прибавить к нему “везде, всегда и при любых обстоятель-ствах”?» Люди стараются воздерживаться от подобных безапелляционныхформулировок и поэтому начинают более тщательно подбирать слова. Про-сеивайте представления концепций через лингвистическое сито, чтобы очи-

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

В какой момент работу над архитектурой можно считать завершенной? Когдаона станет абсолютно прозрачной и вы сможете прочитать дату на монетке.




Для пользователя интерфейс –это и есть система

Âèíàÿê Õåäæä

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

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

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

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

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



207Для пользователя интерфейс – это и есть система

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

торых пользовательский интерфейс пишется не на том языке программиро-вания, на котором создается вся остальная система.

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

Винаяк Хеджд (Vinayak Hegde) – технофил, интересующийся компьюте- рами, фотографией и предпринимательством. В настоящее время работа-ет архитектором в компании Akamai Technologies.



Лучшие программы не строят –их выращивают


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

Самым верным предвестником провала программного продукта является его

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

Поэтому сопротивляйтесь искушению спроектировать крупную завершен-

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

Как этого добиться? Лучший метод снабдить программную систему способ-ностью развиваться и адаптироваться – заставить ее развиваться и адапти-



209Лучшие программы не строят – их выращивают

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

ной архитектуре столько, сколько никогда не расскажет большая система(и тем более подборка документов с описанием архитектуры). Вы с большейвероятностью будете участвовать в его реализации. Миниатюрность упро-щает тестирование и снижает уровень связанности. Для создания такогозародыша потребуется группа меньшего размера, что сократит затраты накоординацию проекта. За его свойствами будет проще наблюдать. Его будетпроще развертывать. По нему вы и ваша группа сможете как можно рань-ше понять, какие решения работают, а какие нет. Он покажет вам, в какихместах развитие системы затруднено, где она наверняка кристаллизуетсяи станет хрупкой. Где она может сломаться. И, что самое важное, вы сможе-

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

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

ной разбивкой на этапы и созданием системы для мусорной корзины.




Алфавитный указатель

AAAM (Architecture radeoff Analysis

Method), 59

СCBAM (Cost Benefit Analysis Method), 59

DDD, 46

EEDA (Event-Driven Architecture), архи-

тектура, управляемая событиями, 98EL, процесс, 47

FFalcon F-16, истребитель, 26

GGraphViz, инструментарий, 71

IInfoViz, инструментарий, 71

RROA (Resource-Oriented Architecture),

ресурсно-ориентированная архитек-тура, 98

ROI (Return on Investment), показательокупаемости инвестиций, 48, 142–143

SSCRUM, 77SEI (Software Engineering Institute),

сайт, 59

SOA (Service-Oriented Architecture),сервис-ориентированная архитектура,74, 98

VVisio, 22vorhanden-инструмент, 192

Zzuhanden-инструмент, 192–193

Аавтоматизированная сборка, 44–45,

54–55автоматизированное тестирование,

44–45, 54–55

инфраструктура, 45аксиомы, 132–133аналогии, 132–133Андерсон, Дейв, 145

«Ваша система станет унаследован-ной – учитывайте это при проек-тировании», 144–145

антипаттерны, 99аппаратное обеспечение, 150–151архитектор

изощренность ума, 174–175

как король, 102–103как посредник между бизнесом

и командой разработчиков, 48, 52как представитель бизнеса, 48, 52как представитель команды разра-

ботчиков, 52как разработчик, 140–141, 164–165,

190ответственность, 172–173



211Алфавитный указатель

Брукс, Фредерик, 76Брюэра теорема, 130Буч, Гради, 62бюджетектура, 32

ВВадья, Зубин, 159

«Хороший контент порождает хоро-шие системы», 158–159

«Ваза», корабль, 58версии продукта

выпуск частый, 49сборка ранняя и частая, 54

взаимодействие социальное, 20Викраманаяке, Камал, 151

«Архитектор должен разбираться

и в оборудовании», 150–151витрины данных, 47внесение изменений в систему, 134время отклика системы, 95второстепенная сложность, 18, 51выбор технологии, 176–177выпуск

версий частый, 49приложения ранний, 91

Г

Гаванде, Атул, 171Гардинер, Сэм, 167

«“Что значит имя?”, или Как розапревращается в капусту», 166

«Четко определенные задачи реша-ются качественно», 168–169

Гарсон, Эдвард, 93«Неоднородность побеждает», 92–93«Правила диктует контекст», 100–101

гибкая разработка, 26, 44гибкое управление, 77

Гиллард-Мосс, Питер, 181«Все будет не так, как задумано»,

180–181Голдберг, Руб, 175Готорн, Эрик, 183

«Выбирайте инфраструктуры, хо-рошо сочетающиеся с другими»,182–183

границы, 114–115

полезные аналогии, 104–105помешанный на тотальном контроле,

110режим решения задач, 190–191усердие, 170–171

хорошийзнания и навыки, 53признаки, 52

архитектураи шаблоны проектирования, 98–99конвейерная, 98на основе бизнес-правил, 74ресурсно-ориентированная, 98сервис-ориентированная, 74, 98стека вызовов, 109управляемая событиями (EDA), 98

этические аспекты, 88–89архитектурные компромиссы, 58–59

Ббаза данных как крепость, 60–61баланс интересов и требований

к системе, 42–43Бартлетт, Дэвид, 55

«Архитектор Янус», 112–113«Обеспечьте непрерывную интегра-

цию», 54–55

бережливая разработка, 49бережливое производство, 77библиотеки проба перед выбором, 72–73Борванкар, Нитин, 17

«Не ставьте свое резюме выше инте-ресов клиента», 16–17

Брайтуэйт, Кейт, 35«Используйте объективные крите-

рии», 34–35«Решений может быть несколько»,

46–47

«Стройте zuhanden-системы»,192–193«Учитесь у архитекторов зданий»,

104–105Браун, Майк, 141

«Архитектор – прежде всего разра-ботчик», 140–141

«Проектируйте только то, что може-те запрограммировать», 164–165



212 Алфавитный указатель

Дданные

как основа представления о системе,136–137

управление, 186–187Дахан, Уди, 29«Встаньте!», 28–29

де Ора, Билл, 131«Лучшие программы не строят – их

выращивают», 208–209«Приготовьтесь выбрать два из

трех», 130–131Джонс, Стивен, 163

«Проверяйте решения на прочностьпо ключевым характеристикам»,162–163

диаграммы, 22документирование архитектурных

решений, 118–119допущения, 120–121, 134Дорненбург, Эрик, 71, 111

«Посмотрите с высоты 300 метров»,70–71

«Пробуйте, прежде чем сделать вы-бор», 72–73

доска для маркеров, 22доступность распределенной системы,

130дублирование, 106–107Дэвис, Джон, 53

«Архитектор должен быть практи-ком», 52–53

Ззадача, определенность, 168–169заинтересованные стороны, соотнесение

интересов с требованиями к системе,42–43

законМура, 94Уэзерна, 120

здравый смысл, 38знания и опыт, обмен, 122–123

Иизменения

внесение в систему, 134

последствия, 148–149изощренность ума, 174–175Инг, Дэвид, 127

«Не увлекайтесь архитектурнымиметафорами», 126–127

инструментvorhanden, 192zuhanden, 192–193

интеграция непрерывная, 44–45, 49,54–55, 186

интерфейс, 114–115, 206–207инфраструктура

автоматизированного тестирования,45

проба перед выбором, 72–73снижение сложности, 19

совместимость с другими, 182–183

ККарновейл, Норман, 57

«Проблема пользовательского при-знания», 202–203

«Старайтесь не нарушать график»,56–57

карта контекстов, 115Каспер, Мнчедизи, 129

«Уделяйте пристальное внимание

поддержке и сопровождению»,128–129

Кениг, Эндрю, 99клиенты

восприятие системы через восприя-тие интерфейса, 206–207

потребности, 16–17признание системы, 202–203соотнесение интересов с требования-

ми к системе, 42–43требования, 178–179

ключевые характеристики, растяжение,162–163Кнут, Дональд, 67Коберн, Алистер, 134компоненты

развертывание, 90–91создание интерфейсов, 91

компромиссы архитектурные, 58–59конвейерная архитектура, 98




консоме, 204–205конструирование и проектирование,

76–77контекст, 100–101контекст ограниченный, 114

контекстное чутье, 38–39контент, качество, 158–159контроль тотальный, 110король как метафора архитектора,

102–103Костоф, Спиро, 104Кофски, Эван, 103

«Гномы, эльфы, волшебники и коро-ли», 102–103

Крачтен, Филипп, 183кредит технический, 188–189

критерии требований, объективные,34–35

критика, 69Кроуфорд, Дуг, 149

«Осознавайте последствия измене-ний», 148–149

Куик, Дэйв, 65«“Я” в архитектуре не существует»,

68–69«Масштаб – враг успеха», 84–85«Проблемы могут быть больше, чем

их отражение в зеркале», 64–65

ЛЛавинь, Чед, 125

«Бизнес и недовольный архитектор»,160–161

«Выбирайте оружие тщательно и неспешите его менять», 176–177

«Найдите и удерживайте энтузиа-стов», 194–195

«Патология шаблонов», 124–125

«Программы на самом деле не суще-ствуют», 196–197«Простое должно быть простым»,

138–139«Управляйте не только кодом, но

и данными», 186–187Лавлейс, Ричард, 179Ландре, Эйнар, 27

«В центре внимания архитектора –границы и интерфейсы», 114–115

«Ищите истинный смысл требова-ний», 26–27

«Программирование – это часть про-

ектирования», 76–77лидерство, 23

ММакгайвер, Ангус, 175Макфи, Скот, 153

«“Срезание углов” сейчас обойдетсяслишком дорого потом», 152–153

Маламидис, Джордж, 143«Окупаемость как фактор проекти-

рования», 142–143

манифест гибкой разработки, 26масштаб проекта, 84–85масштабируемость

вертикальная, 151горизонтальная, 151

матрица решений структурная, 71Мейер, Джереми, 67

«Повторное использование – вопросне только архитектурный», 66–67

Мейлер, Норман, 120метафоры, 126–127

метрики, 185многократная фильтрация, 204–205многоязыковое программирование,

92–93множественные решения, 46–47, 146–147модели данных, 60модульное тестирование, 44–45, 54–55Мойер, Карен, 105Монсон-Хейфел, Ричард, 201

«Не создавайте решения “на пер-спективу”», 200–201

Муирхед, Дейв, 49«Всем заправляет бизнес», 48–49Мура закон, 94мышление опционное, 63

Ннаблюдение, 110–111надежность модели данных, 60Найберг, Грег, 155




«Лучшее – враг хорошего», 154–155«Остерегайтесь “хороших идей”»,

156–157Найгард, Майкл, 31

«Вы ведете переговоры чаще, чем

вам кажется», 32–33«Небоскребы не масштабируются»,

90–91«Проектирование в пустоте», 96–97«Сбои неизбежны», 30–31«У программной архитектуры есть

этические аспекты», 88–89написание кода и проектирование,

36–37Нельсон, лорд, 114Нельсон, Филип, 79

«Время меняет все», 80–81«Предоставьте разработчикам неза-

висимость», 78–79неоднородность, 92–93неопределенность как движущая сила

проектирования, 62–63неотъемлемая сложность, 18непрерывная интеграция, 44–45, 49,

54–55, 186нефункциональные требования, раннее

тестирование, 40

Нигаард, Кристен, 76Нильссон, Никлас, 45

«Боритесь с повторениями», 106–107«Сделать наспех и сбежать – пре-

ступление», 44–45

Ообмен знаниями и опытом, 122–123оборудование, 150–151обоснование экономическое, 184–185обратная связь, 134

общение, 20эффективное, 22переговоры, 32–33рекомендации, 20–21, 28–29стоя, 28–29

ограничения, 130–131ограниченный контекст, 114окупаемость инвестиций (ROI, Return

on Investment), 48, 142–143

оптимизм разработчиков, 64опционное мышление, 63ответственное руководство, 86–87ответственность, 172–173отраслевые тенденции, 74–75

ППарсонс, Ребекка, 41

«Думать о производительности ни-когда не рано», 40–41

переговоры, 32–33планирование, 56–57повторение, 106–107повторное использование, 66–67подверженность сбоям, 30–31поддержка приложений, 128–129

поддержка разработчиков, 116–117показатель окупаемости инвестиций

(ROI), 48, 142–143покомпонентное развертывание прило-

жения, 90–91Поппендик, Мэри, 72Поппендик, Том, 72последствия изменений, 148–149потребности клиента, 16–17предложение ценностное, 184предметная область, понимание, 74–75

признание пользовательское, 202–203приложение

поддержка и сопровождение, 128–129покомпонентное развертывание,

90–91ранний выпуск, 91

принцип разделения ответственности,114–115

принципы, 132–133приоритеты, 85программирование многоязыковое,

92–93программный код и спецификации, 36продуктивность, 94проект, масштаб, 84–85проектирование

в пустоте, 96–97и конструирование, 76–77и написание кода, 36–37крупномасштабной системы, 208–209




на основе предметной области, 39неопределенность, 62–63процесс, 180–181шаблоны, 39, 72, 124–125эвристический подход, 38

производительность, 94–95тестирование, 40–41

производительность, 24–25производство бережливое, 77простота, 80–81

контекст, 100лучшее – враг хорошего, 154–155решений, 50–51

процессразработки, прозрачность, 48

процесс проектирования, 180–181

пустота как пространство для проекти-рования, 96–97

Рразвертывание приложения покомпо-

нентное, 90–91разработка

бережливая, 49гибкая, 26, 44через тестирование, 45

разработчики

независимость, 78–79поддержка, 116–117

Райт, Фрэнк Ллойд, 104ранний выпуск приложения, 91ранняя сборка версий, 54Раскин, Джон, 105Рассел, Крейг, 95

«Не забывайте о производитель-ности», 94–95

растяжение ключевых характеристик,162–163

реальный мир, 108–109режим решения задач, 190–191ресурсно-ориентированная архитектура

(ROA), 98Рехтин, Эберхард, 38решения

документирование, 118–119единообразие, 46множественные, 46–47, 146–147

на перспективу, 200–201примитивность, 174–175простота, 50–51универсальность, 38–39, 50–51

Ривз, Джек, 77

риски, управление, 65Ричардс, Марк, 23

«Архитектурные компромиссы»,58–59, 118

«Изучите профессиональный жар-гон», 98–99

«Общение – король, ясностьи лидерство – его верные слуги»,22–23

«Разберитесь в предметной области»,74–75

руководство ответственное, 86–87Рэмм, Марк, 21

«Возможно, ваша главная проблемане в технологиях», 20–21

Рэндал, Эллисон, 37«Одна строка рабочего кода стоит

500 строк спецификации», 36–37

Ссамонадеянность, 160–161сборка

автоматизированная, 44–45, 54–55ранняя, 54частая, 54

связанность системы, 91сделать наспех и сбежать, 44–45сервис-ориентированная архитектура

(SOA), 74, 98система

зародыш, 209признание пользователями, 202–203распределенная

доступность, 130устойчивость к разделению, 130целостность, 130

связанность, 91сцепление, 91унаследованная, проектирование,

144–145сложность, 138–139

второстепенная, 18, 51




неотъемлемая, 18, 124снижение, 19, 148–149цикломатическая, 70

совместимость инфраструктур, 182–183сопровождение приложений, 128–129

социальные взаимодействия, 20спецификации и программный код, 36Стаффорд, Рэнди, 25

«Производительность приложенияопределяется его архитектурой»,24–25

«Решений на все случай жизни несуществует», 38–39

«Создание архитектуры как искус-ство баланса», 42–43

Стивенсон, Нил, 102

структурная матрица решений, 71сцепление системы, 91

Ттенденции отраслевые, 74–75теорема Брюэра, 130тестирование

автоматизированное, 44–45, 54–55инфраструктура, 45

модульное, 44–45, 54–55нефункциональных требований,

раннее, 40производительности, 40–41техническое, 41

технический кредит, 188–189техническое тестирование, 41технология, выбор, 176–177тотальный контроль, 110требования, 85, 178–179

баланс интересов, 42–43к аппаратному обеспечению, 150–151критерии объективные, 34–35

нефункциональные, раннее тестиро-вание, 40прояснение, 26–27

Тримайл-Айленд, авария, 31

Уунаследованная система, проектирова-

ние, 144–145универсальность решений, 38–39, 50–51

Уотерхауз, Рэнди, 102Уоттон, Генри, 105управление

гибкое, 77данными, 186–187

исходным кодом, 186рисками, 65

упрощение, 138–139снижение сложности, 19, 148–149

усердие, 170–171устойчивость распределенной системы

к разделению, 130Уэзерна закон, 120

Ффактоиды, 120

Фаулер, Мартин, 54, 99фильтрация многократная, 204–205Форд, Нил, 19

«Снижайте неотъемлемую слож-ность, устраняйте второстепеннуюсложность», 18–19

фотоаппарат, 22

ХХай, Тимоти, 117

«Записывайте свои обоснования»,

118–119«Когда вы видите единственное ре-

шение, спросите других», 146–147«Поддерживайте разработчиков»,

116–117«Сомневайтесь в допущениях – осо-

бенно в собственных», 119, 120–121Хайдеггер, Мартин, 192характеристики ключевые, растяжение,

162–163Хармер, Майкл, 133

«Принципы, аксиомы и аналогииважнее личных мнений и предпо-чтений», 132–133

Харт, Брайан, 171«Необходимо усердие», 170–171

Хафнагель, Беркхардт, 189«Освойте новый язык», 198–199«Расплатитесь по техническим кре-

дитам», 188–189




Хеджд, Винаяк, 207«Для пользователя интерфейс – это

и есть система», 206–207Хенни, Кевлин, 51

«Простота лучше универсальности»,

50–51«Руководствуйтесь неопределенно-

стью», 62–63Хиллейкер, Гарри, 26ходячий скелет, 134Хокинс, Барри, 83

«“Архитектор программного обе-спечения” пишется со строчной

частый выпуск версий, 49Чжоу, И, 173

«Отвечайте за свои решения», 172–173«Подготовьте убедительное экономи-

ческое обоснование», 184–185

чутье контекстное, 38–39

Шшаблоны

архитектурные, 98интеграции, 99корпоративного уровня, 98проектирования, 39, 72, 98–99

Documents

97 Этюдов Для Архитекторов Программных Систем