На этой недели было много обсуждений по модульности 1С.  Было прочитано много мнений,  и вот теперь я попробую дать свое видение на данную проблему.
На мой взгляд, реализация подсистем, не упростило сложность системы. По сути, сейчас подсистемы предназначены только для группировки документов, справочников, регистров. И о никакой модульности речи не идет.
Теперь поговорим о модульности, как я реализовал бы ее в системе. Очевидно, что системе необходим некий новый объект – назовем его «Пакет».
Пакеты должны иметься следующие свойства:
- Размещать в себе объекты конфигурации, причем один объект не может относиться к нескольким пакетам.
- У каждого пакета должно быть свойства обмена данными с другими пакетами. Реализовать в виде таблиц пакета, по сути, эти таблицы будут содержать экспортируемые данные в другие пакеты, и работать должны как интерфейсы (шины данных).
- Пакет должен предоставлять возможность отделения интерфейса от реализации. Будем дёргать методы пакета у интерфейса, а интерфейс будет определять подходящую реализацию.
Данная логика позволит реализовать базовую модульность в 1С.

(43) т.е. вместо кучи конф предлагается взять УПП допилить туда "все что нужно кому угодно" разбить на модули и продавать сборками?


получим очередной САП-Аксапта-ОЕБС

(45) а запросто...делаем разные справочники валют

а далее либо синхронизация между ними либо еще 3-й вводим справочник типа базовый и дерево пакетов и их зависимостей ))

(43) Это очень усложнит систему. И самое главное связи между модулями как их реализовывать?

(47) И получаем кучу дублей информации, причем еще нужно следить, чтобы синхронизация успевала вовремя произойти - печаль

(0) По-большому счету Вы пытаетесь заново изобрести Java :)

Если взять и сделать то, что Вы предложили - из этого можно получить много плюсов (и важных). Но есть два основных минуса:

- В очередной раз повышаем сложность как платформы, так и конфигураций на ней
- В очередной раз нужно взять и заново переписать все типовые

Думаете окупится?

(29) См. паттерн Adaptor.

(45) по идее нужна базовая подсистема: валюты. Пусть там будет всего 1 справочник и 1 регистр. А остальные подсистемы имеют валюты в зависимостях

Вообщем давайте подождем модульный смартфон от гугла, потом поржем над тем что в каждом модуле встроены свои часы и каким образом они синхронизируются

и вот потом можно будет порассуждать о модульных конфигурациях

(49) Если говорить об этом в серьез - не нужно никаких дублей.

Есть лишь один справочник (притом возможно вообще не от этих двух подсистем) - и есть адапторы, которые позволяют этим подсистемам работать с этим справочником.

Притом сами подсистемы "думают", что работают со своим справочником.

(48)Отдельная сущность(справочник,регистр) которая будет хранить информацию о модулях которые есть в системе и об их зависимостях. Что мешает написать интерфейс реализуемый отдельным программным модулем, который будет подробно документирован.

(53) Отсюда и получаем, что обновление этой подсистемы (где сам справочник валюты) вызовет необходимость обновления всех остальных, бог его знает, каких подсистем.

И мы не получим той самой желанной модульности, т.к. будет набор (со временем все более большой) независимых подсистем, которые можно внедрять отдельно и огромные списки зависимостей остальных подсистем от различных базовых и других небазовых ...

Нет уж лучше как сейчас

(55)А справочник номенклатура, будет иметь 5000реквизитов которые могут понадобиться какой нибудь одной, из 5000 подсистем.

(51) так так уже и сделано... тока еще детальнее...есть "справочник" есть "регистр сведений" и т.д.

используй как хочешь

осталось для программных модулей добавить зависимости от этих объектов, точнее конкретных представителей

причем можно это программно сделать в коде проверка в начале каждого модуля и если нету объекта то создается авто ))

+(56)Я уже молчу о регистрах, когда каждой подсистеме нужны вроде бы одна и та же информация но в различных разрезах.

(55) Адапторы не идут в комплекте с подсистемами (библиотеками).

