1С — Добро и зло. Расстановка точек в холиварах вокруг 1С18.12.2019 01:48

Друзья и коллеги, в последнее время на Хабре участились статьи с хейтом в адрес 1С, как платформы для разработки, и выступлениями ее защитников. Эти статьи обозначили одну серьезную проблему: чаще всего, критики 1С критикуют ее с позиции «не осиливших», ругая проблемы, которые де-факто, легко решаются, и, напротив, не задевая проблемы, которые действительно важны, стоят обсуждения и не решаются вендором. Полагаю, что имеет смысл провести трезвый и взвешенный обзор платформы 1С. Того, что она умеет, того что она не умеет, того что она должна бы делать, но не делает и, на сладкое — то, что она делает на ура, а ваши разработчики на %technology_name% будут делать стопицот лет, выкинув на ветер не один годовой бюджет.

В результате, вы, как руководитель или архитектор сможете получить четкое понимание — для какой задачи вам будет выгодно взять 1С, и где ее надо выжигать каленым железом. Как разработчик мира «не 1С» вы сможете посмотреть, а что же там такого в 1С есть из-за чего сыр-бор. А как разработчик 1С — сможете сравнить свою систему с экосистемами других языков и понять свое расположение в системе координат софтверной разработки.
Под катом — масса толстых набросов на 1С, на критиков 1С, на Java, .NET и вообще… Вентилятор заправлен, добро пожаловать!

О себе

Я знаком с предметом разговора примерно с 2004 года. Программирую наверное лет с 6, с того самого момента, как у меня появилась книжка про профессора Фортрана с комиксами про кота, воробья и гусеницу. Я разбирал программы, которые писал кот с картинок в книжке и выяснял, что они делают. И да, настоящего компьютера у меня тогда не было, но на развороте книжки был нарисованный и я честно нажимал бумажные кнопки, вводя команды, подсмотренные у кота Икса.

Далее был БК0011 и Бэйсик в школе, С++ и ассемблеры в универе, потом 1С, а потом столько всего, что уже и вспоминать лень. Последние 15 лет я в-основном занимаюсь 1С, не только в части кодинга, а вообще 1С. Постановка задач, админство и девопс сюда же. Последние лет 5 занимаюсь общественно полезной деятельностью в плане развития инструментов разработки и автоматизации для других 1С-ников, пишу статьи и книжки.

Определимся с предметом обсуждения

Для начала давайте определимся о чем пойдет речь, поскольку под буквами »1С» можно понять много всего. В данном случае, под буквами »1С» мы будем понимать исключительно фреймворк разработки »1C: Предприятие» современной, восьмой версии. Мы не будем много говорить о фирме-производителе и ее политике (но немного-таки придется), Мы не будем обсуждать конкретные приложения, написанные с применением этого фреймворка. Технология отдельно, приложения a.k.a конфигурации — отдельно.

Высокоуровневая архитектура 1С: Предприятия

Я не зря упоминаю слово «фреймворк». С точки зрения разработчика платформа 1С это именно фреймворк. И относиться к нему надо именно как к фреймворку. Считайте, что это Spring или ASP.NET, выполняемый некоторой средой выполнения (JVM или CLR соответственно). Так получилось, что в мире обычного программирования («не 1С») разделение на фреймворки, виртуальные машины и конкретные приложения получается естественным, в силу того, что эти компоненты обычно разрабатываются разными производителями. В мире 1С же не принято выделять в явном виде фреймворк разработки и собственно рантайм, кроме того, конкретные приложения, написанные с применением фреймворка, в-основном, также разработаны самой же фирмой 1С. В результате и возникает некая путаница. Поэтому, в рамках статьи нам придется рассмотреть 1С сразу с нескольких сторон и классифицировать ее по нескольким координатным осям. И в каждой оси координат мы положим по лопате коричневого вещества рассмотрим особенности, преимущества и недостатки имеющегося решения.

