Заказчика мы настоятельно отговаривали от разработки в расширениях. Мы в своей практике расширения, в основном, используем для быстрого исправления ошибок. Основной довод против - разработку предполагалось вести на платформе 8.3.24. С момента выхода данной платформы официально зарегистрировано несколько десятков ошибок, связанных именно с расширениями. Часть из этих ошибок казались критичными для работы системы. Аргумент заказчик всерьез не воспринял и разработка в расширениях состоялась.
Все работы проводились в одном расширении, подключенном к хранилищу. Вариант с делением доработок по расширениям даже не рассматривался (хотя удочку клиент закидывал, чуть ли не отдельное расширение на каждый объект метаданных), т.к.:
- Во-первых, это дополнительные временные затраты на обслуживание (подключение к хранилищам, обновление) и на принятие решений, в каком расширении выполнять работы.
- Во-вторых, примерно 80% доработок были взаимосвязаны и использовали новые добавленные объекты. Смысла в данном случае пытаться что-то выделить в отдельную ветку не было. (Хотя бы потому, что обратиться к добавленным объектам в другом расширении с помощью консоли запросов не получится.)
- В-третьих, если бардак может быть разведен - его обязательно разведут. Хаос ликвидировали в зародыше и предупредили временные потери на наведение порядка на переносах доработок между расширениями.
С точки зрения последующего сопровождения, для себя я, скорее всего, бы вывела в отдельное расширение некоторые переопределенные типовые методы, доработки в которых никак не были связаны с изменениями в метаданных. Чтобы минимизировать риски, что расширение станет неактивным после очередного обновления. Но это задача, над которой нужно было основательно подумать, и потратить на нее время в рамках проекта внедрения, где, естественно, горели сроки и был острый дефицит ресурсов, - не представлялось возможным.
Наши опасения по поводу ошибок платформы подтвердились. В ходе разработки мы словили очень неприятную ошибку "Таблица или поле DimHash не содержится в разделе FROM". Ошибка воспроизводилась совершенно случайным образом в пользовательском режиме и не позволяла переносить данные и тестировать доработки. К счастью, тестирование и исправление данную проблему решило. В противном случае разработка в расширениях на данной ошибке могла бы и завершиться.
В рамках финального переноса данных в базе вылезла ошибка "Запись не найдена в менеджере имен базы данных". Причем ошибка проявилась ровно в тот момент, когда разработчики на территории заказчика на выходных грузили данные. Прямо по закону подлости: когда не проверить поможет ли ТИИ и не ясно, не полезут ли массово ошибки в первый рабочий день? Не лучше ли откатиться и начать загрузку данных заново?
После запуска вылезла "Поле DimHash не может принимать значение NULL", для которой уже даже ТИИ не помогло. Спасла принудительная реструктуризация регистра накопления, за счет добавления реквизита в основной конфигурации.
Нервы нам эти ошибки потрепали основательно.
Небольшой совет:
- Обязательно изучите список зарегистрированных ошибок по работе с расширениями для выбранной версии платформы. Кто предупрежден - тот вооружен. И будьте морально готовы, что что-то неучтенное может вылезти.
На текущий момент последние версии платформы позволяют выполнять в расширениях практически все. Но "практически все" - это не "все". Основная конфигурация "на замке" не осталась, так что ключевое преимущество, которое выдвигается в аргументах за разработку в расширениях, не удалось получить. Нам пришлось добавить новые реквизиты в типовые регистры и планы видов характеристик. Часть из них была ссылочного типа на новые объекты. В итоге, несколько новых справочников и роли на них были добавлены в основную конфигурацию. Здесь можно было бы помудрить и добавить новые справочники в расширение, но мы не стали. Также понадобились новые подсистемы. Из вышесказанного второй совет:
- Изучите документацию на ИТС к выбранной платформе в части работы с расширениями. Вероятно, в ней найдутся весомые доводы для клиента против использования расширений. (Если нам не верит - вдруг, поверит официальной документации?) В документации есть раздел с ограничениям, однако он содержит только ключевые. Остальные описываются в прочих подразделах.
Достаточно важной задачей, которую нужно было решить в рамках проекта - как обеспечить "сопровождаемость" наших доработок? Как минимум дважды нам самим нужно было выполнить обновление на последний релиз. В результате решения данного вопроса появилось следующее правило:
- Если требуется внести изменение в обработчик события (в модуле объекта/формы) и код является независимым от кода в исходном обработчике - доработка реализуется в обработчиках расширения события перед/после. Во всех остальных случаях для модификации типового кода изменения реализуются через переопределение методов с использованием директивы &ИзменениеИКонтроль. (По-умолчанию, предполагается что все модификации типового функционала при наличии технической возможности выполняются программно).
Обработчики расширения события "перед/после" отлично справляются с задачам по:
- модификации форм
- добавлению проверок заполнения
- добавлению дополнительной логики при записи/проведении объекта.
Т.к. эти методы вызываются независимо, они нечувствительны к удалению/добавлению основного метода, обрабатывающего это событие.
Директива &ИзменениеИКонтроль позволяет контролировать на обновлениях:
- изменения в переопределенных методах
- удаление типовых методов
- изменение состава параметров.
Достаточно после обновления основной конфигурации проверить возможность применения расширения.
Огромный плюс - возможность трехстороннего объединения с помощью внешних программ. Легко и удобно - по щелчку на гиперссылку отрабатываем нужный метод:
С точки зрения актуализации расширений после обновления типовой конфигурации - сделано все очень удобно.
Как ни странно, в процессе разработки, после платформенных ошибок, самой большой проблемой стало комментирование кода. Регламент разработки сидит глубоко в подсознании и требует каждое изменение обрамить комментариями.
- Если, например, обрамить переопределенный метод с директивой &ИзменениеИКонтроль комментариями - это приведет к ошибке.
- К непонятным сбоям также может приводить наличие закрывающего комментария у новых методов в переопределенных модулях - аварийно завершается сеанс при отладке или выпадает ошибка при обновлении ИБ. И проблема точно не в кэшах - чистили.
- Всем нам присуща некая "зашоренность" мышления, а мозг - "тварь ленивая. Чтобы понять, что в переопределенных методах с директивой &ИзменениеИКонтроль все комментарии нужно обрамлять директивами #Вставка #КонецВставки, потребовалось совершить небольшое умственное усилие.
Миловаться с комментариями мы не захотели и вывели следующее правило оформления комментариев:
- Все комментарии в заимствованных модулях должны размещаться только внутри процедур и функций. В методах с директивой &ИзменениеИКонтроль все комментарии обрамляются директивами #Вставка #КонецВставки
В 24-ой платформе, к счастью, уже реализована полноценная работа с консолью запросов. Если бы этой функциональности не было, фактические трудозатраты на разработку были бы процентов на 10-15 больше. Это одна из ключевых причин, по которым на более ранних версиях платформы возможность приличной по объему часов разработки в расширениях принципиально не рассматривалась. А вот с отчетами на СКД вылезли нюансы.
- Во-первых - нельзя для отладки сохранить отчет как внешний. Слетают настройки, как только открываете внешний отчет в конфигураторе. Как результат - временные затраты на отладку отчетов немного возрастают. Быстро поэкспериментировать с настройками без внесения изменений в основной отчет не получится.
- Во-вторых, обращение к предопределенным элементами и полям со ссылочными типами, отсутствующим в расширении, приводит к ошибкам. Причем ошибки не препятствует настройке вариантов и отладке отчета. Но после помещения в хранилище в отчете слетают все настройки и отчет становится неработоспособным. Особенно это обидно, если в отчете сложный расчет итогов. Можно добавить все необходимые объекты в расширение, тем более что это предлагается сделать автоматически.
Но нам это решение не понравилось - конкуренция за корень и так высокая. И дополнительно усложняется навигация по конфигурации расширения, если в нее добавлять все подряд.
Мы для себя сформировали следующее правило:
- В отчете на СКД источник-запрос не должен порождать никакие ошибки. Добавлять объекты в расширение для устранения ошибок запрещено. Устранение ошибок осуществляется через параметризацию запроса и замену этих параметров на необходимый текст при компоновке результата.
На этом, собственно, специфика, с которой мы столкнулись на разработке в расширении, заканчивается.
В качестве вывода:
- Провести приличную по объемам разработку на проектах внедрения возможно с весьма малым списком ограничений.
- Повторить опыт внедрения с разработкой в расширениях в ближайшее время не хотелось бы. Слишком много нервов отнимают ошибки и ограничения платформы. И, естественно, эти ошибки имеют неприятное свойство проявляться в самый критичный и неподходящий момент. Возможно на более старших версиях платформы ошибок поменьше - пока не анализировали.
- С точки зрения организации процесса разработки и скорости работы - разницы никакой, что в расширении разработку вести, что в основной конфигурации. Возможность обращения к типовым объектам в консоли запросов из расширения поддержана.
- Если разработку вести в хранилище - конкуренция за корень в расширении существенно выше.
- Если в рамках проекта внедрения дробить разработку по расширениям - скорость разработки упадет. Скорее всего начнется путаница - где и что добавили. Дробить целесообразнее уже в рамках сопровождения, когда после нескольких итераций обновления станет понятно, что действительно стоит в отдельные расширения выносить.
- Как до данного проекта, так и после придерживаюсь мнения, что все изменения, связанные с организацией хранения данных, должны выполняться в основной конфигурации, чтобы минимизировать риски потерь. Плюс ошибки у нас как раз вылезли, связанные с хранением. Никто не застрахован, что расширение случайно не отключат (у нас был опыт, когда перепутали кнопки "загрузить" и "добавить"). Есть риски, что после очередного обновления платформы вы расширение реанимировать не сможете (среди ошибок 24-ой платформы были и такие, что в базу зайти не могли).
- Из минусов дополнительно хочется отметить - если все доработки выполнены в расширениях, теряется "общая картина" изменений. Та, которую дает отчет о сравнении двух конфигураций. Я пока не нашла ответ на вопрос, как быстро оценить в незнакомой системе, что у клиента сильно модифицировано. Сколько, например, будет стоить обновление и какие проблемы можно ожидать после него? Как эту оценку быстро сделать, если в базе, например, подключены десятки расширений? В расширениях не виден контекст доработанного кода (но это субъективно).
- С точки зрения последующих обновлений контроль за изменениями и адаптация модифицированных методов реализованы удобно. А сломались доработки или нет - все равно проверять нужно.
- Из преимуществ отметили скорость. Операции внесения изменений в расширение, сравнения/объединения, выгрузки конфигурации для передачи заказчику - выполняются моментально. С этой точки зрения скорость разработки даже немного повышается.
- Расширение практически ничего не весит по-сравнению с основной конфигурацией - можно хоть через мессенджеры клиенту передавать.
- Инструмент позволяет распараллелить работы между различными исполнителями (например, заказчик сам часть доработок реализует) без необходимости организации единого пространства для разработки. Если клиент не может предоставить удаленный доступ к своей инфраструктуре и не может подключаться к Вашей, использовать расширения очень удобно.
P.S. Статью хотелось опубликовать еще несколько месяцев назад, но все никак руки не доходили откорректировать. Скорее всего информация немного устарела, т.к. сейчас активно на последних релизах типовых конфигураций продвигается 27 платформа. Но пусть будет - может, кому-то что-то пригодится. Мне подобного обзора, с чем можно столкнуться, если клиент настаивает только на расширениях, до старта проекта не хватило.
Вступайте в нашу телеграмм-группу Инфостарт