97 Things For Architect

97 вещей, которые должен знать
каждый архитектор ПО
(В оригинале – 97 Things Every Architect Should Know)
Перевод – Александр Лотохов
Эти и другие переводы также доступны онлайн на сайте http://avl2.info
Данная серия переводов распространяется под лицензией Creative Common 3,

точно так же, как и оригинал
97 Things Every Architect Should Know. Материалы по эффективной разработке: http://avl2.info
Содержание
1. Ваше резюме не должно быть на первом месте...................................................................5

2. Сложное - упрощайте, с усложнением - боритесь! .............................................................6
3. Скорее всего, ваша главная пробема - не техническая .......................................................7
4. Коммуникация - это король, а ясность и лидерство - его покорные слуги .....................9
5. Баланс между техническими требованиями и интересами участников.........................10
6. Ищите настоящую причину требований .............................................................................11
7. Встаньте!...................................................................................................................................12
8. Небоскребы не масштабируются! ........................................................................................13
9. Вы участвуете в переговорах чаще, чем вы думаете.........................................................15
10. Количество имеет значение! .................................................................................................17
11. Строка работающего кода ценнее, чем 500 строк спецификации ..................................18
12. Универсальных решений не существует! ...........................................................................19
13. Никогда не рано задуматься о производительности .........................................................20
14. Архитектура определяет производительность...................................................................21
15. Коммит без проверки - убийца производительности........................................................22
16. Однообразия может и не быть ..............................................................................................23
17. Бизнес управляет.....................................................................................................................24
18. Простота лучше универсальности........................................................................................25
19. Архитектор должен быть практиком...................................................................................26
20. Непрерывная интеграция.......................................................................................................28
21. Избегайте неудач планирования...........................................................................................29
22. Все сразу получить невозможно...........................................................................................30
23. База данных - ваша крепость.................................................................................................31
24. Используйте неопределенность как мотиватор .................................................................33
25. Расширение границ проекта – враг успеха .........................................................................34
26. Повторное использование – это, прежде всего, люди.......................................................36
27. В слове "Архитектура" нет буквы "Я".................................................................................38
28. Вид с высоты 300 метров.......................................................................................................40
29. Попробуйте альтернативы перед принятием решения .....................................................41
30. Знания предметной области ..................................................................................................42
31. Программирование - это процесс проектирования ...........................................................43
2
32. Время все меняет.....................................................................................................................44

33. Дайте разработчикам свободу...............................................................................................45
34. Не старайтесь произвести эффект ........................................................................................46
35. Проблемы в зеркале больше, чем они кажутся ..................................................................47
36. Профессия архитектора ПО неофициальная. Ну и что?...................................................49
37. Архитектор, помни об этике!................................................................................................50
38. Любая система рано или поздно откажет ...........................................................................51
39. Контекст решает все ...............................................................................................................52
40. Производительность важна!..................................................................................................54
41. Проектирование пустого пространства ...............................................................................55
42. Язык профессионалов.............................................................................................................57
43. Будущее за разнообразием ....................................................................................................59
44. Гномы, эльфы, маги и короли ...............................................................................................61
45. Давайте учиться у архитекторов зданий .............................................................................62
46. Борьба с повторами.................................................................................................................64
47. Добро пожаловать в реальный мир!.....................................................................................65
48. Наблюдение вместо контроля...............................................................................................66
49. Знакомьтесь, архитектор Янус..............................................................................................68
50. Границы и интерфейсы ..........................................................................................................70
51. Проверяйте предположения, особенно собственные........................................................71
52. Фиксируйте обоснования.......................................................................................................72
53. Давайте разработчикам больше полномочий .....................................................................74
54. Данные - главное в системе...................................................................................................75
55. Система контроля версий - не только для кода, но и для данных ..................................77
56. Будьте осторожны с метафорами .........................................................................................78
57. Фокусируйтесь на техподдержке и сопровождении .........................................................79
58. Выберите любые два...............................................................................................................81
59. Предпочитайте принципы, аксиомы и аналогии вместо мнений и предпочтений ......82
60. Начинайте с "Шагающего скелета"......................................................................................83
61. Делитесь знаниями и опытом................................................................................................84
62. Простые решения для простых задач ..................................................................................85
63. Проектируйте только то, что сможете реализовать сами.................................................86
64. Возврат вложений ...................................................................................................................87
65. Устаревшая версия..................................................................................................................88
3
66. Единственное решение? Найдите еще одно!......................................................................89

67. Оценивайте влияние изменений ...........................................................................................90
68. Вам придется работать и с "железом" .................................................................................92
69. За "хаки" сейчас придется потом расплачиваться с процентами....................................93
70. Лучшее - враг хорошего.........................................................................................................94
71. Избегайте "Замечательных идей".........................................................................................95
72. Качественный контент создает успешные системы..........................................................96
73. Бизнес против архитектора....................................................................................................97
74. Проверьте, что сломается, если изменятся условия..........................................................98
75. Архитектор - прежде всего программист............................................................................99
76. Как вы яхту назовете... .........................................................................................................100
77. Стабильные задачи дают качественные решения............................................................101
78. Вам потребуется усердие.....................................................................................................103
79. Принимайте ответственность за решения.........................................................................104
80. Не спешите решать задачи...................................................................................................105
81. Выбирайте технологии тщательно, а расставайтесь с ними неохотно ........................106
82. Ваш заказчик - не ваш клиент.............................................................................................108
83. Так не будет никогда ............................................................................................................109
84. Выбирайте фреймворки, хорошо стыкующиеся с другими...........................................110
85. Сделайте экономическое обоснование..............................................................................111
86. Паттернопатология ...............................................................................................................112
87. Изучайте языки......................................................................................................................113
88. Не применяйте смекалку......................................................................................................115
89. Проектируйте системы, "прозрачные" в использовании................................................116
90. Ищете и удерживайте тех, кто умеет и любит решать проблемы.................................117
91. Программы не существуют в физическом мире ..............................................................118
92. Оплачивайте технический долг ..........................................................................................119
93. Не пытайтесь угадать будущее ...........................................................................................120
94. Проблема принятия проекта пользователями ..................................................................121
95. Архитектурный консоме......................................................................................................122
96. Система для пользователя - это ее интерфейс..................................................................123
97. Крупные проекты не строятся, а вырастают ....................................................................124
4
1. Ваше резюме не должно быть на первом месте