Точки зрения на 1С

1С для покупателя

Покупатель приобретает систему автоматизации, на которой он сможет быстро решить задачи автоматизации собственного бизнеса. Бизнес может быть маленьким ларьком, а может быть крупным холдингом. Понятно, что потребности у этих бизнесов разные, но поддерживается и то и другое единой кодовой базой платформы.
Для покупателя 1С это быстрый time-to-market. Быстрый. Быстрее чем на Java, C# или JS. В среднем. По больнице. Понятно, что сайт-визитка на реакте получится лучше, но бэкенд WMS-системы — быстрее запустится на 1С.

1С как инструмент

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

серверное приложение
приложение, где фигурируют финансы
с готовым UI, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
с поддержкой фоновых процессов и заданий
с системой безопасности на основе ролей
со скриптуемой бизнес-логикой
с возможностью быстрого создания прототипа и низким time-to-market

1С вам не нужно, если вы хотите:

машинное обучение
расчеты на GPU
компьютерная графика
математические расчеты
CAD-систему
обработка сигналов (звук, видео)
highload http-вызовы с сотнями тысяч rps

1С как фирма-производитель

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

учет финансов
легкая кастомизация бизнес-логики
широкие возможности интеграции в гетерогенных IT-ланшафтах

Как производитель, фирма 1С считает, что именно такая стратегия позволяет работать с партнерами и клиентами в режиме win-win. Можно спорить с этим, но примерно так фирма себя продвигает: готовые решения проблем бизнеса, которые можно быстро кастомизировать силами партнеров и встроить в любой IT-ландшафт.

Все претензии или хотелки к 1С, как к фреймворку стоит рассматривать исключительно через эту призму. «Хотим ООП в 1С» говорят разработчики. «Сколько будет нам стоить поддержка ООП в платформе, поможет ли это нам увеличить продажи коробок?», говорит фирма 1С. Открывает свою «призму» продажи решения проблем бизнеса:

— Эй, бизнес, хочешь, чтобы в твоей 1С было ООП?
— Это поможет мне решить мои проблемы?
— Как знать…
— Тогда не нужно

Это подход может быть хорошим или плохим, в зависимости от того кто на него смотрит, но он просто такой. Говоря о том, что в 1С нет фичи Х, надо понимать, что ее нет там не просто так, а в контексте выбора «стоимость реализации vs размер профита».

Технологическая классификация

«На самом деле одинэсники вовсю используют самые лучшие паттерны, тщательно отобранные заботливыми методистами и разработчиками платформы 1С.
Когда ты пишешь свой тупой код для простенькой управляемой формы, на самом деле ты юзаешь model-view-controller с double-way data binding в three-layered-data-app-engine, сдобренный high level object-relation-mapping на базе declarative metadata description, имеющей свой platform-independent query language, c declarative data-driven user interface, complete transparent serialization и domain-oriented program language.
В чём разработчики 1С отличаются от западных коллег, так это в пиаре. Те любят любой фигне дать громкое имя и носиться с ней, как с писаной торбой.»
А. Орефков

Платформа 1С имеет классическую 3-звенную архитектуру, в центре которой сервер приложений (или его эмуляция за мало денег для мелких лавочников). В качестве СУБД применяется или MS SQL или Postgres. Есть еще поддержка Oracle и IBM DB2, но это, скорее эзотерика, никто не знает что будет, если внедрять 1С на этих базах под средней и высокой нагрузкой. Полагаю, не знает этого и сама фирма 1С.

В качестве клиентской части выступает либо тонкий клиент, устанавливаемый на машину пользователя, либо веб-клиент. Ключевая особенность — программисты не пишут 2 разных кода, они пишут одно приложение, на одном языке, а вы можете выставить его в браузере, если есть желание или потребность. Кто там хотел подлинного фулстэка и единый язык для фронта и бэкенда, node.js? У них до конца так и не получилось сделать совсем одинаково. Настоящий фулстек существует, но писать придется на 1С. Ирония судьбы, такие дела)