Их пишет тот, кто внедряет две подсистемы.
Когда обновляет только одну из них - при необходимости правит свой адаптор.

(54) Это ща есть, называется правила обмена ;-)

(0) За модульностью будущее 1С. БСП - ядро конфигурации, далее все что ты купил и установил.

(59)Изменился справочник валюты. Надо обновить 500 адаптеров. Я правильно понял?

(61) чем текущая модульность не устраивает?

А она есть?

(64) -> (63)

(64) Функциональная есть, приводили же пример БУХ/ЗУП /УТ

(66) о точно! а зачем засовывать функционал в одну конфу? берем нужные и правила обмена и профит

осталось тока вопрос с лицензированием решить... чтобы скидочка была при доп.покупании

(66) По большому счету нет. Попробуйте купить конфу БГУ и добавить в нее функционал ЗиКБУ, причем не весь, а только основную базовую часть; или например купить БГУ и добавить в неё функциональную часть Свода отчетов.

(62) +1

И я о том же. Модульность - великолепно! Мы разработали прекрасные модули - 100 штук - ура!

Человек внедрил 20, причем там связей огого, почти каждый модуль связан с почти каждым другим.

Ура мы выпустили обновление 10 из этих 20 модулей!


У вас система полностью перестала функционировать? Это ваш косяк - сидите и переписывайте адапторы.

Ну нафик, сейчас точно не хуже

(68) Такого рода модульность имеет неоспоримое преимущество при внедрении чем поставка отдельных конфигураций. Отдельная конфигурация это очень громоздко.

(70) Преимущество только в одном - можно срубить кучу бабла на каждом внедрении, а потом еще кучу на поддержке.

Поддержка такого зоопарка собственными силами тихий ужас.

+(70) В добавок дублирование данных, кода, человеческого ресурса.

чего тут рассусоливають?

модульность невозможно без механизма перекрытия базового функционал модульным, соответственно тут все упирается

1. совместимость метаданных
2. единый интерфейс


текущая платформа не содержит ни первого ни второго

(69)Ну скажем, так сейчас ровно то же самое.
Мы написали 100 модулей и мы внедрили 20. Если мы обновили 10, то мы и переписали адаптеры.
Если кто то другой использовал наши модули. То адаптер придется переписать ему, в случае каких то глобальных изменений наших модулей. Но сейчас фирма 1С переименовала названия методов в общих модулях и все кто ими пользовался переписывают свои поделки.

(74) Так и я говорю, если кто-то предложит лучшее решение - прекрасно, но пока никто не предлагает.

А эти рассуждения о модульности это из серии:

у нас че-то бардак в документообороте предприятия. А Вы купите программу "Документооборот" и все будет ОК.

(73) В той, предидущей ветке, был отсыл на статью, где основным недостатком отсутствия модульности в 1с называлось то, что трудно обновлять измененные конфигурации. А с модульностью все будет легко.

Я же говорю, что с модульностью сложность обновления нетиповых не уменьшится, скорее увеличится

(73) >без механизма перекрытия базового функционал модульным

Это только один из вариантов возможной реализации, некоторым образом напоминающий ООП. Однако при этом куча кода тащится постоянно, размер конфы ахриненный, невероятно сложная поддержка.

Кажется более правильным реализация на уровне "ядра" (БСП) конфигурации функционала согласования API отдельных модулей.

Грубо говоря функционал сам знает что ему нужно и требует соотв настройки при установке. Например выбрать в каком регистре хранить сотрудников или использовать существующий с разделением данных по функционалу или нет.

Изоляция реализации на уровне API исключает необходимость изменения "адаптеров". А сам API обновляется на уровне ядра (БСП).

Таким образом ядро сразу же знает что может быть доустановлено, но устанавливается все порознь, тогда когда надо.

Идеала не бывает. Однако наблюдается тенденция улучшения данной задачки за счет использования функциональности и набора библиотек.
Из-за этого, как я понимаю, переименовываются общие модули, которые не совпадают с этой тенденцией. Издержки роста.

(78) А может убрать нафик эти общие модули? Есть же модуль менеджера туда все распихать

(79)+ или сделать "модуль подсистемы"

(79) Очень интересно и сконтекстом что делать?

(81) ?

(82) Ну как бы модуль менеджера это только "Сервер"

(81)(82) да минус вижу например "универсальная" "общая" обработка табличных частей доков но это можно или дублирование кода или модуль подсистемы

(83) эээ да не учел, но значит сделать еще что то но чтобы привязка программного кода была к объектам (затрагиваемым в коде) жестко

а не так как сейчас где общий модуль может все объекты и другие модули юзать и только поиском/проходом по коду можно определить что он затрагивает

(62) Если справочник поменялся так, что адапторы развалились - да.

Только 500 адапторов сложно придумать :)

(85)+ т.е. да нужен механизм зависимостей причем на уровне платформы чтоб поддерживался

БГ по смыслу сказал следующее: рынку это не нужно, и квалифицированных спецов для решения данной задачи у нас нет...
.
ЦИтата:
.
CheBurator (Сергей Коцюра):

Можно ли ожидать появления блочной структуры построения типовых конфигураций? Надо - купил/добавил блок "Резервы", надо - купил/добавил блок "контроль кредита" и т.д. Т.е. изначально покупать простую конфигурацию и по мере необходимости наращивать ее действительно нужными блоками, а не наоборот - иметь мегауниверсальную конфигурацию, в которой "отключать" кучу ненужного...?

Рейтинг: +95

Борис Нуралиев:

Отвечая на этот вопрос можно написать статью, а то и кандидатскую диссертацию. С технической точки зрения, вопросы декомпозиции систем на независимые "блоки", степень их связности, зависят от множества факторов. Нельзя ожидать волшебства: разделение системы на независимые функциональные составляющие неизбежно ведет к увеличению нагрузки на создание прикладных интерфейсов взаимодействия модулей, в результате решение может получиться более громоздким. Мы осознаем важность этого вопроса. Например, в версии платформы 8.3 были добавлены переопределяемые типы, которые позволят частично снизить связность различных модулей и сделать их более независимыми.

С коммерческой точки зрения вызывает большие сомнения, что рынок позитивно воспримет идею "докупки" каждого дополнительного блока – сейчас для успеха на массовом рынке скорее приходится даже самые массовые решения делать очень функциональными, а не "скелетными прототипами". Кроме того,  при "мелкоблочном подходе" может на порядки усложниться поддержка таких решений.

Пока мы считаем более перспективной разработку полнофункциональных типовых решений, хорошо "накрывающих" ту или иную предметную область – с возможностью дополнения их различными отраслевыми и специализированными решениями, которые разрабатывают партнеры.
.
http://infostart.ru/public/194059/

(88) Можно сказать только то, что БГ прав, ему виднее :)

(87) Да согласен, именно описание API. Грубо говоря БСП определяет пространство имен и описывает "заявленную" функциональность.

(88) Если это организовывать в 1С, то придется менять организационную структуру подчиненности отделов и тп. , а это всегда проблемы.

(0)как аццкий макаронный код

+(88) Вот:
>Кроме того,  при "мелкоблочном подходе" может на порядки усложниться поддержка таких решений.


Здесь и порылась собака.


Модульность - это хорошо в теории и в дорогих системах типа САП. Но Вы найдите САП для автоматизации, скажем, бухгалтерии за 50 штук рублей. То-то.

(92) >может на порядки усложниться поддержка таких решений
значит может и не усложниться...

Другое дело опасность видится в том, что такая модификация затрагивает все конфигурации, а это уже серьезно.

(93) Усложнится, т.к. каждое внедрение будет отличаться от другого не только настройкой методики учета, но и связкой разных блоков.


Мне видится, что со стороны 1С следует просто ввести максимальную унификацию в разрабатываемые типовые (что они и пытаются делать своими БСП).

А то в БП 2.0 и ЗуП 2.5 разный механизм добавления внешних обработок. Они очень похожи, но все-таки отличаются.
Нужно сделать одинаковыми механизмы, не зависимые от учета.

(94) >не только настройкой методики учета, но и связкой разных блоков

Связка вообще не меняется, а всегда одна и та же и присутствует на уровне ядра.

Я же говорю просто "связка блоков" = "подчиненность отделов", все очень просто.

в (88) ответ максимально полный.

Модульность бред.
Накой она нужна? Что такого принципиального нельзя реализовать в текущей модели?

(96) удобства нету, никогда не приходилось что то выдирать сз одной конфы чтобы добавить в другую?

К примеру есть конфа Розница, там даже приход от и возврат поставщику есть

А вот платежного поручения нету и банка нету ((

И что делать? покупать еще и УТ(УНФ, БП и т.д.)?

(97) почему бы не купить. не миллион долларов все таки.

даже с сегодняшней моделью, когда есть мастер-конфигурация, и куча совместимых решений, возникает куча проблем с совместимостью совместимых решений друг с другом.

А если это еще и на модули начнут бить, то все проекты на 90% будут состоять из настройки совместимости всего со всем.

(98) ага и обмен настроить... и обучить в двух прогах работать...

тут наоборот мне платят чтобы облегчал работу а не усложнял

(97) Так если используешь блоки (документы) из этих конфигураций их тоже придётся купить. Лицензия...

(100) так куплено уже БП в смысле есть

но неудобно у нас БП тока для отчетности типовая, без всяких доработок

вся работа в Рознице в том числе взаиморасчеты с поставщиками (они там сразу есть)

(99) так подумай головой и сделай одну прогу

кто сказал что модуль предназначеный для бухи будет совместим с розницей?

(102) и кто сказал, что для того, чтобы модуль Банка работал в рознице не придется еще пол бухи в него перетянуть?

И кто сказал что эти пол бухи будут корректно работать с модулями розницы?

(103) ага 1С сказала что "придется еще пол бухи в него перетянуть"

поэтому был переделан документ "РегистрацияБезналичнойОплаты" для выбора расч.счета с которого платим и выгрузки в формате для Клиент-Банк

:)

Простые люди верят, в то что можно написать программу один раз и навсегда..
Когда они становятся программистами, они начинают понимать что это не так, но теперь они верят в то, что можно написать модуль/класс/подсистему один раз и навсегда.. и начинают верить в модульность как в решение всех проблем.
Они ошибаются.

(70)-(72) а вы думаете что с приходом модульности на уровне платформы, у вас жизнь наладится?

Т.е. на уровне данных модульность вам не нравится, где проверяет их 3 уровня пользователей системы (пользователи, разработчики и консультанты), а хочется сделать на уровне платформы где эту самую модульность будут проверять только программисты ;-)

(105) нет они верят/хотят верить что можно взять уже написанный код (по неким стандартам) и использовать его несколько раз в похожих ситуациях/случаях

(88) Какой хитрый человек.
Кстати когда мне говорят что то типа "это очень сложный вопрос..." и посде этого не идет простое объяснение его сложности то я начинаю подозревать что либо человек не владеет темой, либо он просто хочет чтоб я отстал от него с этим.
Здесь он хитро сыграл и вашим и нашим, дурачков которые ждут модульности назвал глубокими личностями, но в конце откровенно сказал что она нафиг не нужна.

Имхо, очень нравилась модульность Паруса в свое время :)

(108) а я считаю что БГ полностью прав. Проблема любой сложной системы-это обмены данных, взять ту же связку УТ/БП/ЗУп, у кого то проблем нет, а кто-то вспоминает ее как страшный сон с переходом на единую корпоративку.

(110) А я считаю, что он прав еще больше...

(111) "Миша, мы тут все за тебя. А вот Саша - он вообще затебее" (с) День Радио )))

(112) Главная заповедь механизатора: не мешай механизму работать. :)

(113) Зачем ты называешь БН механизмом? ))

(114) Если бы я был кличко то ответил бы тебе примерно следующее: "А сегодня в завтрашний день не все могут смотреть. Вернее, смотреть могут не только лишь все, мало кто может это делать."

(115) Как я рад, что ты не Кличко - у меня нет слов описАть...

