Идея не новая, но мало где есть примеры такого подхода. Конфигурация имеет минимально необходимый функционал, который может быть значительно расширен.
Каждый из нас сталкивался с ситуацией, когда нужно добавить какой-то функционал в очень сжатые сроки. В таких случаях все сделать, отладить и отловить все ошибки бывает нереально и, когда этот функционал попадает в рабочую базу, то начинают вылезать ошибки, для исправления которых бывает достаточно поменять одну строчку кода, но потом необходимо выкинуть всех пользователей, обновить базу и не факт что не появятся новые проблемы в коде. А обновлять базу в течение дня и прерывать работу своих коллег бывает очень критично для рабочего процесса.
Суть данной публикации в том, чтобы дать программисту инструмент, который позволяет размещать код во внешних обработках, которые хранятся в справочниках. В случае необходимости можно выгрузить обработку, внести изменения в код и загрузить обратно. При этом изменения сразу же начнут действовать без обновления базы.
Можно менять процедуры, функции, тексты запросов, схемы СКД, формы. В приложенной базе есть пример хранения функций в модуле обработки и обращение к ним из встроенной в конфигурацию обработки. Остальной функционал довольно просто можно прикрутить к существующему механизму.
Справочник ВнешниеОбработки хранит файлы внешних обработок, получение которых идет по уникальному имени, при этом берется последний загруженный файл. В модуле обработки находятся экспортные функции, которые могут быть вызваны из любого места конфигурации.
Предусмотрен режим отладки (который должен быть доступен только разработчику), позволяющий отлаживать код подключаемых обработок.
Практическое применение данного механизма:
1. При добавлении нового функционала без возможности полноценного тестирования. В этом случае тестирование и отладка выполняется уже "на котиках" и часто бывает необходимость исправить ошибку "прямо сейчас".
2. В случае если база очень часто обновляется, активно ведется разработка. Процедуры, функции, тексты запросов можно держать во внешних обработках и оперативно дорабатывать, после доработки, тестирования и исправления ошибок встраивать готовый функционал в конфигурацию.
3. В распределенной базе отпадает необходимость обновления в каждом узле. Изменения кода придут с обменом.
4. Когда заказчик сам не знает что хочет и каждый час просит что-то добавить или убрать. Появляется возможность неограниченное количество раз за день вносить изменения и демонстрировать результат.
5. Перестраховаться. Если есть сомнения, что написанный код "завтра взлетит", можно его разместить во внешней обработке и в случае чего изменить.
и т.д.
Тестировалось на платформе 8.3.12.1685