В режиме браузера работает также облачное SaaS решение 1С: Fresh, в котором можно не покупать 1С, а взять мелкую базу себе в аренду и вести там учет продаж шаурмы. Просто в браузере, не устанавливая и не настраивая себе ничего.

Кроме того, есть легаси-клиент, который в 1С называют «обычное приложение». Легаси оно и есть легаси, добро пожаловать в мир приложений 2002 года, а мы все-таки про современное состояние экосистемы.

Серверная часть 1С поддерживает кластеризацию и масштабируется посредством добавления новых машин в кластер. Тут сломано довольно много копий и про это будет отдельный раздел в статье. Если коротко, то это не совсем то же, что и добавить пару точно таких же инстансов позади HAProxy.

Фреймворк прикладной разработки использует собственный язык программирования, который примерно напоминает слегка улучшенный VB6, переведенный на русский язык. Людям, ненавидящим все русское, которые не верят, что «if» переводится, как «если» предлагается второй вариант синтаксиса. Т.е. при желании на 1С можно писать так, что с виду от VB не отличить.

Вот этот самый язык программирования и является основной причиной хейта 1С-ников в сторону своей платформы. Скажем прямо, не безосновательно. Язык задумывался, как максимально простой, призванный выполнить мантру «DEVELOPERS, DEVELOPERS» в масштабах хотя бы СНГ. Коммерческая суть такого решения, на мой взгляд, просматривается четко: больше разработчиков, больше охват рынка. Это сбылось по разным оценкам от 45% до 95%. Сразу скажу, что писать на том языке, на котором думаешь — реально легче. А я знаю довольно много языков программирования.

С языка, пожалуй и начнем.

Язык программирования 1С

Одновременно сильное и слабое место системы. Обеспечивает легкое вхождение, читабельность. С другой стороны, не обновлялся с момента выхода версии 8 в 2002 году и морально устарел. Кто-то скажет «главный недостаток — нет ООП» и будет неправ. Во-первых, ООП не любит не только Нуралиев, но и Торвальдс. А во-вторых, ООП все-таки есть.

С точки зрения разработчкика, в его распоряжении есть фреймворк с базовыми классами, отображаемыми на СУБД. Разработчик может взять базовый класс «Справочник» и отнаследовать от него справочник «Клиенты». Может добавить к нему новые поля класса, например, ИНН и Адрес, а также, если нужно — может переопределить (override) методы базового класса, например метод OnWrite/ПриЗаписи.

Фреймворк составлен таким образом, что более глубокое наследование требуется редко, и ограничение в ООП, на мой взгляд, имеет смысл. 1С ориентируется на Domain Driven Development и заставляет думать, в первую очередь, о предметной области разрабатываемого решения и это хорошо. Отсутствует не только соблазн, но и необходимость писать 10 разных DTO и ViewModel только для того, чтобы где-то показать какие-то данные из домена. Разработчик 1С оперирует всегда одной сущностью, не забивая себе контекст восприятия десятком классов с похожими названиями, представляющими одну и ту же сущность, но с другого боку. Любое .NET приложение, например, будет обязательно содержать пяток-другой ViewModel-ей и DTO для сериализации в JSON и передачи данных с клиента на сервер. И примерно 10–15% кода вашего приложения займет перекладывание данных из одного класса в другой ручками или костылями вроде AutoMapper. Этот код надо написать и программистам заплатить за его создание и сопровождение.

Выходит, что язык 1С сложно развивать, не усложнив его до уровня мейнстримных языков, потеряв таким образом преимущество простоты. Какая ведь по сути решается задача вендора: выдать типовое решение, которое сможет кастомизировать любой отловленный на улице студент с должным уровнем качества (т.е. кейс охвата от ларька до крупного завода выполняется). Если ты ларек — возьми студента, если ты завод — возьми гуру у партнера-внедренца. То, что партнеры-внедренцы продают студентов по цене гуру, это не проблема фреймворка. Архитектурно фреймворк должен решать задачи и тех и других, код типовых конфигураций (которые мы продали бизнесу с обещанием кастомизации) должен уметь понимать студент, а гуру и так что хочешь поймет.

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

