Различия кастомизируемых программных продуктов и заказной разработки

Продолжаю развивать тему перехода от заказной разработки к продуктовым решениям. Сразу оговорюсь, что речь, конечно, идет не о программах, тиражируемых в сотнях тысяч или миллионах экземпляров, а об информационных системах, внедряемых в нескольких десятках, может быть сотнях организаций. Как я уже отметил в предыдущем сообщении, такие системы от заказных решений отличает наличие архитектуры и процесса внесения изменений. Philippe Kruchten с соавторами в статье Ретроспектива программных архитектур явно отмечает, что архитектура «отражает замысел разработчиков, связанный со структурой и поведением системы, и защищает ее от «эрозии» под воздействием работ по сопровождению.» Об этом же говорит Yefim Natis (Gartner) в работе Conquering IT Complexity Through Software Architecture ( В переводе на русский Покорение сложности ИТ): «Неконтролируемая сложность дорого обходится и сильно мешает, плохо сказываясь на способности к адаптации и изменениям. Однако сложность — вовсе не результат ошибок, а прямой результат адаптации и изменений, свойство растущей компьютерной среды. Это цена, которую пользователи платят за инновации.» Но далее, в той же статье Натис пишет, что избавится от потока изменений программных систем нельзя, а Эрик Реймонд в работе Волшебный котел красноречиво убеждает нас в том, что сопровождение является основной деятельностью программиста « любой разработчик программного обеспечения или специалист по системному анализу скажет вам, что оно (сопровождение) составляет большую часть (более 75%) оплаченной работы, которой занимаются программисты.»

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

Приведу конкретный пример — движок этого блога wordpress. База данных текущей версии wordpress состоит из десятка таблиц (11, если я не ошибаюсь): сообщения, комментарии, пользователи, таксономии, связи, плюс метаданные по этим объектам. Отрисовка пользовательского интерфейса вынесена в темы. Дополнительный функционал в плагины. Команда разработки развивает движок и приложения для мобильных устройств (кстати, посмотрите на свой блог в iOS и в android – будете приятно удивлены), а полторы тысячи тем, 16 тысяч плагинов и локализация продукта – результат работы сообщества. Задумайтесь, база данных одной из ведущих CMS состоит из десятка таблиц, а самая большая таблица – 23 поля. Разработчикам корпоративных информационных систем есть к чему стремиться.