(В оригинале – Don't put your resume ahead of the requirements)
Инженеры иногда отдают предпочтения тем или иным технологиям, методологиям или
вариантам решения задач лишь потому, что им бы хотелось видеть это у себя в резюме, а не
потому, что это – лучший вариант для решения поставленных задач. И такой подход очень
редко приводит к успеху.
Лучшее, что может быть в вашей карьере – это длинный список ваших клиентов, горящих
желанием порекомендовать вас еще кому-нибудь, потому что вы всегда делали правильные
вещи для них и для их проектов. Эта расположенность к вам будет приносить вам важные
проекты гораздо эффективнее, чем самый новый язык программирования или самая
инновационная парадигма. И хотя на самом деле важно оставаться в курсе последних
инноваций, это никогда не должно осуществляться за счет ваших клиентов. Главное –
помните о возложенных на вас обязанностях. Организация оказывает вам доверие, назначая
на должность проектировщика систем, и ожидает, что вы будете стараться избегать
конфликтов интересов и сохранять лояльность компании. Если же проект недостаточно
интересен для вас с точки зрения вашего развития, то лучше поищите другой.
Если же вы не можете выбрать другой проект, и вам приходится участвовать в проекте,

неинтересном для вас, то все равно и вы, и все остальные будут гораздо более
удовлетворены, если будут применяться технологии, реально необходимые клиенту вместо
тех, которые способны украсить резюме. Всегда сложно противиться внедрению новых и
крутых технологий, даже если они вообще никаким образом не подходят для текущей
ситуации.
Правильное же решение приведет к тому, что на проекте будет работать более довольная
команда, а более довольный клиент получит именно то, что ему нужно, и в целом на
проекте будет значительно меньше стресса. Часто это позволит вам потратить больше
времени на доскональное изучение применяемых технологий, или же изучить новые веяния
в свое свободное время. Или же наконец-то пойти на курсы по рисованию, на которые вы
собираетесь пойти уже который год. И конечно же, это оценит и ваша семья – то, что вы
будете приходить домой совсем другим.
Не смотря ни на что, всегда ставьте долгосрочные цели ваших клиентов на первое место, и
вы не ошибетесь.
Автор оригинала: Nitin Borwankar
5
2. Сложное - упрощайте, с усложнением - боритесь!

(В оригинале – Simplify essential complexity; diminish accidental complexity)
Сложность – основное свойство большинства задач. Например, управление воздушным

трафиком – задача сложная. Точные координаты каждого самолета, включая высоту,
скорость, направление и конечную цель должны отслеживаться в реальном времени для
предотвращения столкновений в воздухе или на взлетно-посадочной полосе. Расписание
самолетов должно составляться так, чтобы избежать перегрузки аэропортов в условиях
постоянно меняющегося окружения – серьезные погодные изменения способны полностью
нарушить расписание.
Усложнение же, в отличие от сложности, часто является результатом того, что мы пытаемся
построить систему, решающую сложную задачу. Архаичная система управления
воздушным трафиком, до сих пор использующаяся, является таким примером усложнения.
Эта система разрабатывалась для решения реально сложной задачи управления воздушным
потоком из тысяч самолетов, однако и сама система дополнительно привнесла еще и своей
собственной сложности. Фактически, используемая сегодня система столь сложна, что ее
модернизация уже практически невозможна. В результате во всем мире управление
воздушным трафиком основано на технологиях, которым уже более тридцати лет!
Большинство фреймворков и «решений» от вендоров являются симптомами болезни

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

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

коде, а не сошедшим с академических высот. Обращайте внимание на процент кода,
относящегося непосредственно к вашей бизнес-задаче, по сравнению с процентом кода,
относящемуся лишь к интерфейсу. С особой осторожностью относитесь к решениям от
вендоров. Иногда они не такие уж и плохие, но часто излишне переусложнены. Убедитесь,
что решение соответствует решаемой задаче.
Решение реально сложных задач без излишнего усложнения и является основной задачей
проектировщика.
Автор оригинала: Neal Ford
6
3. Скорее всего, ваша главная проблема - не техническая

(В оригинале – Chances are your biggest problem isn't technical)
Прямо сейчас чей-то проект стремительно катится к полному провалу. Возможно даже, что
и не один.
А почему? Может быть, потому что кто-то выбрал Ruby вместо Java? Или может быть
Python вместо SmallTalk? Или же потому, что было принято решение использовать Postgres
вместо Oracle? Или же вместо Windows надо было выбирать Linux? Все мы так или иначе
сталкивались с технологиями, якобы приведшими проект к провалу. Но каковы на самом
деле шансы того, что задача реально будет столь сложной, что ее невозможно будет решить,
используя Java?
Практически все проекты делаются людьми. И именно эти люди – главная составляющая
успеха или провала. И поэтому стоит подумать над тем, что можно предпринять, чтобы
сделать этих людей успешными.
С высокой долей вероятности на вашем проекте найдется кто-то, кто, как вам кажется,
«делает все не так» и тем самым расшатывает весь проект. И если это так, то технология,
необходимая вам для решения, на самом деле стара как мир. Возможно, эта технология –
самая главная инновация во всей истории человечества. Эта технология называется
"ведение переговоров".
Недооценивать технологию ведения переговоров не стоит. Учиться вести переговоры

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

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

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

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

обучиться чему-то новому и контролируете ваши эмоции, вы не только станете более
эффективным, вы также откроете для себя то, что вы каждый раз узнаете что-то новое.
Автор оригинала: Mark Ramm
8
4. Коммуникация - это король, а ясность и лидерство - его

покорные слуги
(В оригинале – Communication is King; Clarity and Leadership its humble servants)
Слишком часто архитекторы программного обеспечения принимают решения со своих

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

комнате с доской и маркерами. Это один из лучших способов для обсуждения – пригласить
в комнату группу разработчиков (или других архитекторов) и нарисовать все ваши идеи на
доске. При этом имейте под рукой цифровой фотоаппарат. Оставить только на доске
результаты долгого и эффективного обсуждения – не самая лучшая идея. Сфотографируйте
то, что получилось, а фотографию разошлите всей команде. Забудьте о многостраничных
вордовских документах и сфокусируйтесь на обсуждении ваших идей, и лишь после этого
начинайте работать над деталями ваших архитектурных решений.
Еще одна вещь, которую архитекторы программного обеспечения часто не осознают – это
то, что проектировать архитектуру также означает быть лидером. Вы должны добиться
уважения ваших коллег, чтобы эффективно работать в здоровом коллективе. Скрывать от
разработчиков полную картину или не объяснять принятые решения – верный путь к
провалу. Если же разработчики на вашей стороне, то тем самым ваши архитектурные
решения получают поддержку и с их стороны тоже. В свою очередь, вы идете навстречу
разработчикам, посвящая их в тонкости разработки архитектуры. Работайте вместе с
разработчиками, а не против них. Помните, что вся команда (тестеры, аналитики,
менеджеры проекта и разработчики) требуют ясности и лидерства. Совершенствование этих
навыков поможет построить здоровое рабочее окружение.
И если коммуникация – это король, то ясность и лидерство – его покорные слуги.
Автор оригинала: Mark Richards
9
5. Баланс между техническими требованиями и

интересами участников
(В оригинале – Balance stakeholders' interests with technical requirements)
Когда мы говорим о проектировании программного обеспечения, нам прежде всего

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

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

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

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

техническая работа, а и нахождение баланса между техническими требованиями и бизнес-
интересами вовлеченных в проект сторон.
Автор оригинала: Randy Stafford
10
6. Ищите настоящую причину требований

(В оригинале – Seek the value in requested capabilities)
Часто заказчики в качестве требований к проекту выдвигают то, что, как им кажется,
является жизнеспособным решением их проблемы. В качестве примера, ставшего
классическим, можно привести историю, которую рассказал Harry Hillaker, ведущий
разработчик самолета F-16 Falcon. Их команде было поручено разработать самолет,
летающий со скоростью, в 2-2.5 раз выше скорости звука. Тогда, а возможно, и сейчас, это
весьма нетривиальная задача, особенно если при этом требуется построить дешевый и
легкий самолет. Вы же, наверное, помните, что аэродинамическое сопротивление
увеличивается в четыре раза при увеличении скорости в два, и понимаете, как этот факт
влияет на вес самолета.
Когда же команда разработчиков спросила военных, зачем им нужна скорость в два с

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

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

«Сотрудничество важнее контракта». На практике это подразумевает организацию
семинаров и митингов, на которых архитекторы концентрируются на проблемах заказчиков,
помогая им ответить на вопросы «Для чего? Почему? Зачем?». Имейте в виду, что ответить
на эти вопросы заказчику может быть нелегко, потому что часто разговор будет идти о
нечетких, не до конца ясных и сформулированных знаниях и мыслях. Обсуждений
технических решений и деталей лучше при этом избегать, поскольку они будут переводить
дискуссию из домена знаний заказчика в домен знаний разработки.
Автор оригинала: Einar Landre
11
7. Встаньте!
(В оригинале – Stand Up!)
Часто проектировщики ПО вырастают из высокотехнологичных позиций, на которых успех

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

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

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

другие элементы языка тела. В выступлении перед группой более чем из десяти людей вам
проще поддерживать контакт глазами со всеми, если вы стоите. Невербальный язык тела,
контакт глазами и другие визуальные элементы вносят ощутимый вклад в процесс общения.
Когда вы говорите стоя, также меняется тон вашего голоса, громкость, плавность и
скорость, появляются паузы в важных местах. И эти элементы также серьезно повышают
эффективность коммуникации.
Самый легкий способ как минимум удвоить эффективность в процессе «продажи» ваших
идей – это просто стоять во время выступления.
Автор оригинала - Udi Dahan.
12
8. Небоскребы не масштабируются!
(В оригинале – Skyscrapers aren't scalable)
Программистов часто сравнивают со строителями небоскребов, плотин или дорог. И в

некоторых аспектах это сравнение вполне адекватное.
Самое сложное в работе строителей городской инфраструктуры – это не спроектировать

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

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

в коде ошибками. Выпуская продукт покомпонентно, мы распределяем этот риск на
длинный промежуток времени. Если релиз очередного компонента закончится неудачей, мы
сможем сконцентрировать на этом все усилия.
Второй плюс заключается в том, что при таком подходе мы вынуждены создавать гораздо
более продуманный интерфейс между компонентами. Выпуск лишь одного компонента
новой системы практически всегда означает необходимость его интеграции в старую
систему. При этом к концу разработки каждый компонент будет протестирован в двух
различных системах – старой и новой. Повторное использование начинается лишь при
первом повторном использовании :) и разработка по частям автоматически повышает
пригодность к повторному использованию. На практике это к тому же часто приводит к
лучшей когерентности и менее сильной связности.
При этом некоторые ключевые для строительства домов методологии, будучи перенесены
на программирование, будут сбивать нас с пути. Например, незыблемость материального
мира естественным образом подталкивает к применению водопадной модели разработки.
Ведь никто не начинает строить небоскреб без знания о том, где он будет построен и
сколько у него будет этажей. Добавить еще пару этажей к уже построенному зданию будет
слишком дорого и рискованно, поэтому этого избегают всеми возможными способами.
Будучи однажды спроектированным и построенным, небоскреб не предполагает
последующего изменения своего местоположения или высоты. Небоскребы не
масштабируются.
Мы не можем легко добавить полос к построенной дороге, однако все мы знаем, насколько
легко можно добавить функциональность в написанную программу. И это не дефект
13
процесса разработки, а свойство того мира, в котором мы работаем. Выпустить приложение,

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

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

продукта, и лучшее качество проектирования, однако ранний релиз отдельных компонент
обеспечивает и то, и другое.
Автор оригинала: Michael Nygard
14
9. Вы участвуете в переговорах чаще, чем вы думаете

(В оригинале – You're negotiating more often than you think)
Все мы рано или поздно сталкиваемся с ограничениями бюджета. Когда решение о том,
какую технологию использовать, принимается под давлением о необходимости снижения
расходов. Диалог при этом часто выглядит как-то так.
«Нам действительно нужна функциональность Х?» - задает вопрос инвестор.
Под «Х» может пониматься любая жизненно необходимая для проекта вещь: лицензии на
ПО, резервные сервера, удаленное архивирование или источники бесперебойного питания.
Вопрос этот обычно задается в снисходительном тоне, как будто бы взрослый уличил
ребенка в том, что он растратил все свои карманные деньги на комиксы и жвачки.
Правильный ответ на подобный вопрос: «Да, действительно нужна». Ответ, который дается
крайне редко.
В конце концов, мы инженеры, а инженеры всегда готовы искать компромиссы. Все мы

хорошо знаем, что такое расточительство, как источники бесперебойного питания на самом
деле не столь и нужны, а в крайнем случае можно нанять студентов и посадить их крутить
педали в серверной. Поэтому вместо «Да, действительно нужна» мы часто говорим что-то
вроде «Ну... в принципе можно обойтись без резервного сервера, если вас устроит то, что
система будет в оффлайне во время сервисных работ и в случае аппаратных сбоев, но если
использовать память с поддержкой коррекции ошибок, то этих сбоев можно будет избежать,
и останутся только глюки Windows, случающиеся где-то раз в три дня, и значит, нужно
будет делать профилактический ресет каждую ночь, это как раз могут делать студенты в
перерыве между кручением педалей...»
Все это может быть правдой, но к сожалению дать такой ответ будет в корне неправильно.
Инвестор перестанет вас слушать сразу после слова «Ну...».
Проблема в том, что вы по-прежнему видите себя в роли инженера, в то время как инвестор
на 100% уверен, что он обсуждает условия. Вы ищете решение, которое бы всех устроило, а
он ищет выигрышный вариант для себя (и скорее всего, проигрышный для вас), или же,
говоря простым языком, торгуется. А в обсуждении условий ни в коем случае нельзя
соглашаться на первый предложенный вариант. На самом деле, правильный ответ на «А нам
действительно это надо?» должен быть примерно вот таким.
«Без резервного сервера вся система будет падать минимум трижды в день, практически
всегда в моменты максимальной нагрузки, или же когда вы будете что-то демонстрировать
совету директоров. На самом деле нам даже нужно четыре сервера, тогда мы сможем
сделать две резервных пары и гарантировать работоспособность системы в полном объеме,
даже если выйдут из строя сразу два сервера».
15
Конечно, вы понимаете, что на самом деле вам не нужны четыре сервера. Это такой прием в
переговорах, чтобы дать возможность инвестору сменить тему. Вы повышаете стоимость,
показывая, что вы и так уже находитесь на самой границе, на самом минимуме все еще
приемлемой конфигурации. И если вы вдруг в результате таки получите четыре сервера
вместо двух, то вы всегда сможете на одном из лишних серверов развернуть копию системы
для тестирования, а второй использовать для нужд разработки.
Автор оригинала: Michael Nygard
16
10. Количество имеет значение!

(В оригинале – Quantify)
Требование «Быстро» фактически требованием не является. Как и не является требованием

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

неопределенные прилагательные как «гибкий», «легко поддерживаемый» и им подобные. И
в большинстве таких случаев можно задать некий исчисляемый критерий и определить
границы. И если этого не сделать, то у вас не будет основы для критерия сдачи работы
заказчику, у разработчиков не будет мотивации для работы, а у архитекторов – четкого
видения.
Несколько простых вопросов могут это прояснить. Сколько? За какой период? Как часто? К
какому сроку? С какой частотой? Если на эти вопросы не будет ответов, то значит, что
потребность клиента не сформулирована. Ответы должны быть на языке бизнеса,
использующего систему, в противном случае надо очень хорошо подумать. Если вы
проектируете систему и ваш заказчик не хочет или не может назвать вам эти цифры, задайте
себе вопрос «Почему?». А потом все же получите эти ответы. И если в следующий раз вам
скажут, что система должна быть «масштабируемой», спросите, откуда появятся новые
пользователи, сколько их будет, и как часто это будет происходить. И не принимайте
ответы «Много» и «Часто».
Если критерий нечеткий, то практически всегда его можно описать диапазоном: ожидаемое
значение, минимум, максимум. Если такой диапазон задать не получается, то значит,
требуемое поведение недостаточно продумано. После того, как диапазон задан, в процессе
детализации архитектуры можно повторно проверять, находимся ли мы все еще в заданных
рамках или уже нет. Нахождение таких диапазонов и их проверка являются достаточно
затратными операциями. И если никто не захочет тратить ресурсы на это, значит, скорее
всего, данный критерий вообще не важен. И вы спокойно можете переключиться на то, что
действительно важно.
«Система должна давать ответ пользователю не позднее чем через 1500 миллисекунд после
ввода. Во время нормальной загрузки (определяемой как...) среднее время ответа должно
быть в диапазоне от 750 до 1250 миллисекунд. Для времен менее 500 миллисекунд
пользователь уже не заметит особой разницы, поэтому тратить ресурс на снижение времени
ниже этой границы мы не будем» - вот теперь это требование!
Автор оригинала: Keith Braithwaite
17
11. Строка работающего кода ценнее, чем 500 строк

спецификации
(В оригинале – One line of working code is worth 500 of specification)
Проектирование – замечательная вещь. Подробный и систематический анализ исходных

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

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

тратите на написание кода. Не верьте тем, кто будет говорить, что это лишь отвлекает вас от
проектирования. Ваше видение как макро, так и микро уровня очень сильно улучшится,
если вы часть времени потратите на воплощение идей в жизнь.
Автор оригинала: Allison Randal
18
12. Универсальных решений не существует!

(В оригинале – There is no one-size-fits-all solution)
Проектировщику необходимо постоянно развивать и тренировать то, что можно назвать как
«контекстно-зависимый здравый смысл», потому что единого решения, подходящего для
всех случаев, просто не существует.
Словосочетание «контекстно-зависимый здравый смысл» (В оригинале – “contextual sense”)

было введено в оборот в книге Eberhardt Rechtin “Systems Architecting: Creating & Building
Complex Systems”:
«[Центральная идея «эвристического подхода» в проектировании сложных систем] состоит

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

неудача в попытках применить принципы Domain-Driven Design, когда это нужно, отход от
прагматического видения, переусложненные программные решения, а также неуместные и
необоснованные предположения при проведении оптимизации.
Самые важные знания о шаблонах проектирования – это знания о том, когда их нужно
применять, а когда нет. И то же самое верно и для других основополагающих гипотезах и
связанных с ними действиях во время анализа задачи. И в проектировании, и в анализе
является аксиомой то, что не существует универсального решения, подходящего на все
случаи жизни. Архитектор должен тренировать свое чувство контекстного здравого смысла,
решая поставленные перед ним задачи.
Автор оригинала - Randy Stafford
19
13. Никогда не рано задуматься о производительности

(В оригинале – It's never too early to think about performance)
Когда клиенты формулируют свои требования, в основном они затрагивают лишь те,
которые относятся к непосредственной функциональности системы. Нефункциональные же
аспекты, такие как производительность, гибкость, время старта, необходимость
техподдержки и прочее, остаются на усмотрение архитектора. Однако, очень часто первое
тестирование нефункциональных требований отодвигается до самого последнего момента
цикла разработки. Это ошибка, встречающаяся слишком часто.
Причины этого могут быть различными. Возможно, иногда нет смысла делать что-то
быстрым и гибким, если оно при этом не будет выполнять основные требуемые функции.
Тестирование может быть очень сложным. Возможно, первые версии системы не будут
работать под максимальной загрузкой.
Однако, если вы не обращаете внимание на производительность вплоть до конца проекта,

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

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

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

(В оригинале – Application architecture determines application performance)
Архитектура приложения определяет его производительность. Это утверждение кажется

очень простым и очевидным, однако мировая практика показывает, что это не так.
Например, проектировщики ПО часто верят в то, что для значительного прироста
производительности достаточно простого перехода от одного бренда производителя к
другому. Эта вера может быть вызвана разрекламированными результатами измерения
производительности от вендора, обещающими, к примеру, на 25% лучшую
производительность по сравнению с конкурентами. Но на самом деле, если к примеру
продукт данного вендора выполняет одну операцию за 3 миллисекунды, а продукт
конкурента – за 4 миллисекунды, то этот 25% выигрыш производительности (1
миллисекунда!) окажет очень несущественное влияние на конечную производительность
всей системы, особенно если в проблемы производительности находятся в корне
архитектуры системы.
В дополнение к руководителям ИТ и командам измерения производительности различных

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

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

(В оригинале – Commit-and-run is a crime)
Вторая половина дня. Команда дописывает последние фрагменты новой функциональности

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

потому что убивает поток. Очень часто один разработчик, желая сэкономить свое время,
вызывает потерю времени всей команды, и это весьма неучтиво. Однако, это происходит
практически везде. Почему? Обычно потому, что правильный цикл сборки и тестирования
занимает слишком много времени.
И здесь вам, как архитектору, нужно вступать в игру. Если вы постараетесь создать гибкую
архитектуру, обучите людей agile-практикам, к примеру, разработке через тестирование,
настроите интеграционный сервер, то тем самым вы воспитаете культуру, в которой не
будет правильным тратить чье-либо время впустую. Чтобы это стало реальным, вы должны
быть уверены, что система, кроме всего прочего, имеет подходящую для
автоматизированного тестирования архитектуру. Это изменит поведение разработчиков.
Если тесты будут выполняться быстро, то их будут запускать чаще, что хорошо уже само по
себе, однако главное – это то, что разработчики не будут оставаться наедине с испорченным
кодом. Если тесты зависят от внешних систем, если требуется база данных, то измените их
так, чтобы их можно было запускать локально с использованием симуляторов или заглушек,
или хотя бы с использованием локальной копии базы данных, и пусть тесты выполняются
автоматически. Люди не должны ждать, потому что в противном случае они будут
придумывать обходные пути, что часто приводит к описанным выше проблемам.
Инвестируйте время в создание систем, которые будут работать быстро. Это ускоряет весь
поток, делая разработку более быстрой. Используйте симуляторы, уменьшайте зависимости,
разбивайте систему на маленькие модули – делайте то, что считаете нужным. Главное –
обеспечьте, чтобы у людей не было причин даже думать о том, чтобы сделать коммит без
проверки.
Автор оригинала - Niclas Nilsson
22
16. Однообразия может и не быть

(В оригинале – There Can be More than One)
Кажется, что архитекторов никогда не перестанет удивлять тот факт, что не существует
единственной модели, единственного формата данных, единственного протокола передачи
– фактически, любого крупного архитектурного компонента, политики или положения,
способных полностью подойти для любой ситуации в бизнесе. Конечно же, для достаточно
крупного энтерпрайза, которому нужно беспокоиться о том, сколько различных таблиц
“Account” понадобится в следующей декаде, одной таблицы “Account” для всего будет
недостаточно.
В технических областях мы все можем привести к одинаковости. Для нас – очень удобно.
Однако бизнес имеет дело с неупорядоченным, множественным, запутанным и
неопределенным миром. Более того, бизнес имеет дело даже не с «миром», а с мнениями
людей о том или ином аспекте этого мира. Одно из решений – считать, что мы имеем дело с
технической областью, и принудительно применить универсальное решение. Однако
реальность – такая штука, которая продолжает существовать, даже если вы не верите в нее.
И сложность все равно появляется по мере эволюции бизнеса. В результате появляются
энтерпрайз команды, тратящие свое очень недешевое время на попытки побороть страхи
разговорами о DTD. А заказчики, оплачивающие это, склоняются в результате к тому, что
получаемый результат далек от совершенства.
Почему же не принять реальность этого беспорядочного мира и не разрешить

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

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

(В оригинале – Business Drives)
В контексте разработки бизнес-приложений проектировщик должен быть связывающим

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

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

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

заказчик.
Автор оригинала - Dave Muirhead.
24
18. Простота лучше универсальности

(В оригинале – Simplicity before generality, use before reuse)
Общая проблема различных компонент, библиотек классов, базовых сервисов и других

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

склонит чашу весов при прочих равных условиях. Если у вас есть два возможных решения,
выберите простое, решающее только требуемые задачи, вместо запутанного и обещающего
универсальность. Скорее всего, более простое решение окажется достаточно
универсальным на практике. И если даже в результате окажется, что таки нужно
использовать более универсальное решение, то поменять простое решение на более
сложное, понимая, зачем и почему это надо, будет намного проще, чем обнаружить, что
универсальное решение оказалось недостаточно универсальным в нужном вам контексте.
Также часто случается, что разработанное решение «для всего сразу» в реальности
оказывается не пригодным «ни для чего конкретного». Компоненты ПО должны в первую
очередь разрабатываться для конкретных целей и удовлетворять именно эти цели.
Эффективная универсализация следует лишь из глубокого понимания, которое в свою
очередь, приводит к упрощению. Такая универсализация может позволить упростить задачу
до более базовой, основываясь на анализе известных примеров и выделении общих для них
концепций. Универсальность, которая четко выражена, лаконична и обоснована. Однако
часто универсализация становится вещью в себе, уводя проект в противоположном
направлении и добавляя сложность вместо ее уменьшения. Погоня за таким обобщением
часто приводит к решениям, никак не привязанным к реальности разработки. Такое
обобщение оказывается основанным на предположении, которое позже оказывается
неверным, предлагает варианты, которые никогда не понадобятся, накапливает «багаж»,
который невозможно выбросить, и таким образом добавляет излишнюю усложненность, с
которой приходится иметь дело будущим разработчикам и архитекторам.
И хотя многие архитекторы ценят универсальность, она не должна быть безусловной. Люди
не хотят платить за универсальность, они хотят получить решение для их уникальной
ситуации. Мы можем найти некоторую универсальность и гибкость в процессе разработки
конкретного решения, но если мы слишком увлечемся и забудем о реальных требованиях,
то мы очень быстро окажемся среди не слишком ясных возможностей, переусложненных
опций конфигурации, чересчур перегруженными списками параметров, неоправданно
сложными интерфейсами и неактуальными абстракциями. В погоне за ненужной гибкостью
вы можете потерять ценные аспекты альтернативного, более простого решения.
Автор оригинала - Kevlin Henney
25
19. Архитектор должен быть практиком

(В оригинале – Architects must be hands on)
Хороший архитектор должен быть практиком. Он должен быть способным занять любую
позицию в команде, начиная от прокладки сети и конфигурации процесса сборки до
написания юнит-тестов и измерения производительности. Без глубокого понимания всего
диапазона технологий архитектор ничем не отличается от обычного менеджера проекта.
Конечно же, люди в команде могут иметь более глубокие знания тех или иных технологий в
своих областях, но при этом очень сложно представить, как они смогут доверять
архитектору, если он вообще не разбирается в технологии. Как уже было сказано,
архитектор – это интерфейс между бизнесом и разработкой, и поэтому он должен понимать
все аспекты разработки, чтобы адекватно представить все возможности для заказчика, не
прибегая к постоянным консультациям остальных. Аналогично, архитектор должен
понимать язык заказчика, чтобы вести команду к целям, поставленным заказчиком.
Архитектор – как первый пилот самолета. Он может не выглядеть слишком занятым

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

например, IDE. Логично ожидать, что проектировщик ПО должен знать IDE,
проектировщик баз данных – средства моделирования баз данных, а информационный
проектировщик – инструменты XML. Однако технический архитектор должен знать хотя бы
минимально все инструменты от мониторинга сети (Wireshark) до моделирования сложных
финансовых сообщений (XMLSpy) – ни один уровень тут не будет ни слишком высоким, ни
слишком низким.
26
Проектировщик обычно приходит с отличным резюме и впечатляющим прошлым, он даже

может впечатлить заказчика, но пока он не покажет себя реальным практиком, ему будет
сложно завоевать уважение команды, команде будет сложно учиться на его примере, и всем
будет практически невозможно выпустить тот продукт, для выпуска которого они и были
наняты.
Автор оригинала - John Davies
27
20. Непрерывная интеграция

(В оригинале – Continuously Integrate)
Разработка по методу «Большого взрыва» способна убить практически любой проект.

Проектировщик должен инициировать и поддерживать использование методов и
инструментов непрерывной интеграции для любого проекта.
Термин «Непрерывная интеграция» (Continuous Integration) впервые был введен в

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

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

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

эффективности. Как архитектор вы несомненно полюбите этот процесс, но более важно то,
что ваша организация и ваша команда разработки станут более эффективными.
Автор оригинала - Dave Bartlett
28
21. Избегайте неудач планирования

(В оригинале – Avoid Scheduling Failures)
Проект может закончиться неудачей по множеству причин. Одна из наиболее частых

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

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

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

немедленного вашего вмешательства, чтобы повысить вероятность успешного завершения.
Действуйте сразу и быстро. В первую очередь попытайтесь сохранить качество, отстаивая
первоначальные сроки. Если же сокращения сроков избежать не удается, тогда пытайтесь
перенести некритичную функциональность в следующий релиз. Обычно для этого
требуется хорошая предварительная подготовка, мастерство ведения переговоров и умение
влиять на людей. Готовьтесь к этому, заранее оттачивая эти умения, начинайте прямо
сейчас. Когда-нибудь вы это очень сильно оцените.
Автор оригинала - Norman Carnovale
29
22. Все сразу получить невозможно

(В оригинале – Architectural Tradeoffs)
Каждый проектировщик ПО должен понимать, что невозможно сделать все и сразу.

Невозможно разработать архитектуру, которая была бы высокопроизводительной,
стабильной, безопасной и с высокой степенью абстракции на всех уровнях. Есть один
реальный пример, знать который рекомендуется каждому архитектору. Это история корабля
Васа.
В 1620-м году шла война между Швецией и Польшей. Желая побыстрее завершить эту
разорительную войну, шведский король начал строительство корабля, названного Васа. Это
должен был быть не простой корабль. Требования к нему были уникальными для того
времени. Он должен был быть более 60 метров в длину, нести 64 пушки на двух оружейных
палубах, и иметь возможность перевозить 300 солдат на борту. Сроки были критичны, денег
было мало (звучит знакомо, не так ли? :) Дизайнер корабля никогда до этого не
проектировал корабли такого класса. Он был экспертом в постройке кораблей меньшего
класса, однопалубных. Тем не менее, он экстраполировал свой предыдущий опыт и
спроектировал Васа. Корабль был успешно построен по его спецификациям, и в день
запуска корабль гордо вышел в гавань, отсалютовал из своих пушек и практически сразу же
затонул.
Проблема корабля оказалась тривиальной – палуба боевых кораблей тех лет была обычно
тесным и опасным местом, особенно в бою. Постройка же корабля, одновременно
являющегося и боевым, и транспортным, оказалась дорогой ошибкой. Архитектор, желая
удовлетворить желания короля, построил слишком неустойчивый корабль.
Попытка удовлетворить все требования может привести к нестабильной архитектуре и как

следствие, неудовлетворительной реализации всех требований. Хорошим примером может
быть требование создать серверную архитектуру, хорошо работающую и для случаев
«точка-точка». Чтобы сделать такое, вам придется серьезно нарушать уровни абстракций,
созданные для серверной версии, приводя к тому, что архитектура становится похожей на
одно из блюд итальянского ресторана. Существует несколько инструментов, позволяющих
определить и выявить альтернативы при разработке архитектуры. Две популярные
методологии, делающие это - Architecture Tradeoff Analysis Method (ATAM) и Cost Benefit
Analysis Method (CBAM). Подробнее про эти методологии можно почитать на сайте
Software Engineering Institute здесь и здесь.
Автор оригинала - Mark Richards
30
23. База данных - ваша крепость

(В оригинале – Database as a Fortress)
База данных – это то место, где находятся все данные, как внесенные вашими
сотрудниками, так и полученные от ваших заказчиков. Пользовательский интерфейс,
бизнес-логика, логика приложения и даже ваши сотрудники могут меняться, но данные
будут всегда. И поэтому нельзя переоценить важность построения целостной модели
данных с самого начала.
Распространенность agile технологий разработки сделало массовой мысль о том, что

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

структуры данных и связи между ними этого не делают. Поэтому очень важно иметь
правильную модель данных с самого начала, как со структурной точки зрения, так и с
аналитической. Миграция с одной схемы на другую в лучшем случае – сложная задача,
всегда требующая много времени и часто склонная к внесению ошибок. Если с ошибками
на уровне приложения некоторое время вполне можно жить, то ошибки на уровне базы
данных могут стать катастрофой. Обнаружение и исправление проблемы дизайна на уровне
базы данных не вернет вам потерянных или поврежденных данных назад.
Целостная модель данных – это то, что обеспечивает вам сохранность данных сегодня и
расширяемость завтра. Обеспечение сохранности подразумевает устойчивость к ошибкам,
которые, несмотря на все ваши усилия, будут возникать в часто меняющемся уровне
приложения. Это означает обеспечение ссылочной целостности. А также построение
доменозависимых правил и ограничений везде, где это возможно. Это означает выбор
ключей, помогающих вам убедиться в ссылочной целостности и соответствии
установленным правилам. Быть готовым к расширению завтра означает правильным
образом нормализовать данные, чтобы потом легко надстраивать уровни над моделью
данных. Это означает не искать коротких путей.
База данных должна быть последним привратником, охраняющим ваши ценные данные.
Приложение, могущее меняться ежедневно, не может быть сторожем даже для самого себя.
Чтобы база данных могла играть эту роль, модель данных должна быть спроектирована так,
чтобы не принимать изначально неправильные данные и предотвращать не имеющие
смысла отношения. Ключи, внешние отношения, правила и ограничения, описывающие
схему – это лаконичные, понятные и легко проверяемые вещи, к тому же отлично
самодокументируемые. Правила, задающие модель данных, к тому же достаточно
стабильные, и изменения уровня приложений часто оставляет их без изменений.
31
Чтобы использовать возможности реляционной базы данных на все сто – сделать ее

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

(В оригинале – Use uncertainty as a driver)
Оказавшись перед выбором из двух альтернатив, большинство думает, что главное – это
сделать правильный выбор между ними. В проектировании (ПО и не только) это не так.
Наличие двух возможностей – индикатор того, что вам нужно подумать о внесении
неопределенности в дизайн. Используйте неопределенность как повод определить, где вы
можете отложить принятие решения, или где вы можете снизить значимость этого выбора.
Если вы привяжете себя к первому пришедшему в голову варианту, скорее всего, поменять
его потом будет сложно, в результате случайный выбор станет значимым и гибкость
продукта снизится.
Одно из самых простых и конструктивных определений архитектуры дал Гради Буч: «Вся
архитектура – это дизайн, но весь дизайн – это не архитектура. Архитектура представляет
значимые решения дизайна, формирующие систему, где значимость измеряется стоимостью
изменения». Что из этого следует – это то, что эффективная архитектура должна снижать
значимость решений. Неэффективная же архитектура значимость усиливает.
Когда решение в дизайне может развиваться двумя путями, архитектор должен сделать шаг
назад. Вместо выбора альтернативы между А и В нужно задать себе другой вопрос: «Как
сделать дизайн таким, чтобы выбор между А и В был менее значимым?». Самое интересное
– не выбор между А и В, а само наличие такого выбора (и кстати, сам выбор далеко не
всегда будет окончательным).
Архитектор должен пройти огонь и воду, чтобы научиться легко видеть дихотомию.
Стояние у доски и энергичное обсуждение вариантов с коллегами? Пыхтение над кодом и
размышление, попробовать ту или эту реализацию? Когда новое требование или уточнение
старого перечеркивает текущую реализацию, это проявление неопределенности. Ответ на
это – найти такую инкапсуляцию, которая могла бы изолировать решение от кода, сильно
зависящего от этого решения. Без этого умения видеть ответ часто заключается во внесении
хаотичных изменений в код и попытках компенсировать неопределенность
множественными универсальными опциями. Или же, если решение принимается случайно,
результатом может оказаться поворот в неправильном направлении.
Часто требуется принимать решения ради решений. В таких случаях может помочь
подумать о возможностях. Там, где есть неопределенность, каким путем идти разработке,
примите решение не принимать решения. Откладывайте решение до тех пор, пока оно не
сможет быть принято более ответственно, на основании актуальных знаний, но при этом это
не должно быть уже слишком поздно, чтобы суметь использовать преимущества этих
знаний.
Архитектура и процесс тесно переплетены, что является причиной выбрать такие

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

(В оригинале – Scope is the enemy of success)
Границы проекта определяют его размер. Сколько времени, усилий и ресурсов потребуется?
Какая функциональность и какого уровня качества? Насколько сложно это будет внедрить?
Какой риск? Какие ограничения? Ответы на эти вопросы и определяют границы проекта.
Проектировщикам нравятся большие, сложные проекты. Потенциальная награда за
сложный проект может подталкивать людей искусственно раздвигать границы проекта для
повышения видимой важности. Раздвигание границ – враг проекта, потому что при этом
вероятность провала растет быстрее ожидаемого. Увеличение проекта вдвое может
повысить вероятность провала на порядок.
Почему это работает именно так? Давайте рассмотрим несколько примеров.
 Интуиция нам подсказывает удвоить время или ресурсы при удвоении объема
работы. История же говорит ("The Mythical Man-Month" by Fred Brooks), что
зависимость здесь нелинейная. К примеру, команда из четырех человек потратит
более чем в два раза времени на коммуникацию, чем команда из двух человек.
 Оценки оказываются далеки от реальности. Кто ни разу не сталкивался с вещами,
реализовать которые оказывалось значительно сложнее, чем ожидалось?
Конечно, некоторые проекты невозможно сделать без присущей для них определенной
сложности и размера. Сделать текстовый редактор без возможности ввода текста может
быть и легко, только результат не будет текстовым редактором. Какие же стратегии могут
помочь лучше контролировать границы реальных проектов?
 Понимание реальных потребностей. Проект должен содержать то, что перечислено

в требованиях. Требования определяют функциональность и ее качество. Если
требование не объяснено в терминах измеряемой ценности для заказчика, то это
повод задавать вопросы. Если требование не приносит заказчику прибыли, зачем оно
вообще нужно?
 Разделяй и властвуй. Ищите возможности разделить проект на несколько
независимых частей. Гораздо легче управлять несколькими маленькими проектами,
чем одним большим.
 Приоритет. Мир бизнеса изменчивый. Требования к большому проекту могут
поменяться несколько ко времени его окончания. Важные требования обычно
остаются важными и при изменении в мире бизнеса, а остальные могут измениться
или даже совсем исчезнуть. Приоритизация позволит вам выпустить наиболее
важные вещи в первом релизе.
 Выпуск результата как можно ранее. Очень мало людей точно знают, что именно
они хотят до того, как это получат. Наверняка вы видели известную картинку,
показывающую эволюцию проекта детских качелей, и помните разницу между тем,
что хотел заказчик, и что было сделано реально. Переусложненный результат
напоминал качели очень отдаленно, а последний кадр «что на самом деле хотел
заказчик» показывает самые простые качели из старой автомобильной шины. Если
заказчик получит возможность что-то попробовать, решение может оказаться сильно
34
проще первоначально ожидаемого. Реализация наиболее важных вещей в первую

очередь даст вам важную обратную связь раньше, когда она вам больше всего и
нужна.
Сторонники agile разработки ("eXtreme Programming eXplained" by Kent Beck) советуют

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

(В оригинале – Reuse is about people and education, not just architecture)
Вы можете думать, что отлично спроектированный фреймворк или хорошо продуманная и

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

2. Знают, как это использовать;
3. Уверены, что это лучше, чем если бы они это написали сами.
1. Знают о том, что это существует.
Внутри вашей организации разработчики или дизайнеры должны знать о том, что дизайн,
фреймворк, библиотека или фрагменты кода существуют, и где можно найти всю
необходимую информацию о них (документацию, версии, совместимость) чтобы это
повторно использовать. Очевидно, что люди не станут искать вещи, о существовании
которых они даже не подозревают. Гораздо больше шансов, что повторно используемые
вещи реально будут повторно использованы, если информация о них будет активно
продвигаться.
Есть много вариантов распространения этой информации. Это и wiki-страницы с

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

тренингов. Разумеется, есть люди, «резонирующие» с кодом и дизайном (по терминологии
Д. Кнута). Все мы сталкивались с такими людьми, которые схватывают все на лету. Но
такие люди – редкость. Остальных людей требуется обучать.
Разработчики и проектировщики могут не знать того или иного дизайн-паттерна, могут не

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

вместо того, чтобы попросить кого-то помочь. Вопрос о том, как что-то работает – знак
слабости или даже индикатор незнания. Конечно, тут многое зависит от конкретных личных
качеств людей в вашей команде, однако «лучше, чем сделать это самим» для разных людей
имеет очень разное значение. Молодые разработчики всегда хотят все писать с нуля, потому
что это удовлетворяет их эго, а более опытные могут предпочесть, чтобы кто-то другой
позаботился о решении проблем и предложил готовое решение.
И если ваша команда не знает, где лежат вещи, доступные для повторного использования,
или не знает, как конкретно их использовать, они будут поступать согласно естественной
своей человеческой природе. Они будут делать эти вещи с нуля. А вы будете за это платить.
Автор оригинала: Jeremy Meyer
37
27. В слове "Архитектура" нет буквы "Я".

(В оригинале – There is no 'I' in architecture)
В слове «архитектура» нет буквы «Я». И нет ее там потому, что так требуют правила
правописания.
Как это связано с архитектурой ПО? Очень просто. Наш главный враг – наше эго. Покажите
мне опытного архитектора ПО, который не делал таких вещей:
 думал, что он понимает требования лучше, чем заказчик;

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

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

любая архитектура, им удовлетворяющая, будет хорошей. Плотно работайте с
заказчиком, чтобы убедиться, что вы оба понимаете бизнес-ценности, стоящие за
требованиями к системе. Вы не задаете путь для архитектуры, это делают
требования. А вы по максимуму стараетесь им в этом помогать.
 Фокусируйтесь на команде. Ваша команда – это не только ресурс. Они тоже
вовлечены в дизайн и в создание вашей страховочной сетки. Люди, ощущающие себя
недооцененными, создают плохую страховочную сетку. Архитектура – работа всей
команды, не только вас. Вы даете направление, а все вместе участвуют в
затаскивании проекта на вершину успеха. Вам нужна их помощь, также как и им
нужна ваша.
38
 Проверяйте вашу работу. Модель – это еще не архитектура. Это лишь ваше
понимание того, как архитектура должна работать. Работайте вместе с командой,
чтобы определить тесты на соответствие архитектуры требованиям.
 Наблюдайте за собой. Большинство из нас склонны защищать результаты своей
работы, акцентироваться на личных интересах и считать себя самым умным в
комнате. Анализируйте свое поведение хотя бы несколько минут в день. Оказали ли
вы чьим-то идеям заслуженное уважение? Реагировали ли негативно без всякого
повода? Понимаете ли вы на самом деле, почему кто-то не согласен с вами?
Удаление буквы «Я» из слова «Архитектура» еще не гарантирует успеха, а лишь удаляет
самую частую причину провалов.
39
28. Вид с высоты 300 метров

(В оригинале – Get the 1000ft view)
Мы всегда хотим знать, насколько качественным является разрабатываемое нами ПО.

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

линии между ними могут значить что угодно: зависимость, поток данных или общий ресурс
типа шины. Эти диаграммы – вид с высоты 10 километров, как пейзаж из окна самолета. И
часто единственный другой вид – это исходный код, что можно сравнить с видом с высоты
1 метра над землей. Оба эти вида не показывают достаточно информации о качестве ПО,
один – слишком высокоуровневый, другой – слишком детальный. Нам требуется
промежуточный, скажем, метров с 300.
Вид с высоты 300 метров предоставит информацию как раз нужного уровня. Он объединяет
большие объемы данных и множество метрик, таких как количество функций, разветвление
структуры классов или цикломатическая сложность. Конкретный вид сильно зависит от
конкретных аспектов качества. Это может быть визуальное представление графа
зависимостей, диаграмма метрик на уровне классов или сложная множественная метрика,
зависящая от множества входных данных.
Создавать такие представления вручную и поддерживать их в актуальном состоянии –

безнадежно даже пытаться. Нужно использовать инструменты, автоматически строящие эти
метрики на основе реального исходного кода. Для некоторых отображений существуют
коммерческие программы, однако их легко можно строить и при помощи комбинации
небольших утилит, извлекающих метрики, вместе с пакетами для визуализации. Простой
пример – загрузить результат работы утилиты checkstyle в электронную таблицу для
построения диаграмм. Точно также можно визуализировать метрики в пакете InfoViz.
Отличная утилита для визуализации сложных графов связей – GraphViz.
Как только подходящий вид становится доступным, качество ПО становится чуть менее
субъективным. Становится возможно сравнивать его с аналогичным. Сравнение различных
версий позволит понять общую тенденцию, а сравнение различных подсистем – резкие
отличия или отклонения. Даже имея единственную диаграмму, мы уже можем понадеяться
на наше чувство прекрасного. Хорошо сбалансированное дерево, скорее всего, представляет
отличную иерархию классов, гармонический набор квадратиков может означать, что код
адекватно разбит по классам подходящего размера. В большинстве случаев можно доверять
правилу: «Если что-то хорошо выглядит, то, скорее всего, оно действительно хорошее».
Автор оригинала - Erik Doernenburg
40
29. Попробуйте альтернативы перед принятием решения

(В оригинале – Try before choosing)
Написание ПО предполагает принятие множества решений. Это, например, выбор

фреймворка или библиотеки, или же выбор конкретного паттерна проектирования. В любом
случае ответственность за принятие решения лежит на архитекторе. Классический
архитектор обычно старается собрать всю доступную информацию, «попереваривать» ее
некоторое время, и после этого принять решение со своих академических высот,
обязательное для выполнения разработчиками. Неудивительно, что существует путь
получше.
В своей работе, посвященной Lean разработке, Mary и Tom Poppendieck описывают технику
принятия решений. Они оспаривают подход, согласно которому нужно откладывать
принятие решений как можно дольше, до самого последнего момента, когда дальше
откладывать уже нельзя, когда в случае бездействия последствия будут необратимы. Это в
общем благоразумно с той точки зрения, что чем позже принимается решение, тем больше
доступно информации, на основе которой это решение и принимается. Однако часто больше
информации еще не означает достаточно информации, к тому же известно, что лучшие
решения основаны на прошлом опыте. Что же это значит для архитектора?
Архитектор должен постоянно отслеживать решения, которые должны быть приняты в

ближайшем будущем. И когда такое решение будет приближаться, дать задание нескольким
разработчикам попробовать решение проблемы и немного его развить. И когда подойдет
время принятия решения, команда соберется и обсудит плюсы и минусы различных
вариантов. И обычно, когда за обсуждением стоит реальный опыт, лучшее решение
становится очевидным для всех. Архитектор теперь не принимает решение, а лишь
дирижирует процессом принятия решения.
Этот подход работает как для небольших задач, так и для больших. Он может помочь
команде выбрать, использовать или нет Hibernate шаблоны из Spring фреймворка, и точно
также может помочь найти ответ на вопрос, какой Javascript фреймворк лучше
использовать. Время, в течении которого пробуются различные подходы, сильно зависит от
сложности принимаемого решения.
Попробовать два или более варианта решения одной и той же проблемы требует больше
усилий, чем просто принять решение «авансом» и потом его реализовать. Однако шансы,
что таким образом принятое решение потом окажется не самым оптимальным, достаточно
велики. И в результате архитектор может оказаться перед дилеммой: откатить назад уже
проделанную работу по неправильно принятому решению, или же продолжать уже начатое,
пусть и с меньшей эффективностью, и при этом оба выбора в результате приведут к
серьезной потере времени. Или, что еще хуже, никто в команде вообще не увидит
альтернативного варианта, в этом случае потери времени не будут даже обнаружены. На
фоне всего этого, потратить некоторое количество времени на анализ альтернатив может
оказаться самой выгодной стратегией.
Автор оригинала - Erik Doernenburg
41
30. Знания предметной области

(В оригинале – Understand The Business Domain)
Эффективный дизайнер ПО должен разбираться не только в технологиях, но и обладать

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

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

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

архитектуры. Например, является ли целью заказчика резкое расширение компании за счет
слияний и приобретений других компаний? Ответ на этот вопрос может сильно повлиять на
выбор архитектуры. В случае положительного ответа архитектура может включать
множество уровней абстракции для облегчения процессов слияния. Если целью, например,
является активное расширение рынка за счет выхода бизнеса в онлайн, основным
требованием может стать высокая надежность и доступность. Архитектор ПО всегда
должен понимать цели компании, для которой ведется разработка, и следить за тем, чтобы
архитектура была подходящей для этих целей.
Самые успешные архитекторы, которых я знаю, это те, у кого есть как широкие технические
знания, так и глубокие знания определенных предметных областей. Такие архитекторы
могут вести переговоры с директорами компаний-заказчиков, говоря с ними на их языке.
Это обеспечивает уверенность в понимании того, что делается в результате. Знания
предметной области позволяют проектировщику лучше понимать проблемы, задачи, цели и
процессы, что является ключевым фактором для разработки эффективной архитектуры.
42
31. Программирование - это процесс проектирования

(В оригинале – Programming is an act of design)
Kristen Nygaard, отец объектно-ориентированного программирования и языка

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

которая делается – это концепт. В основном речь идет о позиционировании. BMW X6 –
пример нового концепта, объединяющего свойства «практичного спортивного автомобиля»
(SUV) и купе в то, что BMW назвала “Sport Activity Coupe”. Главное здесь то, что до того
момента, когда можно будет купить новый Х6, BMW инвестировало тысячи часов и
миллионы долларов как в сам автомобиль, так и в линию его производства. Когда BMW
получит индивидуальный заказ на машину, одна из их линий соберет именно такой
индивидуальный экземпляр Х6.
Какой же урок можно вынести из этого примера? Главное – это то, что производство
автомобиля состоит из двух процессов. Первый процесс – это собственно проектирование
автомобиля и наладка сборочной линии. Второй процесс – это сборка автомобилей по
индивидуальным заказам. В том или ином виде оба эти процесса присутствуют и в
индустрии ПО. Проблема лишь в том, что вкладывается в эти определения.
В статье «Что такое проектирование ПО» Jack Reeves предположил, что единственная вещь
в разработке ПО, подходящая под определение документа дизайна (так, как этот документ
понимается и используется в классической инженерии) – это исходный код. А сборка ПО
автоматизирована и выполняется компилятором, скриптом сборки и тестирования.
Приняв то, что исходный код – это проектирование, а не сборка, мы можем адаптировать
гарантированно работающие практики управления сложными и непредсказуемыми
работами, такими как разработка нового автомобиля, лекарства или компьютерной игры.
Мы говорим о практиках agile управления, как например, SCRUM. Эти практики
фокусируются на максимизации возврата вложений в терминах ценности заказчика.
Для использования опыта остальной индустрии в разработке ПО мы должны помнить:

программирование является проектированием, а не сборкой.
Автор оригинала - Einar Landre
43
32. Время все меняет

(В оригинале – Time changes everything)
Одна из вещей, меня занимающих – это наблюдать, какие вещи поменялись со временем, а
какие – нет. Множество паттернов, фреймворков, парадигм изменились, а алгоритмы, когда-
то увлеченно обсуждаемые умными людьми, думающими о долгосрочных перспективах,
сейчас могут вызвать лишь зевоту. Почему? Что нам хочет сообщить история?
Выбор достойной проблемы.
На первый взгляд, это представляет определенную сложность для проектировщика ПО.

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

обеспечивающую предсказуемость, которую мы страстно желаем, и ясные ответы,
кажущиеся всегда чуть-чуть, но недосягаемыми. Проблема лишь в том, что какой бы луч
света не вел вас вперед сейчас, он вряд ли останется таким же через год, а тем более через
десять лет. Когда бы вы не оглянулись назад, вы всегда найдете что-то, сделанное вами
ранее и не соответствующее вашим нынешним ожиданиям. Научитесь принимать эти
старые вещи и бороться с соблазном все это переделать. Решение было подходящим для той
проблемы? Оставьте это как отметку вашего роста, и будете гораздо счастливее.
Автор оригинала - Philip Nelson
44
33. Дайте разработчикам свободу

(В оригинале – Give developers autonomy)
Большинство архитекторов начинали свою карьеру как разработчики. Архитектор имеет

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

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

(В оригинале – Value stewardship over showmanship)
Когда архитектор назначается на новый проект, у него может возникнуть желание

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

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

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

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

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

(В оригинале – Warning, problems in mirror may be larger than they appear)
Я участвовал более чем в сотне различных программных проектов. В каждом из них были
моменты, приносящие гораздо больше проблем, чем ожидалось. Часто небольшая часть
команды определяла эти возможные проблемы на ранних стадиях, однако остальное
большинство не соглашалось или игнорировало это, потому что не понимало всей важности
до тех пор, пока не становилось слишком поздно.
Причины этого таковы:
 То, что казалось тривиальным вначале, потом становилось критическим, часто после
того, как было уже слишком поздно для исправления. Эксперимент с лягушкой в
медленно нагревающейся воде хорошо иллюстрирует эту ситуацию.
 Люди часто встречают сопротивление, когда остальная часть команды не разделяет
их опыта или знаний. Преодоление этого сопротивления требует достаточно
смелости, уверенности в себе и убедительности. И часто случается, что даже
высокооплачиваемые опытные консультанты, специально нанятые для
предотвращения подобных ситуаций, не могут это сопротивление преодолеть.
 Большинство программистов – оптимисты. Болезненный опыт может умерить
оптимизм, но до его приобретения присутствует склонность к оптимизму.
Пессимисты в команде часто не пользуются популярностью, даже если они
оказываются правы. Мало кто будет рисковать репутацией и идти против
большинства без очень серьезной для этого причины. При том, что проблемы часто
дают о себе знать как «Мне это не нравится, но я пока не могу объяснить почему», и
с такой аргументацией редко удается выиграть спор.
 Каждый разработчик смотрит на проект под разным углом, фокусируясь на зонах
своей ответственности, а не на целях проекта в общем.
 У всех нас есть «слепые пятна», ситуации, которые нам сложно распознать или
принять.
И несколько возможных стратегий по предотвращению причин:
 Создайте систему управления рисками. Один из вариантов – делать трекинг рисков

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

заказчика. Отсортированный список задач может в чем-то помочь, но не может
заменить полноценного диалога с заказчиком и беспристрастности.
 «Слепые пятна» сложно распознаются по определению. Люди, которые всегда
скажут вам всю правду, даже если она будет нелегкой, являются самым ценным для
вас ресурсом.
48
36. Профессия архитектора ПО неофициальная. Ну и что?

(В оригинале – The title of software architect has only lower-case 'a's; deal with it)
Не так давно была попытка сделать профессию архитектора ПО официальной, по аналогии

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

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

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

(В оригинале – Software architecture has ethical consequences)
Когда говорят об этике в программировании, чаще всего подразумевают пиратство или

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

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

можно повесить на той высоте, докуда вы сможете дотянуться, если у вас нет под рукой
лестницы. Это всего лишь заставит людей слегка наклонять голову, проходя под ней или
делать пару шагов в сторону, чтобы ее обойти. Вы же сэкономите пару часов времени на
монтаж и какое-то количество денег на покупку лестницы. Однако в течении долгого
времени та пара секунд, которую тратит каждый прохожий, чтобы обойти нависающую
вывеску, сложится в очень большую сумму, многократно превышающую сэкономленный
вами час. Ваше действие окажет влияние на множество людей – это и есть тот самый
коэффициент умножения.
Другой пример. Вы разрабатываете новую функцию для очередной версии вашего ПО, и у
вас есть два варианта. Более простой – добавить дополнительное поле в таблицу и форму
ввода и сделать все за день-два, и более сложный – не добавлять его и потратить неделю-
две. Какой вариант вы выберете?
Добавление нового поля в таблицу выглядит вполне невинно. Однако это – требование для
ваших пользователей. Они будут должны вносить больше информации, возможно они будут
забывать это делать в силу привычки, что приведет к потере времени, задержкам и
раздражению.
Неэтично ухудшить жизнь множеству других людей, даже совсем чуть-чуть, лишь для того,
чтобы облегчить жизнь себе. Ваша программа может воздействовать на миллионы людей.
Каждое ваше решение будет оказывать на них влияние. Всегда имейте это в виду. Более
правильным будет взвалить на себя тяжелую ношу, чтобы облегчить ее вашим
пользователям.
Автор оригинала - Michael Nygard
50
38. Любая система рано или поздно откажет

(В оригинале – Everything will ultimately fail)
Поскольку оборудование может отказать, мы добавляем избыточность. Это позволяет нам

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

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

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

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

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

привносит новые возможные сбои или поломки. Мы создаем кластерное ПО для переноса
приложения с отказавшего сервера на работающий, но при этом не можем никак
проконтролировать работоспособность кластерной сети.
Стоить вспомнить, что авария атомной станции на острове Трех Миль была вызвана
неисправностью предохранительного клапана – механизма безопасности, предназначенного
для предотвращения последствий превышения давления в контуре выше допустимого.
И что же мы можем с этим сделать?
Примите как данность то, что в вашей системе будут происходить сбои и отказы. Если вы
это не признаете, вы потеряете возможность обнаружения и контроля таких ситуаций –
нельзя контролировать то, чего не может случиться. Как только вы признаете, что сбои
возможны, вы получите возможность спроектировать и реакции системы на конкретные
сбои с целью минимизировать последствия и защитить остальные части системы.
Если вы не заложите в систему режимы работы в случае сбоев, то сбои все равно случатся,
но система при этом будет вести себя полностью непредсказуемо.
51
39. Контекст решает все

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

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

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

решений. Один из замечательных примеров – выбор базы данных для программного
обеспечения современного боевого танка. (Хотя выбор базы данных обычно не является
значимым с точки зрения архитектуры, этот пример приводится лишь для иллюстрации
идеи).
Когда потребовалось выбрать базу данных для танка, команда протестировала несколько
вариантов. Оказалось, что требуемое быстродействие для обработки потока информации
для работы системы слежения за целями обеспечивают практически все рассмотренные
СУБД. Однако для них было большим сюрпризом обнаружить, что выстрел из пушки танка
создает столь мощный электромагнитный импульс, что все системы на борту
перегружаются. Без работающих систем современный танк в буквальном смысле слепнет. И
самым главным фактором при выборе базы данных становится время восстановления после
сбоя. И по этому критерию лучше всего подходит решение вообще без базы данных, чем
Interbase, имеющий минимальное время восстановления среди рассмотренных. И именно
поэтому оно и было выбрано для танка M1 Abrams.
Таким образом, пока на форумах кипят обсуждения, какая технология лучше – Х или У, это
все лишь пустое времяпровождение. Причина таких горячих дебатов обычно не в серьезном
превосходстве одной из технологий, а наоборот, практически полном отсутствии
значительных отличий. Какие-то свойства больше нравятся одним, какие-то другим, и пока
нет решающего контекста, выбор сделать сложно.
52
Ваша команда не должна иметь идей вообще, ставя в фокус контекст и находя наиболее
простое решение в этом контексте.
Автор оригинала - Edward Garson
53
40. Производительность важна!

(В оригинале – It's all about performance)
Представьте себе автомобиль. Просторный, комфортабельный, с очень низким расходом,

дешевый и перерабатываемый на 98%. Хотите себе такой? А если окажется, что он не ездит
быстрее, чем 10 км/ч? Все еще его хотите? Вот на таком простом примере можно показать,
что производительность столь же важна, как и любой другой критерий.
Причины, по которым проектировщики ПО ставят производительность в самый низ

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

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

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

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

терминах предметной области и включать все взаимодействия пользователя с системой.
Тогда в измерения попадут и время, потраченное оператором на обдумывание, и время,
потраченное на ввод данных. С одной стороны, эти вещи не подконтрольны системе, с
другой – их включение в измерение будет очень сильно мотивировать создание удобного и
оптимального интерфейса. Должное внимание к тому, как представить информацию и как
оптимизировать необходимое количество действий для выполнения задачи приведет к
серьезному повышению производительности с точки зрения пользователя.
Скорость работы неинтерактивных компонент тоже важна. Как пример – «ночной» скрипт,
запускаемый каждую ночь, не сможет работать, если для его работы будет требоваться
более 24-х часов. Производительность может быть очень важна, например, в системе
восстановления после катастрофы. Насколько быстро будет возможно полное
восстановление системы после полного выхода из строя одной из ее частей?
Чтобы сделать успешную систему, всегда обращайте внимание на ее производительность.
Автор оригинала - Craig L Russell
54
41. Проектирование пустого пространства

(В оригинале – Engineer in the white spaces)
Система состоит из взаимосвязанных частей. Организация из этих частей и связей между

ними системы мы и называем проектированием. Когда мы рисуем диаграммы, мы часто
обозначаем части квадратиками, а связи – соединяющими квадратики стрелочками.
При этом одна маленькая стрелочка может означать что-то вроде «Синхронный запрос-
ответ с использованием SOAP-XML поверх HTTP». И это слишком много информации для
одной маленькой стрелочки. Часто даже не хватает места полностью это написать над этой
стрелочкой, и мы сокращаем надпись до чего-нибудь вроде «XML over HTTP» для
внутреннего использования или «SKU Lookup» для показа заказчику.
Эта стрелочка выглядит как непосредственный контакт между приложениями, однако это
не так. Пространство между квадратиками, пустое на диаграмме, в реальности заполнено
аппаратными и программными компонентами. Такими как:
 Сетевые карты
 Коммутаторы
 Файрволы
 Маршрутизаторы
 XML преобразователи
 FTP серверы
 Метро-сети
 MPLS шлюзы
 Океаны
 Рыболовные траулеры, случайно повреждающие сетями кабели
Скорее всего, на пути между программами А и В будет четыре или пять компьютеров. И вы,
как архитектор, проектирующий взаимодействие между этими программами, должны это
учитывать.
Однажды я видел стрелочку с надписью «Выполнение». Один сервер был внутри компании
клиента, другой был в другой компании. Эта стрелочка, критичная для удовлетворенности
заказчика, будучи распакованной в цепочку событий, стала напоминать головоломку, а не
простой интерфейс. Сообщение отправлялось обработчику, который записывал его в файл,
который загружался периодически запускаемым FTP процессом, и так далее. Всего шагов в
этой последовательности оказалось более двенадцати!
Важно понимать все, что стоит за каждой стрелочкой. Вместо «SOAP-XML over HTTP»
следовало написать «Потребуется один запрос для каждого HTTP запроса, плюс
подтверждение для каждого HTTP ответа. Планируется около 100 запросов в секунду и
доставка ответов за время не более чем 250 миллисекунд в течение 99.999% времени».
55
И даже это еще не все, что нужно знать об этой стрелочке. Без следующей информации нам
тоже не обойтись:
 Что, если запросы приходят слишком часто? Должны ли мы их отбрасывать без

подтверждения, подтверждать отбрасывание или стараться обработать максимально
возможное количество?
 Что должна предпринять другая сторона, если начнет получать ответы с задержкой
более 250 миллисекунд? Пересоздать соединение? Подождать в течении заданного
тайм-аута? Выдать сообщение о недоступности вызываемой стороны?
 Что если вызывающая сторона пошлет запрос версии 1.0 и получит ответ версии 1.1?
А если получит HTML вместо XML? А если MP3 вместо XML?
 Что произойдет при отсутствии связи между сторонами?
И вот ответы на такие и им подобные вопросы и есть проектирование пустого пространства.
56
42. Язык профессионалов

(В оригинале – Talk the Talk)
В каждой профессии существует свой профессиональный жаргон, благодаря которому

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

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

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

высокого уровня. Наиболее известные паттерны – это Event Driven Architecture, Service
Oriented Architecture, Resource Oriented Architecture и Pipeline Architecture.
Паттерны уровня архитектуры приложения определяют то, как должны быть

спроектированы отдельные приложения, входящие в корпоративную архитектуру. Наиболее
часто встречающиеся паттерны – это J2EE паттерны (Session Façade и Transfer Object), а
также паттерны, описанные в книге Martin Fowler «Patterns of Enterprise Application
Architecture».
Паттерны интеграции важны для проектирования концепций распределения информации

между компонентами, приложениями и подсистемами. Примеры интеграционных паттернов
– общие файлы, удаленный вызов процедур и множество схем обмена сообщениями. Эти
паттерны можно найти вот тут: http://www.enterpriseintegrationpatterns.com/eaipatterns.html.
Знание основных паттернов проектирования, описанных в книге «Design Patterns: Elements

of Reusable Object-Oriented Software», обязательно для каждого проектировщика. Хотя эти
паттерны могут казаться слишком низкоуровневыми для архитектора ПО, однако они
являются частью стандартного словарного запаса, облегчающего коммуникацию с
разработчиками.
Также очень важно знать и понимать различные антипаттерны. Термин «Антипаттерн»

предложил Andrew Koenig для обозначения часто встречающегося процесса, приводящего к
57
неудовлетворительному результату. Наиболее известные антипаттерны – это Analysis

Paralysis, Design By Committee, Mushroom Management, и Death March. Знание этих
антипаттернов поможет вам избежать множества ошибок, которые вы бы наверняка
совершили без этого знания. Более полный список антипаттернов вы можете найти в
википедии: http://en.wikipedia.org/wiki/Anti-patterns.
Для архитектора ПО возможность эффективной коммуникации – один из ключевых

моментов. И чтобы общаться на том же языке, на котором говорят архитекторы ПО,
понимание паттернов является необходимым.
58
43. Будущее за разнообразием

(В оригинале – Heterogeneity Wins)
Естественная эволюция компьютерных технологий привнесла важные изменения,

касающиеся того, какие инструменты могут выбирать архитекторы для проектирования
систем. Эти изменения возродили интерес к мультиязыковому программированию —
использованию более одного языка в разработке систем.
Мультиязыковое программирование — это не новая концепция. Один из известных

примеров из прошлого — поддержка COM-объектами, написанными на С++, Visual Basic.
Эта архитектура использовала плюсы обоих языков, наиболее популярных на тот момент.
Что же привело к возрождению интереса к мультиязыковому программированию?
Главное изменение — то, что стандарты вместе с ростом пропускной способности каналов и
вычислительной мощности ресурсов сделали жизнеспособными текстовые протоколы. Дни,
когда бинарные протоколы были единственной альтернативой для эффективных
распределенных систем, прошли. Текстовые протоколы взаимодействия начинались с
XML/SOAP web-сервисов и эволюционировали дальше в архитектурные стили RESTful и
другие протоколы, такие как Atom и XMPP.
Эти новые веяния предоставили гораздо более широкие возможности для гетерогенной
разработки, чем когда либо раньше, хотя бы потому, что в основе — обычный
форматированный текст, универсальный для обработки. Гетерогенное программирование
дает возможность выбрать подходящий инструмент для выполнения работы, и текстовые
протоколы взаимодействия распахнули этой возможности двери.
Архитектор теперь может комбинировать специализированные, мощные инструменты, что

позволяет мыслить категориями «какую концепцию здесь лучше всего применить», вместо
более раннего «какую концепцию позволит применить используемый язык
программирования». Различные языки программирования поддерживают различные
парадигмы: объектно-ориентированную, функциональную или парадигму распределенных
и параллельных вычислений. Какие-то из этих парадигм идеально подходят для решения
каких-то задач, а какие-то не подходят совсем. И сейчас стало возможным одновременно
комбинировать различные, на первый взгляд, несочетающиеся инструменты в элегантные
решения гораздо проще, чем это было в прошлом.
Шаг вперед уже произошел и заявил о себе взрывным ростом различных архитектурных
топологий современных программных решений. И это не просто отражение их
многообразия, а свидетельство новых возможностей.
И хотя временами выбор — не самая хорошая вещь, это точно наименее плохая
альтернатива в контексте современной архитектуры ПО. Индустрия стоит перед лицом
серьезных проблем (грядущая эра многоядерности и многопроцессорности обещает стать
самой большой проблемой ИТ сообщества), и нам понадобятся все возможные механизмы
взаимодействия, какие мы сможем задействовать, особенно еще и потому, что
59
существующие платформы плохо приспособлены для их решения (The Free Lunch is Over by
Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm).
И работа архитектора становится еще более ответственной, поскольку существующие

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

(В оригинале – Dwarves, Elves, Wizards, and Kings)
В книге «Cryptonomicon» Randy Waterhouse приводит свою классификацию персонажей.
1. Гномы – трудолюбивы, старательно работая над созданием удивительных

артефактов в своих темных пещерах. Они затрачивают невероятные усилия, двигая
горы и меняя рельеф, и славятся своим мастерством.
2. Эльфы – элегантные, культурные, и проводят дни, создавая прекрасные магические
вещи. Они настолько одаренные, что даже не понимают, что остальные расы считают
эти вещи сделанными в других мирах.
3. Маги – невероятно сильны, и в отличие от эльфов, понимают магию, ее силу и
природу, и способны применять ее с потрясающей эффективностью.
Однако есть еще и четвертый тип персонажей, на который Waterhouse ссылается, но явно не
упоминает. Это короли – провидцы, знающие, как управлять всеми остальными расами.
Архитектор по этой классификации подобен королю. Архитектор должен уметь

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

(В оригинале – Learn from Architects of Buildings)
«Архитектура — это социальный акт и материальный театр человеческой активности» -

Спиро Костоф.
Сколько архитекторов ПО видят свою роль исключительно или в основном технической?

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

способностью вспомнить огромное количество технических деталей, или хорошим вкусом,
утонченностью и благородством? И что вам больше по душе?
«Доктор может похоронить свою ошибку, а архитектор может лишь посоветовать

посадить виноград» - тот же автор.
Не является ли техподдержка устаревших систем именно этим виноградом? Хватит ли у вас

в роли архитектора силы духа уничтожит кусок работы, завершившийся провалом? Или
предпочтете его спрятать? Райт также говорил «Лучший друг архитектора — кувалда». Что
вы «уничтожали» в последний раз?
«Архитекторы не только верят, что сидят рядом с Богом, но и думают, что если Бог
когда-нибудь встанет, они возьмут стул себе» - Карен Мойер.
Вместо «Бог» читайте «Заказчик»
«В архитектуре, как в любом другом искусстве, финал должен задавать направление

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

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

всего лишь строитель» - Джон Рускин.
Играет ли художественность хоть какую-то роль в вашей работе архитектором ПО?

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

болезни архитекторов ПО.
«Звучит парадоксально, но все же в этом заключена важная правда. Архитектура не

может быть выдающейся, если она идеальна» - тот же автор.
Автор оригинала - Keith Braithwaite
63
46. Борьба с повторами

(В оригинале – Fight repetition)
Ваши разработчики выполняют повторяющиеся задачи, не задумываясь? В вашем коде

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

разработке ПО:
1. Повторение – это зло.
2. Повторяющаяся работа замедляет процесс написания ПО.
Как архитектор, вы задаете тон. В ваших руках вся власть над системой, и возможно,
именно вы спроектировали задающий направление срез системы, служащий примером для
команды – примером, который будет скопирован многократно. Когда разработчик копирует
что-нибудь, будь то несколько строк кода, XML-файл или класс, это явный индикатор того,
что что-то можно сделать проще или даже вынести отдельно. Чаще всего копируется не
логика предметной области, а код, обслуживающий инфраструктуру. В связи с этим очень
важно предвидеть эффект от ваших примеров. Как код, так и конфигурация из примера
будут основой для десятков, сотен или даже тысяч других частей этой системы или других
систем. Поэтому ваш код должен быть максимально прозрачным, ясным и не содержать
ничего повторяющегося и лишнего, кроме решаемой проблемы. Как архитектор ПО, вы
должны обладать высочайшей чувствительностью к любым повторяющимся шаблонам,
поскольку все, что вы напишете, будет повторяться :)
Но в вашей системе ничего этого нет, не так ли? Тогда посмотрите внимательней на
конфигурационный файл. Что изменится, а что останется, если его применить к другой
части системы? Посмотрите на прослойку бизнес-логики. Есть ли там шаблон,
повторяющийся от метода к методу, вроде обработки транзакций, логирования,
аутентификации или аудита? А если посмотреть в уровень доступа к данным? Не найдется
ли там кода, отличающегося лишь именами полей? Посмотрите шире. Не найдется ли
нескольких строк кода, часто стоящих рядом друг с другом и оставляющих ощущение
повторяемости, даже если они используются в различных местах и с разными объектами?
Все это примеры повторений. Разработчики привыкают «фильтровать» повторы при
просмотре кода, как только определят, в чем отличия, но даже в этом случае они все равно
снижают свою эффективность. Код, написанный так, написан для выполнения
компьютером, а не для чтения разработчиком.
Вы несете ответственность за удаление этих повторов. Чтобы сделать это, вам придется
поработать. Продумать более эффективные абстракции, установить аспектно-
ориентированный фреймворк, написать небольшие генераторы кода. Повторы никуда
самостоятельно не денутся, пока кто-то этим целенаправленно не займется.
И этот кто-то – это вы.
Автор оригинала - Niclas Nilsson
64
47. Добро пожаловать в реальный мир!

(В оригинале – Welcome to the Real World)
Инженеры любят точность, особенно это характерно для программистов, живущих в мире
нулей и единиц. Им приходится работать с бинарными выборами: ноль или один, true или
false, да или нет. Все ясно и согласованно, гарантируемо атомарными транзакциями,
ограничениями и контрольными суммами.
К сожалению, реальный мир не столь бинарный. Клиенты делают заказы лишь для того,
чтобы их отменить в следующий момент. Чеки не принимаются к оплате, письма теряются,
платежи задерживаются, а обещания не выполняются. Ошибки ввода данных случаются
слишком часто. Пользователи предпочитают простые интерфейсы, предоставляющие
доступ сразу ко многим функциям, без выстраивания последовательных процессов с
фиксированной очередностью выполнения операций, что кажется более логичным для
большинства разработчиков, а также более простым для реализации.
Более того, широко распространенные системы вносят еще больше несоответствия.

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

справляется с такими же задачами вот уже очень долгое время: задержанные письма,
невыполненные обещания, платежи, отправленные не по адресу – примеры можно
перечислять бесконечно. И людям приходится отправлять письма повторно, игнорировать
неправильные заказы или просить не обращать внимание на напоминание о платеже, если
платеж уже выполнен. Поэтому не осуждайте реальный мир за вашу головную боль, а
используйте его подсказки для нахождения решений. В конце концов, Starbucks тоже не
используют методологию двухфазового коммита в своем процессе. Добро пожаловать в
реальный мир!
Автор оригинала - Gregor Hohpe.
65
48. Наблюдение вместо контроля

(В оригинале – Don't Control, but Observe)
Современные системы – распределенные и слабо связанные. Проектирование слабо

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

это хорошая идея. Но это также означает и то, что наша система будет постоянно меняться
со временем. Система сегодня уже не будет такой, какая она была вчера. К сожалению, это
делает документирование системы очень нетривиальной задачей. Хорошо известен факт,
что документация устаревает в тот момент, когда отправляется на печать. Но для постоянно
меняющейся системы все еще гораздо хуже. К тому же если система гибкая, то это также
означает и то, что она достаточно сложна, и как следствие, сделать пресловутую “big
picture” тоже будет сложно. Например, если все компоненты системы связываются друг с
другом при помощи логических, конфигурируемых каналов, то лучше посмотреть на
конфигурацию каналов, чтобы понять, что происходит. Отправка сообщения без понимания
системы вряд ли приведет к ошибке компилятора, но наверняка расстроит пользователя, чьи
действия были инкапсулированы в этом сообщении.
Быть поклонником управляемой архитектуры и сильносвязанных, «хрупких» решений –

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

искушению нарисовать плакат 3 на 5 метров, весь заполненный квадратиками и линиями и
содержащий каждый класс в вашей системе. Получившаяся картина может занять призовое
место на выставке современного искусства, но не будет являться пригодной к
использованию моделью. Вместо этого, используйте вид с высоты 300 метров, описанный
Эриком Дорненбургом – уровень абстракции, который может реально показать полезную
информацию. В результате вы сможете также убедиться, что модель соответствует
определенным правилам, например, что в ней отсутствуют циклические зависимости или
что никто не посылает сообщения в канал, который никем не прослушивается.
66
Потеря контроля – ужасная вещь, даже если речь идет об архитектуре ПО. Но если это
дополнить наблюдением, извлечением модели и проверкой на корректность, то в результате
получится способ проектирования 21-го века.
Автор оригинала - Gregor Hohpe.
67
49. Знакомьтесь, архитектор Янус.

(В оригинале – Janus the Architect)
В древнем Риме Янус был богом начала и конца и изображался с двумя головами,
смотрящими в разные стороны. Наверняка вы где-нибудь видели этот символ. Янус
символизирует течение жизни от прошлого к будущему, от молодости к зрелости, являясь
привратником между прошлым и будущим.
Для каждого архитектора возможность Януса смотреть как в прошлое, так и в будущее –
очень желаемый навык. Архитектор старается соединить видение и реальность, прошлые
успехи и направления развития, ожидания заказчиков и руководства с ограничениями
разработки. Создание таких мостов – основная часть работы архитектора. Часто архитектор
может чувствовать себя пытающимся объять необъятное в процессе ведения проекта из-за
большого количества различных сил, действующих в рамках проекта. Например, конфликт
требований безопасности и простоты доступа, или удовлетворение сегодняшних бизнес-
процессов и видения будущего. Хороший архитектор должен, как и Янус, иметь две головы,
способных одновременно думать две мысли, чтобы быть способным создать проект,
максимально удовлетворяющий столь разным требованиям.
Обратите внимание, что у Януса две полноценные головы, а не два лица. Это дает ему еще
одну пару ушей и глаз, улучшая его информированность. Хороший ИТ-архитектор должен
быть замечательным слушателем и аналитиком. Понимание целей инвестиций критически
важно для определения видения руководства относительно будущего вашей организации.
Способность соотнести технические знания вашей команды с дизайном и используемыми
на проекте технологиями поможет в создании эффективного процесса обучения и
разработки и для успешного завершения проекта. Информация о доступных open source
решениях вместе с программными инструментами может сильно повлиять на сроки сдачи и
стоимость проекта. Хороший архитектор обязательно воспользуется возможностями этих
готовых «составных частей» в нужных местах жизненного цикла проекта.
Есть менеджеры, ожидающие и требующие от архитекторов наличия «божественных»

качеств чуть ли не в буквальном смысле слова. Сравнение же архитектора с Янусом говорит
немного о другом. Хороший архитектор должен быть открытым для новых идей,
инструментов и решений, способствующих движению вперед. Архитектор не должен
тратить все свое время на менеджерские совещания или на написание кода лично. Вместо
этого он должен принимать хорошие идеи и культивировать атмосферу, в которой эти идеи
появляются. Архитектор должен обладать открытым разумом, способным сбалансировать
множество разнонаправленных сил, тянущих проект в разные стороны. Все архитекторы
стараются достигнуть успеха в выполнении проекта. А лучшие архитекторы стараются
построить системы, выдерживающие проверку временем – системы, способные легко
расширяться в будущем по мере роста организации или изменения технологий. Такие
архитекторы отслеживают и при необходимости меняют свои процессы, решения и методы
для достижения максимального успеха. Они стараются гарантировать то, что их продукты
устоят перед грядущими изменениями.
68
Именно такой тип мышления ожидается от архитектора. При кажущейся простоте это не так
просто. Как и Янус, архитектор должен быть привратником дверей между прошлым и
будущим, связывая прошлое и будущее, старое и новое, удовлетворяя требования
сегодняшнего дня и одновременно готовясь к ожиданиям дня завтрашнего.
Автор оригинала - Dave Bartlett
69
50. Границы и интерфейсы

(В оригинале – Architects focus is on the boundaries and interfaces)
C тех пор как Нельсон разбил флот Испании и Франции в Трафальгарском сражении,
«Разделяй и властвуй» стало девизом при решении сложных проблем. Более простая
формулировка, означающая почти то же самое – разделение интересов. Разделение
интересов дает нам инкапсуляцию, а инкапсуляция приводит к появлению границ и
интерфейсов.
С точки зрения проектировщика, самая сложная задача в построении системы – найти

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

описанная в книге Эрика Эванса “Domain-Driven Design”. Ограниченный контекст – это
область, в пределах которой модель или концепция однозначно определены, обычно
представляемая в виде облака с информативным названием, определяющим ее роль и
ответственность в предметной области. Например, в системе доставки могут быть такие
контексты как «Погрузка», «Расписание» и «Доставка морем». В других предметных
областях будут другие имена.
После того как контексты выделены и нарисованы, время определить отношения между
ними. Эти отношения могут отображать организационные, функциональные или
технические зависимости. Результатом будет отображение контекстов – набор самих
контекстов и интерфейсов между ними.
Отображение контекстов дает архитектору мощный инструмент, позволяющий

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

(В оригинале – Challenge assumptions - especially your own)
"Предположение – причина большинства неудач", или более популярно: "Don’t assume – it

makes an 'ass' of 'u' and 'me', что в дословном переводе звучит как «Предположения делают
из нас ослов», увы, не передавая замечательную игру слов оригинала. И когда речь заходит
о предположениях, за которыми стоят тысячи или даже миллионы долларов, то
вышеприведенная фраза – уже не просто смешная шутка.
Одна из хороших практик разработки ПО – документировать причины того или иного

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

 Bitmap индексы приносят больше проблем, чем пользы
 Заказчик никогда не согласится с тем, что страница грузится пять секунд
 Директор согласится только на продукцию крупного вендора
Важно сделать эти предположения видимыми ради потомков и для будущего анализа.
Однако еще более важно убедиться, что все предположения, не имеющие адекватного
эмпирического подтверждения, проверяются перед тем, как решение окончательно принято.
Что, если заказчик не будет возражать против пятисекундной загрузки страницы, если
добавить на нее прогресс-бар? Какой именно open-source проект ненадежен и как именно
ненадежен? Тестировали вы bitmap-индекс на ваших данных?
И не игнорируйте слово «релевантный». Иногда то, что было истинным в предыдущих

версиях, не является таковым сейчас. Производительность bitmap-индексов в одной версии
Oracle может отличаться от производительности в другой версии. Старая версия библиотеки
могла иметь дыры в безопасности, исправленные в новой версии. Ваш поставщик
надежного ПО может быть на грани банкротства. Технологии меняются каждый день, и с
ними меняются и люди. Возможно, ваш шеф завтра станет фанатом Linux.
Факты и предположения – основа, на которой строится ваше ПО. Какими бы они ни были,
будьте уверены в том, что они согласованные.
Автор оригинала - Timothy High
71
52. Фиксируйте обоснования

(В оригинале – Record your rationale)
В сообществе разработчиков часто ведутся дебаты о ценности документации, особенно по

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

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

проекта, начиная от заметок в текстовом файле, wiki или блоге до использования
формальных шаблонов для записи всех возможных аспектов принятых архитектурных
решений. Но каким бы ни был формат, документация должна давать ответ на вопросы
«Какое решение было принято» и «Почему это решение было принято». Второй вопрос,
часто задаваемый, и который поэтому тоже должен быть задокументирован – «Какие
альтернативы были рассмотрены, и почему они не были приняты» (обычно такой вопрос
задают в форме «Почему мы не реализуем мое решение»). Документация также должна
быть удобной для поиска, чтобы ответ на нужный вопрос было всегда легко найти.
Такая документация может оказаться полезной во многих разных ситуациях:
 Как способ коммуникации с разработчиками по поводу важных архитектурных

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

заметок по результатам совещания или обсуждения темы. Какой бы формат вы не выбрали,
это тот тип документации, вложения в который оправданы.
73
53. Давайте разработчикам больше полномочий

(В оригинале – Empower developers)
Говорить гораздо проще, чем делать, и архитекторы ПО печально известны как раз первым.
Чтобы ваши слова были не пустым сотрясением воздуха (что, однако, часто используется
для создания продуктов-фантомов), вам нужна довольная команда разработчиков. Роль
архитектора обычно заключается в установке ограничений, но архитектор может быть и
тем, кто разрешает. Для этого вам нужно давать все возможные полномочия вашим
разработчикам.
Убедитесь, что у разработчиков есть все необходимые инструменты. При этом инструменты
не должны навязываться, а должны тщательно выбираться так, чтобы обеспечивать все
необходимое для работы. Повторяющаяся бездумная работа должна автоматизироваться
везде, где только это возможно. Кроме этого, одно из лучших вложений – обеспечить
разработчиками высококлассными компьютерами, быстрой сетью и доступом к ПО, данным
и информации, требующейся для наилучшего выполнения работы.
Убедитесь также в том, что у разработчиков есть все необходимые знания. Если
потребуются тренинги, обеспечьте их. Вкладывайте в книги и поощряйте активные
дискуссии о технологиях. Рабочая жизнь программистов должна быть практичной, но при
этом и активно-академической тоже. Если у вас есть средства, отправляйте команду на
технические конференции и презентации. Если средств нет, используйте хотя бы
тематические рассылки и бесплатные мероприятия в вашем городе. Участвуйте в отборе
программистов. Ищите тех, кто хочет обучаться, кто старается основательно разбираться в
технологиях (при этом убедитесь, что они способны работать и в команде). Сложно ожидать
выдающихся результатов от посредственных исполнителей.
Позволяйте разработчикам принимать их собственные решения, если это не противоречит

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

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

(В оригинале – It is all about the data)
Будучи программистами, мы изначально понимаем ПО как систему команд, функций и

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

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

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

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

данным. Собирает ли система правильные данные в правильное время? Кто должен иметь
возможность эти данные видеть и изменять? Данные какого качества собраны и как быстро
растет их количество? Какая их структура и как именно обеспечивается надежность? Когда
данные уже в системе, возникает еще один вопрос – нужно ли вывести и/или изменить
существующие данные или добавить новую порцию?
75
С точки зрения дизайна, наиболее критическая задача для большинства систем – собрать
правильные данные в правильное время. После этого различные преобразования делаются
уже для того, чтобы сделать данные доступными, выполнить какую-либо функциональность
и сохранить результат. Большинство систем необязательно должны быть чрезвычайно
сложными, они лишь должны работать с все большими и большими объемами данных.
Функциональность – то, что мы видим вначале, но данные являются ядром практически
любой системы.
Автор оригинала - Paul W. Homer.
76
55. Система контроля версий - не только для кода, но и

для данных
(В оригинале – Control the data, not just the code)
Системы контроля версий и непрерывная интеграция – превосходные инструменты для

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

2. Отправить скрипты ответственному за БД
3. Ответственный за БД копирует скрипты туда, где их запустит планировщик
4. Проверить логи выполнения скриптов и помолиться, что запустились все скрипты,
потому что вы не уверены в том, что получится, если их запустить еще раз
5. Запустить проверочный скрипт и выборочно проверить данные
6. Запустить регрессионные тесты приложения и найти причины ошибок
7. Написать скрипты, исправляющие найденные проблемы в данных
8. Повторить с самого начала
Да, возможно, преувеличенно, хотя не так уж и сильно. Многие проекты проходят через
что-то подобное для успешной миграции базы данных. По какой-то причине миграция базы
данных должным образом не рассматривается во время планирования миграции всей
системы. И в результате миграция данных превращается в ненадежный ручной процесс.
Такая сложная работа создает множество возможностей для того, чтобы развалить процесс.
Еще хуже то, что ошибки миграции данных не всегда могут быть обнаружены юнит-
тестами и проявляют себя уже после выпуска релиза. Проблемы в базе данных приходится
исправлять вручную, а их решения – сложно проверяемые. Ценность полностью
автоматического процесса, способного вернуть базу данных в известное состояние
становится особенно очевидной, когда вам нужно восстановить систему после неудавшейся
миграции. Если вы не можете «убить» базу данных и восстановить ее в состояние,
совместимое с конкретной версией приложения, то у вас те же самые проблемы, как если
бы вы не могли вернуться назад после изменения в исходном коде.
Изменения базы данных не должно нарушать ваш процесс сборки. Вы должны быть в
состоянии собрать все приложение целиком, включая базу данных. Сделайте базу данных
неотъемлемой частью автоматизированной сборки и тестирования на начальном этапе
разработки, и добавьте кнопку «Вернуться назад». Это принесет вам серьезные дивиденты.
В лучшем случае это сохранит вам много часов болезненного решения проблем после сбоя
в ночной сборке. В худшем случае это позволит вашей команде уверенно двигаться вперед,
спокойно меняя при необходимости структуру базы данных.
Автор оригинала - Chad LaVigne
77
56. Будьте осторожны с метафорами

(В оригинале – Don't Stretch The Architecture Metaphors)
Архитекторы ПО любят использовать метафоры. Метафоры предоставляют простой и

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

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

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

неактуальных метафор и давно переработанных концепций.
Пример: Почему объект Billing Factory создает канал для системы гребных шлюпок?
Действительно ли он должен возвращать отображение граната для автовокзала?
Говорите, вы тут недавно работаете?
В общем, не зацикливайтесь на метафорах, используйте их лишь для облегчения

коммуникации и не позволяйте им обернуться против вас.
Автор оригинала - David Ing
78
57. Фокусируйтесь на техподдержке и сопровождении

(В оригинале – Focus on Application Support and Maintenance)
Поддержка и сопровождение никогда не должны планироваться в последнюю очередь.

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

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

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

техподдержку:
 Большинство проблем требует вмешательства разработчиков.

 Отношения между командами разработки и техподдержки напряженные,
разработчики считают, что в техподдержке сидят одни идиоты.
 Техподдержка ненавидит ваше приложение.
 Архитектор и разработчики проводят много времени «в поле».
 Приложение приходится часто перезапускать с целью решить проблемы.
 У администраторов никогда нет времени нормально настроить систему, потому что
все время уходит на «тушение пожаров».
79
Чтобы быть уверенным в том, что ваше приложение ожидает успех после того, как оно
выйдет из разработки, вам следует:
 Понять, что для разработки и техподдержки требуются различные умения и

способности.
 Как можно раньше назначить на проекте руководителя техподдержки.
 Вовлекать руководителя техподдержки в планирование техподдержки.
Проектируйте так, чтобы кривая обучения для работников техподдержки была минимально
возможной. Возможность отслеживания событий, аудит и наличие логов – обязательны!
Когда техподдержка счастлива, то и все остальные тоже счастливы (особенно ваше
руководство).
Автор оригинала – Mncedisi Mawabo Kasper.
80
58. Выберите любые два

(В оригинале - Prepare to pick two)
Иногда принятие ограничений приводит к тому, что приложение проще и дешевле

спроектировать и запустить. Желаемые требования часто приходят тройками, при этом
попытка построить систему, удовлетворяющую всем трем, может привести к тому, что
реально не будет удовлетворяться ни одно из них.
Известный пример такого ограничения – гипотеза Брюера (Brewer), также известная как
Целостность, Доступность и Устойчивость (Consistency, Availability, and Partitioning, или
CAP). Эта гипотеза утверждает, что для распределенной системы невозможно достичь
выполнения всех трех требований. Попытка это сделать лишь приведет к значительному
расходу ресурсов и резкому росту сложности, при этом все три цели, конечно же,
достигнуты так и не будут. Если ваши данные должны быть распределенными и
доступными, то обеспечить их целостность окажется слишком дорого. Если же система
должна быть распределенной и целостной, то в результате появятся проблемы
производительности и задержки, переходящие в недоступность данных в те моменты, когда
система будет занята обеспечением целостности.
Очень часто некоторые свойства декларируются как такие, нарушить которые нельзя
никогда:
 данные не должны дублироваться;

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

причин, из-за которых эти свойства появляются. В результате могут потеряться различия
между догматизмом и строгим дизайном, и появиться обсуждения нарушений вместо
принципов. Вместо этого нужно задать себе вопрос, почему эти свойства должны
выполняться? Какие преимущества мы получим, если их реализуем? Когда эти свойства
необходимы? Где мы можем их нарушить, чтобы получить лучший результат? Будьте
скептиком, поскольку догмы проектирования часто отодвигают выпуск продукта на
неопределенный срок. Неизбежность компромисса здесь сложнее всего принять, причем не
только на уровне архитектора, но и на уровне программиста или заказчика. Но нужно
стараться это сделать, поскольку компромисс вместо прямого следования за догмами часто
приводит к замечательному результату.
Автор оригинала - Bill de hÓra
81
59. Предпочитайте принципы, аксиомы и аналогии вместо

мнений и предпочтений
(В оригинале - Prefer principles, axioms and analogies to opinion and taste)
Проектируя архитектуру, вы должны руководствоваться принципами, аксиомами и

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

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

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

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

времени. Постоянство часто является проблемой, особенно в больших системах,
охватывающих различные технологии и существующих много лет. Ясные принципы
архитектуры позволят тем, кто не силен в одной из используемых технологий, быстрее и
легче с ней разобраться.
Автор оригинала — Michael Harmer.
82
60. Начинайте с "Шагающего скелета"

(В оригинале - Start with a Walking Skeleton)
Одна очень эффективная стратегия разработки, верификации и развития архитектуры

приложения — начать с того, что Элистейр Кокбурн (Alistair Cockburn) назвал «Шагающий
скелет». «Шагающий скелет» - это минимальная завершенная реализация системы,
содержащая в себе все основные компоненты. Начиная с малого и отрабатывая на
работающей системе все возможные ситуации, вы будете уверены, что двигаетесь в
правильном направлении.
Как только скелет зашагает, нужно будет начать его тренировать. Наращивайте его
мышечную массу. Это значит — реализуйте инкрементально, добавляя завершенные
функциональности. Цель — все время поддерживать систему работающей.
Внести изменение в архитектуру тем сложнее и дороже, чем дольше система существует и
чем больше она сама. Поэтому мы и хотим найти ошибки как можно ранее. И данный
подход обеспечивает нам короткий цикл обратной связи, при помощи которого мы можем
быстро адаптироваться с целью удовлетворения бизнес-требований, порой проясняющихся
лишь в ходе работы. Предположения по поводу архитектуры проверяются на ранней
стадии. Архитектура получается легко изменяемой, поскольку проблемы выявляются на
ранних стадиях, до того, как были сделаны серьезные вложения в реализацию.
И чем больше система, тем более важна эта стратегия. В маленьком приложении один
разработчик может сделать все сам от начала и до конца, что становится невозможным для
больших систем. Обычная практика — это несколько разработчиков в команде или даже
несколько распределенных команд вовлекаются в разработку. Как следствие — требуется
гораздо больше координации. К тому же, разные программисты работают с разной
скоростью. Кто-то может сделать много и быстро, а кто-то другой потратит больше
времени, а сделает меньше. Наиболее критические и затратные по времени части должны
быть сделаны на ранних стадиях проекта.
Начинайте с «Шагающего скелета», поддерживайте его живым и наращивайте его

постепенно.
Автор оригинала - Clint Shank
83
61. Делитесь знаниями и опытом

(В оригинале - Share your knowledge and experiences)
Мы многому обучаемся на своем опыте, включая успехи и неудачи. В столь молодой

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

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

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

развиваться. Мы также понимаем, что это помогает и нам самим. Для нас важна любая
возможность поделиться тем, что мы знаем, тем, о чем мы думаем, что знаем это, и тем, с
чем мы сталкивались. Если мы поможем усовершенствоваться тем, кто вокруг нас, они, в
свою очередь, помогут нам достичь максимума.
Автор оригинала – Paul W. Homer.
84
62. Простые решения для простых задач

(В оригинале - Make sure the simple stuff is simple)
Архитекторам ПО приходится порой решать очень сложные проблемы. Но также нам

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

Запомните: пытаясь угадать требования в будущем, вы в 50% случаев ошибетесь, а в 49%
случаев из оставшихся 50% — ошибетесь очень сильно. Решайте сегодняшние проблемы
сегодня. Выпустите приложение вовремя и подождите обратной связи, чтобы получить
реальные требования к новой версии. Ваш простой дизайн обеспечит легкую интеграцию
новых требований, когда они появятся. Если даже ожидаемые вами требования и
подтвердятся, то у вас уже будет продуманное решение. И вы сможете рассчитать оценку на
реализацию достаточно точно, и будете это делать для реальных, а не ожидаемых
требований. В результате вы и ваша команда заслужат репутацию делающих точные оценки
и завершающих работу вовремя.
85
63. Проектируйте только то, что сможете реализовать сами

(В оригинале - If you design it, you should be able to code it)
Для архитектора заманчиво создать продуманный дизайн, элегантно решающий

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

разработчикам. Если вы не знаете, сколько времени потребуется на изучение новой
технологии, вы не сможете дать реальную оценку для реализации.
2. Вы не будете знать о проблемных местах, которые необходимо избегать при
использовании. В реальности все будет совсем не так гладко, как на демонстрации
технологии, показанной экспертом в этой технологии. Если вы не работали с этой
технологией ранее, то проблемы возникнут неожиданно для вас.
3. Вы потеряете доверие разработчиков. Когда разработчик задает вопрос по дизайну и
не может получить полный и связный ответ, он очень быстро перестанет доверять
вам и вашему дизайну.
4. Вы добавите проекту ненужный риск. Отсутствие информации поставит большой
знак вопроса на ключевых элементах проекта. И мало кто захочет браться за проект с
большим и неоправданным риском.
Так что же делать, если нужно начать использовать новый паттерн, фреймворк или
платформу? Не забывайте, что «прежде всего, архитектор – это программист».
Автор оригинала - Mike Brown
86
64. Возврат вложений

(В оригинале - The ROI variable)
Любое решение, принимаемое нами на проекте, будь это связано с технологиями,

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

(Return of Investment, ROI). Например, мы предполагаем, что, потратив больше времени на
написание тестов, мы получим меньше ошибок в релизе продукта». Стоимость инвестиции
– это время, потраченное на написание тестов. Получаем же мы экономию времени на
исправление ошибок в будущем, а также более высокую удовлетворенность заказчика
стабильным продуктом. Предположим, что мы сейчас тратим 10 из 40 часов в неделю на
исправление ошибок. И по нашей оценке, если тратить на тестирование по 4 часа в неделю,
то исправлять ошибки придется лишь 2 часа в неделю. Тем самым мы сохраним 8 часов
времени. Возврат вложений в данном случае будет 200% - 8 часов времени, сэкономленного
на исправлении ошибок, против 4-х часов, потраченных (инвестированных) на
тестирование.
Не обязательно оценивать все в деньгах, но все инвестиции должны приводить к получению

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

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

(В оригинале - Your system is legacy, design for it)
Даже если вы разрабатываете систему с нуля с использованием самых современных

технологий, для следующего разработчика она будет устаревшей. Примите это. Природа
ПО в наши дни такова, что все очень быстро устаревает. Если вы ожидаете, что ваша
система будет запущена в производство и проработает хотя бы несколько месяцев, тогда
вам нужно принять, что техподдержке придется исправлять ошибки. А это означает, что
система должна обладать следующими характеристиками:
 Ясность – должно быть просто понять, что делает определенный компонент или
класс.
 Тестируемость – легко ли протестировать вашу систему?
 Корректность – работает ли все именно так, как было спроектировано? Избегайте
быстрых и «грязных» исправлений в системе.
 Возможность отладки – сможет ли специалист из техподдержки, который никогда
не видел вашего кода, в производственных условиях найти проблему и решить ее?
Или же ему понадобится для этого два месяца?
Старайтесь думать о том, что другой команде придется взять ваш код и разобраться с тем,
как он работает. Эта мысль – одна из главных на пути к качественной архитектуре. Это не
значит, что архитектура должна быть примитивной или задокументированной «по самое не
хочу», хорошая архитектура будет самодокументируемой, причем сразу несколькими
способами. Поведение системы в производстве также может пролить свет на то, как она
была спроектирована. Например, беспорядочная архитектура с отвратительными
взаимосвязями практически всегда будет себя вести точно так же. Подумайте о тех
программистах, кому придется искать и исправлять ошибки.
«Устаревшая версия» все чаще становится проклятием для разработчиков, однако в

реальности это ждет каждую систему. И в этом нет ничего плохого, скорее наоборот, это
может показывать, что ваша система – жизнеспособная, удовлетворяет ожидания и имеет
ценность. Система, которая никогда не станет устаревшей, скорее всего, никогда и не будет
успешной.
Автор оригинала – Dave Anderson.
88
66. Единственное решение? Найдите еще одно!

(В оригинале - If there is only one solution, get a second opinion)
Вероятно, вы уже слышали это раньше. Если вы опытный архитектор, то вы уже знаете, что
это действительно так: если вы знаете только одно решение задачи, то у вас проблемы.
Проектирование ПО – это всегда выбор лучшего решения задачи с учетом имеющихся
ограничений. И очень сложно удовлетворить сразу и все требования, и все ограничения с
первым же пришедшим в голову решением. В общем случае необходимо найти компромисс
между выбором решения, наилучшим образом удовлетворяющее наиболее критичным
требованиям. И если у вас есть только одно решение, то это значит, что у вас не будет
пространства для маневра. Очень может быть, что ваше единственное решение не подойдет
заказчикам. Также если в процессе из-за изменения бизнес-окружения поменяются
приоритеты, у вас не будет возможности к ним приспособиться.
Очень редко такая ситуация возникает из-за реального отсутствия альтернатив. Скорее
всего, причина – в недостаточном опыте архитектора в данной предметной области. Если
это ваш случай, то найдите в себе силы обратиться к кому-нибудь более опытному за
советом. Хуже, если архитектура разрабатывается по привычке. Архитектор может быть
специалистом в проектировании определенного типа (например, трехуровневая клиент-
серверная архитектура), но не иметь достаточно опыта, чтобы определить, когда этот тип
применять нельзя. Если вы обнаружили, что вы сразу знаете решение, без какого-либо
анализа других возможностей, то остановитесь, вернитесь на шаг назад и поищите другие
возможные варианты. Если не сможете, то возможно, вам нужна помощь.
Один мой знакомый однажды отвечал за техническую часть маленького, но

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

(В оригинале - Understand the impact of change)
Хороший архитектор снижает сложность до минимума и может спроектировать такое

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

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

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

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

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

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

бюджета, и быть готовым потратить больше времени в тех местах, в которых последствия
изменений будут наиболее проблемными. Оценка риска – полезный инструмент для
обнаружения мест, на которые стоит затратить больше времени. Снижение сложности –
важно, но сниженная сложность все равно не будет эквивалентна простоте. Преимущество
понимания воздействия изменения на ваш проект просто неизмеримо в среднесрочной и
долгосрочной перспективе.
Автор оригинала – Doug Crawford.
91
68. Вам придется работать и с "железом"

(В оригинале - You have to understand Hardware too)
Для многих архитекторов ПО планирование аппаратной конфигурации — тема, выходящая

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

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

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

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

системы ранее, а значит, какой-то опыт проектирования аппаратной конфигурации у вас
есть. Вы можете обсудить эту тему с заказчиком и убедить его потратить часть средств на
проектирование «железа», поскольку это может оказаться значительно выгоднее, чем
затраты на ненужный запас производительности. В таком случае ключевой момент — это
горизонтальная масштабируемость, т.е. возможность добавлять компоненты по мере
надобности вместо изначальной покупки с запасом. Чтобы сделать эту концепцию рабочей,
архитектору необходимо постоянно измерять производительность и изолировать
компоненты ПО для выполнения в предсказуемом по производительности окружении.
Проектирование аппаратной части не менее важно, чем дизайн ПО, и ему должно уделяться
адекватное время независимо от того, есть у вас в команде проектировщик инфраструктуры
или нет. Точно так же, как архитектор отвечает за соответствие бизнес-требований и
программного решения, он должен представлять соответствие между «железом» и ПО.
Автор оригинала - Kamal Wickramanayake
92
69. За "хаки" сейчас придется потом расплачиваться с

процентами
(В оригинале - Shortcuts now are paid back with interest later)
При проектировании системы важно помнить, что для ее сопровождения потребуется

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

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

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

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

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

она была решена прямо сейчас, когда это сделать дешевле всего. Чем дольше откладывать
решение, тем больше процентов придется заплатить.
Автор оригинала — Scot Mcphee
93
70. Лучшее - враг хорошего

(В оригинале - "Perfect" is the Enemy of "Good Enough")
Проектировщики ПО имеют склонность оценивать решение по тому, насколько оно

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

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

слишком запутанным решениям, что в конце концов приводит к более сложному
сопровождению.
Много аксиом в этой серии статей обращают внимание проектировщиков на то, что нужно
избегать ненужных абстракций или усложнений. Почему для нас так сложно делать вещи
простыми? Потому что мы хотим найти идеальное решение! Зачем еще архитектору
добавлять сложности в рабочее решение, кроме как из-за понимания неидеальности
простого дизайна? Помните, что разработка ПО — это не конкурс красоты, поэтому
перестаньте выискивать незначительные неидеальности и гнаться за идеалом.
Автор оригинала - Greg Nyberg
94
71. Избегайте "Замечательных идей"

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

засунуть в проект последнюю версию Hibernate, чтобы воспользоваться новыми
вкусностями, или же реализовываете AJAX на части ваших страниц, потому что
разработчик показал заказчику, как это круто, или же пересматриваете дизайн базы данных,
чтобы использовать возможности XML. Вы говорите менеджеру проекта, что реализуете
эту «замечательную идею» за пару недель, но потом оказывается, что переписывать
придется гораздо больше кода, чем казалось вначале, и вы начинаете выбиваться из
графика. К тому же, позволив появиться одной «замечательной идее», в скором времени вы
получите множество других, при этом сказать «нет» вам будет уже сложнее — вы же
согласились в первый раз?
Коварство «замечательных идей» в том, что они «замечательные». Кто угодно легко скажет
«нет» в случае плохой идеи, хорошие же могут проскользнуть, приведя к усложнению и
бесполезной трате ресурсов на добавление чего-то, что не требуется для решения
поставленных задач.
Вот несколько ключевых фраз, услышав которые, стоит насторожиться:
 «По-моему, будет круто, если...» - слово «круто» практически всегда является

сигналом опасности.
 «О, вышла новая версия фреймворка! Нужно проапдейтиться!»
 «Нам необходим рефакторинг XXX пока мы работаем над ZZZ...»
 «Технология ХХХ очень мощная! Возможно, мы сможем ее применить для...»
Хорошо, возможно, последняя фраза и не всегда предвещает проблемы. Но не забывайте

следить за «замечательными идеями», способными убить ваш проект.
Автор оригинала - Greg Nyberg
95
72. Качественный контент создает успешные системы

(В оригинале - Great content creates great systems)
Я много раз видел, как все внимание команды разработки сосредотачивалось на

требованиях, дизайне, разработке, безопасности и сопровождении, но главная часть
системы — данные — оставалась без внимания вообще. Особенно это актуально для систем
управления контентом, в которых информация неструктурирована или структурирована
лишь частично. Качественный контент — то, что отличает пустую оболочку от
функциональной системы.
Контент — это главное. Во все более взаимосвязанном мире именно качество контента
становится тем, что отделяет успех от провала. Facebook и Orkut, Google и Cuil, NetFlix и
BlockbusterOnline (увы, не подобрал аналогий из рунета), и этот список побед в поединке
контентов можно продолжать и продолжать. Кто-то может возразить, что контент не имеет
никакого отношения к задачам архитектора, но я думаю, что следующее десятилетие
покажет, что это не так.
Часть процесса проектирования новой системы должна быть посвящена оценке имеющегося
контента. Одного проектирования эффективных моделей (предметной области, данных или
объектов) недостаточно.
Проанализируйте весь доступный контент и оцените его ценность по следующим

критериям:
 Достаточно ли в наличии контента? Если нет, как мы сможем достичь критической

массы?
 Контент достаточно актуален? Если нет, как мы сможем повысить скорость его
доставки?
 Все ли возможные каналы задействованы? RSS, почта, оффлайн...
 Есть ли постоянные потоки поступления нового контента в систему? Одно дело —
определить ценный контент, и другое — регулярно добывать его.
Не допускайте здесь ошибок, успех системы зависит от контента. Потратьте часть времени
при проектировании на оценку вашего контента. Если ваша оценка будет далека от
удовлетворительной, то это важный сигнал, и об этом должны быть оповещены
заинтересованные стороны. Я видел много систем, удовлетворяющих всем требованиям, но
при этом все равно провальных, потому что аспект контента в них был проигнорирован.
Качественный контент создает успешные системы.
Автор оригинала — Zubin R. Wadia
96
73. Бизнес против архитектора

(В оригинале - The Business Vs. The Angry Architect)
Рано или поздно в нашей карьере архитектора наступает момент, когда мы понимаем, что
большинство проблем, с которыми мы сталкиваемся, повторяются. Несмотря на то, что
индустрия меняется, многие проблемы остаются такими же. В этот момент мы можем
положиться на свой опыт, быстро находя решение большинства проблем, оставляя больше
времени для работы над реально сложными задачами. Мы уверены в своих решениях и
выполняем работу качественно и в срок. Мы достигли равновесия. И в этом состоянии мы
легко можем совершить колоссальную ошибку, например, решить, что уже знаем столько,
что можем позволить себе больше говорить, чем слушать. Такое решение обычно приходит
вместе с цинизмом, нетерпением и недовольством к тем, кто осмеливается противоречить
нашему совершенному пониманию всех вещей.
В худшей своей форме такая самоуверенность может проникнуть в область бизнеса. Этот
путь может быстро привести к окончанию вашей карьеры. Бизнес обеспечивает наше
существование. Возможно, вам не очень приятно это осознавать, но это так. Мы
обслуживаем бизнес, а не наоборот. Слушать и понимать бизнес, нанявший нас для решения
своих проблем — наиболее критическая для нас способность. Вы когда-нибудь ловили себя
на том, что ожидаете, пока бизнес-аналитик закончит говорить, чтобы рассказать о своей
точке зрения? Значит, скорее всего, вы не прислушались к его предложениям. Уважайте
экспертов предметной области бизнеса, для вас не будет ничего хорошего, если они сочтут
вас неподходящим. Если вы им не понравитесь, то вы станете причиной проблем в
коммуникации и, как следствие, проблем в проекте. Помните: когда говорите вы, вы не
услышите ничего нового. Даже не начинайте думать о том, что вы настолько умны, что
никто другой не сможет вам рассказать что-то новое и полезное для вас.
Когда мы слушаем, мы часто не соглашаемся с тем, что слышим про то, как работает
бизнес. Это нормально. Мы можем предлагать варианты улучшений и даже должны это
делать. Однако если в конце дня вы все еще не согласны с тем, как работает бизнес, и не
собираетесь менять свою позицию, то это уже плохо. Не позволяйте себе стать
рассерженным гением, тратящим все свое время в попытках впечатлить других, выдвигая
остроумные и снисходительные предположения о том, насколько неэффективно работает
компания. Это их не впечатлит. Они уже такое видели. Ключевое свойство хорошего
архитектора — увлеченность работой, но увлеченность не должна становиться агрессией.
Научитесь принимать расхождения во мнениях и двигаться дальше. Если же расхождения
слишком велики для вас, найдите другую компанию, с которой вам будет проще
договориться, и работайте на них. Неважно как, но найдите способ установить хорошие
отношения с бизнесом и не позволяйте вашему эго их разрушить. Это сделает вас более
счастливым и продуктивным.
Автор оригинала — Chad LaVigne.
97
74. Проверьте, что сломается, если изменятся условия

(В оригинале - Stretch key dimensions to see what breaks)
Наброски дизайна приложения делаются на основании бизнес-требований, выбранных или

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

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

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

(В оригинале - Before anything, an architect is a developer)
Вы когда-нибудь слышали о судье, который бы не был юристом? Или о заведующем

хирургическим отделением, который не был бы хирургом? Даже после того, как они
достигли вершины своей карьеры, от них по-прежнему ожидается, что они будут
продолжать изучать все новшества своих соответствующих областей. Будучи архитектором
ПО, вам нужно следовать тем же стандартам. Неважно, насколько хорош дизайн, один из
главных факторов успеха реализации — вовлечь программистов в игру. Самый быстрый
способ сделать это — заработать их доверие и уважение. И мы все знаем, как проще всего
заработать доверие программиста — ваш код станет вашим посредником. Если вы сможете
показать программистам, что вы не один из «витающих в облаках» теоретиков,
неспособных закодировать свой собственный дизайн, то и недовольства вашими решениями
будет значительно меньше. Хотя мне не нужно этим заниматься на моей должности, я часто
берусь за реализацию сложных задач. Это преследует две цели: во-первых, это интересно и
это поддерживает мой уровень умения программировать, во-вторых, это помогает мне
демонстрировать своей команде, что я не витаю высоко в облаках. Ваша задача в роли
архитектора — спроектировать решение, которое будет выполнимо, сопровождаемо, и
конечно же, будет соответствовать проблеме. А чтобы знать, что выполнимо, а что нет, вам
нужно уметь оценивать требуемые для реализации решения ресурсы. Поэтому я предлагаю,
чтобы вы всегда могли реализовать то, что сами спроектировали.
Автор оригинала - Mike Brown.
99
76. Как вы яхту назовете...

(В оригинале - A rose by any other name will end up as a cabbage)
Однажды мои коллеги пытались создать фреймворк, содержащий в себе бизнес-логику.

Вместо того, чтобы решить несколько конкретных проблем, они начали с идеи того, чтобы
сделать фреймворк, заключающий в оболочку базу данных и создающий объекты. И
использующий объектно-реляционное отображение. И сообщения. И веб-сервисы. И много
других прикольных штучек.
К сожалению, поскольку они сами не знали точно, какие именно прикольные штучки
должен делать этот фреймворк, они не знали, как его назвать. И они устроили небольшое
соревнование, чтобы придумать имя. И вот это и есть та точка, показывающая наличие
проблемы: если вы не знаете, как это назвать, то вы на самом деле не знаете, что это. А если
вы не знаете, что это, то вы не сможете это закодировать.
В данном конкретном случае история в системе контроля версий показывает всю глубину
проблемы. Конечно же, там было множество пустых «реализаций» интерфейсов. И
особенно смешным было то, что они меняли имена три раза без реального кода. В самом
начале они назвали это ClientAPI («client» означало бизнес-заказчика, а не клиента из связки
«клиент-сервер»), финальным именем стало ClientBusinessObjects. Отличное имя:
неопределенное, общее и вводящее в заблуждение.
В конце концов, имя — это лишь указатель. Как только каждый вовлеченный поймет, что
имя — это просто имя, а не метафора проектирования, вы можете двигаться дальше.
Однако, если вы не можете договориться об имени, достаточно специфическом, чтобы было
понятно, что именно оно значит, то похоже, у вас проблемы еще на старте. Проектирование
— это попытка выполнить цели (например, быстро, дешево, гибко) и договориться об
именах.
Если вы не можете это назвать, вы не сможете это и написать. Если вы меняете имя три
раза, то вам нужно остановиться до тех пор, пока вы не поймете, что же вы пытаетесь
построить.
Автор оригинала — Sam Gardiner
100
77. Стабильные задачи дают качественные решения

(В оригинале - Stable problems get high quality solutions)
Программирование в реальном мире не имеет ничего общего с решением задач, которые

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

разбить его на небольшие кусочки. Важно, чтобы эти задачи, разбитые на кусочки, были
стабильными во времени, что позволит их решить с использованием конечного количества
оборудования, и само решение также будет стабильным. Задачи, разбитые на куски, должны
быть:
 внутренне цельными, т.е. все внутренние задачи, данные и функции связаны друг с
другом;
 хорошо отделенными от других кусков: пересечения между ними должны
отсутствовать полностью или практически полностью.
Человек, преуспевший делать именно так, часто даже не осознает, что он выполняет эту
работу по разбиению по таким критериям, примерно как человек, обладающий хорошей
ориентацией в пространстве, просто знает, где он сейчас находится. Для них просто
естественно разбить задачи, данные и функции так, чтобы образовать удобные границы или
интерфейсы (я имею в виду не интерфейсы в ООП, а границы системы).
Например, у реляционных баз данных такая граница видна очень хорошо. Они могут
работать с любыми типами данных, которые могут быть преобразованы в
последовательность байт, и могут хранить, искать и извлекать такие данные. Все просто.
Что еще интересно, если задача стабильна, то ее решение также будет стабильным. Лет
через пять (или пятьдесят) вы можете захотеть добавить к решению веб-интерфейс (или
телепатический интерфейс), но ядро системы при этом не изменится. Система долговечна,
поскольку задача долговечна.
Естественно, для этого код должен быть изящным. Но если сама задача изящна, то написать
для ее решения изящный код – не проблема. Изящный код – это хорошо, потому что его
легко тестировать, легко просматривать, что в итоге обеспечивает высокое качество
реализации. А когда у вас не будет спагетти-кода, вы можете сконцентрироваться на вещах,
выходящих за рамки того, что видит пользователь, как например, надежная система
сообщений, распределенные транзакции или же повышение производительности при
помощи многопоточности, а может даже и низкоурвневые вставки на ассемблере.
Поскольку задача не меняется, вы можете сконцентрироваться на обеспечении требуемого
качества.
101
Стабильные во времени задачи позволяют вам создавать системы со стабильным дизайном,

а стабильный дизайн, в свою очередь, позволяет вам сконцентрироваться на реализации
высокого качества.
Автор оригинала - Sam Gardiner
102
78. Вам потребуется усердие

(В оригинале - It Takes Diligence)
Работу архитектора ПО часто представляют как изобретательность и решение задач.

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

 выполнение всей работы, которая делает проектирование эффективным, а не только
того, что нравится делать;
 приверженность процессам и методологиям;
 принятие ответственности.
Атул Гаванд (Atul Gawande) в своей замечательной книге «Лучшее: заметки хирурга об
эффективности» (Better: A Surgeon's Notes on Performance) говорит об усердии в медицине:
«Настоящий успех в медицине — нелегкое дело. Он требует силы воли, внимания к деталям
и креативности. Однако в Индии я понял, что он возможен где угодно для кого угодно. Я
знаю очень мало мест, где условия еще тяжелее, однако поразительный успех встречается и
там. Лучшее — возможно. Для этого не надо быть гением. Для этого нужно усердие,
высокая мораль, находчивость. И главное — готовность попробовать».
Автор оригинала — Brian Hart
103
79. Принимайте ответственность за решения

(В оригинале - Take responsibility for your decisions)
Архитектор ПО должен принимать ответственность за свои решения, поскольку он обладает

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

решения?
Во-первых, вы должны быть принимать решения осознанно. Вам не следует заявлять о

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

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

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

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

архитекторы ошибочно полагают, что они должны принимать все решения. И поэтому
позиционируют себя как универсального эксперта. В реальности же такого не бывает.
Каждый архитектор — эксперт в одних областях, что-то знает о других и полностью
некомпетентен в третьих. Опытный архитектор будет делегировать принятие решений в тех
областях, в которых он не является экспертом.
Автор оригинала — Yi Zhou
104
80. Не спешите решать задачи

(В оригинале - Don’t Be a Problem Solver)
Архитектор должен быть программистом, за некоторыми исключениями. Программисты

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

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

точнее, вообще не знаем) о том, что сначала нужно изучить саму задачу. Нам нужно
рассмотреть задачу с различных сторон, чтобы убедиться, что сама задача сформулирована
правильно, вместо того, чтобы сразу браться решать то, что нам предлагается изначально.
Мы не должны быть пассивными приемниками требований, всегда выдающими готовое
решение, как автомат выдает чашку кофе.
Вместо того, чтобы сразу браться решать задачу в том виде, как вы ее получили,
посмотрите, не сможете ли вы ее изменить. Спросите себя, как будет выглядеть
архитектура, если бы этой задачи не было вообще? Это может привести к гораздо более
элегантному решению. Проблемы бизнес-уровня также не следует решать моментально.
Нам нужно разрушить нашу зависимость от задач. Нам нравится получать задачи. В
следующий раз, столкнувшись с задачей, перед тем, как браться ее решать, подумайте о
том, что будет, если бы вам не пришлось ее решать вообще.
Автор оригинала - Eben Hewitt
105
81. Выбирайте технологии тщательно, а расставайтесь с

ними неохотно
(В оригинале - Choose your weapons carefully, relinquish them reluctantly)
Каждый архитектор вооружен набором технологий, используемых для достижения успеха.

По определенным причинам эти технологии завоевали доверие и заняли первые места в
списке предпочитаемых решений. Скорее всего, они занимают правильные места в вашем
арсенале, победив в жестоком поединке своих соперников. Однако, новые технологии
постоянно покушаются на их успех. Мы часто оказываемся вынуждены сложить наше
лучшее оружие и взять вместо него одну из новейших альтернатив. Однако не спешите
расставаться с тем, что прошло проверку временем. Замена на альтернативу, которая хотя
бы несколько раз не была проверена в действии — слишком рискованное предложение.
Это не означает, что, однажды попав в список ваших фаворитов, технология останется там
навсегда, и тем более не означает, что вы должны игнорировать новые достижения в
разработке ПО. Любая технология рано или поздно требует замены. Прогресс движется
быстро, и появляются новые отличные решения. Как архитекторы, мы не должны отставать
от тенденций в индустрии, нам всего лишь не надо идти в первых рядах испытателей.
Обычно от того, что вы сталкиваетесь с технологией одним из первых, вы получаете не так
много бонусов, получая одновременно достаточно проблем.
Чтобы уравновесить риск, связанный с выбором новой технологии, ее достоинства должны

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

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

Выбирайте оружие тщательно, и расставайтесь с ним неохотно. Позвольте вашим прошлым
успехам стать основой успехов в будущем и меняйте используемые технологии с
осторожность.
Автор оригинала — Chad LaVigne
107
82. Ваш заказчик - не ваш клиент

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

заказчику использовать программистские термины, только если они не являются
общепринятыми и однозначными. Пусть ваш заказчик объясняет лишь свое видение,
концепции и цели, а не диктует вам то, как именно вы будете это реализовывать.
Конечно же, такая линия поведения – далеко не самая простая. Помните, что вы заботитесь
о клиентах вашего заказчика! Помните, что хотя и ваш заказчик платит вам, вы должны
следовать наилучшим практикам и стараться сделать то, что заказчику действительно
нужно, а не то, что он вам говорит, что ему нужно. Конечно же, для этого потребуется
много обсуждений и полное понимание того, что именно вы делаете и почему.
Автор оригинала – Eben Hewitt
108
83. Так не будет никогда

(В оригинале - It will never look like that)
Так не будет никогда. Очень легко поддаться соблазну потратить больше времени на
проектирование, чтобы быть уверенным, что реализация будет соответствовать дизайну.
Подробный дизайн может вселить в вас уверенность, что вы предусмотрели все. И чем
больше деталей, чем глубже они рассмотрены, тем больше вы будете уверены в этом. Но
это лишь иллюзия. Так не будет никогда.
Правда же в том, что каким бы детальным и глубоко продуманным не был дизайн,

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

новую информацию, которую часто было невозможно узнать заранее. Приняв тот факт, что
проектирование — это непрекращающийся и экспериментальный процесс в постоянно
меняющемся мире, мы поймем, что проектирование должно быть гибким и
непрекращающимся. Если же вы будете цепляться за финальную версию дизайна и
пытаться добиться именно такой же реализации любыми средствами, то это закончится тем,
что вам придется понять и принять тот факт, что так не будет никогда.
Автор оригинала - Peter Gillard-Moss.
109
84. Выбирайте фреймворки, хорошо стыкующиеся с

другими
(В оригинале - Choose Frameworks that play well with others)
Выбирая фреймворк в качестве основы своей системы, обращайте внимание не только на

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

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

другим, выбирайте фреймворки с высоким отношением полезного кода к «лишнему» в
контексте требований к вашей системе. Полезный код — то, что требуется вашей системе
непосредственно. Лишний — все остальное, что есть во фреймворке на разные случаи
жизни. Фреймворк требует объединения уровня представления данных и управления? Его
модели данных и классов расширяются далеко за необходимые вашей системе пределы?
Выбрав его, вы ограничите свой выбор других фреймворков, так или иначе пересекающихся
с ним. И если в выбранном фреймворке много лишнего, то пусть он хотя бы предоставляет
не менее 75% требуемой функциональности.
Ваша система должна быть составлена из непересекающихся фреймворков, каждый из

которых должен отвечать за единственную предметную область, и при этом быть простым и
гибким.
Автор оригинала — Eric Hawthorne
110
85. Сделайте экономическое обоснование

(В оригинале - Make a strong business case)
Будучи архитектором ПО, испытывали ли вы когда-нибудь сложности в получении

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

резюме, почему заказчику стоит использовать ваше архитектурное решение.
Ключевой момент — сравнить ваше архитектурное решение с уже существующими.
Фокус должен делаться на возможности повысить продуктивность и эффективность
бизнеса, а не на том, насколько хороши используемые технологии.
 Постройте количественные метрики. Ценность, которую вы обещаете создать,
должна быть понятным образом измерима. Чем больше вы сможете измерить, тем
проще вам будет продвинуть свое предложение, показав, что его применение даст
реальный возврат. Чем раньше вы построите метрики, тем лучше вы сможете
воздействовать на восприятие людей, что поможет вам продавать свои решения.
 Используйте традиционные для бизнеса показатели. Идеально, если вы сможете
перевести технические метрики в денежные. В конце концов, в бизнесе существует
лишь один важный параметр — деньги. Найдите бизнес-аналитика, если вы не
чувствуете в себе силы работать в финансовой сфере.
 Определите точку завершения. Перед тем, как определить это, вам нужно
подготовить дорожную карту (roadmap), показывав связь каждой контрольной точки
с реализуемой ценностью. Пусть на основании этих данных заказчик решит, в какой
точке остановиться. Если реализуемая ценность в каждой точке будет существенной,
то скорее всего вы получите финансирование.
 Выберите правильное время. Даже если вы проделаете все четыре предыдущих
пункта, вы не сможете продать свое решение, если выберете для этого неправильное
время. Я помню, как однажды мои предложения не принимались долгое время, пока
очередной проект не закончился полным провалом из-за отвратительно
выполненного проектирования. Предлагайте вовремя!
Автор оригинала — Yi Zhou
111
86. Паттернопатология
(В оригинале - Pattern Pathology)
Паттерны проектирования — один из наиболее ценных инструментов, доступных

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

автоматически хорошим. Это — повторно используемые решения повторяющихся проблем.
Эти решения были найдены и описаны другими людьми, чтобы помочь нам определить, что
мы смотрим на колесо, которое уже изобрели до нас. И наша работа — определить, что
задача может быть решена с помощью одного из этих решений, и применить
соответствующий паттерн для решения. Не позволяйте знанию паттернов проектирования
затмить ясность вашего взгляда. Фокусируйтесь на проектировании системы,
предлагающем наиболее эффективные решения, и используйте паттерны по мере
необходимости.
Автор оригинала — Chad LaVigne
112
87. Изучайте языки.

(В оригинале - Learn a new language)
Чтобы стать успешным архитектором ПО, вам придется научиться понимать тех, кто не
говорит на вашем языке. Я не имею под этим в виду изучение Эсперанто или клингонского
языка. Вместо этого вам необходимо освоить хотя бы на базовом уровне язык бизнеса и
тестирования. А если вы еще и не владеете языком программистов, то его нужно выучить в
первую очередь.
Если вам не кажется это важным, представьте следующий сценарий. Бизнес-заказчик хочет
внести изменение в существующую систему, для чего собирает митинг с архитектором и
программистами, чтобы это обсудить. К сожалению, никто из технарей не владеет языком
бизнеса, а представитель заказчика не понимает языка программистов. И митинг, скорее
всего, пройдет как-то так.
 Бизнес-заказчик в течении пяти минут расскажет об относительно простом

изменении в существующем проекте, объяснив, как это изменение сможет сильно
поднять им продажи и завоевать доверие клиентов.
 Еще до окончания его рассказа архитектор начинает зарисовывать в блокноте какие-
то оккультные символы и что-то тихонько обсуждать с одним из программистов на
своем непонятном языке.
 Наконец, бизнес-заказчик заканчивает доклад и смотрит ожидающе на архитектора.
 Закончив свое обсуждение с программистом, архитектор выходит к доске и начинает
рисовать сложные диаграммы, показывающие различные отображения
существующей системы, при этом объясняя на своем техническом языке, почему это
изменение практически невозможно реализовать без глобального редизайна всей
системы чуть ли не с самого начала.
 Бизнес-заказчик, совсем немного понимающий диаграммы и вообще ничего не
понимающий из объяснения, стоит с отвисшей от удивления челюстью, не в силах
понять, как столь малое изменение может потребовать такого количества работы. Он
даже начинает подумывать, не разыгрывает ли его архитектор. Или, может быть, он
просто не хочет делать это изменение, вот и рассказывает тут непонятные никому
сказки?
 Одновременно с этим архитектор и программисты не менее удивлены тем, что
заказчик в упор не замечает того, как его «небольшое» изменение разрушает всю
концепцию, и потребуется чуть ли не полностью переписывать ядро всей системы. И
вот здесь-то и лежит проблема. Люди не понимают ни того, как мыслит их
собеседник, ни половины используемых им слов. Это приводит к возникновению
недоверия. Всего лишь психология – люди комфортнее себя чувствуют среди тех,
кто им подобен, а не среди тех, кто от них радикально отличается.
И попробуйте представить развитие ситуации, если бы архитектор был способен объяснить

проблему на понятном заказчику языке, а также перевести пожелание заказчика на язык,
понятный программистам. Вместо недоверия и непонимания в результате стороны могли бы
придти к согласию.
113
Я не утверждаю, что понимание других языков поможет решить все ваши проблемы, но оно
способно помочь предотвратить недопонимание и недоверие, приводящие к проблемам в
будущем.
Тем же, кто счел этот совет дельным, я желаю удачи!
Автор оригинала – Burk Hufnagel
114
88. Не применяйте смекалку

(В оригинале - Don't Be Clever)
Интеллект, изобретательность, вдумчивость, широта и глубина знаний, а также стремление

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

быть умным. Будьте настолько глупым, насколько сможете, чтобы сделать дизайн так, как
надо. Правильный дизайн никогда не будет умным. Если же применение смекалки окажется
обязательным, то скорее всего, проблема неправильно сформулирована изначально.
Переформулируйте ее так, чтобы вы снова смогли стать глупым. Работайте эскизно,
оставайтесь неконкретным. Никаких «изюминок». Умный архитектор должен оставаться
глупым.
Именно наша смекалка позволяет нам применять «трики» и «хаки», чтобы заставить ПО
работать. Не делайте этого! Вы не Руб Голдберг1. И не агент Макгайвер2, всегда готовый
сделать сложное устройство, имея в руках лишь скрепку, петарду и жвачку. Постарайтесь
выбросить из головы подобные способности. Конечно же, иногда вам понадобится именно
это. Но — гораздо реже, чем вы можете подумать.
Простые, «тупые» решения может реализовать большинство программистов. В таких

решениях каждый компонент делает только что-то одно. Такие решения требуют меньше
времени на создание, а также меньше времени на модификацию в будущем. Они просты и
элегантны. Умные же решения оказываются намертво «вросшими» - их детали слишком
сильно вплетены в общую картину. Они рассыпаются, если их тронуть.
Автор оригинала — Eben Hewitt
1
http://ru.wikipedia.org/wiki/Голдберг,_Руб
2
http://ru.wikipedia.org/wiki/Секретный_агент_Макгайвер
115
89. Проектируйте системы, "прозрачные" в использовании

(В оригинале - Build Systems to be Zuhanden)
Мы создаем инструменты. Системы, которые мы проектируем, предназначены для того,

чтобы облегчить кому-то его жизнь.
Мартин Хайдеггер, немецкий философ 20-го столетия, исследовал то, как люди обращаются
с инструментами в своей повседневной жизни. Люди используют инструменты для
достижения своих целей, и инструмент – часто единственная возможность эту цель
достигнуть. Он ввел термин zuhanden (готовый к использованию, незаметный),
относящийся к инструментам, которые успешно используется. В этом случае назначение
инструмента понятно само по себе, без длительного изучения теории. Мы просто берем
инструмент и делаем то, что нам нужно. Инструмент становится продолжением нашего
тела, становится незаметным. Представьте себе забивание гвоздя молотком или писание
шариковой ручкой. Обратите внимание на то, как легко инструмент становится
продолжением вашей руки. В противоположность этому он также ввел термин vorhanden
(присутствующий в руках), для инструментов, использование которых вызывает сложности.
Инструмент ничем не показывает своего предназначения. Его необходимо изучить, прежде
чем вам удастся использовать этот инструмент для своих целей.
Для нас, проектировщиков ПО, системы, которые мы разрабатываем, являются vorhanden во

время их разработки (а также в тот момент, когда мы получаем отчет об ошибке). Для нас
разрабатываемая нами система – это объект исследования и изучения. Однако для успеха
системы необходимо, чтобы для конечного пользователя система была zuhanden.
Задумайтесь, является ли проектируемая вами система незаметной в использовании?
Понятен ли ее интерфейс пользователю с первого взгляда? Или же ваша система постоянно
требует внимания к себе, отвлекая пользователя от его собственных целей?
Автор оригинала – Keith Braithwaite
116
90. Ищете и удерживайте тех, кто умеет и любит решать

проблемы
(В оригинале - Find and retain passionate problem solvers)
Собрать вместе команду выдающихся разработчиков – одна из наиболее важных для

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

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

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

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

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

(В оригинале - Software doesn’t really exist)
Программистов часто сравнивают с инженерами из «реального мира». Однако у такой

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

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

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

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

(В оригинале - Pay down your technical debt)
В любом проекте, запущенном в эксплуатацию и реально используемом, наступает момент,

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

что цена эта слишком высока для вас. Однако, если перед вами будет выбор между «сделать
как можно быстрее» или потерять значительную сумму денег, быстрое и неидеальное
решение может быть оправданным. Поэтому сделайте его, но не останавливайтесь на этом.
После того, как заказчики получат быстрое решение, вернитесь назад и сделайте это
изменение так, как надо, чтобы оно попало в следующий релиз. Это как потратить
небольшую сумму с кредитки и вернуть ее назад в том же месяце, пока банк не начислил
проценты. Таким образом вы можете сделать требуемые заказчиком изменения быстро, при
этом не давая проекту скатиться в долговую яму.
Автор оригинала - Burk Hufnagel
119
93. Не пытайтесь угадать будущее

(В оригинале - You can't future-proof solutions)
Никто не может предсказать будущее. Если вы примете это утверждение, то следующим

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

системы. К сожалению, защитить архитектуру от будущего не представляется возможным.
Не важно, какое решение вы примете сейчас, когда-нибудь это решение станет устаревшим.
Замечательный язык программирования завтра станет КОБОЛом. А распределенный
фреймворк – DCOM-ом. Другими словами, сегодняшнее решение обязательно превратится
в проблему в будущем.
Если вы примете этот факт, что любой ваш выбор сегодня обязательно станет проблемой в
будущем, то это облегчит вам попытку построить устойчивую к будущему архитектуру.
Ведь если любой ваш выбор окажется неверным в будущем, то просто перестаньте об этом
думать и выбирайте то, что наилучшим образом подходит для вас сегодня.
Одна из проблем архитекторов – слишком большое вложение ресурсов в попытку угадать

лучшую для будущего технологию. Выбор технологии, оптимальной сейчас – уже является
нелегкой задачей. А выбор технологии, оптимальной в будущем – пустая трата времени.
Смотрите на то, что требуется вашим заказчикам прямо сейчас. Смотрите на то, что
предлагается на рынке технологий сегодня. Выбирайте лучшее решение, удовлетворяющее
вашим сегодняшним требованиям, потому что все остальное будет не только неправильным
выбором в будущем, а и неправильным выбором прямо сейчас.
Автор оригинала – Richard Monson-Haefel
120
94. Проблема принятия проекта пользователями

(В оригинале - The User Acceptance Problem)
Люди не всегда рады получить новую систему или серьезное обновление. И это может
угрожать успешному завершению проекта.
Не так уж и редко случается, что люди не соглашаются с решением разработать новую

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

старой). Сюда можно также включить страх потерять необходимую
функциональность в системе или же утратить влияние из-за смены ролей.
2. Люди испытывают страх перед новыми (непроверенными) технологиями
3. У людей могут быть вопросы о стоимости новой системы
4. Люди просто не любят изменений
Каждая причина требует различных решений. Некоторые вы можете предоставить, а

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

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

(В оригинале - The Importance of Consommé)
Консоме – это очищенный до прозрачности бульон, обычно приготовленный из говядины

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

тест: преподаватель бросает 10 центов в приготовленный бульон. Если вы можете прочесть
дату у монетки, лежащей на дне, вы сдали экзамен, если нет – провалили.
Архитектура ПО требует непрерывной очистки и фильтрации всех требований, до тех пор,

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

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

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

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

монетке, лежащей на дне.
Автор оригинала – Eben Hewitt
122
96. Система для пользователя - это ее интерфейс

(В оригинале - For the end-user, the interface is the system)
Существует очень много замечательных программных продуктов, спрятанных за

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

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

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

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

просто удобными, а очень удобными. Чем лучше интерфейс пользователя, тем больше
довольных (а значит, и более продуктивных) клиентов. Если ваш продукт помогает людям
быть более продуктивными, значит, он будет ценным.
Автор оригинала – Vinayak Hegde
123
97. Крупные проекты не строятся, а вырастают

(В оригинале - Great software is not built, it is grown)
Как архитектор вы решаете задачу создания начальной структуры программной системы,

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

известные требования и желаемую функциональность, как бы соблазнительно это не
выглядело. Смотрите на вещи широко, но не позволяйте излишне расширяться проекту.
Позвольте и вам, и вашей системе обучиться адаптации к ситуации по мере ее изменения.
Как этого достичь? Лучший способ – сделать так, чтоб система могла расти и
адаптироваться, и сделать это как можно раньше. Это значит, что нужно начать с
небольшой работающей системы, с работающего подмножества планируемой архитектуры
– с простейшей системы, которая при этом уже может функционировать. Такая
зарождающаяся система будет обладать множеством полезных свойств и сможет научить
нас гораздо большему, чем сразу сделанная большая система или ее проект. Скорее всего,
вы будете вовлечены в ее реализацию. Из-за небольшого размера ее будет легче
протестировать и отследить связи. Для реализации будет достаточно меньшей команды, что
отразится на стоимости. Ее свойства будет легче отслеживать. Ее будет проще запустить.
Она покажет вам, что работает, а что нет, причем сделает это очень быстро. Она покажет
места, сложные для изменения, а также нестабильные места. И все это будет сразу же видно
заказчикам, что даст им возможность адекватно отреагировать на обнаруженные проблемы
в самом начале проекта.
Проектируйте систему настолько маленькой, насколько это возможно. После чего позвольте
ей развиваться согласно глобальному видению. Хотя это может выглядеть как потеря
контроля или даже ограничение вашей ответственности, ваши заказчики будут благодарны
вам за это. Не бойтесь применить эволюционный подход, отбрасывая требования или уже
реализованную функциональность.
Автор оригинала – Bill de hÓra
124

97 Things For Architect

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

97 Things For Architect

Загружено:

Авторское право:

Доступные форматы

97 вещей, которые должен знать

(В оригинале – 97 Things Every Architect Should Know)

Перевод – Александр Лотохов

Эти и другие переводы также доступны онлайн на сайте http://avl2.info

Данная серия переводов распространяется под лицензией Creative Common 3,

1. Ваше резюме не должно быть на первом месте...................................................................5

32. Время все меняет.....................................................................................................................44

66. Единственное решение? Найдите еще одно!......................................................................89

1. Ваше резюме не должно быть на первом месте

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

Автор оригинала: Nitin Borwankar

2. Сложное - упрощайте, с усложнением - боритесь!

Сложность – основное свойство большинства задач. Например, управление воздушным

Большинство фреймворков и «решений» от вендоров являются симптомами болезни

Сложность привлекает разработчиков как свечка мотыльков. Часто с теми же результатами.

Как вам это делать? Отдавайте предпочтение фреймворкам, основанным на работающем

Автор оригинала: Neal Ford

3. Скорее всего, ваша главная проблема - не техническая

Недооценивать технологию ведения переговоров не стоит. Учиться вести переговоры

1. Переговоры не должны быть противостоянием

Если вы настроены на позитив, то вы получите больше, и с меньшей вероятностью

2. Начинайте переговоры лишь когда вы в хорошем настроении.

Если вы рассержены, разочарованы. раздражены, то очень вероятно, что ваш

3. Используйте это как возможность достигнуть взаимных договоренностей на пути

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

Автор оригинала: Mark Ramm

4. Коммуникация - это король, а ясность и лидерство - его

Слишком часто архитекторы программного обеспечения принимают решения со своих

Еще один хороший способ эффективно передать информацию – неформальные митинги в

И если коммуникация – это король, то ясность и лидерство – его покорные слуги.

Автор оригинала: Mark Richards

5. Баланс между техническими требованиями и

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

Рассмотрим, например, отдел разработки компании, предлагающей на рынке сервис

И работа проектировщика заключается не только в том, чтобы спроектировать

Проектировщик может осознанно нарушить баланс в пользу одного из приоритетов в

Подводя итог: проектирование программного обеспечения – это не только лишь

Автор оригинала: Randy Stafford

6. Ищите настоящую причину требований

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

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

И как же это делать? Один из вариантов следует из манифеста agile разработки:

Автор оригинала: Einar Landre

Часто проектировщики ПО вырастают из высокотехнологичных позиций, на которых успех

Хотя измерить влияние проектировщика на проект достаточно сложно, но если

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

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

Автор оригинала - Udi Dahan.

Программистов часто сравнивают со строителями небоскребов, плотин или дорог. И в

Самое сложное в работе строителей городской инфраструктуры – это не спроектировать

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

Первое, когда мы выпускаем релиз, мы подвергаем себя риску, связанному с накопленными

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

Может показаться, что «ранний релиз» является противоположностью «инкрементальной

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

Автор оригинала: Michael Nygard

9. Вы участвуете в переговорах чаще, чем вы думаете

«Нам действительно нужна функциональность Х?» - задает вопрос инвестор.

В конце концов, мы инженеры, а инженеры всегда готовы искать компромиссы. Все мы

Автор оригинала: Michael Nygard

10. Количество имеет значение!

Требование «Быстро» фактически требованием не является. Как и не является требованием

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