Неотъемлемая сложность (essential complexity) представляет собой проблему, изначально присущую любой задаче. Например, задача координации воздушного движения в национальном масштабе является сложной сама по себе. Управляющая система должна отслеживать в реальном времени точное местоположение каждого самолета (включая высоту), его скорость, направление и место назначения, чтобы предотвратить столкновения в воздухе и на посадочных полосах. Необходимо также оперативно управлять расписаниями полетов, чтобы избежать заторов в аэропортах в постоянно меняющихся условиях — при резком изменении погоды все расписание приходится пересматривать.
С другой стороны, второстепенная сложность (accidental complexity) обусловлена теми задачами, которые, как нам кажется, необходимо решить для снижения неотъемлемой сложности. Примером второстепенной сложности может служить устаревшая система управления полетами, используемая по сей день. Система проектировалась для решения сложной проблемы управления движением тысяч самолетов, но это решение порождает свои собственные проблемы. Современные системы управления полетами настолько сложны, что само их обновление становится трудным, если не невозможным делом. Почти во всем мире управление полетами осуществляется по технологиям более чем 30-летней давности.
«Синдром второстепенной сложности» проявляется во многих инфраструктурах (framework) и фирменных «решениях». Инфраструктуры для решения узких, конкретных задач приносят реальную пользу; чрезмерно сложные инфраструктуры создают больше трудностей, чем устраняют.
Сложные решения привлекают разработчиков, как пламя привлекает мотыльков, причем часто с тем же результатом. Решать сложные задачи интересно, а работа программиста по сути состоит из сплошного разгадывания головоломок. Кто не испытывал азарта при решении какой-нибудь невероятно сложной задачи? Однако в крупномасштабных проектах бывает очень трудно избежать второстепенной сложности, сосредоточившись на работе со сложностью неотъемлемой.
Как этого добиться? Отдавайте предпочтение инфраструктурам, созданным на базе работающего кода, а не в башнях из слоновой кости. Соотносите объем кода, направленного на решение непосредственной задачи, с объемом кода, который просто обслуживает взаимодействие пользователя с приложением. С осторожностью относитесь к решениям, продвигаемым фирмами-разработчиками: такие решения не всегда изначально плохи, но в них часто присутствует второстепенная сложность. Проверяйте соответствие решения поставленной задаче.
Обязанность архитектора — решать проблемы, лежащие в плоскости неотъемлемой сложности, без введения второстепенной сложности.
Нил Форд (Neal Ford) — архитектор программного обеспечения и «мемовод»[3] из ThoughtWorks, международного консалтингового агентства, специализирующегося на разработке и поставке комплексных решений. Он является создателем многих приложений, учебных материалов, компьютерных учебных курсов, видео/DVD-презентаций, а также автором и/или редактором пяти книг и многочисленных журнальных статей. Часто выступает на конференциях. Жгучее любопытство по поводу личности Нила можно утолить на сайте http://www.nealford.com.