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