Читаем 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) и фирменных «решениях». Инфраструктуры для решения узких, конкретных задач приносят реальную пользу; чрезмерно сложные инфраструктуры создают больше трудностей, чем устраняют.

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

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

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