Comments 23
Сам-то инструмент создавался ради того, чтобы не снимать конфигурацию с поддержки. Но поддержка и реализация этого инструмента доставляет не меньше проблем. Такой вот каламбур :)
Удобная вещь, особенно когда конфа на поддержке, а исправить нужно сейчас и не ждать обновление, которое может выйти не так быстро.
И чтобы меньше с формами эксперементировать прописывайте элементы формы программно.
Приколюха, 1с косячит так часто , что уже не может оперативно исправлять свои косяки в конфах, а механизм костыля исправления выдает за что-то нужное конечному пользователю на совершенно голубом глазу.
Причем за 10 лет механизма ревизии: " этот патч не нужен, а вот с этим вообще 1с не запустится" так и не появился, вот и ловишь в конфигураторе, какой их чудо патч рушит систему. Отсюда вывод что это не для людей было сделано, даже видимость не пытаются создать. Костыль на от-е-бись, дело раскрыто
Перед/После/Вместо/ПродолжитьВызов это наследование методов для альтернативно одаренных
Если бы расширения были нормальным механизм модульности (как в тех же Java приложениях), то и типовые конфигурации были бы на них построены и были бы модульными (как, например, в lsFusion). А так, если сам же разработчик 1С не пользуется своим же механизмом, то однозначно это костыль.
Часто для bugfix используется этот механизм, после выхода релиза, расширение удаляется.
Это другое. Суть в том, что могли бы типовое решение (например, ERP) разбить на разные расширения (модули), с возможностью подключения/отключения. Например, отдельно Закупки, отдельно Бухгалтерия и т.д. Как в том же SAP (SAP MM, SAP FI и т.д.). Но почему так не сделали ? Почему существуют отдельные дублирующие конфигурации вместо просто разных расширений ?
В этом плане согласен ) Может быть придут к этому, когда реализуют полную функциональность в расширении, как и в основной конфигурации.
Все же замечу, что конфигурации специализированные. В ерп бухгалтерия есть, но все же не такая богатая, как 1с БП. В самой бухгалтерии не очень то и поторгуешь в розницу, а в рознице нет бух учёта и производства. Так что о дублирующих я бы не говорил.
Согласен отчасти, отсутствие модульности - это самый большой недостаток платформы на данный момент по моему мнению, но расширения всё таки для другого
Вообще-то имейте в виду, что текущие топовые конфигурации начали разработку тогда, когда расширениями мало что можно было сделать. Соответственно, они так и разрабатываются.
Зато новейшие отраслевые конфигурации -- модули к ERP -- теперь разрабатываются именно как расширения. См. например, не так давно вышедшую LIMS. Так что давайте обсуждать устрицы с теми, кто их ел, а чем пользуется или не пользуется разработчик -- будем смотреть по его решениям, а не придумывать.
В любом случае, без наследования и полиморфизма модульность будет, скажем прямо, очень специфическая.
Не, давайте скажем так: без наследования и полиморфизма объектная модель будет так себе. Но 1С изначально декларирует концепцию "предметно-ориентированного" программирования как сильно специфический вариант "объектно-ориентированного".
Нам вот в расширениях не хватает множественного наследования: возможности поставить одни расширения в зависимость от наличия других и применять ИзменениеИКонтроль в несколько слоёв либо по отношению к другому расширению, а также на результат параллельного применения двух расширений.
Основная причина в то, что мы разрабатываем свои расширения для некоторых белорусских конфигураций как отдельный продукт-модуль, и хотелось бы, чтобы расширения, реализующие функциональность под конкретного заказчика, могли накладываться на общее расширение-продукт, а они вместе -- на основную конфигурацию.
Нам вот в расширениях не хватает множественного наследования: возможности поставить одни расширения в зависимость от наличия других
Это не множественное наследование, а просто зависимость между модулями. Но вообще, конечно, странно. Сделать возможность указывать зависимость между расширениями и выполнять их в порядке зависимостей - это же очень легко делается. Удивительно, что этого нет. При том, что частично последовательность же контролируется исходя из логики Адаптация, Исправление, Дополнение.
это же очень легко делается
Простите, а Вы точно программист? Там уже навскидку пачка трудностей напрашивается. Вроде контроля наличия расширений, контроля диапазона версий расширений, различных спорных или взаимоисключающих моментов вроде "вставки внутри вставки", противоречивые изменения и т. п. Это мы ещё внутреннюю архитектуру базы не затронули.
Простите, а Вы точно программист?
Мы просто это как раз реализовали в lsFusion без каких-либо проблем. Нет там никаких сложностей.
Там уже навскидку пачка трудностей напрашивается.
Смотрите, сейчас в 1С и так можно подключать кучу расширений. Что будет в спорных ситуациях ? Они сами автоматически разрешатся ? Я понимаю, что у 1С уже крайне кривая архитектура (привет обратной совместимости и техническому долгу), о чем мы уже писали в статье, и там проблем будет выше крыши. Но почему их должно стать больше просто от явно заданного порядка инициализации расширений (в соответствии с зависимостями) ? Просто выстроить дерево в список и инициализировать их по порядку.
Расширения в 1С лучше всего описывает армейская поговорка: если это выглядит глупо, но это работает, значит не так уж это и глупо. Впрочем, это применимо не только к 1С, а вообще чуть менее, чем повсеместно.
ИМХО, где-то с 8.3.16 расширения доведены до рабочего состояния. Сам давно работаю только через расширения и внешние обработки, если версия конфигурации это позволяет. Проблем не испытываю. Те кто говорят, что это костыль, просто забыли (или вообще никогда не знали) что такое подписки на события, переопределяемые процедуры и обновление доработанной типовой конфигурации, особенно если доработки делала другая команда.
Расширения - отличный инструмент, на 8.3.23 почти весь функционал нужный в моей работе там есть. Для себя выделил несколько правил работы с расширениями:
1) Расширения в идеале должны быть полностью независимыми. Отключение любого расширения должно оставлять систему в рабочем состоянии. Это позволяет накатывать апдейты и быстро и смело одновременно. К сожалению, это не всегда реализуемо т.к для этого может потребоваться перевести конфигурацию на поддержку с редактированием, чтобы вынести общий функционал на уровень основной конфигурации - но тогда стоит задуматься, нужно ли много расширений или какие то лучше склеить в одно.
2) Работа с заимствованными "закрытыми" формами ведется исключительно в коде. Никаких правок на форме. 80% времени обновления конфигурации с доработками форм уходило на анализ конфликтов обновлений, при выносе в код - проблема исчезает, т.к при реальных конфликтах можно поискать имя элемента/реквизита в коде и быстро проверить.
3) "Новые" объекты если есть возможность лучше добавлять в основной конфигурации с префиксом. Так и рисков потерять данные меньше, и несколько расширений реализовать проще, и на обновление не влияет никак. Опять же, в случаях когда основная не полностью закрыта от мира.
Для нас расширения -- замечательная технология. Мы пользуемся ими с режима совместимости 8.3.12, когда ещё не было аннотации ИзменениеИКонтроль -- мы использовали Вместо с "псевдоаннотацией", имитирующей ИзменениеИКонтроль с помощью вставок в комментариях, и контролировани соответствие с основной конфигурацией после обновления с помощью автоматизированных тестов кода.
Для нас в расширении главное -- это чёткое отделение кода изменений от кода вендора конфигурации, и его текстуальная независимость. Это значит, что никакое обновление конфигурации наши изменения не затронет. Правда, они могут стать неработоспособными, но на это есть несколько этапов приведения расширения в соответствие с конфигурацией. Но в любом случае: обновлением конфигурации нельзя нечаянно лишней птичкой удалить данные расширения, нельзя порушить изменения из расширения. Этап обновления конфигурации чётко отделяется от этапа обновления изменений в расширении и становится независимым.
Это позволяет относительно легко обновлять какую-нибудь ERP, в которой изменены сотни модулей. В то время как в эпоху "до расширений" распространённой практикой было такие масштабно изменённые базы вообще не обновлять а частями накатывать нужные доработки из обновления, наращивая химеру и накапливая технический долг вплоть до внедрения новой редакции с нуля, что проще, чем обновиться. А с расширениями несколько недель работы -- и готово. В ситуации, когда без расширений никто бы вообще не брался.
Ну и наши внутренние правила и подходы:
1) Если под что-то можно написать автотесты, их имеет смысл написать.
2) Префиксы -- на верхнем уровне добавленной иерархии. Добавили документ -- он с префиксом, реквизиты без. Добавили реквизит в существующий документ -- он с префиксом. Всё, что добавляем на верхнем уровне -- с префиксом, вложения в то, что имеет префикс -- уже без.
3) Про формы. Много видел мнений, что добавление на форму реквизитов только программно. Мы добавляем непосредственно. Проблемы возникают редко, но один из этапов обновления при этом -- открыть в конфигураторе все заимствованные формы из расширения и проверить наличие сверху панельки обновления формы.
4) Храним всё в Гите, разрабатываем в конфигураторе. Приходится по нескольку месяцев поддерживать параллельно расширения, например, для ERP 2.5.8 и 2.5.12 в одной организации. То есть, обновление на тесте и работа разработчиков происходит буквально за пару недель, но потом достаточно долго может идти пользовательское тестирование и ловля организационного окна для обновления прода. Всё это время на проде 2.5.8 получает какие-то текущие доработки, а параллельно на тесте 2.5.12 может быть исправлена какая-то ошибка, актуальная и для прода. Соответственно, надо гонять изменения туда -- сюда. Для этого используем Гит.
5) Если расширение что-то не поддерживает -- лучше сделать костыль, чем менять основную конфигурацию. Например 8.3.12 не поддерживала константы в расширении. Костыль -- заводить регистр сведений для таких данных.
С нетерпением ждём перевода основных конфигураций (белорусских) на режим совместимости, позволяющий менять типы данных. Изменение числовых типов -- это одна из тех вещей, где разработка костыля в расширении может "стоить" намного дороже изменения основной конфигурации.
Расширения 1С: хотфикс или костыль?