Возможность типизации на уровне, например, TypeScript (как следствие более развитые средства анализа кода в IDE, рефакторинг, меньше обидных косяков)
Наличие функций как объектов первого класса. Чуть более сложная концепция, но количество boilerplate-code из типовых можно было бы сильно сократить. Понимание кода студентом, имхо, даже повысилось бы за счет сокращения объема
Литералы универсальных коллекций, инициализаторы. То же самое — снижение объема кода, который надо написать и/или просмотреть глазами. Наполнение коллекций это over 9000% времени программирования на 1С. Писать это без синтаксического сахара долго, дорого и error-prone. Вообще, количество LOC в решениях на 1С превосходит все мыслимые пределы по сравнению с доступными открытыми фреймворками и вообще, всех ваших энтерпрайз Джав вместе взятых. Язык многословен, а это вырождается в объем данных, память, тормоза IDE, время, деньги….
конструкции finally У меня есть гипотеза, что эта конструкция отсутствует из-за того, что не подобрали удачного перевода ее на русский язык:)
Собственных типов данных (без ООП), аналогов Type из VB6. Позволит не типизировать структуры с помощью комментариев в БСП и волшебных методов, конструирующих эти структуры. Получаем: меньше кода, подсказку через точку, более быстрое решение задачи, меньше ошибок по опечаткам и отсутствующим свойствам структур. Сейчас типизация пользовательских структур лежит полностью на команде разработки Библиотеки Стандартных Подсистем, который, к честью для нее, тщательно пишет комментарии по ожидаемым свойствам передаваемых структур параметров.
Отсутствие сахара при работе с асинхронными вызовами на веб-клиенте. callback-hell в виде ОбработкаОповещения это временный костыль, вызванный внезапным изменением API основных браузеров, но жить так все время — нельзя, преимущество «понимания студентом» асинхронного кода теряется все сильнее. Добавьте сюда никакую поддержку этой парадигмы в основной IDE и все станет еще хуже.

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

Программисту, который уже много поработал с этим языком, заглянул в js или c# становится скучно в рамках этого языка. Это факт. Ему необходимо развитие. На другой чаше весов у вендора лежит стоимость реализации указанных фич vs увеличение выручки после их внедрения. Тут у меня нет никакой информации о том, что в глазах фирмы в данный момент перевешивает.

Среда разработки

Здесь все тоже не гладко. Сред разработки существует две. Первая, это входящий в состав поставки Конфигуратор. Вторая — разрабатываемая на базе Eclipse среда Enterprise Development Tools, сокращенно EDT.

Конфигуратор обеспечивает полный спектр задач разработки, поддерживает все фичи и является основной средой на рынке. Тоже морально устарел, не развивается, по слухам — из-за объема техдолга внутри себя. Ситуацию могло бы улучшить открытие внутреннего API (в виде дружбы со Снегопатом А. Орефкова или на самостоятельной основе), но этого нет. Практика показала, что сообщество само напилит себе фич в IDE, лишь бы вендор не мешал. Но имеем что имеем. Конфигуратор был прекрасен в 2004–2005, очень напоминал Visual Studio тех времен, местами даже был круче, но так и застрял в тех временах.
Кроме того, объем среднего типового решения с тех пор вырос в несколько раз и сегодня IDE тупо не справляется с тем объемом кода, которым её кормят. Юзабилити и возможности рефакторинга даже не на нуле, они в минусе. Все это не добавляет энтузиазма разработчикам и они мечтают свалить в другие экосистемы и продолжать говнокодить там, но уже в приятной среде, которая не плюет тебе в морду своим поведением.

