Ну я бы не стал драматизировать ситуацию. 1С это прежде всего прикладные решения, та же бухгалтерия, торговля, зарплата и т.д., причем от разработчика таких решений требуется быть не столько профессиональным программистом, сколько специалистом в этих прикладных областях. Если заставить его писать низкоуровневый код, то с точки зрения производительности и чистоты он может и выиграет, но с точки зрения выполнения прикладных задач существенно проиграет, в том числе и по стоимости.
Низкий порог входа и низкая стоимость доработки и обеспечило 1С популярность, поверьте, там не все так плохо. Реально я не вижу им реального конкурента не смотря на все их недостатки. Даже на крупных внедрениях. Потому что все можно относительно недорого дописать.
А как это работает внутри, это не к разработчикам 1С, это к разработчикам платформы, это они должны реализовать корректную работу с СУБД, так, чтобы даже неоптимальные запросы разработчика прикладного решения превращались в максимально оптимизированные запросы СУБД.
И это нормально, прикладная область уже достаточно сложна и разработчик прикладного решения должен быть сосредоточен именно на решении прикладных задач, а не на низкоуровневом программировании, этим, повторюсь, должны заниматься разработчики платформы.
Плюс должен сохраняться требуемый уровень абстракции, потому что прикладное решение может работать с разными СУБД и это опять не забота разработчика 1С.
Да и стоимость такой разработки вырастет на порядок, так как потребует гораздо более высококвалифицированных специалистов. На выходе получим еще один SAP - долго и дорого, очень дорого. Сопровождать тоже дорого.
Да, у 1С как платформы есть проблемы производительности, неоптимальная работа с СУБД, спорные маркетинговые решения, которые еще более ухудшают ситуацию, но сколь-нибудь вменяемого аналога ей нет. Который бы позволял быстро и недорого разрабатывать прикладные решения.
Это бизнес, решение может быть неоптимальным, но здесь и сейчас, помогая решать текущие задачи, потому что вылизанное и идеальное решение, но потом может уже никому не пригодиться.
У нас разработчики борятся с тем что написали год назад, потому что надо обновится, а нельзя так как сломается. А пишут как? Да как сказал начальник планого отдела: «мужики надо чтоб вот так и так, а тут вот так. Можете?» «Можем. Служебку напиши и все напишем» Потом это пишется, потом это работает, люди начинают работать на этом, бизнес процесс уже или часть БП. И таких самоделок куча, ни документации ничего, половина уже кто писал уволилось.
Это не проблемы 1С, это проблемы подхода к процессу разработки, точнее полное его отсутствие. А также незнание типовых возможностей платформы. Когда вместо типовой процедуры используется собственный велосипед. Когда разработчик точно не знает что, где, когда, кем и зачем дописывалось, то обновлять такое решение естественно стремно.
Дополнительный хаос вносят франчи, там существует пагубная модель почасовой оплаты за разработку. А уж сколько фрагментов кода с зашитыми прямо в нем переменными (номенклатурой, контрагентами, пользователями и т.д.) я видел. С точки зрения кода - это работает. С точки зрения правил программирования - это зашквар. Но в этом скрыт свой тайный смысл - заказчик что-то поменял в своих данных и нужно снова дорабатывать обработку, т.е. платить франчу.
Также существуют ситуации, когда надо еще вчера, поэтому сильно в алгоритмы никто не вникает, ищется нужный кусок кода и туда втыкаются свои костыли, хотя правильнее было бы изменить весь алгоритм.
Сейчас 1С уходит от практики изменения конфигурации вводом механизмов расширений, пока там еще не все гладко, но уже сейчас значительно облегчает доработку баз, особенно если доработки сильно не меняют штатные алгоритмы, а расширяют или дополняют их.
Так что это сугубо человеческий фактор. Тут проблема не с 1С, а с культурой разработки в целом. Сколько раз сталкивались с такими же кривыми отраслевыми решениями, только если в 1С я сам могу залезть и переделать, то там все остается на милость разработчика. Снизойдет ли он и сколько денег попросит.
Не так давно внедряли мы общепитовскую конфигурацию Трактир, точнее переводили клиента с версии 7.7. То, что касается штатного функционала - работает без вопросов. А вот алкоголь работать так как надо не хотел, поддержка закрывала наши обращения с отпиской "не является ошибкой", вопрос "где это написано в инструкции" игнорировала и предлагала купить платную поддержку.
Пришлось лезть в код и в режиме отладки выяснять реальный алгоритм работы, который показал правильный набор настроек, причем в официальной инструкции некоторых моментов просто не было, а некоторые даны очень расплывчато. В принципе, за те деньги, что клиент заплатил нам, он бы мог купить платную поддержку и ему, возможно, все бы настроили. Но ничего бы не рассказали. Незачем франчам это делать, это же их хлеб. В нашем же случае все эти тонкости мы ему отразили в местной документации, вышло причем достаточно немного.