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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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