Привет, Хабр! На связи Саша Чебанов, product owner платформы Modus.

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

Язык программирования 1C — это язык для написания кода и создания алгоритмов при работе с технологической платформой «1С:Предприятие». Для простоты понимания и сокращения букв я буду писать «язык 1С» или просто «1С».

Так вот, 1С — это давно не только язык локальной бухгалтерской или финансовой программы, а мощное решение, проверенное огромным количеством компаний сектора enterprise. Например, в сервисе «1С:Фреш» тысячи предприятий и десятки тысяч пользователей, которые одновременно работают в облаке.

1С предназначен для:

  • описания внутренней логики работы приложений «1С: Предприятие»;

  • ввода и вывода информации и ее изменения;

  • работы с формами объектов и списков, описания их внешнего вида и поведения;

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

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

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

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

Визуализация ациклических графов
Визуализация ациклических графов

У 1С есть плюсы и минусы, ниже поговорим про них.

Высокая скорость разработки

У 1С есть технологическая платформа – это и среда исполнения, и набор средств для разработки приложений и администрирования.

Интерфейс платформы 1С
Интерфейс платформы 1С

По большому счету, 1С – это большая low-code платформа для настройки доступных на этом уровне объектов. Поэтому с точки зрения frontend мы не программируем «с нуля» формы интерфейсов, а конфигурируем из доступных шаблонов, настраиваем получившийся элемент и передаем информацию в движок. Дальше за отображение элемента отвечает платформа.

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

Платформа сильно сокращает время на модификацию продукта. К примеру, перед нами стоит задача обеспечить ввод, модификацию и выполнение шагов преобразования данных, при этом нужно предоставить простой и понятный интерфейс пользователю, хранить историю изменений объектов и ограничить доступ к каким-то данным у части пользователей. Трудозатраты вырастут в 8-10 раз, если мы решим сделать задачу не в 1С, а в web-серверном приложении, где, например, серверная часть написана на Go, а клиентская на Reackt.

В качестве еще одного примера приведу антикейс другой компании. У них есть система управления внутренней инфраструктурой, которая написана на 1С. В 2022 году решили ее переписать: разработать backend на Python, frontend на JavaScript. Количество спринтов для реализации задач, решавшихся в 1С за один, выросло в несколько раз. В итоге, они вернулись к 1С.

Концентрация на архитектуре и функциональности, а не на коде

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

Поэтому 1С-программист меньше погружен в код и больше – в бизнес-процессы: управление производством (ERP), складом (WMS), бюджетирование, документооборот и т.п. Он должен понимать, как организованы и работают эти процессы, чтобы составить архитектуру будущего приложения. 

Платформа берет на себя работу с кодом, облегчает решение прикладных задач и дает возможность погружаться в работу с предметно ориентированными объектами метаданных (справочниками, документами, регистрами и т.д.).

Более низкая стоимость владения и сопровождения продукта на 1С

Существенная часть стоимости владения для заказчика – это стоимость обслуживания аналитической системы, куда входит ФОТ сотрудников.

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

И чаще всего, для этого не нужно нанимать дополнительного специалиста – в компаниях, как правило, уже есть разработчики 1С. И стоимость часа их работы ниже, чем программистов Java, С# и других.

Если такого специалиста в штате нет, то найти его тоже проще. Если посмотреть резюме, то количество кандидатов 1C – примерно 40% от общего количества соискателей, а оставшиеся 60% будут распределяться между 10-15 другими языками. Например, на сайте hh.ru в Москве прямо сейчас ищут работу программиста около 490 000 человек. Из них по языкам: 172 328 программируют на 1С, 5 040 – на Go, 75 884 на JavaScript, 38 767 – на С#.

Минусы 1С

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

Приведу пример, что нельзя или неудобно делать на 1С:

  • Визуальные формы для удобной работы с не специфичными для 1С объектами. Например, вот здесь я писал про WorkFlow. Мы подключили библиотеку GoJS и использовали JavaScript, внедрив ее в 1С.

  • Выполнять большое количество математических расчетов с оптимальным потреблением памяти.

  • Решать задачи, связанные с компьютерной графикой и т.д.

  • Полностью кастомизировать шаблоны. Это не значит, что интерфейс будет «как в «1С:Бухгалтерия» 2000-х годов». Просто форма 1С всегда выдержана в одном стиле, который мы можем кастомизировать, но не полностью.

Рабочий список
Рабочий список

Например, вот интерфейс рабочего списка из Modus ETL.

