Комментарии 24
Сам-то инструмент создавался ради того, чтобы не снимать конфигурацию с поддержки. Но поддержка и реализация этого инструмента доставляет не меньше проблем. Такой вот каламбур :)
Удобная вещь, особенно когда конфа на поддержке, а исправить нужно сейчас и не ждать обновление, которое может выйти не так быстро.
И чтобы меньше с формами эксперементировать прописывайте элементы формы программно.
Приколюха, 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С для вас это был бы очевидный момент. Потому что усложнение разработки ненужной технологией - это плохое архитектурное решение.
Итог. Да, расширения - это багфикс, плагинчик на продажу, экспериментальная доработка для проверки гипотезы. Для постоянного внедрения должна быть законченная конфигурация в себе, чётко привязанная, зависящая. Платформа это позволяет делать параллельно с разработкой от 1С.
Расширения 1С: хотфикс или костыль?