Как альтернатива предлагается написанная с нуля IDE, построенная на базе Eclipse. Там исходники, как и в любом другом софте живут в виде текстовых файлов, хранятся в GIT, ветки-пулреквесты, все вот это вот. Из минусов — уже который год не выходит из статуса беты, хотя с каждым релизом становится все лучше. Про минусы EDT писать не буду, что сегодня минус, завтра исправленная фича. Актуальность такого описания быстро сойдет на нет. На сегодняшний день разрабатывать в EDT можно, но непривычно, нужно быть готовым к некоторому количеству багов IDE.
Если посмотреть на ситуацию через упомянутую «призму 1С», то получается примерно следующее: продажи коробок выход новой IDE не повышает, но отток DEVELOPERS-ов возможно сократит. Что ждет экосистему с точки зрения комфорта разработчика сказать сложно, но Microsoft уже однажды профукал мобильных разработчиков, слишком поздно предложив им свои услуги.

Управление разработкой

Здесь все существенно лучше, чем в написании кода, особенно в последнее время, когда стараниями сообщества на свет были вытащены проблемы автоматизации администрирования, запущены прототипы, призывающие выкинуть на свалку хранилище 1С и пользоваться git, быстрым blame, code-review, статическим анализом, автодеплоем и etc. В платформу были добавлены многие фичи, повышающие уровень автоматизации задач разработки. Однако, все эти фичи были добавлены только и исключительно для разработки собственных крупных продуктов, когда стало очевидно, что без автоматизации уже никак. Появились авто-слияния, трехстороннее сравнение KDiff-ом и всякое такое. На гитхабе запущен gitconverter, который, положа руку на сердце, был идеологически утянут с проекта gitsync, но доработан под процессы компании-вендора. Благодаря упоротым парням из open-source автоматизация разработки в 1С сдвинулась с мертвой точки. Открытое API конфигуратора, имхо, сдвинула бы и моральную отсталость основной IDE.

На сегодняшний день, хранение исходников 1С в git с привязкой коммитов к задачам в Jira, ревью в Crucible, накатка кнопкой из Дженкинса и отчеты Allure о тестировании кода в 1С и даже статический анализ в SonarQube — это уже далеко не новость, а, скорее, мейнстрим в компаниях где есть много разработки на 1С.

Администрирование

Вот тут есть много о чем сказать. Во-первых, это, конечно-же сервер (кластер серверов 1С). Замечательная штука, но за счет того, что это полностью черный ящик, документированный достаточно подробно, но специфичным образом — осилить запуск бесперебойной работы в режиме highload на нескольких серверах — это удел избранных, которые носят медаль с надписью «Эксперт по технологическим вопросам». Стоит отметить, что в принципе, администрирование сервера 1С не отличается от администрирования какого-нибудь другого сервера. Это сетевое многопоточное приложение, потребляющее память, процессор и дисковые ресурсы. Предоставляет широкие возможности для сбора телеметрии и диагностики.
Проблему здесь составляет то, что вендор не предлагает ничего особенного в части готовых решений для этой самой диагностики. Да, есть 1С: КИП и ЦУП, они даже и неплохи, но сильно платные и есть не у всех. В сообществе есть ряд наработок по подключению графаны, заббикса, ELK и прочего из типового набора админа, но единого решения, которое устроит большинство — нет. Задача ждет своего героя. А если вы бизнес, который планирует запуститься на кластере 1С — вам нужен Эксперт. Свой внутри или со стороны, но нужен. Это нормально, что есть отдельная роль, с компетенциями по работе сервера, не каждый 1С-ник должен это знать, просто надо понимать, что такая роль нужна. Возьмем к примеру SAP. Там программист, скорее всего, даже со стула не встанет, если ему на сервере приложений предложат что-то настроить. Он может тупо не уметь и ему стыдно не будет. В методологии SAP есть отдельная роль сотрудника под это. Почему-то в отрасли 1С считается, что это должно сочетаться в одном сотруднике за ту же зарплату. Это заблуждение.