Мы не сможем здесь:

  • убрать или поменять лого 1С и обозначение меню тремя чертами в верхней части;

  • отменить уведомления;

  • изменить структуру размещения подсистемы;

  • изменить «звездочку» на кнопке, чтобы добавить ее в избранное или вернуться назад, вбок и т.п.

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

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

Если бы у нас было много таких форм и элементов, не стоило бы использовать 1С – риски были бы слишком велики, нужно было бы долго отлаживать всю систему при добавлении новых компонентов. К примеру, связать 1C и JavaScript не так просто. Но т.к. у нас всего 2 такие формы, то 1С здесь оправдан.

Интеграция с другими системами

Есть несколько вариантов интеграции аналитической платформы, написанной на языке 1С, и учетных систем, написанных на других языках:

  • через http-сервис;

  • через веб-сервисы (SOAP);

  • через файловый обмен;

  • через сервисы интеграции (новый функционал для поддержки брокеров сообщений, типа «1С: Шина» или Rabbit MQ).

В последнее время набирает популярность способ интеграции через http-сервис.

Например, наш Агент ETL, который предназначен для сбора данных из различных источников, взаимодействует с 1С через http-сервис. Если нужно интегрировать аналитическую платформу с каким-то необычным ПО – например, мы работали с лабораторной системой, которая управляла всем технологическим процессом – мы подключаемся через API.

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

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

