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

Самым мощным катализатором вашей карьеры будут благодарные заказчики, выстроившиеся в длинную очередь, чтобы порекомендовать вас другим — ведь вы так хорошо для них потрудились. Благосклонность клиентов послужит вам на порядок лучше, чем любой новомодный объект новомодного языка и любая свежеизобретенная парадигма. Хотя для архитектора очень важно (и даже жизненно необходимо) быть в курсе новейших тенденций и технологий, никогда не пытайтесь расширять свой кругозор за счет клиента. Помните, что вам как архитектору доверено благополучие вашей организации; соответственно от вас ожидают, что вы будете честно и грамотно действовать в интересах заказчика, избегая любых конфликтов интересов и сохраняя полную лояльность своей организации. Если предложенный проект недостаточно актуален или перспективен для ваших текущих карьерных целей, найдите другой проект.
А что, если это невозможно, и вы все же вынуждены участвовать в таком проекте? И вам самому, и всем остальным будет лучше, если вы будете выбирать технологию в интересах клиента, а не своего резюме. Подчас трудно устоять перед искушением применить новое модное решение, даже если оно плохо подходит к текущей ситуации.
При правильно выбранном решении вы получаете довольную команду и удовлетворенного клиента, а общая напряженность работы над проектом заметно снижается. Часто это позволяет вам глубже изучить уже знакомую технологию или заняться освоением новинки в свободное время. А может быть, у вас даже высвободится время для посещения курсов живописи, о которых вы всегда мечтали. Ваши близкие это тоже оценят — они заметят разницу в вашем состоянии, когда вы приходите домой после работы.
Всегда ставьте долгосрочные потребности клиента над своими собственными краткосрочными потребностями, — и вы не ошибетесь.
В начале 1990-х Нитин Борванкар (Nitin Borvankar) работал в Ingres и Sybase, где создавал первые веб-приложения на базе SybPerl и OraPerl, а вскоре после этого — на базе ранних версий Enterprise Java. Он также был активным участником New-EDI — процесса IЕТF-стандартизации [1] EDI в Интернете. С 1994 года работал, независимым консультантом и исследователем в области организации и интеграции данных в масштабах предприятия, а также обмена сообщениями. В настоящее время занимается схемами баз данных для приложений с фолксономической [2] организацией контента в системах масштаба предприятия, а также проблемами сопровождения БД в социальных сетях, находящих практическое применение в коммерческих отраслях. Входит в Policy Group проекта Data Portability, где занимается, подготовкой лицензионных соглашений и вопросами прав пользователя на владение данными. Помимо этого пишет о базах данных на сайте GigaOm.com и ведет блог  http://tagschema.com. Является владельцем патента в области передачи сообщений через границы доверия (trust boundaries).
  
Снижайте неотъемлемую сложность, устраняйте второстепенную сложность
 
Нил Форд
 
Неотъемлемая сложность (essential complexity) представляет собой проблему, изначально присущую любой задаче. Например, задача координации воздушного движения в национальном масштабе является сложной сама по себе. Управляющая система должна отслеживать в реальном времени точное местоположение каждого самолета (включая высоту), его скорость, направление и место назначения, чтобы предотвратить столкновения в воздухе и на посадочных полосах. Необходимо также оперативно управлять расписаниями полетов, чтобы избежать заторов в аэропортах в постоянно меняющихся условиях — при резком изменении погоды все расписание приходится пересматривать.
 
С другой стороны, второстепенная сложность (accidental complexity) обусловлена теми задачами, которые, как нам кажется, необходимо решить для снижения неотъемлемой сложности. Примером второстепенной сложности может служить устаревшая система управления полетами, используемая по сей день. Система проектировалась для решения сложной проблемы управления движением тысяч самолетов, но это решение порождает свои собственные проблемы. Современные системы управления полетами настолько сложны, что само их обновление становится трудным, если не невозможным делом. Почти во всем мире управление полетами осуществляется по технологиям более чем 30-летней давности.
«Синдром второстепенной сложности» проявляется во многих инфраструктурах (framework) и фирменных «решениях». Инфраструктуры для решения узких, конкретных задач приносят реальную пользу; чрезмерно сложные инфраструктуры создают больше трудностей, чем устраняют.
Сложные решения привлекают разработчиков, как пламя привлекает мотыльков, причем часто с тем же результатом. Решать сложные задачи интересно, а работа программиста по сути состоит из сплошного разгадывания головоломок. Кто не испытывал азарта при решении какой-нибудь невероятно сложной задачи? Однако в крупномасштабных проектах бывает очень трудно избежать второстепенной сложности, сосредоточившись на работе со сложностью неотъемлемой.
Как этого добиться? Отдавайте предпочтение инфраструктурам, созданным на базе работающего кода, а не в башнях из слоновой кости. Соотносите объем кода, направленного на решение непосредственной задачи, с объемом кода, который просто обслуживает взаимодействие пользователя с приложением. С осторожностью относитесь к решениям, продвигаемым фирмами-разработчиками: такие решения не всегда изначально плохи, но в них часто присутствует второстепенная сложность. Проверяйте соответствие решения поставленной задаче.
Обязанность архитектора — решать проблемы, лежащие в плоскости неотъемлемой сложности, без введения второстепенной сложности.
Нил Форд (Neal Ford) — архитектор программного обеспечения и «мемовод» [3] из ThoughtWorks, международного консалтингового агентства, специализирующегося на разработке и поставке комплексных решений. Он является создателем многих приложений, учебных материалов, компьютерных учебных курсов, видео/DVD-презентаций, а также автором и/или редактором пяти книг и многочисленных журнальных статей. Часто выступает на конференциях. Жгучее любопытство по поводу личности Нила можно утолить на сайте  http://www.nealford.com.
  
Возможно, ваша главная проблема не в технологиях
 
Марк Рэмм
 
Прямо сейчас где-то терпит бедствие очередной проект системы расчета зарплаты… А скорее всего, и не один.
Почему это случилось? Потому что разработчики выбрали Ruby вместо Java или Python вместо Smalltalk? Потому что решили использовать Postgres, а не Oracle? Или потому что предпочли платформу Windows, хотя следовало выбрать Linux? Как известно, во всех неудачах проектов обычно винят технологию. Но действительно ли ваша задача была настолько сложна, что возможностей Java оказалось для нее недостаточно?
Проекты обычно создаются людьми, и именно от этих людей зависит успех или провал всего проекта. А раз так, стоит немного подумать, как помочь им добиться успеха.
Возможно, в команде есть кто-то, кто, с вашей точки зрения, не справляется со своей работой и тем самым препятствует успеху проекта. Технология, применяемая для решения подобных проблем, очень стара и проверена временем; в сущности, это едва ли не самое важное техническое достижение в истории человечества. То, что вам нужно, называется общением.
При этом простого владения приемами общения как технологией недостаточно. Уважительное отношение к людям, умение предоставлять им кредит доверия — важнейшие навыки, превращающие умного руководителя в эффективного.