Минусы сервера 1С

Минус ровно один — надежность. Или, если угодно, непредсказуемость. Внезапные странности поведения сервера уже стали притчей во языцех. Универсальное средство — остановка сервера и чистка всех кешей даже описаны в настольной книге эксперта и даже рекомендован батничек, который делает это. Если у вас 1С начала делать то, чего не должна делать даже теоретически — время чистить кеш сеансовых данных. По моей оценке, людей, которые умеют эксплуатировать сервер 1С без этой процедуры — во всей стране человека три и они не делятся секретами, т.к. с этого живут. Возможно, их секрет в том, что они чистят сеансовые данные, но никому не говорят про это, гыгыгы.

В остальном, сервер 1С это такое же приложение, как любое другое и администрируется примерно так же, посредством чтения документации и стука в бубен.

Docker

Полезность применения контейнеризированного сервера 1С в продакшене пока не доказана. Сервер не кластеризуется простым добавлением нод за балансировщиком, что сводит преимущества контейнеризации продакшена к минимуму, а практика успешной эксплуатации в контейнерах в режиме highload — не наработана. В результате, докером+1С пользуются только разработчики для поднятия тестовых сред. Там это зело полезно, применяется, позволяет играть с современными технологиями и отдыхать от уныния конфигуратора.

Коммерческая составляющая

С точки зрения инвестиций — 1С позволяет закрыть задачу быстрого запуска бизнес-идей за счет широких возможностей прикладных классов. 1С из коробки дает весьма достойный Reporting, интеграцию с чем угодно, веб-клиент, мобильный клиент, мобильное приложение, поддержку разных СУБД, в т.ч. бесплатных, кроссплатформенность как сервера, так и устанавливаемых клиентских частей. Да, UI приложений будет желтым, иногда это минус, но далеко не всегда.
Выбирая 1С, бизнес получает набор программных решений, позволяющих строить очень широкий спектр приложений, а также массу разработчиков на рынке, которые хотят денег меньше чем джависты и при этом быстрее выдают результат.
Например, задача послать клиенту счет в PDF решается за час работы студента. Та же задача на .NET решается покупкой проприетарной библиотеки, либо парой дней или недель кодинга сурового бородатого разработчика. Иногда, и то и другое сразу. И да, я говорил только про формирование PDF. Мы не сказали, откуда этот счет вообще появится. Веб-фронтендер должен наверстать формочку, куда оператор вобьет данные, бэкендер должен будет создать dto-модели в для передачи JSON, модели для складирования в базу данных, структуру самой базы данных, миграции на нее, формирование графического отображения этого самого счета и только потом — PDF. На 1С, вся задача целиком, с полного нуля делается за час ровно.

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

Сколько времени займет эта задача у разработчика .NET с момента установки visual studio на чистый комп до демонстрации заказчику? А по стоимости разработки? То-то же.

Сильные стороны 1С, как платформы

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

