Перелом наступил тогда, когда после трех итераций в проект была введена поддержка Spring1. Мы следовали методологии «гибкой архитектуры»: поддерживали минимальную архитектуру и добавляли новые архитектурные возможности только тогда, когда затраты от их отсутствия превышали затраты на их реализацию. Это то, что в методологии Lean называется «последним ответственным моментом». Поначалу мы лишь в общих чертах представляли себе инфраструктуру Spring, поэтому решили не зависеть от нее, хотя и ожидали, что позднее она нам понадобится.
При добавлении Spring к проблемам зависимостей файлов .jar добавились проблемы с конфигурационными файлами. Каждая конфигурация развертывания должна была иметь собственный файл beans.xml, но более половины компонентов дублировалось между файлами – очевидное нарушение принципа «не повторяйся2», и несомненный источник дефектов. Нельзя полагаться на ручную синхронизацию определений в XML-файлах под тысячу строк. Кроме того, разве XML-файл размером под тысячу строк не является тревожным признаком?
Нам требовалось решение, которое обеспечивало бы модульное разбиение файлов beans, управляло зависимостями файлов .jar, позволяло хранить библиотеки поблизости от кода, в котором они используются, и управлять путем к классам во время построения и выполнения.
Related posts: