Большая проблема 1С — Одноразовый код

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

1С завершила поддержку УТ 10.3, реализовав поддержку пробития в разрешительном режиме только при вводе чека из РМК, не из формы чека или реализации.

И тут мне пришла в голову давно созревавшая мысль, в чем проблема 1С, из-за которой она не может делать сложные решения, а монстр 1С:ERP выглядит «колоссом на глиняных ножках».

Дело в том, что типовой код 1С всегда «одноразовый».

1С не пишет изолированных функций и библиотек функций. Для мнимого быстродействия код щедро переплетен с запросами к объектам базы данных даже там, где выигрыш от этого копеечный.

В итоге код 1С — это монолитный конгломерат.

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

Но о БПО (и БСП) 1С еще позаботилась, чтобы они были изолированы. А что говорить о других модулях — маркировки, учета НДС, списания себестоимости и прочих алгоритмов.

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

Но в итоге функции пишутся на угоду текущему моменту. Нет многократно хорошо отлаженного кода, все новое, полное багов, сложно переплетенное, плохо отлаживаемое.

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

Это одна из слабостей типового кода 1с.