Unicode. Что, блин, может быть проще? Не надо в 2019 году использовать однобайтные ASCII кодировки (кроме интеграции с дремучими legacy). Ни за что. Но нет же. Все равно кто-то в какой-нибудь таблице использует однобайтный varchar и приложение поимеет проблемы с кодировками. В 2015 году у gitlab отваливалась LDAP-авторизация из-за неправильной работы с кодировками, у JetBrains IDE до сих пор не везде работает с кириллицей в именах файлов. В 1С качественная изоляция прикладного кода от слоя работы с БД. Там нельзя типизировать таблицы на низком уровне и косяки малокомпетентных джуниоров на уровне БД там невозможны. Да, там возможны другие косяки малокомпетентных джуниоров, но разнообразие проблем сильно меньше. Вы мне сейчас скажете, что у вас-то приложение спроектировано правильно и слой доступа к БД изолирован как положено. Посмотрите в свое корпоративное самописное Java-приложение еще раз. Пристально и честно. Совесть не мучает? Тогда я за вас рад.
Нумерация документов/справочников. В 1С она точно не самая гибкая и не самая лучшая. Но что делают в банковском софте и в самописных системах учёта — ну это же просто мрак. То identity воткнут (и потом «ой, а почему у нас дырки»), то наоборот, сделают генератор, который работает с блокировкой на уровне СУБД (и станет узким местом). На самом деле, довольно сложно сделать эту, казалось бы, простую задачку — сквозной нумератор сущностей, с разрезом уникальности по некоторому набору ключей, префиксацией, так чтобы это не блокировало базу при параллельном вводе данных.
Идентификаторы записей в БД. 1С приняла волевое решение — все идентификаторы ссылок абсолютно синтетические и всё тут. И нет проблем с распределенными базами и обменами. Разработчики других систем упрямо лепят что-то типа identity (она же короче!), тащат их в GUI, пока не придёт пора делать несколько связанных инстансов (и тут их ждёт открытие). У вас такого нет? Честно?
Списки. В 1С есть достаточно удачные механизмы листания (больших) списков и навигации по ним. Сразу оговорюсь — при правильном применении механизма! Вообще тема достаточно неприятная, она идеально не решается: тут либо интуитивно и просто (но риск огромных рекордсетов на клиенте), либо той или иной кривизны пейджинг. Те, кто делают пейджинг часто делают его криво. Те, кто делает честный скроллбар — кладут базу данных, канал и клиента.
Управляемые формы. Спору нет, в веб-клиенте интерфейс работает не то чтоб идеально. Но работает. А вот для многих других учётных и банковских систем сделать удалённое рабочее место — это проект уровня предприятия. Оговорка: к счастью для тех кто изначально сделал на вебе это не коснется.
Мобильное приложение. С недавних пор вы можете писать и мобильные приложения, находясь в той же самой экосистеме. Тут чуть сложнее, чем с веб-клиентом, специфика устройств заставляет писать специально под них, но, тем не менее — вы не нанимаете отдельную команду мобильных разработчиков. Если нужно приложение для внутренних нужд компании (когда мобильное решение корпоративной задачи важнее желтого дизайна UI) — просто пользуетесь той же платформой из коробки.
Reporting. Под этим словом я понимаю не BI-систему с большими данными и лагом на ETL-процесс. Имеются в виду оперативные отчеты персонала, позволяющие оценить состояние учета здесь и сейчас. Остатки, взаиморасчеты, пересортицу и т.п. В 1С из коробки поставляется система отчетов с гибкой настройкой группировок, фильтров, визуализации на стороне пользователя. Да, на рынке есть аналоги круче. Но не в рамках решения все-в-одном и за цену порой выше, чем решение все-в-одном. А чаще даже наоборот: только reporting, но дороже, чем платформа целиком, и хуже по качеству.
Печатные формы. Ну-ка решите на .NET задачу отправки зарплатной ведомости в PDF сотрудникам на почту. А теперь задачу печати товарных накладных. А с сохранением их копий в тот же PDF? Для 1С-ника вывод в PDF любого макета это +1 строка кода. А значит + 40 секунд рабочего времени, вместо дней или недель на другом языке. Макеты печатных форм в 1С потрясающе удобны в разработке и достаточно мощны, чтобы конкурировать с платными аналогами. Да, наверное, в табличных документах 1С не так много возможностей по интерактиву, нельзя быстро получить 3D диаграмму с масштабированием при помощи OpenGL. Но оно точно надо?

