В сообществе гибких методологий постоянно встречается один вопрос: «Какая часть архитектуры должна создаваться заранее?» Некоторые теоретики на это отвечают: «Никакая. Безжалостно перерабатывайте свой код, и архитектура сформируется сама». Я никогда не принадлежал к этому лагерю.
Переработка улучшает архитектуру кода без изменения его функциональности. Но чтобы улучшить архитектуру, необходимо отличать хорошее от плохого. У нас уже имеется хороший каталог «запахов кода», которым мы можем руководствоваться, но аналогичные каталоги «запахов архитектуры» мне неизвестны. Кроме того, должна существовать возможность непрерывного внесения изменений даже через границы интерфейсов. Из-за этого я всегда считал, что фундаментальная архитектура системы должна быть сформирована до начала разработки.
Теперь, после проекта Creation Center, я уже не так уверен в этом ответе. Многие серьезные архитектурные блоки были добавлены на относительно поздней стадии проекта. Примеры:
• Поддержка Hibernate, добавлена после двух или трех итераций. До этого момента мы не использовали базы данных.
• Поддержка Spring, добавлена почти на трети пути к версии 1.0, быстро заняла центральное место в нашей архитектуре. Даже не представляю, как мы обходились без нее.
• Поддержка FIT, добавлена на половине пути к версии 1.0.
• Программа записи DVD, куплена и добавлена в конце стадии начальной разработки.
• Поддержка оконных интерфейсов, добавлена за две итерации до выпуска.
В каждом случае перед принятием решения мы тщательно исследовали все доступные варианты. Решение принималось в «последний ответственный момент» – когда затраты от непринятого решения перевешивали затраты на его реализацию. Возможно, если бы поддержка Spring присутствовала в проекте с самого начала, кое-что было бы сделано иначе, но ее добавление на более поздней стадии обошлось без вреда.
Во время ранних итераций наше внимание было направлено на то, каким мы хотели видеть наше приложение – а не на то, как оно должно строиться по канонам Spring.
Related posts: