Comments 26
Программирование в 1с это маршрутизация данных между свойствами и методами встроенных объектов программы. Вы стрелочник, без возможности влиять на конструкцию или наполнение еле-еле подвижного состава. Когда конечных пунктов десятки это играбельно, когда их десятки тысяч играбельным должны быть уже вы.
Да, система ограничена своим функционалом, и заставляет «играть по ее правилам». Если вы имеете в виду «конечных пунктов» – «функциональные возможности», то зачем их в рамках одной ИС закрывать?
Например, для действительно крупного федерального сегмента в проекте вы увидите не одну только 1С и не в единственном экземпляре.
Вот конкретный пример: внедряли подсистему учета кадров и ЗП в одном федеральном ведомстве, где пользователями были все кадровые службы этого ведомства в регионах и центральном управлении (представляете количество человек, да?). И могу сказать, что каждая функциональная подсистема была реализована отдельным решением. Связь между этими решениями была через общую шину (которая тоже, кстати, на 1С была реализована).
Старт эксплуатации случился в 2018 году, и сейчас система уверенно существует и развивается, причем за последние 4 года количество программистов поддержки не увеличилось.
Что мешает на создавать тысячи справочников и регистров? Меня в этом останавливает только убогость языка запросов в 1с и отсутствие возможности языком запросом делать изменения в данных как в Sql
Что мешает на создавать тысячи справочников и регистров?
мне прям интересно стало, попробуйте создать тысяч 10 справочников и регистров... мне кажется конфигуратор харакири себе сделает от такого финта..да и сама 1Сина не загрузится
Недостающий функционал дописываем на другом стеке – выделяем части, которые не могут быть реализованы на 1С, и рассматриваем их, как отдельные сервисы или встраиваемые компоненты. Например, для высоконагруженных систем мы пишем сервис получения данных на Go. Часть, связанную с графическим проектированием, пишем на JavaScript.
Каша из топора))
Мы часто сталкиваемся с несколько устаревшим мнением, что язык 1С – это только про финансовые системы.
Значит, правда?
Как по мне, это не статья, а материал для пресейл брошюры
А как у вас дела обстоят с CI/CD, а конкретно
Используете ли вы системы типа GitHub или Gitlab для того чтобы прозрачно отслеживать изменения в коде, проводить там review, иметь понятный, прозрачный и защищенный workflow, который не позволит без апувов/автотестов коду залететь в прод или в основную ветку?
Получается ли у вас декларативно выкатывать в прод one-time скрипты/код которые должны менять/исправлять структуру данных?
Автотесты (unit/интеграционные). Насколько сложно, автоматически поднять отдельный инстанс приложения со всеми данными в контейнере и натравить на него UI тесты? А unit тесты вы пишите?
И еще интересно, как можно без ООП не превратить бизнесовый код в полотно спагетти-кода, без явных архитектурных границ?
Можно использовать гит. Функционал есть. Но, в большинстве случаев разработка ведется в проприетарной системе совместной разработки. И в среде 1С не принято цеплять прод к системе разработки. Обычно это самостоятельная база, все релизы на которые накатывается осознанно из специально подготовленного файла.
Платформа 1С вполне адекватно умеет менять структуру данных. Да, требуется отправить прод на техническое обслуживание, но сама бизнес-направленность подразумевает, что такие приостановки допустимы в моменты низкой активности, в основном - ночью.
Развернуть копию - это, буквально, поднять текущий бэкап SQL базы прода в отдельную базу и прописать путь к ней. Всё, будет полноценный инстанс, в котором делай что хочешь. Что касается тестов - тесты есть. В силу специфики, запускаются вручную.
В 1С ООП реализовано. Да не полностью, нет, непонятно зачем нужных в бизнес-логике наследований, полиморфизмов и прочих механизмов реализации БИБЛИОТЕК кода, пригодных для переиспользования в других проектах. Платформа предоставляет специализированные объекты, предоставляет возможность на основании этих объектов создать прикладные объекты (вот оно ваше наследование). Имеет типизацию. Имеет возможность создавать методы для объектов. Что ещё от ООП нужно для создания прикладной бизнес-логики?
Развернуть копию - это, буквально, поднять текущий бэкап SQL базы прода в отдельную базу и прописать путь к ней. Всё, будет полноценный инстанс, в котором делай что хочешь. Что касается тестов - тесты есть. В силу специфики, запускаются вручную.
Свежо предание, да верится с трудом (с)
Нигде больше я не видел такой высокий процент багов, которые воспроизводятся только на проде и никак не проявляются на других окружениях.
Отвечу по порядку:
Используете ли вы системы типа 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С" встречаются в одном приложении - это всегда означало встречу с кем-то больше похожим на самоуверенного джуна. Единственный вменяемый разработчик 1С описан у @nmivan, да и тот вымышленный :)
Единственный плюс 1С для русского разработчика - раскладку переключать не надо:
print("Привет мир!") -> ВЫВЕСТИ("Привет мир!")
Как только бизнес, использующий 1С, становится крупным - стоимость сопровождения и уровень боли при этом улетает в космос...
Это справедливо для любой учетной системы, почивший (в РФ) SAP стоил куда дороже 1С
САП обычно внедрял уже большой на момент внедрения бизнес. При этом расклады уже совсем другие, бизнес готов был платить (о причинах, почему был готов, промолчу, пожалуй).
Пару лет назад для одного холдинга мы писали интеграцию зарплатного блока с блоком HR SAP, там не хвалило нескольких аналитик в карточках сотрудников (в SAP один физик может быть только одним сотрудником, о ужас!), так добавление аналитик для обмена стоило чуть ли не 10% от всего бюджета нашего проекта (6 месяцев, 10 человек). Вокруг SAP мы как могли изгалялись, лишь бы его не дорабатывать.
ну так и что предлагается делать чтобы этой боли не было?
Соблюдаем соглашение о написании кода, выделяем функции программного интерфейса и не трогаем служебный, держим с самого начала архитектора решения, проводим ревью, держим грамотных аналитиков, коммитим изменения под задачи из трекера, контролируем задачи, входящие в релиз - и код от 10+ программистов через 5 лет будет читаемый.
А когда задачи решаются за 5 минут, исходя из подхода «сделай как можно быстрее, это нужно было вчера», и так на протяжении нескольких лет, то волшебства ждать не придется.
Хороший вопрос... Возможно, своевременно осознать, что держаться за 1С далее будет слишком дорого и рискованно.
- стоимость сопровождения и уровень боли при этом улетает в космос
ага, конечно, я помню гдето старую хохму о удобстве и безглючности сапа по сравнению с ненависной 1С вытекающий из простого факта:
1) менеджер, бухгалтер, и т.п., хочет какуюто фичу/фикс минорной ошибки, чуть подправить обработку какойто цифры
в случае с 1С:
2) отправляет задачу программисту
3) задачку делают
4) выплывает пачка багов и непродуманных ошибок (на аналитика зажали бабки как обычно)
5) повторяем п.2 до итогового результата
6) 1С страшно глючная, кто делает такой кривой софт олололо
в случае с сап:
2) отправляет задачу аналитику сап
3) через неделю аналитик выкатывает план доработку стоимостью 500тыр за добавления округления одной цифры
4) заказчик охреневает и идет считать в экселе
5) САП идеально работает и не требует никаких донастроек! (потому что всю мелочевку считают в экселе)
Язык 1С: плюсы и минусы для аналитических платформ