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

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

Обновление

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

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

В течение четырех лет одна австралийская компания с большим успехом применяла вариант этого подхода. Она выпускала по три релиза программной системы в год. Часть «спокойного времени», которое неизбежно появляется в периоды между выпуском релизов, выделялась на обзор архитектуры и планирование. Таким образом, архитектура обновлялась почти непрерывно.

Архитектурное планирование может существенно сэкономить время даже при очень жестких графиках работ. У саги о доблестной команде Ernst amp; Young, которая во время однодневного соревнования нашла время на проектирование архитектуры своей системы (см. главу 30), есть продолжение. Эта команда в полной готовности появилась на следующем соревновании Software Challenge, проходившем на XTWorld в Брисбене (Австралия). На этот раз они применяли новый инструмент (Delphi от Borland) и пересмотренный план для «безумного проектирования приложений» (так этот процесс назвали их соперники). Кроме того, они использовали управление версиями и резервное копирование, а также быстрый, но тщательный анализ и планирование архитектуры. Они выиграли.

Из журнала Software Development, том 4, № 1, январь 1996 г.

33 Пошаговое улучшение качества