Java-разработчик долгое время наслаждались свободой разработки, тестирования и хранения своих исходных файлов и архивов на локальных ПК, возлагая ответственность за управление изменениями исключительно на централизованные системы управления исходным кодом. Однако в корпоративной среде разработчики могут находиться по разные стороны земного шара и при этом одновременно работать над одним и тем же кодом, из-за чего эта модель быстро становится совершенно неуправляемой. Например, предположим, что требуется применить пакет поддержки SAP к измененному приложению SAP CRM: необходимо неким образом быстро определить, какие именно файлы изменены SAP, а какие – разработчиком, чтобы применение изменений из пакета поддержки не повлекло за собой нарушение работы приложения¹.

¹ Концепция модификации, широко известная в мире ABAP, теперь вводится в Java благодаря NWDI.

На Рис. 1 ниже показаны характерные черты типичного процесса разработки на Java. Этот процесс должен выглядеть знакомым для любого разработчика, побывавшего в команде Java-программистов. Возможно, знакомыми покажутся и общие болезненные моменты, подчеркнутые в левой части рисунка:

• Сложность поиска исходных версий: эта проблема встает особенно остро, когда требуется произвести “откат во времени” для поддержки старых версий. Также непросто координировать параллельную работу над несколькими версиями одного объекта (например, одновременное устранение ошибок и добавление новых функций) и не допускать конфликтов компоновки.
• Сложность поиска и отслеживания сторонних библиотек: большинство поставщиков J2EE не включают в комплект автоматизированные инструменты обнаружения исходного кода сторонних библиотек, требуемых для разработки проекта. Даже в случае использования систем управления исходным кодом третьих фирм разработчикам может потребоваться определенное время для поиска нужных версий исходного кода. Например, в большинстве подходов к управлению версиями подразумевается обход всех ветвей решения в поисках конкретных файлов, связанных с определенным уровнем версии. При этом удовлетворительного результата можно достигнуть только в том случае, если и разработчик, и все члены команды сумеют найти правильные версии!
• Расхождения между локальной и центральной среда ми: нередко в архивы, на которые установлены ссылки, либо которые используются повторно, вносятся изменения на центральном сервере непосредственно во время локальной разработки. Зачастую разработчики компонуют и тестируют свои компоненты с использованием устаревших копий, что приводит к дальнейшим проблемам компоновки на сервере группы. Даже если разработчики обновляют локальные копии перед локальной сборкой, не исключено, что в период между локальной сборкой и централизованной ночной сборкой используемые сторонние архивы будут изменены.
•  Конфликты, возникающие при одновременной работе нескольких разработчиков над одним объектом: возможны коллизии изменений, вносимых разработчиками в разные версии одного и того же объекта (например, обслуживание и обновление) во время разработки или после модификации и обновления, особенно же – во время процесса сборки.

Рис. 1 Типичный процесс корпоративной Javaразработки с NWDI и без нее