На прикладные решения мы затратили в разы больше времени и средств, чем на
платформу. Код настроек лежит в непрозрачных двоичных
.gsf файлах. Проследить, вычленить, откатить изменения от версии к версии невозможно. Методика апгрейда существующих баз, переноса изменений от одного клиента другому, доработки и разработки хаотична и трудоемка. Юнит тестирование отсутствует как таковое.
Пришло время разгрести эти авгиевы конюшни.
Надо:
Легковесный текстовый формат с минимумом разметки. Из стандартов -- YAML 1.1 вне конкуренции. Отчеты FR4 включать в файл как отформатированный, удобочитаемый XML с отступами.
Никаких промежуточных состояний типа "настройка загружена в базу, но не активирована".
Никаких "затягиваний" объектов по зависимостям при формировании настройки. Только то, что программист включил непосредственно, должно идти в файл.
Один объект должен входить только в один файл. Использование одного объекта в разных прикладных системах через выделение его в отдельный модуль.
Никакой самотужной терминологии. Хватит с нас пакетов и настроек. Даешь модули, приложения, компоненты, пространства имен и т.п.
Сравнение и синхронизация текущего состояние базы с содержимым файлов на диске. Отдельный механизм загрузки/выгрузки не основанный на существующем коде сохранения в поток.
Использование РУИД-ов и уникальных наименование объектов для обозначения связей. Раскрытие полного пути при сохранении элемента древовидной иерархии.
Git или Subversion в качестве основной системы хранения и распространения настроек. Никаких больше "я переслал тебе настройку в имэйле, не забудь загрузить и активировать ее". Ветви в хранилище исходного кода для специфических решений, сделанных под конкретного клиента.
Минимум служебной информации. Контроль версий, история и логирование средствами VCS.
Списки обработчиков события и перекрытых методов для безболезненного совмещения нескольких прикладных решений на одной базе.
Источник картинки: http://www.marvunapp.com/Appendix3/augeanstables.htm
Комментариев нет:
Отправить комментарий