Всё это лишь горстка примеров, когда ограничение функциональных возможностей или реализация с компромиссами оказывается важным архитектурным преимуществом в будущем. Даже компромиссный или не самый эффективный вариант — он уже есть в коробке и принимается как данность. Его самостоятельная реализация будет либо невозможной (потому что такие решения надо принимать в начале проекта, а там не до того, да и вообще архитектора нет), либо несколькими дорогими итерациями. В каждом из перечисленных пунктов (а это далеко не полный перечень архитектурных решений) можно накосячить и заложить ограничения, блокирующие масштабирование. В любом случае, вам, как бизнесмену, надо убедиться, что ваши программисты, делая «систему с нуля», имеют прямые руки и сделают тонкие системные моменты сразу хорошо.

Да, как и в любой другой сложной системе сама 1С точно так же имеет решения, которые в тех или иных аспектах блокируют масштабирование. Однако, повторюсь, по совокупности факторов, по стоимости владения, по количеству уже заранее решенных проблем — я не вижу на рынке достойного конкурента. За одну и ту же цену вы получаете фреймворк финансового приложения, кластеризуемый балансируемый сервер, с UI и веб-мордой, с мобильным приложением, с отчетностью, интеграцией и кучей еще чего. В мире Java вы нанимаете команду фронт-енда, бэкенда, отлаживаете низкоуровневые косяки самописного серверного кода и отдельно платите за 2 мобильных приложения под 2 мобильные ОС.
Я не говорю, что 1С решит все кейсы, но для внутреннего корпоративного приложения, когда не надо брендировать UI — что еще нужно?

Ложка дегтя

Наверное, сложилось впечатление, что 1С спасет мир и все другие способы написания корпоративных систем — неправильны. Это совсем не так. С точки зрения бизнесмена, если вы выбираете 1С, то помимо быстрого time-to-market необходимо учесть и следующие минусы:

Надежность сервера. Требуются действительно качественные специалисты, способные обеспечивать его бесперебойную работу. Мне неизвестна готовая программа подготовки таких специалистов от вендора. Есть курсы для подготовки к сдаче экзамена «Эксперт», но этого, на мой взгляд, недостаточно.
Поддержка. Смотри предыдущий пункт. Чтобы иметь поддержку от вендора, ее надо купить. Почему-то в отрасли 1С это не принято. А у SAP — почти обязательно к приобретению и никого это не смущает. Без корпоративной поддержки и без эксперта в штате — с глюками 1С можно остаться один-на-один.
Все-таки на 1С нельзя сделать совсем все. Это инструмент и как у каждого инструмента у него есть границы применимости. В ландшафте с 1С очень желательно иметь «не 1С-нутого» системного архитектора.
Хорошие 1С-ники стоят не дешевле хороших программистов на других языках. Хотя, плохих программистов нанимать дорого независимо от языка, на котором они пишут.

Расставим точки

1С это фреймворк быстрой разработки приложений (RAD) для бизнеса и заточен под это.
Трехзвенка с поддержкой основных СУБД, клиентским UI, весьма неплохим ORM и репортингом
Широкие возможности по интеграции с системами, которые умеют то, чего 1С не умеет. Хотите машинного обучения — возьмите Python, а результат слейте в 1С по http или RabbitMQ
Не надо стремиться делать все на 1С, надо понимать ее сильные стороны и использовать их в своих целях
Разработчики, которые тяготеют к копанию в технологических фремворках-гаджетах, и к переделыванию каждые N лет на новый движок — в 1С скучают. Там все очень консервативно.
Скучают разработчики и в силу очень маленькой заботы о них со стороны фирмы производителя. Скучноватый язык, слабая IDE. Они требуют модернизации.
С другой стороны, разработчики, которые не могут найти себе развлечение посредством применения и изучения другой нравящейся технологии — плохие разработчики. Они будут ныть и перейдя в другую экосистему.
Работодатели, не позволяющие своим 1С-никам запилить что-то на Питоне — плохие работодатели. Они потеряют сотрудников с пытливым умом, а на их место придут monkey-кодеры которые, будучи со всем согласны, затащат корпоративный софт в болото. Его все равно придется переписать, так может было б лучше чуть ранее немного инвестировать в Питон?