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

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

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

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

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

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

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

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

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

Беркхардт Хафнагель

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

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

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

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

• Наконец бизнесмен завершает свою речь и выжидательно смотрит на архитектора.

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

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

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

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

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

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

Тем читателям, кто находит эту точку зрения разумной, я желаю успеха на их пути. Или, как говорят клингоны, — Qapla![40]

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

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

Ричард Монсон-Хейфел

Сегодняшнее решение становится завтрашней проблемой

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

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

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

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