Автор всё правильно пишет - Расширения конфигураций - та ещё шняга! Автор сабжа, конечно, тему вообще не раскрыл, но в общем верные выводы представил!
Но, тут налицо 5 фундаментальных проблемы:
1. Расширения конфигураций - задумывались, всё-таки, чтобы что-то дополнять, а не замещать (хотя и с этой своей функцией они справляются погано - по сути всё это расширение "чисто для галочки" - а по факту особо и не расширишь, ни 10 лет назад, ни сейчас - дополнить можно, а вот расширить...). То есть, Расширения хороши именно когда нужно привнести что-то новое, а не заниматься полиморфизмом старого! Хотя да - часто слышны лозунги, что расширения эффективно помогают упростить обновления конфигураций на новые версии поставщика.
Но привнести что-то новое можно эффективно и в основную конфигурацию, и мешать обновлению это новое будет не сильно (если будет вообще). Другое дело - это когда нужно это новое собирать из кучи источников - что-то, условно, куплено у других вендоров, что-то разработано разными командами - как своими так и на аутсорсе, что-то просто ставится не во все ИБ. То есть - когда есть целый зоопарк отдельных дополнений. Но... опять же - это всё было бы уместно, если бы решении были чуточку функциональней, и поддерживай более 90% видов метаданных, а пока это не так - так или иначе - всё равно приходится лазить в основную конфигурацию. Да и одними дополнениями не обойтись - часто нужно изменять, или, хотя бы, расширять! Ещё расширения хороши как хотфикс!
2. Архитектура конфигураций (даже типовых 1С) крайне плохо адаптирована под расширения! Я бы сказал - там вообще очень скверная архитектура в принципе, для изменений, адаптаций и сопровождения! Ну не создавалась она для таких целей - да, безусловно, многое сделано в этом направлении, особенно в последние лет 10. Но... я бы большую часть этих шагов назвал бы шагами в сторону и в кювет, чем вперёд - в светлое будущее!
Чтобы конфигурацию можно было бы эффективно расширять / изменять - её архитектура и код должна быть очень "чистой" (условно, по Бобу Мартину), но чистота типовых решений хромает даже по стандартам 1С, а они сами по себе - весьма специфичны. Но это не достаточно! Нужно ещё и очень широко повысить уровень абстракций описания внутренней логики, интонаций, и многослойных взаимодействий (от более веского уровня кода и архитектуры к более низкому), и изначально повысить изолированность модулей друг от друга (не между слоями, что само собой, на в рамках одного и того же уровня слоя). Но это прям совсем иначе надо переписать всю архитектуру типовых решений! И, видоизменить стандарты! А ещё... как минимум заняться глубокой оптимизацией и когенерацией программного кода! Сейчас же оптимизации в платформе нет. А кодогенерация очень примитивна и ограничена! Ну и см. следующий пункт, он важен для переработки архитектуры конфигураций (но и без него многое можно сделать).
3. Платформенная ограниченность - Платформа 1С: Предприятие 8.3 (и, судя по всему, 8.5) - крайне ограничены в своих возможностях создавать эффективный полиморфный, расширяемый и абстрагированный / обобщённый код!
Её низкоуровневые инструкции крайне примитивны, почти всё на уровне конца 70-х годов XX век (хоть платформа и появилась в начале XXI; прикладные языки же, существуют с конца 60-х, если мне память не изменяет), хоть визуально это и обёрнуто в красивые оболочки, которые, в прочем, полностью устарели уже на момент выхода платформы 8.3).
Чтобы иметь возможность писать эффективно расширяемый код и создавать расширяемую гибкую архитектуру - нужно применять более продвинутые механизмы, как функции высшего порядка, все аспекты ООП, глубокие инъекции и AОП, Контрактная разработка, расширенное манипулирование кодовым контекстом, пространства имён, изолированность кода/архитектуры, асинхронное программирование (нормальное, а не тот огрызок что есть сейчас - как синтаксический сахар над ОписаниеОповещение, который так и не стал применяться даже в типовых), эффективный API встроенных библиотек - для сокращения рутины, и повышения уровня абстрагирования при манипулировании над данными! И, само собой, глубокие встроенные средства анализа и рефакторинга (крайне желательно - относительно легко кастомизируемые и расширяемые плагинами). А уж сколько всего надо переработать в сфере Форм - то лгбт, что предлагается в изменении пользовательских интерфейсов в 8.5 - крайне далеко от того, чем реально надо было заниматься перерабатывая интерфейсные формы! И это я ещё AI-помощника не упомянул - а во второй четверти XXI века пора уже о нём задуматься (хотя 1С уже задумалась и натужилась с "1С Напарник" - но, тужиться, видимо, долго будет), чтобы переложить на AI большую часть рядовой архитектурной, стилистической рутины (а так же рефакторинг, анализ, и часть кодогенерации и трансформации кода - но это всё уже отдельная тема).
Будет ли хоть толика из описанного в какой-либо из будущих платформ 1С: Предприятие 8.x - я сильно сомневаюсь. Но без этого создать эффективно расширяемую архитектуру будет очень затруднительно! Но, явно, новое поколение зумеров и позже - все нынешние потуги компании 1С совершенно не оценят и не поймут! Но пока да - жизнь их обстоятельно будет пытаться ставить раком в позу 1С - и пытаться уложить в прокрустово ложе 1С: Предприятие 8.5 - ибо - МОНОПОЛИЯ и БЕЗЫСХОДНОСТЬ ИЗОЛЯЦИИ!
4. Нестабильность - в первую очередь - расширений - они отваливаются. Зачастую, на ровном месте и незаметна. И вместе с ними отваливается и часть архитектуры. Проблема тут в их "плюсах" - динамичности и разделяемости - т.е. заточкой под 1С Фреш! Не будут тут останавливаться - итог - серьёзно полагаться на расширения нельзя - если в любой момент они могут отвалиться!
А ещё они могут создавать ошибки при изменении основной конфигурации, например при обновлении, особенно когда в ИБ стоит "хотфикс на хотфиксе" - а 1С очень любит поставить несколько десятков "хотфиксов"! А процесс обновления в 1С Предприятие 8 до сих пор плохо организован!
5. Непроизводительность - Продолжая, в первую очередь динамику расширений, но и в основной конфигурации так же полно проблема с непроизводительностью - обычно из-за архитектурных проблем платформы - не могут эффективно организовать архитектуру с отключаемым функционалом! Зачастую происходит много лишних динамических проверок и лишних выборок данных, которые никак не нужны! А когда это всё ещё и начинает дорабатываться (даже без расширений) - часто таких лишних алгоритмов и выборок данных становится ещё больше - ведь умные разработчики будут стараться как можно меньше лезь в тьму 1С кода и архитектуры - и будут стараться создавать больше новых - изолированных объектов, и повторно обрабатывать уже обработанные данные (чтобы внести в них новые веенья) -и чем в компании разношёрстнее команда(ы) разработки - тем таких повторных обработок и выборок будет ещё больше - т.к. так уже об этом позаботилась компания 1С, создавая архитектуру платформы и конфигураций, и стандартов разработки!
