Человеческий фактор в программировании.

Второй шанс.

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

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

Было бы большим соблазном просто вернуться к тем легендарным дням функциональной декомпозиции, когда дисциплинированные разработчики с помощью САSЕ-инструментов проектировали устойчивую и упорядоченную архитектуру всей системы. Такое проектирование велось до написания первых строк кода. Однако к тому времени, когда одна команда при помощи традиционных методов создает лишь системную архитектуру, RАD-команда¹, оснащенная инструментами быстрого визуального проектирования, уже сдает готовую рабочую систему. Поэтому методы построения системной архитектуры необходимо включить в ускоренный цикл разработки. Построение надежной структуры не должно существенно замедлять процесс разработки в целом.

Возможно, для этого надо заново пересмотреть место архитектуры программного обеспечения в процессе разработки. Обычно под архитектурой мы понимаем нечто, предшествующее построению. Однако так же, как можно переписать код, можно перестроить и архитектуру (в мире экстремального программирования такая процедура называется рефакторин-гом). Например, одному большому банку в Австралии пришлось вернуться к своим традиционным системам после того, как был прекращен один претенциозный и чрезмерно крупный проект построения новой общебанковской информационной системы. Прежняя система объединяла многие поколения клуджей[Клудж (от англ. кludgе) — устройство, программа или ее часть, которые теоретически не должны работать, но почему-то работают. — Примеч. ред.

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