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

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

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

Было бы большим соблазном просто вернуться к тем легендарным дням функциональной декомпозиции, когда дисциплинированные разработчики с помощью CASE-инструментов проектировали устойчивую и упорядоченную архитектуру всей системы. Такое проектирование велось до написания первых строк кода. Однако к тому времени, когда одна команда при помощи традиционных методов создает лишь системную архитектуру, RAD-команда 1, оснащенная инструментами быстрого визуального проектирования, уже сдает готовую рабочую систему. Поэтому методы построения системной архитектуры необходимо включить в ускоренный цикл разработки. Построение надежной структуры не должно существенно замедлять процесс разработки в целом.

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

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

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