Комментарии (22)


  1. panvartan
    10.08.2023 17:04
    +9

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


    1. Alek_Che Автор
      10.08.2023 17:04
      +1

      Да, система ограничена своим функционалом, и заставляет «играть по ее правилам». Если вы имеете в виду «конечных пунктов» – «функциональные возможности», то зачем их в рамках одной ИС закрывать?

      Например, для действительно крупного федерального сегмента в проекте вы увидите не одну только 1С и не в единственном экземпляре.

      Вот конкретный пример: внедряли подсистему учета кадров и ЗП в одном федеральном ведомстве, где пользователями были все кадровые службы этого ведомства в регионах и центральном управлении (представляете количество человек, да?). И могу сказать, что каждая функциональная подсистема была реализована отдельным решением. Связь между этими решениями была через общую шину (которая тоже, кстати, на 1С была реализована).

      Старт эксплуатации случился в 2018 году, и сейчас система уверенно существует и развивается, причем за последние 4 года количество программистов поддержки не увеличилось.


  1. ramil_trinion
    10.08.2023 17:04
    +1

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

    Каша из топора))


  1. Andy_U
    10.08.2023 17:04
    +2

    Мы часто сталкиваемся с несколько устаревшим мнением, что язык 1С – это только про финансовые системы.

    Значит, правда?


    1. Ghostcar
      10.08.2023 17:04
      +1

      Чатик уже есть. Видеозвонки есть. Сторисы, если будет потребность, запилят и будут продавать за бабло.


  1. uuger
    10.08.2023 17:04
    +1

    Как по мне, это не статья, а материал для пресейл брошюры


  1. damewigit
    10.08.2023 17:04
    +3

    А как у вас дела обстоят с CI/CD, а конкретно

    • Используете ли вы системы типа GitHub или Gitlab для того чтобы прозрачно отслеживать изменения в коде, проводить там review, иметь понятный, прозрачный и защищенный workflow, который не позволит без апувов/автотестов коду залететь в прод или в основную ветку?

    • Получается ли у вас декларативно выкатывать в прод one-time скрипты/код которые должны менять/исправлять структуру данных?

    • Автотесты (unit/интеграционные). Насколько сложно, автоматически поднять отдельный инстанс приложения со всеми данными в контейнере и натравить на него UI тесты? А unit тесты вы пишите?

    И еще интересно, как можно без ООП не превратить бизнесовый код в полотно спагетти-кода, без явных архитектурных границ?


    1. Ghostcar
      10.08.2023 17:04
      +4

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

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

      Развернуть копию - это, буквально, поднять текущий бэкап SQL базы прода в отдельную базу и прописать путь к ней. Всё, будет полноценный инстанс, в котором делай что хочешь. Что касается тестов - тесты есть. В силу специфики, запускаются вручную.

      В 1С ООП реализовано. Да не полностью, нет, непонятно зачем нужных в бизнес-логике наследований, полиморфизмов и прочих механизмов реализации БИБЛИОТЕК кода, пригодных для переиспользования в других проектах. Платформа предоставляет специализированные объекты, предоставляет возможность на основании этих объектов создать прикладные объекты (вот оно ваше наследование). Имеет типизацию. Имеет возможность создавать методы для объектов. Что ещё от ООП нужно для создания прикладной бизнес-логики?


      1. uuger
        10.08.2023 17:04

        Развернуть копию - это, буквально, поднять текущий бэкап SQL базы прода в отдельную базу и прописать путь к ней. Всё, будет полноценный инстанс, в котором делай что хочешь. Что касается тестов - тесты есть. В силу специфики, запускаются вручную.

        Свежо предание, да верится с трудом (с)

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


        1. Ghostcar
          10.08.2023 17:04

          А больше нет настолько массовых ОДИНАКОВЫХ решений. А тут процент багов именно таких - большой именно за счет массовости. Плюс специфика работы с данными и большого количества человеческого фактора при вводе данных.


    1. Alek_Che Автор
      10.08.2023 17:04
      +1

      Отвечу по порядку:

      Используете ли вы системы типа GitHub или Gitlab

      Получается ли у вас декларативно выкатывать в прод one-time скрипты/код которые должны менять/исправлять структуру данных?

      Есть gitlab. Но используется не для CI/CD, а для анализа изменений и просмотра истории кода. Для CI/CD используется Jenkins, который выполняет автоматическую сборку проекта, прогон unit и сценарных тестов, статический анализ код, рассылку отчетов. Только после этого принимается решение перенести код в основную ветку и собрать дистрибутивы. Развертывание на наш внутренний прод. автоматизировано, есть скрипты которые деплоят все изменения, с созданием бэкапов, блокировками и рассылками в телегу. Для этого активно используется OneScript (https://oscript.io/) и пакеты из библиотеки для него (https://github.com/oscript-library).

      Автотесты (unit/интеграционные). Насколько сложно, автоматически поднять отдельный инстанс приложения со всеми данными в контейнере и натравить на него UI тесты? А unit тесты вы пишите?

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

      И еще интересно, как можно без ООП не превратить бизнесовый код в полотно спагетти-кода, без явных архитектурных границ?

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


  1. remzalp
    10.08.2023 17:04

    Сколько живу и общаюсь, но если "разработчик" и "1С" встречаются в одном приложении - это всегда означало встречу с кем-то больше похожим на самоуверенного джуна. Единственный вменяемый разработчик 1С описан у @nmivan, да и тот вымышленный :)

    Единственный плюс 1С для русского разработчика - раскладку переключать не надо:
    print("Привет мир!") -> ВЫВЕСТИ("Привет мир!")


    1. SGordon123
      10.08.2023 17:04

      о кавычках же надо думать, где русские где английские ;-))


    1. Honomer
      10.08.2023 17:04

      Не Вывести, а Сообщить


  1. gennayo
    10.08.2023 17:04

    Как только бизнес, использующий 1С, становится крупным - стоимость сопровождения и уровень боли при этом улетает в космос...


    1. MaksIII
      10.08.2023 17:04
      +2

      Это справедливо для любой учетной системы, почивший (в РФ) SAP стоил куда дороже 1С


      1. gennayo
        10.08.2023 17:04

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


      1. Alek_Che Автор
        10.08.2023 17:04

        Пару лет назад для одного холдинга мы писали интеграцию зарплатного блока с блоком HR SAP, там не хвалило нескольких аналитик в карточках сотрудников (в SAP один физик может быть только одним сотрудником, о ужас!), так добавление аналитик для обмена стоило чуть ли не 10% от всего бюджета нашего проекта (6 месяцев, 10 человек). Вокруг SAP мы как могли изгалялись, лишь бы его не дорабатывать.


    1. koltsov22
      10.08.2023 17:04

      ну так и что предлагается делать чтобы этой боли не было?


      1. Alek_Che Автор
        10.08.2023 17:04
        +1

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

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


      1. gennayo
        10.08.2023 17:04

        Хороший вопрос... Возможно, своевременно осознать, что держаться за 1С далее будет слишком дорого и рискованно.


    1. DMGarikk
      10.08.2023 17:04
      +1

      • стоимость сопровождения и уровень боли при этом улетает в космос

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


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


      в случае с 1С:


      2) отправляет задачу программисту
      3) задачку делают
      4) выплывает пачка багов и непродуманных ошибок (на аналитика зажали бабки как обычно)
      5) повторяем п.2 до итогового результата
      6) 1С страшно глючная, кто делает такой кривой софт олололо


      в случае с сап:
      2) отправляет задачу аналитику сап
      3) через неделю аналитик выкатывает план доработку стоимостью 500тыр за добавления округления одной цифры
      4) заказчик охреневает и идет считать в экселе
      5) САП идеально работает и не требует никаких донастроек! (потому что всю мелочевку считают в экселе)