(116) Да уж это перл всех перлов. Видно что он предельно логичен :)

http://lukomore.org/lurk/Виталий_Кличко

(117) А он модульный? Или хотя бы объектно-ориентированный?

(118) Скорее модульный.

(119) модульный-дизорентированный

(67) в снеговике у тебя и так скидка огромнач на доплицензии

(0) В реальности очень интересно когда 1с-ники-конфигуристы массово зарыдают от "возможностей платформы" и от повышения сложности настройки конфигураций.

(122) :слоупок.пнг:

Они давно рыдают. Посмотри в (0)

(97) аку еть. Платежные документы стоят меньше бутылки пива

(124) аку есть вы пиво пьете ))

т.е. предлагаете юзверям делать двойную работу? и внедрять/писать обмен данными с синхронизацией?

(123) Не видно слез, одни "СферическиеПакетыВВакууме"

(125) а я на себе не экономлю.

(123) :слоупок.пнг:
на шой-то вы намякиваете ?

(125) что плохого в обмене? Вы работале с обменом? Люди чертей гоняют по обмену при нормальном написании.
Учите матчасть там все написано

(125)+ и один расчетный счет у контрагента это да сильно!

(129) ничего плохого в обмене нет, но не в данном случае

походу не у меня с матчастью плохо, выше я писал что усть БП типовая для отчетов, чем изобретать лисапед с "Платежными документами" (они кстати без УФ т.е. - тонкие клиенты)

в нашем случае проще делать платежки в БП, но это неудобно, потому что двойная работа и нет контроля по взаиморасчетам без доп.настройки обмена (сейчас он односторонний Розница>БП)

(130) так у вас розница или сеть, вы что то завралися.
Очередной "нищеброд"типа х5 и прочих рейтелиров

(131) настройте обмен с розниуе и вы просто будите в счастье.
Имея БП и такую писать, стрянно.
Ищите специалистов, они есть

проблема 1с не в отсутствии модульности, а в пересмотре подходов: был метод, изменили и без сохранения совместимости.

а многое что есть в бсп - вообще давно должно на уровне платформы.

а еще в (1) мне пункт 2б понравился. правда с ним в «умелых» руках...

(134) ну блин, ну потрать чутка времени, изучи модульности и прикрути свое. Даже я лохпидальныей почти все свои доработки перевел на такси. Кроме перерисовки морды не чего не делал, да и то через 2 недели формы на такси рисовать офегенной удовольствие не то что в убогом толстом клиенте

Так вы новый "линукс" напишите...

(134) Что именно у Вас должно быть на уровне платформы? Виды контактной информации? КЛАДР? Курсы валют? Движок обменов?

(136) я тебе про функции языка говорю, причем тут морда клиента. аля httpсоединения с его параметром защищенное. и подобного было много.

(138) строковые функции, работа с файлами, хранение файлов, журнал регистрации, внешние отчеты и обработки. тысяча их в БСП. и работать оно станет в разы шустрее, если будет из платформы работать.

(139) Строковые функции - http://v8.1c.ru/o7/201408str/index.htm

Работа с файлами, хранение файлов - может быть, не готов оспорить.

Журнал регистрации - там в БСП окромя формы с гридом от него и нет ничего. Все средствами платформы работает. И тормозит. А из конфигуратора ЖР так вообще без БСП работает - и тоже тормозит.

Внешние обработки - см. http://v8.1c.ru/o7/201410ext/index.htm

(140) ну привел ты ссылки, что это когда-нибудь реализуют, и?

совместимости с существующими решениями не станет (переделывать прийдется), а вопрос нафейхуа реализовывали средствами конфигуратора и поддерживали кучей версий останется.

А давайте модульность машин обсуждать. Наверное фольксваген-тележка, без движка и электрооборудования, то-же будет востребован. Надо на ТС попробовать сей вариант.

А как модули в САПе интегрируются? нет ли проблем с дубликацией саповских справочников и документов?

(143) Там вроде-бы только функционал добавляется или убавляется, типа "прав" в 1С.

(143) Там те же проблемы, просто ценники такие, что они все покрывают