Т.З. примерно следующее — необходимо иметь некоторый «быстрый старт» для приложений с стандартным функционалом. Дополнительным (и самым «заковыристым») условием является то, что этот стандартный функционал необходимо иметь возможность изменять самым невероятным образом, вплоть до полного отключения и замены своим (специфичным для данного приложения) кодом.
Приведу жизненный пример: есть необходимость делать ОЧЕНЬ похожие приложения. Например интернет-магазины, которые построены на примерно одинаковых схемах данных, бизнес-процессах и тп. Т.е. функционал любого из магазинов примерно идентичен, различается только view слой.
Однако в одном из магазинов цена формируется не из таблицы Prices, а получается по более сложной схеме из хранимой процедуры.
Собственно задача такая — как уменьшить «повторяемость кода» (т.е. отойти от monkey-patching-а) и при этом не потерять полный контроль над кодом.
После непродолжительного анализа существующих решений пришёл к выводу, что существует три вменяемых подхода к решению:
Заявки и анкеты: как попасть в программу?
RoR-style (он же maven-archetype)
Весь (практически) код приложения создаётся для приложения в начале разработки автоматически (скриптом, батником, архетипом и тп) а в последствии изменяется под свои нужды в каждом конкретном проекте.
Примером такого подхода являются большинство фреймворков на динамических ЯП: ruby on rails, django, grails,… Кроме того в java существует такой фреймворк как appfuse, использующий maven примерно для тех же целей (автогенерации начального кода).
- Очень простая структура кода. Нет дополнительных описаний модулей или их конфигурирования. Зачастую — просто код на основном ЯП.
- Скорость работы приложения — см. ниже
- Monkey-patching. Изменения (например bugfix) в основном коде придётся вносить во все проекты вручную.
Java-style
Код разносится по библиотекам и делается очень «настраиваемым» (код в таких библиотеках должен очень хорошо настраиваться и, кроме всего прочего, его можно заменить собственным кодом, специфичным для данного проекта).
Примером такого подхода является например eclipse ide или nuxeo ecm, которые используют equinox (OSGI реализация) для уменьшения «связанности» кода (code decoupling).
- отсутствие monkey-patching-а (изменения произошедшие в базовой библиотеке автоматически появятся во всех приложениях, его использующих).
- скорость (при использовании такой прослойки как equinox все операции взаимодействия между модулями приложения будут по определению медленнее, чем без использования такой прослойки. Насколько это замедляет приложение на практике сказать сложно — необходимо тестирование).
- дополнительное «оформление» кода (в зависимости от фреймворка описание отдельного модуля потребует как минимум одного «файла описания» этого модуля. Так в nuxeo — это xml файл, в котором описывается модуль, его зависимости от других модулей и методы его «расширения». Т.е. то, как его можно сконфигурировать или отключить.
Специфичное ручное тиражирование
Наверное всем знакомое разнесение кода по библиотекам… Это когда ручками, без всяких «методов и концепций» а так — как бог на душу положит и архитектура позволит… Для Java кода — это использование Interface-ов и применение паттерна plugin, для view слоя — это написание чего-нибудь типа customViewHandler-а и так далее.
Тиражируемый бизнес
- Не надо ничего изучать, не надо применять новые фреймворки. Весь код «специфичен» для данной области (будь то core или view или ещё что).
- Неуниверсальность. Для частного случая сложно предсказать заранее можно ли будет придумать «вынесение кода в библиотеку» или нет. А если будет возможно вынести код, то возможно это потребует нестандартного (не привычного) стиля написания кода или дополнительного его описания.
Заключение
В заключение хотелось бы спросить у аудитории — кто какой метод использует и насколько успешно?
Источник: habr.com
Тиражируемость, ау, где ты?!
На так давно меня пригласили на дискуссию о будущем ERP-систем: какими они станут в будущем, какие технологии должны применяться и т.д. Как ни странно, беседа шла, в основном, о технологиях низкого уровня, о технологиях вычислений, представления данных.
erid: LjN8KXX2o
ООО «ИТ Медиа»
На так давно меня пригласили на дискуссию о будущем ERP-систем: какими они станут в будущем, какие технологии должны применяться и т.д. Как ни странно, беседа шла, в основном, о технологиях низкого уровня, о технологиях вычислений, представления данных.
И больше всего меня поразило, что участники обсуждали, как представлять данные, а не что представлять.
Почему-то производителей не беспокоит, что большая часть ERP-решений сегодня являются не тиражируемыми, а скорее эксклюзивными. Каждый клиент платит деньги за реализацию тех же самых функций, за которые платил предыдущий. И это при том, что в большинстве своем такие функции не являются чем-то изысканным. Поэтому, на мой взгляд, сначала необходимо решить вопрос именно тиражируемости, т.е. сделать так, чтобы бизнес-приложения работали сразу, а не через год после инсталляции (да и то не факт), а затем уже думать о том, как совершенствовать технологические платформы и средства представления данных.
«Счастье в коробке»
Все понимают, что тиражируемое решение — это хорошо со всех точек зрения. Это понимает и бизнес, и разработчики ERP-систем. Производители, конечно же, сразу взяли этот термин на вооружение, и во всех пресс-релизах «пиарят» его направо и налево. Это не важно, что тиражируемостью в большинстве случаев и не пахнет. Главное, чтобы клиент прочитал пресс-релиз об очередном «успешном внедрении».
Почему ни у кого не возникает мысли переписывать «под себя» MSWord или MSExcel, OpenOffice, Adobe Reader и т.д.? Все просто: потому что эти продукты работают сразу, то есть «здесь и сейчас» (plugplay, то бизнес захочет их кромсать и переписывать? Конечно же, нет! Переписывание денег стоит, и не малых, и бизнес просто вынужден этим заниматься, потому как получает откровенно сырые решения. И даже не решения, а скорее некие платформы, на базе которых за свои же деньги уже пытается сделать решение. И так каждый клиент.
Понятно, что сравнивать ERP-систему с MSWord не совсем корректно. Однако я намеренно привел именно это сравнение. В любой ERP-системе 80% функционала абсолютно одинаково для всех клиентов. Потому что все компании работают примерно по одним и тем же законам, документооборот (в особенности по унифицированным формам) тоже не сильно отличается.
Каждая компания — это не отдельно взятая микроэкономика со своими законами. Если бы это было так, то не существовало бы международных стандартов отчетности, все отчитывались бы по своим собственным принципам. Финансовые и логистические потоки во всех компаниях очень похожи.
Так почему не дать бизнесу некое решение, где уже настроена и работает система управления затратами, логистикой, финансами? Но только так, чтобы это решение работало, чтобы были настроены бизнес-цепочки. Я уверен, что большая часть среднего и малого бизнеса с удовольствием возьмет готовый инструмент, вместо того чтобы изобретать свой собственный, ошибаясь на каждом шагу. Другой разговор, что в рамках цепочки нужно расставить сотрудников в рамках конкретной организации. Но одно дело — определить функциональное разделение доступа сотрудников в рамках существующей цепочки и совсем другое — изобретать эту цепочку.
Кому велосипед?
На практике более половины проектов по внедрению ERP-систем превращаются в изобретение велосипеда, когда на каждом проекте разработчики делают то же самое, что и на предыдущем. И это обстоятельство не мешает производителям витать в эмпиреях, устраивать семинары, на которых рассказывать потенциальным «жертвам» о том, как «корабли бороздят просторы вселенной», а затем, когда «клиент клюнул», за его же деньги реализовывать в своих продуктах фундаментальные (а зачастую даже элементарные) функции по учету, не говоря уже про анализ.
Я приведу небольшой фрагмент из обзора рынка ERP-систем для представителей среднего и малого бизнеса, над которым сейчас работаю. Речь пойдет об одном ERP-решении всемирно известного бренда.
В рамках обзора я лично проводил тестирование целого ряда тиражируемых программных продуктов, причем тестирование с обязательным сопровождением и комментариями представителя. Нами был разработан некий бизнес-кейс, и предварительно мы показали его руководителям нескольких предприятий.
Первые радости