В статье рассмотрены недостатки типовых конфигураций с точки зрения программиста.

Проблемы в коде и архитектуре

Привязанность кода к конкретной задаче

Очень часто код располагается в формах, что делает его выполнение возможным только на клиенте.

Часто процедуры в формах и модулях не помечены как экспортные. Их можно сделать экспортными через расширение, но штатно они недоступны.

Функции плохо изолированы, всегда связаны друг с другом и часто с контекстом формы.

Примеры:

1. Загрузка выписки — только из формы

2. Заполнение организации и контрагента по ИНН — плотно привязано к форме. При создании организации программно приходится извлекать и дублировать код.

Святость галочки «Вызов сервера»

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

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

Было бы логичнее помечать функции, которые вызываются только с сервера, как это сделано с ключевым словом Экспорт.

Святость извлечения данных запросами

1С молится на извлечение данных запросами в ущерб понятности и читаемости кода.

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

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

Странные контейнеры и упаковки данных

Например, при печати данных несколько табличных документов объединяются в один и затем уже разделяются областями Документ1, Документ2, вместо передачи их в коллекции.

Коллекции пытаются имитировать объекты, но часто их логика состава полей очень странная.

Галлюциногенные цепочки асинхронных процедур

Если посмотреть, как 1С оформляет цепочки асинхронных процедур, то можно ужаснуться.

Их наименование совершенно не говорит о том, что в них происходит. Комментарии отсутствуют.

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

Полюбоваться можно, отладив, например, пробитие чека.

Отсутствие «безопасных» вызовов

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

Изменчивый naming

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

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

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

Пример: ввести в конфигурации отбор по «Удалить«, будет выдано более сотни элементов.

Нарушение одинаковости

Одни и те же интерфейсные элементы могут иметь разное наименование, например кнопка добавить в табличной части Запасы имеет название ЗапасыДобавить или просто Добавить в УНФ.

Или правая колонка в документах может иметь название ПраваяКолонка или ШапкаПраво.

Неоптимальные решения

1С декларирует, что «борется» за производительность. Но во многих местах ее кода полно неоптимального кода.

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

Клонирование функционала

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

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

Недостатки функционала

Решил добавить раздел, где опишу недостатки функционала, потому что некоторые говорят мне — ну ладно, пусть типовые 1с это черный запутанный сложный, не поддающийся анализу ящик кода, но свои задачи решает?

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

1. Методисты рассматривают задачу в тепличных условия, без сбоев и ошибок.

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

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

Многострадальная себестоимость

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

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

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

1С работает на стороне государственных органов

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

Например, запрещает настраивать две кассы на одном рабочем месте.

Сгораемые бонусы в 1С считаются неправильно

Сгораемые бонусы, которые начисляются на определенный срок, а потом сгорают — это типичный пример партионного учета. Но в последние пятилетки 1С отказывается от партионного учета и пытается вместо него делать какие-то костыльные решения. Но природу бонусов не обмануть — она партионная.

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

Детская травма ролей доступа

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

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