Comments 142
Вспоминаю 1С-ку с нежностью. Гениальная штука, кроме шуток. Фуллстэк-фреймворк, на котором обычный мидл между двумя чашечками чая делает то, на что во "взрослой" веб-разработке будет задача на целый спринт с сабтасками для дизайнеров, бэкендеров и фронтендеров.
1С до сих пор замечательно работает, когда не нужно ничего "сверх":
Сверхпроизводительности, сверхкастомизации, сверхмасштабов, и т.д.
Пока остаёмся в рамках типовых задач, скорость прототипирования и разработки действительно высокая.
Плюс у мелких организаций есть возможность, например, сделать небольшое мобильное приложение - и это сделает тот же самый миддл, дообучившись неделю, не надо нанимать отдельного человека, или переплачивать подрядчику
Крупные конторы сидят на 1С, потому что долго и дорого переписывать кучу легаси. Новые проекты "импортозамещения" стартуют на 1С, потому что практически нет альтернатив, подпадающих под условия "импортозамещения". Так что у 1С в России всё будет хорошо
у них и до импорта замещения было всё хорошо. условия как раз попаданием под отечественное либеральные у нас очень. взял опен сорс, дописал модуль- уже ответсвенное.
Или система с котороя я работал несколько лет- там вся бизнес логика реализована в хранилках на tsql. то есть жесткая привязка к mssql. но в реестре отечесвеного ПО. мы покупали через 223 фз. Аналогичные системы две были на oracle.
А вы попробуйте с этими системами зайти в транснефть или роснефть :)
Подтверждаю. Работал на проекте для одной из дочек Газпрома. Собственно, в общих чертах архитектура была понятна до меня, поскольку специфические требования (геоданные и прочее). Допиливал архитектуру на стеке, под который меня и других людей приглашали: C# и React (поскольку именно под React заточены практически все библиотеки работы с геоданными). Передали заказчику на утверждение список ПО. Получаем ответ: C# американский, React вообще написан Meta, которая в РФ считается экстремистской организацией. Ну и там что-то еще по мелочи.
я работал в одной из дочек газпрома. c# был. . собственно можете посмотреть вакансии разработчиков в компаниях группы.
Предполагаю, что от легаси никуда не деться. Невозможно то, что нарабатывалось десятилетиями взять и переписать на чем-то другом. Кроме того, попробуй это другое найти: куда не копнешь, везде Пентагон свои щупальца сунул, даже в open source, везде, если не террористы, так экстремисты злобные, закладывающие бомбы замедленного действия прям в публичные репозитории.
Ну и, видимо, требования к новым проектам были такие: все импортозаместить и не пущать! К тому же, дочка абсолютно зависимая, по сути прослойка, своего мнения принципиально не имеет, на все возражения отвечала либо шаблонно, либо, в лучшем случае, все отправляла в "голову", ответа от которой можно было ждать неделями по самому ничтожному вопросу. Имя дочки называть не буду, но у них слово "газ" в названии аж два раза, я сам чуть не газанул со смеху, как его услышал.
Короче, чем там все закончилось (или не закончилось), я не знаю. Лично для меня проект на этом этапе завершился.
смотря когда зайти. Я систему о которой говорю внедрял задолго до СВО. Лет 10 назад. Но тренд на импортозамещения для гос организаций уже был. Унитарка была. Не АО с мажоритарием гос-вом. И ПО закупали в т ч и как отечественное. А в Роснефти думайте нет, например SAP ?)) Сейчас понятно- mssql банально не купить легально.
Они давно там есть, часть пришла в довесок с покупкой новых компаний, а часть реализована уже в действующих. Всё есть и "малое" и "большое"
подпадающих под условия "импортозамещения"
Помнится, SAP тогда шикарно людям подгадил. Продал своего овнища на миллиарды и свалил, оставив всех без поддержки, новых форм отчётности и т.д.
Именно. Поэтому зависимость от такого партнёра, даже если он захочет вернутся- риск
Новые проекты не начинали бы- ок. но вот кидать тех кто тебе платил ярды..
Помнится, SAP тогда шикарно людям подгадил. Продал своего овнища на миллиарды и свалил, оставив всех без поддержки, новых форм отчётности и т.д.
Форм отчетности, бу га га. Для ERP формы отчетности это последнее дело, и так как SAP - это крупняки, то и отчтетность зачастую делали сразу свои штатные разработчики, не ожидая когда саповские индусы реализуют что то для России.
С уходом наоборот появились те кто специализируется на таких формах. Причем делают быстрее чем делал вендор, к примеру LAB SP.
Потому плевать на уход вендора, если платформа топовая, локализацию есть кому делать. Да плюс долю вендору засылать теперь не нужно, а ранее драли 21% от стоимости лицензий в год.
Крупные конторы редко сидят на 1с
Это вы явно не про Россию :)
Бред. Как раз на 1С и сидят.
Тут смотря как считать. Многие используют 1С-Бухгалтерию для сдачи фискальной отчетности, экспортируя туда данные из своей ERP. Но, как с точки 1С, так и с точки зрения интегратора - доход с такого клиента мало отличим от дохода с ИП, плательщика НДС.
Ну закупил Газпром несколько десятков лицензий 1С:Бухгалтерия ПРОФ на фоне десятков тысяч лицензий SAP. Можно ли при этом утверждать, что Газпром сидит на 1С?
Если пройтись по ТОП-100 списка Forbes - увидим аналогичную картину. 1C вроде бы как есть, но на фоне общих затрат компании на ERP доля 1С находится на уровне статистической погрешности.
Ну не взлетело у 1С ERP, да и не могло взлететь по целому ряду причин.
Одинэсничал с 2005 по 2017. Полностью согласен с автором. Это отличный продукт для своей ниши. Единственное что могу сказать плохого, из практики, - были трудности с масштабированием. Но сейчас, по слухам, это вроде как решено.
насколько понимаю они и шли от малого бизнеса к энтерпрайду. на 1С 7.7 помню были нарекания большие на sql версию. и люди использовали терминалку на которой и работали пользователи- пи их сколько либо существенном количестве. На восьмерке появился сервер приложений (кластер 1С)- уже можно и без терминального сервера использовать. сейчас может ещё что то придумали
1С довольно качественная платформа, но самое важное это большое количество специалистов на любой вкус и размер кошелька
С неприязнью вспоминаю 7-ю 1С-ку. Ради которой приходилось городить костыли с терминал-сервером. Но это моё отношение как админа сети в те времена.
Хотя сами 1С-ники ничего особо плохого про неё не говорили, благо куча однокурсников ушла по тем стопам.
Ну а с выходом 8-ки как понимаю и проблем таких не осталось.
А вот про SAP как раз читал всякое и понял, что ну очень недружелюбная система.
Мой опыт говорит, что 1С 7.7 как платформа была вполне себе ничего. И можно было найти сторонние конфигурации, которые снимали большинство проблем в функционале базовых решений от 1С. Проблемы с терминалами у нас тоже были, но, по моим ощущениям, они были вызваны нашим неумением нормально настроить термальную инфраструктуру и проблемами на каналах связи.
Если говорить прямо, то собирали из экологически чистых отечественных материалов, ломаных Windows, самосборных серверов на базе дешевой комплектухи для офисных ПК. программную часть настраивали по советам похмельных 1С-консультантов и по своему разумению. А физическими каналами были, по выражению наших телефонистов, «гнилые веревки». (Вот как ты думаешь, почему оно в дождь лучше работает? - Веревки-то намокают, гниют и лучше проводят сигнал). *DSL модемы и проблемы с электропитанием на складах добавляли еще перца в этот "локальный технологический суп".
А к моменту перехода на 1С v8* уже накопился опыт, гнилые веревки заменили на оптику и нормальную медь, закупили нормальные терминальные сервера.
Проблемы с терминалами у нас тоже были, но, по моим ощущениям, они были вызваны нашим неумением нормально настроить термальную инфраструктуру и проблемами на каналах связи.
У нас лет 15-ть крутилась конфигурация 1С7.7 БУХГАЛТЕРИЯ. "SQL-версия" с RDP-терминалами. 20+ канкарент юзеров.
"Тормоза" там связаны с тем, что версия не совсем SQL и "сервер" - не совсем сервер.
Проблема там - с оплоками на служебные файлы "сервера" и на временные файлы пользователя. Пользователей нужно разнести по собственным домашним папкам и каталоги временных файлов назначить отдельные.
Памяти на все это добро, понятно, нужно было много.
"Специалисты 1С", помнится, - сильно возражали против памяти почему-то.
По итогу - крутилось до тех пор, пока на 1С8 не переехали.
Я к тому, что "бутылочные горлышки" в многопользовательских системах искать задача нетривиальная. Требует специальных навыков.
Можно, конечно, ткнуть пальцем в небо, типа "многопоточности нет" или "1С7.7 плохая".
Но объемный тест сам себя не прогонит и монитор, определяющий сколько блокировок на каком файле висит сам себя не запустит...
С неприязнью вспоминаю 7-ю 1С-ку. Ради которой приходилось
8-ка УТП вышла в 2003 году.
Сразу трехуровневая с поддержкой MS SQL
22 года уже на рынке.
Именно народная любовь к v7.7 не давала ей развиваться.
1C умеет в многопоточность?
загуглил. в современных версиях -да
ФоновоеЗадание = ФоновыеЗадания.Выполнить("МойМетод", Параметры)
ПулПотоков = Новый ПулПотоков(4); // Создаем пул из 4 потоков ПулПотоков.ДобавитьМетод("МойМодуль.МойМетод");
Хотя мне году ещё в 16 том разработчики конфигурации реализовывали что то типа многопоточности. Может через win 32 api реализовывали
Интересно, почему тогда пишут что 1с любит "горячий" процессор, а не многоядерность? А фоновые задания это часом не порождения отдельного процесса?
Потому что практически нет задач в учете которые можно сделать в несколько потоков. Разве что запустить где-то формирования длительного отчета. А все основные действия обязаны проводиться атомарно.
А распаралелливание в большей части берет на себя сервер БД. Когда разбивает большие запросы на потоки. Клиент в итоге получает единый набор данных который выводится уже в UI потоке, который и так везде, в любых системах, один.
в UI потоке, который и так везде, в любых системах, один
Это не совсем так.
Я не знаю многопоточных UI тулкитов. Может быть имеется ввиду что-то типа SurfaceView из andoid или текстур directx или что-то еще. Но во всех известных мне вариантах другие процессы формируют кадр и отдают его в очередь основному потоку для компоновки в общий макет.
Я не про графические тулкиты. Это лишь обертки поверх системных библиотек типа GDI/GDI+/DirectX, которые тоже обертки, так как предоставляют HAL поверх драйвера видеокарты. И UI - это, прямо скажем, не отрисовка на экране. UI - это обмен сообщениями от пользователя системе и от системы пользователю. Разработчик UI может вообще не вызывать какие-либо функции отрисовки в явном виде, он работает с событиями и свойствами окон/контролов/виджетов.
И что именно здесь многопоточное? Я не знаю ни одного стека где функции отрисовки, вызываемые явно или не явно, работали бы в несколько потоков. Какие-то части UI могут создаваться отдельными потоками/процессами но результат они отдают одному компоновщику а не напрямую дергают железо для обновления области видеопамяти. Так же и обмены сообщениями между системой и пользователем. Все системы имеют очередь куда попадают сообщения от системы и обрабатываются последовательно.
Знаете в чем между нами разница? Вы категоричны, я нет.
Вот я написал "это не совсем так". Но вы начинаете яростно доказывать, что в UI все однопоточное, при этом упирая почему-то на отрисовку, которая только небольшая часть UI, которая, кстати, с точки зрения прикладного программиста вполне себе многопоточная, если ему это понадобится. Вообще, мне кажется, что вы не очень понимаете разницу между UI и графической подсистемой.
Я не буду говорить за системы на базе Unix я там не настолько компетентен, тем более, что там свой зоопарк в каждой семейке огромного клана: Quartz/QuickDraw GX в macOS, DRM/Wayland/Mesa в Linux, X11 в базе Unix и т.п. Но я неплохо разбираюсь в Windows. Так вот, если взять всю цепочку от настоящего UI до рендеринга, то там на каждом слое свои пляски с бубном по поводу параллелизма.
Самый верхний уровень, включая объектные врапперы типа .NET WinForms, MFC или Qt, является вполне себе многопоточным. Можно Можно создать дополнительный поток UI, для него будет создана отдельная очередь сообщений. Да, там понадобится организовывать отдельное взаимодействие между потоками, да там будут ограничения и окно из одного потока не сможет владеть окном другого потока, да многопоточнось на этом уровне закончится на единственной очереди сообщений приложения (хотя обычно прикладник с ней дело имеет крайне редко). Но при всем при этом UI будет с точки зрения пользователя вполне себе многопоточным (в рамках отдельных окон верхнего уровня) и если "подвиснет" окно из одного потока из-за того, что этот поток занят работой или находится в состоянии ожидания, то окна из других потоков вполне себе останутся интерактивны.
Идем глубже, в слой отрисовки. Опять же, с точки зрения прикладного программиста здесь все вполне себе многопоточное: если я создал несколько UI потоков, то я не должен беспокоиться о том, что отрисовка должна происходить в один момент в одном единственном потоке и что-то там вручную блокировать. Все это происходит на уровне системных библиотек. Кстати, забавно, что виндовые GDI и GDI+ устроены ну очень по-разному и GDI+ действительно однопоточный начиная с уровня своего публичного API, т.е. если одно приложение начинает рисовать, получая контекст, то этот контекст исключительный и все остальные GDI+ приложения ждут, пока он не освободится. Так же GDI+, в отличии от GDI, не может корректно работать в службах Windows, так что если вам надо написать сервис, к примеру, выводящий что-либо на печать, то добро пожаловать в GDI. Так вот, на уровне отрисовки в рамках системных библиотек (за исключением мьютексного GDI+) все еще работает мультипоточность.
Тут мы спускаемся еще на уровень ниже - на WDDM пользовательского режима. И драйверы пользовательского режима все еще многопоточны https://learn.microsoft.com/en-us/windows-hardware/drivers/display/threading-model-of-user-mode-display-driver с единственным ограничением, что если поток создал устройство, то им может пользоваться только он, совсем как с окном на уровне оконного UI.
Если пойдем еще глубже, на уровень ядра, то выясняется, что ядерные miniport-драйверы (тадааам!) тоже могут быть вполне себе многопоточными, но тут уж от вендора все зависит https://learn.microsoft.com/en-us/windows-hardware/drivers/display/threading-and-synchronization-model-of-display-miniport-driver.
До эпохи WDDM действительно на переходе от системных библиотек пользовательского режима к режиму ядра все функции отрисовки укладывались в очередь (не простую, конечно, а очень хитрую, с приоритетами и другими плюшками, типа выбрасывания "протухших" по времени команд отрисовки), но эти времена давно прошли, вся отрисовка теперь передается сверхумным драйверам акселераторов, которые и тайловую структуру, и шейдерные вычислители и бог знает что еще задействуют для реальной распараллеленной оптимизированной отрисовки.
Спасибо за ретроспективу. Только к чему она. Единственное относящееся к вопросу - " врапперы типа .NET WinForms, MFC или Qt, является вполне себе многопоточным", просто ложь. Все эти технологии используют Single UI Thread. Вы можете запустить какие-то потоки но обновлять UI можно только из основного. Если вы запустите новый Application.Run то это будет уже другой процесс, физически другое окно в системе. Ничем в общем то не отличающееся от запуска двух экземпляров приложения.
Еще раз повторюсь я не знаю ни одного тулкита (это такой набор, предоставляющий разработчику готовые наборы элементов) работающих в не Single Thread модели.
познавательно. Не знаю правда любой ли мидл умеет разрабатывать решения с такой синхронизацией потоков.
Как же нет многопоточных задач - а параллельно подтянуть данные из разных апишек, очерпдность вызова которых не важна?
Какое кол-во конфигураций это используют? Особенно те, которые разрабатывались по появления этой функции
Мы про кластер 1С? там насколько помню порождается столько рабочих процессов сколько в настройках задашь.
А рекомендацию- да. Встречал. Насколько актуальна на сегодняшний день и для каких конфигураций -не скажу. Можно потестить. Тест Гилева в помощь. Не знаю, правда умеет ли он сам многопоточность
Это для однопользовательского режима, когда, допустим, ноут подбирают бухгалтеру для работы с файловыми базами.
То есть уже в платформе 8.3.XXXX это можно было реализовать в обработке например выполняющей запись PLU торговое оборудование по списку (речь о РРО и весах с принтерами и панелями самообслуживания?) А то что-то я что в интерактивных обработках что в т.н. "регламетных заданиях" не вижу никаких изменений годами. По сути повторяется один и тот же код, тупо в цикле склеивающий реквизиты в строку и запихивающий её на вход драйверу. Тот же самый подход я вижу и более в чувствительном расчёте который вместо параллельного запуска на выполнение нескольких запросов опять таки линейно их выполняет, что растягивает проведение итогового документа до полутора часов. Так что похоже с применением многопоточности всё сложно.
Не загуглили, а спросили у chatgpt. И кроме первой строки (и то с ошибкой) он вам сгаллюцинировал чушь
Умеет.
Да, на стороне сервера можно запускать фоновые задания отдельным потоком
Да здесь все правильно написано, 1С решает. Но когда в той статье чел написал, что 1С попахивает сектой, он выразил мое ощущение, которое я не мог сформулировать. Купи ознакомительный курс, купи обучающий курс, доступ к великим скрижалям только для своих помеченных)
Во, кстати да, с этой точки зрения 1С похожа на секту 😁
На самом деле почти вся информация есть в открытом доступе, большинство толковых книг по 1С тоже в сети болтаются. Сама 1С предоставляет бесплатно много материала.
Курсы - необязательны, но в среде 1С много крайне качественных курсов, с тонной полезного материала и поддержкой экспертов. Даже мелкие франчайзи периодически покупают курсы, один на несколько сотрудников. Но, повторюсь - в большинстве случаев необязательны.
Лично сам потратил на своё обучение и проф. развитие 1000 рублей на одну книжку. Сертификации - платные, 1000 рублей стоит прийти сдать тест "джун уровня", и порядка 5000 сертификация уровня "миддл". Но их оплачивал за меня работодатель.
таблички в SQL нормализованные до третьей формы? какие то справочники и регистры
Самое весёлое в этом то, что "справочники и регистры" это и есть те самые "таблички, нормализованные до третьей формы" :)
Доступные с самого начала программирования на платформе. Не, можно, конечно, лихим наскоком с методом Тыка наперевес соорудить вообще что угодно (платформа и это позволяет), но в целом, если изучить хоть что-то, прежде чем начинать разработку, то получается, что даже самому новичковскому новичку сразу доступны инструменты, позволяющие разрабатывать плюс-минус правильно.
я понимаю что регистр конкретный в базе БД в виде таблицы явлен. Тут личное- я не с ORM привык работать а более низким уровнем. Понятно, что здесь немного другой понятийный аппарат. и это имеет свои плюсы. Не задумывается разработчик о каком ни будь odbc и обработки ошибки подключений к СУБД. Берёт это на себе платформа
Неа, регистры как раз не нормализованы до третьей нормальной формы. Точнее, они сознательно денормализованы для улучшения производительности. И это нормально :-)
Неа, регистры как раз не нормализованы до третьей нормальной формы
Это почему?
Измерения - внешние ключи из других таблиц, ресурсы - данные этой таблицы. Транзитивных отношений в самой структуре регистра нет.
Понятно, что в конкретный регистр можно запихнуть что угодно и как угодно в нарушение всех нормальных форм и здравого смысла, но сам по себе инструмент-то сделан корректно.
Начнем с того, что регистр (накопления) это две таблицы — движений и остатков, и данные во второй однозначно вычисляются из данных в первой. А данные в первой однозначно вычисляются из данных в таблицах документов-регистраторов.
И я, кстати, не говорил, что инструмент сделан некорректно. Просто нормализация — это не божья заповедь, и иногда её НУЖНО нарушать.
и данные во второй однозначно вычисляются из данных в первой
Поэтому таблица остатков и является виртуальной. В "традиционных" SQL-базах такие способы кэширования расчётов тоже имеются.
А данные в первой однозначно вычисляются из данных в таблицах документов-регистраторов
Это почти так, но не совсем. Данные в регистре бывают зависимы от времени выполнения записи в регистр, например, стандартизованные отчёты, которые при распроведении и повторном проведении записывают новый GUID - т.е. никакие исходные данные не изменились, но выходные данные - другие.
Просто нормализация — это не божья заповедь, и иногда её НУЖНО нарушать.
Да, теперь с подробным описанием я понял, о чём Вы говорите, полностью Вас поддерживаю.
у нас реально идиотское щаконодательство, поэтому лезть туда никто не хочет. туда идут криворукие любители ради ленег, поэтому все бух программы коивое говно из костылей. база 1с родная это такой калл что за него должны платить, а не ты платить за мускуль вместо нее
Вам автора той статьи не переубедить, он же "программист с 40 лет стажа".
Во всем согласен с автором. Но. Все таки платформа 1С - это МСП, к сожалению. Крупняк с количеством одновременно работающих пользователей от 1000, плюс за несколько лет работы появляющиеся узкие места - большие таблицы от нескольких сотен миллионов записей - начинают доставлять головные боли, убогую скорость записи, блокировки, и чисто "платформой" решить такое бывает невозможно.
поднимали выше вопрос. Да- изначально были большие проблемы. Сейчас полегче. я не 1Сник. Но в хозяйстве у меня была терминальная ферма где 1800 пользователей в ERP работали. База не маленькая. Компания огромная. Думаю там не чисто платформой- были и кастомные регламентные на сервере СУБД. И отдельный отдел который кластера 1С сопровождал. Какие настройки они на кластерах прописывали- не знаю. Причем там были ребята которые и в sql умели. И отдельно разработчики конфигураций (несколько отделов для разных конфигураций).
Собственно при количестве пользователей от тысячи многие системы требуют "доводки". Банально - один компонент обновляет данные на текущий лень (update+ insert). а другой формирует отчёт (за завершённый период. Но разрабы не озаботились тем что бы использовать select nolock (разрешить грязное чтение). и ко мне приходили коллеги которые никак не дождутся отчёта.
Тут или с уровнями изоляции работать. Но чревато- контроль тогда должен быть полностью на бизнес логике- либо восстановление из бэкапа копии во вторую базу и отчёты на основе неё. Пошел по второму варианту- время отчётов в 3 раза уменьшилось. Возможно ещё как то можно- я не профессиональный DBA. они думаю могут и ещё пару вариантов предложить.
Не суть. Идея в том что в энтерпрайзе так или иначе уже приходится с узкими местами работать. и next-next-next с параметрами по умолчанию не продут. и те же dba траблшутят планы выполнения выдавая рекомендации разрабам. Собственно за это нам и платят. было бы просто как в малом бизнесе- платили бы медианную ЗП. ну или чуть больше. Что в общем то в малом бизнесе и происходит.
Смысл в том, что даже если твоя команда разрабов в рамках разумного исполняет "систему стандартов и методик".
А архитекторы более менее не делают грубых ошибок в проектировании, умеют договариваться с бизнесом и убеждать его не плодить костыли.
То все равно рано или поздно большая вероятность возникнуть потребности в опытной, штучной и очень дорогой команде эксплуататоров-экспертов, шаманстве со скулем (прямая запись, неплатформенные индексы, всякие дата-акселераторы, о чем вы упомянули, ну и прочие штуки, нарушающие политику лицензирования платформы). И кстати шаманстве с неочевидным результатом.
И проблему вижу как раз таки в концепции самого фреймворка (платформы)-прокладки, максимально упростить разработку, но потерять в гибкости в плане положить/достать из sql.
Сам если что в 1Се около 15 лет, изначально и целенаправленно туда заходил еще в университете и до сих пор не сворачиваю.
Но считаю внедрение современной ERP/ERPУХ для "очень крупных" - профанацией и путем большой боли, в случае с "импортозамещением" - откровенной заявкой на распил.
До 1К пользователей это МСП??? Серьëзно?
А недавний тест на 30K одновременных сеансов под нагрузкой это тоже про МСП?
Очень часто в статьях (как в хвалебных, так и в гневных) упускают аспект стоимости владения системой с точки зрения поддержки законодательства. Если взять условный сектор СМБ, который использует 1С для ведения регламентированного учета + кадровый учёт и расчет зарплаты на "коробочных" решениях, поддержка требований законодательства (плохого или хорошего можно долго разглагольствовать, есть реалии) обойдется около 50 тыс. руб./год на момент написания комментария. При этом ещё и куча сервисов-плюшек в эту стоимость будет входить, включая пресловутый ИТС (1С: КП), который даёт ещё и вагон методологической поддержки для "учётных" подразделений бизнеса, при условии если хотят и умеют пользоваться.
Это я все к лейтмотиву статьи: есть реальные ежедневные задачи бизнеса, которые 1С решает очень дёшево, но иногда и сердито.
P.S. сам из той самой пресловутой секты, но не занимаюсь слепой экспансией, прекрасно понимаю и плюсы и минусы
У автора не снобизм, а карма фарминг с рэйдж байтом, он же написал в комментариях, что 1С много лет в глаза не видел, а пишет для развлечения
Последний раз 1с я видел в декабре. На прошлой работе. На новой у меня задачи совсем иные пока. В конфигуратор заходил. прошлым летом- траблшутили с разработчиком блок кода выдающий ошибку который на стороне клиента выполняется или на сервере кластера 1С.
А написал я, что не являюсь 1С разработчиком, но во внедрениях участвовал активно.
[речь об авторе исходной статьи с "критикой"]
Я правильно понимаю, что вся основная информация по языку и разработке у 1с закрытая? Хочешь знакомиться - проходи курсы, верно?
Нет, не правильно. Есть совершенно бесплатная версия для обучения. В которой есть огромнейшая Справка. Эта справка содержит всю информацию которая раньше была в толстых книгах комплекта 1С. Там есть абсолютно все описание от параметров запуска до описания языка и всей объектной модели.
С 2024г. также есть бесплатная комьюнити лицензия, в которой меньше ограничений и можно поднять базу в режиме клиент-сервера.
Есть бесплатные учебные конфигурации типа "бухгалтерия", "зарплата".
Есть книги и статьи из раздела ИТС которые при большом желании можно локально выкачать за период бесплатного использования.
Да, но чтобы получить эту комьюнити лицензию вам нужно иметь сертификат 1С. А чтобы получить сертификат нужно изучить ее для подготовки к экзамену. Так что для начального ознакомления остается только версия для обучения.
Нет, для комьюнити лицензии не нужен сертификат. Нужно просто на портале зарегистрироваться.
На сайте https://developer.1c.ru нужно зарегистрироваться, получить комьюнити лицензию и откроется раздел для скачивания платформы и постгри для всех ОС. При первом заходе в конфигуратор он попросит залогиниться комьюнити учеткой и всё, можно разрабатывать.
По поводу курсов уже много написали, но можно на канал Учебный Центр 1С на Ютубе зайти и там на любой вкус курсы есть, сгруппированные по плейлистам.
Они скучные )) книжки, кстати, думаю в букинисте подошвке можно взять. У меня на одной из прошлых работ была их куча т к закупали коробочные версии для кучи филиалов и с каждой по две шли. Когда то мне помог mista.ru. Есть на инфостарте много полезного
Я правильно понимаю, что вся основная информация по языку и разработке у 1с закрытая?
~1000 рублей считается "закрытой информацией"?
Если нет, то коробка с учебной версией включает в себя два (если не ошибаюсь) учебника-самоучителя в твёрдой копии. На сайте 1С можно купить электрические версии по отдельности ещё дешевле.
На официальном its.1c.ru есть руководство разработчика, но это справочник, а не учебник.
На всяких видеохостингах полно разных видеоуроков/курсов.
Не знаю как сейчас, но в мои времена в 1С заходили в основном со стажерства во франчайзи, а там уж и реальные задачи, и книжки дадут, и на курсы отправят. Хоп и через полгодика ты уже понимаешь с чем связался и куда дальше развиваться.
Это продажа бизнесу. Но совершенно ни слова нет зачем разработчику. Потому что экспириенс для программиста у 1с ужасный. Хабр это все же ресурс не для бизнесменов, а для айтишников (ну, в основном). Ни единой причины не вижу разработчику изучать 1с. Разве что первую работу в айти получить, а затем свичнуться на что то комфортное и приятное спустя несколько лет, как я сделал.
Ну а куда ещë податься не особо хватающему звезд с неба выпускнику колледжа, чтобы войти в айти?
или в связи с засилием ИИ вокруг:-)
ищите небольшую компанию небольшим ай ти отделом Человек в 5. Там обычно нет жесткого разделения труда. Идите аникеем. Будите справляться и будет желание развиваться- сможете и задачи админа на серверах брать. И в 1С пользователя завести и права назначить разрешат. Админу самому это может быть интересно, если часть его задач сможете Вы выполнять и у него свободного времени на сидении на хабре больше будет, да и рутинные задачи заели его. Попробуйте разные ниши. К примеру BI. там уже определистесь.
Это как вариант. Хотя это и не модная ай ти компаний. Н
Какого экспириенса разработчику 1с по-вашему не хватает? Разработчик прежде всего выбирает предметную область и затем фреймворк для наиболее эффективного решения задач. Мне нравится предметная область - системы учета и 1С вполне справляется с ролью наиболее эффективного фреймворка.
В более менее крупном франче разработчик никогда не будет общаться с бизнесом, только с аналитиками (как франча, так и клиента) и разработчиками клиента, которые часто общаются с бизнесом. Что касается используемых технологий, то помимо 1С приходится использовать:
C++ для написания библиотек для работы с отсутствующей в 1С функциональностью, причем мультиплатформенный, как минимум для Windows и Linux, но иногда требуется включать и MacOS
Python - обработка текстов, парсинг сайтов, несложные сайты на Django и HTTP сервисы
bash - анализ файлов технологического журнала, скрипты devops
WinCMD - локальные скрипты автоматизации
T-SQL и PL/pgSQL - оптимизация запросов к СУБД
COM - манипуляция с документами Microsoft Office
Web/HTTP-сервисы, брокеры сообщений и мессенджеры, работа с XML и JSON
https://habr.com/ru/companies/trinion/articles/892272/#comment_28064164 - Вот тут можно почитать мой камент на эту тему.
https://habr.com/ru/articles/905440/comments/#comment_28250220 И еще вот тут ветка.
Отсутствие системы управления зависимостями
Можно организовать с помощью конфигураций поставщика. Можно скрипт сделать, чтобы она обновлялась автоматически, но обычно этого не делают. Не понятно какое к этому имеет отношение "обновление чужого кода"
Отсюда же идет отсутствие модульности
Открываете регистр сведений "Версии подсистем" и обнаруживаете что модули все-таки есть, как и их версии.
Отсутствие ООП / Отсутствие лямбд/замыканий
Отчасти соглашусь, причина почему до сих пор не сделали функцию объектом непонятна. Это могло бы более эффективно решить многие задачи
Динамическая типизация
Это вкусовщина. На мой взгляд ЯП со статический типизацией были сделаны во времена недостаточной производительности компьютеров и популярность Python это доказывает. А популярность Rust показывает, что C++ не решил всех недостатков C.
Печальная поддержка плагинов
Скорее печальная поддержка EDT. Первоклассной средой разработки он так и не стал. Количество ошибок и скорость их исправления вызывает недоумение.
Необходимо учитывать следующие моменты разработки платформы и типовых решений:
В платформу добавляется только то, что жизненно необходимо, т.к. реализовывать это приходится для нескольких ОС/СУБД/клиентов
Типовые решения содержат огромное количество функциональности, каждую часть которой разрабатывают разные команды разработчиков. При таком подходе создание сложных многоуровневых иерархий классов если и возможно, то будет скорее вредить. Так как на любом более крупном проекте внедрения эта функциональность обрастет дополнительными требованиями от клиентов. А требования конечного пользователя могут погубить самую лучшую архитектуру.
Ориентированность на язык запросов. Началось это с момента разработки ERP, а когда у вас большая часть функциональности связана с построением запросов иерархия классов тоже не пригодится
Можно организовать с помощью конфигураций поставщика. Можно скрипт сделать, чтобы она обновлялась автоматически, но обычно этого не делают. Не понятно какое к этому имеет отношение "обновление чужого кода"
В теории да, на практике не делают этого. Причин много, какие-то я возможно себе надумываю, какие-то реальные, но важно то что выходит на практике. Это есть во всех современных языках (pip, npm, gradle с его dependencies, cargo, etc), а в 1с отсутствует. Везде авторы свои библиотеки делают в готовом к такому распространению виде. В итоге для пользователя добавление/обновление библиотеки выглядит как поменять одну строчку в проекте (иногда несколько, если например с библиотекой еще и плагин для кодогенерации поставляется), но только не в 1с. В 1с либо сравнение/объединение, либо внешние обработки с примерами, которые еще скопипастить надо. Кстати, отсутствие кодогенерации автоматической еще один минус. Часть проблем 1с можно было бы подобным механизмом решить.
Открываете регистр сведений "Версии подсистем" и обнаруживаете что модули все-таки есть, как и их версии.
Не соглашусь, эта не та модульность которую я имею в виду. То о чем я говорю - это что-то в духе gradle модулей. Пространство имен в случае 1с общее, в случае модулей же - дерево зависимостей выстраивается отдельно, и модуль может быть подключен для использования в других модулях и попадать в их пространство имен, а может быть не подключен, и тогда не засоряет его. Плюс в 1с нет аналога package private. Потому внутренности модуля на все пространство имен торчат.
Это вкусовщина. На мой взгляд ЯП со статический типизацией были сделаны во времена недостаточной производительности компьютеров и популярность Python это доказывает. А популярность Rust показывает, что C++ не решил всех недостатков C.
При этом даже в python завезли type hinting. А в случае веба на крупных проектах переходят на typescript с js. По сути в python два режима сейчас, полностью динамическая типизация, которая подходит для скриптов и мелких проектов, и режим статической типизации, который подходит для крупных проектов. Система типов в первую очередь это снижение когнитивной нагрузки на программиста. Например, переименование поля или метода в языке с динамической типизацией штука не самая удобная, нужно руками искать все места вызова и менять автозаменой, и еще не напутать, ведь у двух разных классов (или в двух разных модулях) может быть метод с одинаковым именем, а переименовываем мы только для одного. Таким образом нужно смотреть откуда что приходит, убеждаться что только для правильного меняем и т.п. Плюс статическая типизация дает удобное автодополнение и служит автоматической документацией. Это все не критично если проект максимум несколько тысяч строк. Если же он за 10к строк переваливает - динамическая типизация превращается в кошмар.
Скорее печальная поддержка EDT. Первоклассной средой разработки он так и не стал. Количество ошибок и скорость их исправления вызывает недоумение.
Это в том числе, да. EDT это движение в правильную сторону, конечно, но недостаточное.
Отсутствие ООП / Отсутствие лямбд/замыканийОтчасти соглашусь, причина почему до сих пор не сделали функцию объектом непонятна. Это могло бы более эффективно решить многие задачи
Это пожалуй было одной из наибольших болей для меня. В упор не понимаю почему замыканий или просто хотя бы ссылок на функции не добавить. Язык не сильно усложнило бы, а возможностей дало бы много.
В теории да, на практике не делают этого. Причин много, какие-то я возможно себе надумываю, какие-то реальные, но важно то что выходит на практике
Поставщик конфигурации распространяет ее в виде файла поставки и вы не видите, сколько конфигураций поставщика используется при ее разработке. Так сделано в том числе для упрощения обновления. Но то что они используются это факт.
Конфигурация 1С строится не библиотеками, а слоями. То есть разработчики БП, УТ, ЗУП создали функциональность на базе БСП, затем на уровне ERP их интегрировали, затем разработчики ERP:УХ интегрировали УХ в ERP и затем у клиента развернули ERP:УХ + CRM. В результате клиенту достаточно обновлять 2 конфигурации вместо 5. При этом никто не запрещает добавить клиенту новую версию функциональности из новой версии конфигурации на любом из уровней. При очередном обновлении версия поставщика догонит или перегонит добавленную. Механизм обновления конфигураций поставщика вполне справляется с этой задачей.
Пространство имен в случае 1с общее
Если разработчик поставляет отдельный модуль для добавления в другие конфигурации он добавляет префикс
модуль может быть подключен для использования в других модулях и попадать в их пространство имен, а может быть не подключен, и тогда не засоряет его
Вы можете включить в конфигурацию не все объекты конфигурации поставщика, как собственно делают при внедрении БСП
Плюс в 1с нет аналога package private. Потому внутренности модуля на все пространство имен торчат.
В Python тоже нет, только условное. В 1С есть условное разделение на модули - Обычные, Служебные, Перепределяемые, Локальные. При этом в отличие от Python, есть настроящие private функции
При этом даже в python завезли type hinting. А в случае веба на крупных проектах переходят на typescript с js.
И по этому механизму Python до сих пор идут споры, пока договорились до того, что использовать их следует только в публично распространяемых библиотеках. В EDT тоже есть плагин для этого, есть даже директива для strict модуля. Насколько я знаю с TypeScript та же история
По сути в python два режима сейчас, полностью динамическая типизация, которая подходит для скриптов и мелких проектов, и режим статической типизации, который подходит для крупных проектов
Впервые слышу об этом. Вижу кучу популярных публичных библиотек без всяких типов и возбуждаются от отсутствия типов только адепты языков со статической типизацией
Это пожалуй было одной из наибольших болей для меня. В упор не понимаю почему замыканий или просто хотя бы ссылок на функции не добавить
На данным момент разработчики платформы считают, что механизма передачи полного имени функции и последующего Выполнить достаточно для решения текущих потребностей. Было несколько сообщений на партнерском форуме по этому поводу, но ни одно из них не набрало такого количества лайков, чтобы разработчики платформы обратили на это внимание. Они вообще считают, что в платформе все есть для того чтобы разрабатывать бизнес-приложения любой сложности и в основном занимаются добавлением функциональности, а не развитием языка. Сейчас хоть планы свои публикуют на https://wonderland.v8.1c.ru, гораздо понятней стало в каком направлении развивается платформа
Нельзя рассматривать платформу 1С:Предприятие только как язык, это все-таки огромный фреймворк, поэтому сравивать его нужно не с условным Python, Java или Javascript, а с Axapta, Odoo, iDempiere. И я могу сказать, что по многим возможностям этим системах до 1С очень далеко, хотя там есть и ООП, и пакеты, и модули.
Поставщик конфигурации распространяет ее в виде файла поставки и вы не видите, сколько конфигураций поставщика используется при ее разработке. Так сделано в том числе для упрощения обновления. Но то что они используются это факт.Конфигурация 1С строится не библиотеками, а слоями. То есть разработчики БП, УТ, ЗУП создали функциональность на базе БСП, затем на уровне ERP их интегрировали, затем разработчики ERP:УХ интегрировали УХ в ERP и затем у клиента развернули ERP:УХ + CRM. В результате клиенту достаточно обновлять 2 конфигурации вместо 5. При этом никто не запрещает добавить клиенту новую версию функциональности из новой версии конфигурации на любом из уровней. При очередном обновлении версия поставщика догонит или перегонит добавленную. Механизм обновления конфигураций поставщика вполне справляется с этой задачей.
Ну и где десятки тысяч библиотек со всякими служебными функциями для 1с вроде аналогов gson, кастомных логгеров, какой нибудь кастомной работы с датами и временем, парсингом html/xml нестандартным? Может есть такие вот библиотечки для работы с нестандартными структурами данных и алгоритмами? Которые вот так же как в gradle, добавлялись бы просто одной строчкой конфигурации в программу? Нету их.
Если разработчик поставляет отдельный модуль для добавления в другие конфигурации он добавляет префикс
Ну т.е. вопрос решается костылями (которые еще и не работают, поскольку все равно замусоривают поиск и автодополнение).
Вы можете включить в конфигурацию не все объекты конфигурации поставщика, как собственно делают при внедрении БСП
Так оно нужно. Но оно не должно торчать в тот код который этим будет пользоваться. А предоставляться только через абстракции. Пример см. в моем комментарии тут https://habr.com/ru/articles/897564/#comment_28134226
В Python тоже нет, только условное. В 1С есть условное разделение на модули - Обычные, Служебные, Перепределяемые, Локальные. При этом в отличие от Python, есть настроящие private функции
Одна из причин почему python тоже так себе, да. Там это через костыли надо делать, типа создания библиотек (хотя и gradle модули это по сути те же библиотеки, просто в один проект объединенные).
И по этому механизму Python до сих пор идут споры, пока договорились до того, что использовать их следует только в публично распространяемых библиотеках. В EDT тоже есть плагин для этого, есть даже директива для strict модуля. Насколько я знаю с TypeScript та же история
Насчет python тут точно не скажу как там в коммьюнити к этому относятся, на мой взгляд это язык либо для датасатанистов, у них вариантов тупо нет других толком, либо для того чтобы наколеночные поделия клепать, если писать без типов. Но вот с typescript вы точно ошибаетесь, там без типов никто не пишет насколько мне известно (потому что по сути это тот же js, но с типами, смысла нет typescript использовать если не используешь типы).
На данным момент разработчики платформы считают, что механизма передачи полного имени функции и последующего Выполнить достаточно для решения текущих потребностей. Было несколько сообщений на партнерском форуме по этому поводу, но ни одно из них не набрало такого количества лайков, чтобы разработчики платформы обратили на это внимание. Они вообще считают, что в платформе все есть для того чтобы разрабатывать бизнес-приложения любой сложности и в основном занимаются добавлением функциональности, а не развитием языка. Сейчас хоть планы свои публикуют на https://wonderland.v8.1c.ru, гораздо понятней стало в каком направлении развивается платформа
Нельзя рассматривать платформу 1С:Предприятие только как язык, это все-таки огромный фреймворк, поэтому сравивать его нужно не с условным Python, Java или Javascript, а с Axapta, Odoo, iDempiere. И я могу сказать, что по многим возможностям этим системах до 1С очень далеко, хотя там есть и ООП, и пакеты, и модули.
А мне как программисту какое дело до того достаточно ли всего чтобы бизнес-приложения разрабатывать или не достаточно? В теории и на брейнфаке можно код писать. Мне как программисту важно чтобы на языке было писать просто и приятно. Если от этого еще и бизнес получает плюшки (вроде снижения количества ошибок от статической типизации) то вообще отлично, win-win. А если мне нужно страдать от неудобства работы с языком - значит язык уг.
Ну и где десятки тысяч библиотек со всякими служебными функциями для 1с вроде аналогов gson, кастомных логгеров, какой нибудь кастомной работы с датами и временем, парсингом html/xml нестандартным?
При таком объеме кодовой базы как в 1С:ERP (даже без УХ или CRM) идет унификация всего и вся. Для этих целей в свое время была создана БСП. Если производительности встроенного языка недостаточно, при достаточном количестве обратной связи это появится в платформе. И всегда есть возможность реализовать ваши хотелки с помощью внешних компонент или вызовом внешних программ.
Так оно нужно. Но оно не должно торчать в тот код который этим будет пользоваться. А предоставляться только через абстракции
Я уже писал ранее, что на проекте внедрения все ваши идеально построенные абстракции могут накрыться медным тазом из-за специфических требований клиента. Система изначально создана для внесения изменений в любую часть функциональности и лишние уровни абстракции тут только вредят. Хотя, например, я бы полностью поддержал появление в платформе интерфейсов для модулей.
Насчет python тут точно не скажу как там в коммьюнити к этому относятся, на мой взгляд это язык либо для датасатанистов, у них вариантов тупо нет других толком, либо для того чтобы наколеночные поделия клепать, если писать без типов
То есть по вашему мнению такие продукты как Odoo или Django (в которых нет type hinting) это "наколеночные поделия"? Не нужно забывать, что есть языки вообще без типов, что не мешает писать на них огромные проекты.
Но вот с typescript вы точно ошибаетесь, там без типов никто не пишет насколько мне известно
Под typescript я разумеется подразумевал javascript с типами и популярным он стал во многом из-за популярности node.js, в том числе из-за того что сам javascript весьма специфичный язык. Но что-то не припомню, чтобы кто-то из знакомых frontend-разработчиков его использовал.
В теории и на брейнфаке можно код писать. Мне как программисту важно чтобы на языке было писать просто и приятно. ... А если мне нужно страдать от неудобства работы с языком - значит язык уг.
Не нужно абсолютизировать. Для каждой каждой предметной области используется свой инструментарий. Вы написали, что не считаете платформу 1С:Предприятие достойной внимания разработчиков, но при этом так и не написали, с помощью какого инструментария в вашем понимании должны быть написаны учетные системы.
В то же время многие разработчики, которым нравится эта предметная область и которые работали с множеством из них в последнюю очередь обращают внимание на современность языка.
При таком объеме кодовой базы как в 1С:ERP (даже без УХ или CRM) идет унификация всего и вся. Для этих целей в свое время была создана БСП. Если производительности встроенного языка недостаточно, при достаточном количестве обратной связи это появится в платформе. И всегда есть возможность реализовать ваши хотелки с помощью внешних компонент или вызовом внешних программ.
И вот опять, какие то костыли вместо нормальных решений. Вы мне сейчас пытаетесь доказать что то что я при работе с 1с ненавидел и от чего ощущал дискомфорт - это плюсы, а не минусы. Если это такие вот плюсы, чего же во всех современных языках перешли на нормальное управление зависимостями вместо прямого включения и прочих вариантов?
То есть по вашему мнению такие продукты как Odoo или Django (в которых нет type hinting) это "наколеночные поделия"? Не нужно забывать, что есть языки вообще без типов, что не мешает писать на них огромные проекты.
На 1с тоже пишут, но страдают. Есть у меня опыт участия в разработке коробочных решений, писать и поддерживать сотни тысяч строк кода коробки 1сной это боль без типов.
Под typescript я разумеется подразумевал javascript с типами и популярным он стал во многом из-за популярности node.js, в том числе из-за того что сам javascript весьма специфичный язык. Что-то не припомню, чтобы кто-то из знакомых frontend-разработчиков его использовал.
Не знаю что вы там подразумевали. typescript это вполне себе отдельный язык от microsoft которой в js транспилируется.
Не нужно абсолютизировать. Для каждой каждой предметной области используется свой инструментарий. Вы написали, что не считаете платформу 1С:Предприятие достойной внимания разработчиков, но при этом так и не написали, с помощью какого инструментария в вашем понимании должны быть написаны учетные системы.В то же время многие разработчики, которым нравится эта предметная область и которые работали с множеством из них в последнюю очередь обращают внимание на современность языка.
Вы не путайте платформу и язык. Платформа и фреймворк в целом неплохи, пусть и не без недостатков. УГ именно язык на котором нужно для них писать.
Вы мне сейчас пытаетесь доказать что то что я при работе с 1с ненавидел и от чего ощущал дискомфорт - это плюсы, а не минусы
Повторюсь, дискомфорт у вас скорее был от предметной области, иначе бы вы ее не поменяли
Если это такие вот плюсы, чего же во всех современных языках перешли на нормальное управление зависимостями вместо прямого включения и прочих вариантов?
Я не говорил что это плюс, это особенность и чтобы понять хорошо это или плохо нужна для сравнения другая система с сопоставимой по размеру кодовой базой и построенная на других архитектурных принципах. Но такой нет, есть либо явно недотягивающие по функциональности, типа Odoo или iDempiere, либо явно недотягивающие по удобству SAP, OEBS. Отдельным особняком всегда стояла Axapta, но там уже много лет такой застой, что она ко второй группе присоединилась
На 1с тоже пишут, но страдают. Есть у меня опыт участия в разработке коробочных решений, писать и поддерживать сотни тысяч строк кода коробки 1сной это боль без типов.
Не смотря на то, что для ряда проектов (в том числе коробочного решения) использую EDT никогда не обращал внимание на типы. И судя по количеству упоминаний об этом в telegram-канале по EDT это точно не является причиной, по которой люди ее используют
Не знаю что вы там подразумевали. typescript это вполне себе отдельный язык от microsoft которой в js транспилируется.
В js много чего транслируется, в том числе 1С. Но я никогда не воспринимал TypeScript как отдельный язык, скорее как надстройна над JavaScript. Но не буду утверждать, т.к. ни строчки кода на нем никогда не написал.
УГ именно язык на котором нужно для них писать.
Нельзя встроенный язык 1С рассматривать отдельно от платформы 1С:Предприятие. Более того, нельзя отдельно рассматривать платформу 1С:Предприятие от типовой конфигурации 1C. По-отдельности они никому не интересны. Кроме того, 1С генерирует байт-код обычной стековой машины, что теоретически позволяет скомпилировать в него код "более современного" языка программирования. Но я о таких попытках не слышал, возможно из-за того что никому это особо не интересно.
Повторюсь, дискомфорт у вас скорее был от предметной области, иначе бы вы ее не поменяли
А какая разница какая предметная область? Мне неважно для какой предметной области писать код. Важно чтобы это было делать комфортно и приятно.
И судя по количеству упоминаний об этом в telegram-канале по EDT это точно не является причиной, по которой люди ее используют
Так там типов и нет толком. Я вот как раз немало людей встречал кто, как и я, ушел из-за языка.
Нельзя встроенный язык 1С рассматривать отдельно от платформы 1С:Предприятие.
Можно и нужно. Ведь в работе с кодом на этом языке и заключается основная часть работы.
Более того, нельзя отдельно рассматривать платформу 1С:Предприятие от типовой конфигурации 1C.
А это вообще странное заявление. Может для тех кто только внедрением типовых занимается и их доработкой оно и оправдано, но я большую часть времени когда был в сфере 1с как раз разработкой типовой конфы и занимался, пусть не от самой 1с, но от франча (1с тоир).
Можно и нужно. Ведь в работе с кодом на этом языке и заключается основная часть работы.
Вы не сможете использовать платформу 1С:Предприятие без ее встроенного языка, каким бы ужасным он вам не казался. Но вы ругаете платформу без предложения разумной альтернативы для данной предметной области, из которой в итоге вообще ушли. Достаточно странно при таких вводных давать советы о том какие технологии для этой предметной области необходимо использовать.
Так там типов и нет толком. Я вот как раз немало людей встречал кто, как и я, ушел из-за языка.
И куда ушли в итоге? Когда я начинал работать с платформой 1С:Предприятие 7.7 в ней не было вообще ничего, ни функциональности платформы, ни функциональности типовых решений. Было огромное количество неофициальных библиотек, которые позволяли заставить все это как-то работать. Рядом была Axapta 3.0, которая была лишена большинства из этих недостатков и многие переходили на нее. Но потом вышла платформа 1С:Предприятие 8 и после выхода 1С:УПП поток желающих перейти резко остановился, а после выходя 1С:ERP пошел обратный процесс.
А это вообще странное заявление. Может для тех кто только внедрением типовых занимается и их доработкой оно и оправдано
Это оправдано прежде всего с точки зрения клиента. Ему вообще без разницы какой там язык и какая платформа. Ему нужно получить определенную функциональность за определенную стоимость с определенной стоимостью владения.
Вы не сможете использовать платформу 1С:Предприятие без ее встроенного языка, каким бы ужасным он вам не казался.
Именно поэтому мой выбор не использовать платформу 1с, да. Поскольку язык первичен, в работе именно с языком проходит большая часть времени.
Но вы ругаете платформу
Платформу я ругаю разве что за отсутствие нормальной системы управления зависимостями. Что мелочь на фоне того за что я ругаю язык 1с.
И куда ушли в итоге?
Сейчас под мобилки пишу (в основном android, но и ios немного). Возможно позже переключиться попробую на бекэнд или десктоп. А именно предметная область, повторюсь, мне все равно какая будет. Хоть что-то учетно-экономическое, хоть b2c решения, хоть чисто пользовательские приложения.
Это оправдано прежде всего с точки зрения клиента.
А какое мне дело как разработчику до клиента? Работа должна в первую очередь удовольствие мне доставлять. Одно дело если бы в сфере программирования в принципе бы не было вариантов на каком языке писать, пришлось бы давиться языком 1с. Но ведь это не так. Крепостное право отменили, можно выбирать работу по своему вкусу, а не по вкусу работодателя.
Язык не сильно усложнило бы, а возможностей дало бы много.
Можете привести пример кода, который можно реализовать только и исключительно лямбдами/замыканиями и принципиально невозможно реализовать просто функциями/процедурами?
Кстати, по поводу полного переписывания кода в расширениях в 1С уже достаточно давненько добавили синтаксис ИзменениеИКонтроль, когда платформа определяет, что изменённый Вами участок кода изменился в основной конфигурации.
принципиально невозможно реализовать просто функциями/процедурами
Можно и вовсе писать на ассемблере. Он позволяет реализовать все то что позволяют и высокоуровневые языки. Но ведь люди перешли на языки высокого уровня зачем-то, правда? Языки это про абстракции, комфорт и удобство, ну и про сокращение объемов кода/гарантии линтеров/компилятора, а не про принципиальную возможность или невозможность что-то реализовать.
Проблема в том что язык 1с в выразительности и комфорте даже низкоуровневому rust бы проигрывал если бы не ограничения borrow checker. Ну а тому же swift/kotlin/typescript и без всяких "если бы" язык 1с проигрывает. Они более высокоуровневые чем 1с (не в плане что дальше/ближе к железу, а в том плане что позволяют более надежные системы писать проще и выразительнее). Так что сделать удобный ЯП в 1с не осилили (а вот фреймворк достаточно удобный у них вышел, если бы с другим ЯП можно было бы использовать).
Но ведь люди перешли на языки высокого уровня зачем-то, правда?
Как раз-таки для реализации функционала, которого нет в ассемблере, в частности, строгой типизации и переносимости между машинами одной архитектуры.
Языки это про абстракции
Языки это про инструменты, позволяющие выполнять заданную функцию, всё остальное вообще вторично.
комфорт и удобство
Так лямбды и замыкания - это вообще одни из самых некомфортных и неудобных вещей, которые только сумели выдумать. Без них переменная либо локальна, либо глобальна (ещё в классе, если язык с ООП), а с замыканием - удачи в поисках, захватить её могло откуда угодно.
гарантии линтеров/компилятора
На всякий случай напомню, что в ИТ буквально на всём налеплено: "AS IS, ABSOLUTELY NO WARRANTY".
линтеров
Но ведь 1С создавали в то время, когда никаких линтеров и прочих гироскутеров не было.
позволяют более надежные системы писать проще и выразительнее
На счёт "надёжные" я прям сильно сомневаюсь, 1С. Чтобы уронить 1С кодом на 1С - это надо прям очень сильно постараться, кривой код на 1С обычно приведёт к тому, что в окно сообщений выплюнет какую-нибудь ошибку и закроет текущую форму. Причём, сработает это даже в том случае, если программист полнейший новичок и об обработке ошибок даже не задумывался. В Kotlin не отловил исключение - программа крашнется.
Как раз-таки для реализации функционала, которого нет в ассемблере, в частности, строгой типизации и переносимости между машинами одной архитектуры.
Ну в том же C типизация не то чтобы строгая (хоть и статическая). Ну так писали бы на алголе/коболе/C, в чем проблема?
Языки это про инструменты, позволяющие выполнять заданную функцию, всё остальное вообще вторично.
Повторюсь, тогда бы новых языков не появлялось, если бы это было так. Языки это всегда трейдофы между производительностью, скоростью прототипирования, скоростью разработки крупных проектов, простотой модификации и рефакторинга, простотой поддержки и расширения, а так же комфортом и удобством разработчика.
Так лямбды и замыкания - это вообще одни из самых некомфортных и неудобных вещей, которые только сумели выдумать. Без них переменная либо локальна, либо глобальна (ещё в классе, если язык с ООП), а с замыканием - удачи в поисках, захватить её могло откуда угодно.
Глобальные сразу в топку. Ну а насчет "откуда угодно" - замыкание захватывает из доступных областей видимости. Т.е. максимум границы текущего класса. Но чаще всего и вовсе границы текущей функции. А тому методу которому передается замыкание внутри себя о захваченных переменных/значениях знать и не надо.
Тейка насчет неудобства же не понял совсем. Вот только 5 минут назад воспользовался лямбдой, передал в функцию filter. Что тут неудобного? Не нужно зато временные переменные для складирования результата городить и дополнительный if писать. Минус несколько строк служебного ненужного для логики кода который бы только перекладывал значения.
Но ведь 1С создавали в то время, когда никаких линтеров и прочих гироскутеров не было.
Язык для восьмерки выбирали явно когда они уже были (впрочем думаю и во времена семерки вполне себе существовали).
На счёт "надёжные" я прям сильно сомневаюсь, 1С. Чтобы уронить 1С кодом на 1С - это надо прям очень сильно постараться, кривой код на 1С обычно приведёт к тому, что в окно сообщений выплюнет какую-нибудь ошибку и закроет текущую форму. Причём, сработает это даже в том случае, если программист полнейший новичок и об обработке ошибок даже не задумывался. В Kotlin не отловил исключение - программа крашнется.
Надежные в плане бизнес логики, что свежие правки старую бизнес логику не сломают. Благодаря удобным абстракциям куда меньше копипасты в коде, например. Плюс куда проще в существующую логику вставлять точки расширения/изменения поведения, например на другие типы объектов. А не в том плане что приложение будет или нет падать.
По поводу отлова исключений в том же котлине - никто не мешает в общем то повесить глобальный обработчик исключения в том же main условном (или в функциях служащих входными точками для api/gui). На беке в общем то так и делают как правило.
Ну так писали бы на алголе/коболе/C, в чем проблема?
Видимо в том, что необходимый функционал не реализуем. В том же С++ по умолчанию предлагается рулить памятью в парадигме объектов, а не куска байтов, как в С.
Повторюсь, тогда бы новых языков не появлялось, если бы это было так.
Конечно же нет, т.к. фантазия человека безгранична и языки возникают не только как инструмент. Как пример - Malbolge какой-нибудь, just for lulz.
а так же комфортом и удобством разработчика
Это явно на каком-то молодёжном. Достаточно открыть хотя бы Perl, чтобы понять, что комфорт никого не интересовал.
Глобальные сразу в топку.
С чего вдруг?
Т.е. максимум границы текущего класса. Но чаще всего и вовсе границы текущей функции.
Да чего проще: замыкание на замыкание поверх замыкания.
А тому методу которому передается замыкание внутри себя о захваченных переменных/значениях знать и не надо.
Ровно до того момента, когда всё это упадёт из-за того, что в захваченной переменной лежит не то, что ожидалось, например как в недавнем обсуждении странностей JS: https://habr.com/ru/articles/904868/
Минус несколько строк служебного ненужного для логики кода который бы только перекладывал значения.
"Вы так говорите, как будто это что-то плохое"(с)
Так мы и доходим до какого-нибудь convention over configuration, когда код передачи значений не пишется вообще и всё работает на очередной "магии".
Язык для восьмерки выбирали явно когда они уже были (впрочем думаю и во времена семерки вполне себе существовали).
Формально - да, первые линтеры ещё в прошлом веке создали. Однако то, что подразумевается сегодня - автоматический лупцеватель программиста - получило распространение к концу нулевых в лучшем случае, а 1С 8 в начале нулевых уже в релиз вышла.
Благодаря удобным абстракциям куда меньше копипасты в коде, например.
В 7.7 копипасты было вообще минимум. При том, что 7.7 это, по большому счёту, вообще структурное программирование, даже не ООП. Может количество копипасты зависит прежде всего не от наличия удобных абстракций?
Надежные в плане бизнес логики, что свежие правки старую бизнес логику не сломают.
Так 1С именно такова, написал начинающий программист какую-нибудь кривую обработку - она просто упадёт, не изменив ни логики других блоков, ни испортив данных при падении.
в общем то повесить глобальный обработчик исключения в том же main условном
В котором программисту придётся обрабатывать все возможные исключения. И в котором новичок ошибётся и исключение перебросит выше, что, опять же, крашнет программу.
Достаточно открыть хотя бы Perl, чтобы понять, что комфорт никого не интересовал.
Ну я и не понимаю тех кто пишет на perl или 1с. А комфорт интересует многих. На комфортные языки проще найти людей. Люди в работе с комфортными языками меньше стрессуют, быстрее в квалификации растут (в свободное время например тоже пишут, так как язык удовольствие доставляет).
Да чего проще: замыкание на замыкание поверх замыкания.
И так просто. Весь код в одном месте.
Ровно до того момента, когда всё это упадёт из-за того, что в захваченной переменной лежит не то, что ожидалось, например как в недавнем обсуждении странностей JS
Конкретно JS как раз пример плохого дизайна языков. Один из моих не любимых, наряду с 1с. С ним та же проблема, что и с 1с, тупо нет альтернативы для среды выполнения + тащит наследие из всякого Г из девяностых. Хотя и тут последние годы либо TS выбирают часто, либо какие-то вещи в wasm компилируют. Так что люди ССЗБ, которые на js пишут. Все современные языки того бреда, что в статье по ссылке описан не позволяют.
В 7.7 копипасты было вообще минимум. При том, что 7.7 это, по большому счёту, вообще структурное программирование, даже не ООП. Может количество копипасты зависит прежде всего не от наличия удобных абстракций?
Семерку не застал, так что не знаю что такого магического там было что позволяло обойтись без копипасты. Имея 4.5 года опыта на восьмерке и 6 на котлине - прекрасно вижу как возможность строить свои удобные абстракции кардинально упрощает работу и снижает количество кода.
Так 1С именно такова, написал начинающий программист какую-нибудь кривую обработку - она просто упадёт, не изменив ни логики других блоков, ни испортив данных при падении.
Вернемся к примеру из другого моего комментария. Есть кусок бизнес логики какой-то большой описанный как несколько десятков вызовов функциями друг друга. И вот на каком нибудь 5 уровне вложенности в Функция1, на 6 уровне вложенности в Функция2 и на 2 уровне вложенности Функция3 для нового добавленного в систему справочника/документа нам нужно изменить поведение этой бизнес логики (и только для этого документа). Например, валидация данных отличается, поскольку и поля другие, и правила. Или правила зависят от сочетания конкретного документа и роли пользователя. Или же вовсе, правила валидации зависят от места откуда изначальная функция вызывается, например из самого документа для "сухого прогона" и для полноценного. А из третьего места (из обработки какой-нибудь) эти правила вообще кардинально другие. Как сейчас можно реализовать подобное изменение в 1с? Либо снимать с поддержки нужные общие модули и вносить правки в виде Если ТипДокументаТакойТо Тогда... Либо через расширения работать, но тогда придется в расширение скопипастить всю оригинальную функцию (поскольку модернизировать только ее часть нужно, а не всю). Либо во все документы правки нужные вносить, если функция для объекта документа определена. И неопытный программист запросто может например для одного места правку сделать, для двух других забыть. Или же на еще одном новом документе забыть где-то поправить. И в итоге получится что для нового документа отработает та же логика что для старых документов (и даже не упадет вполне возможно, но приведет к неверным данным на выходе).
А в случае с функциями как объектами первого класса - оригинальные функции трогать вообще не надо. И не получится ничего забыть, поскольку вызываемая функция требует ей эти самые функции явно передать через аргументы.
В котором программисту придётся обрабатывать все возможные исключения. И в котором новичок ошибётся и исключение перебросит выше, что, опять же, крашнет программу.
Вообще нет. Если прям не хочется сервис ронять - не нужно все типы исключений указывать. Достаточно Throwable. Одна строчка кода (ну еще исключения бизнес логики какие нибудь). Впрочем, я вообще противник исключений. Предпочитаю Result/Either, и никаких исключений не нужно. Разве что они должны программу именно уронить (вошла в такое состояние из которого не выйти), тогда панику кидать. Подход rust мне нравится в этом плане гораздо лучше. Go туда же в принципе, но он слишком унылый для меня, переупрощенный. В котлине в теории можно было бы без исключений писать, но они из java кода тянутся(((
я думаю идеальный эксприенс это на кубинском пляже рядом с красоткой и попивая коктель. А на работе, я лично, работаю. И там критерий- помочь компании достичь бизнес целей. А не получить удовольствие от процесса. Удовольствие- это на заработанные деньги на пляже ))
Вычитай, что написал: море ошибок, читать невозможно.
Полностью соглашусь с автором статьи, просто кому то нужны шашечки, а кому то ехать…
PS
Если кто то может сделать лучше - почему до сих пор не сделали? Монополии тут нет: любая программа ведения учета или формирования отчетов, а так же накладных или инвентаризации, движения товара по складу и прочие бизнес процессы - может выйти на рынок с данным функционалом и занять свою нишу, НО почему то вот уже сколько воды утекло, а воз и ныне там! Все только ругают за корявость продукта (как буд то есть программы, которые не имеют ошибок)))), но при этом ничего нового так и не создали, ни за бугром ни локально! А по итогу эти ВСЕ - это люди далекие не только от IT, но и от бизнеса (кстати обычно это или бухгалтер любящий гонять чаи, а не работать или чувак, который умеет на «си» или «питоне» и считает почему то, что и «эксель» должен «программироваться», а еще всякие pm, которые больше втиратели очков, чем дела ну и бездельники на местах, хотя про буха гоняющего чаи с подругами я уже упомянул)
Где в этой "открытой" штуке взять метрики человеческие? Чтобы понять, что тормозит, СХД, база, платформа или конфигурация. Ибо разработчики обычно кроме технологического журнала ничего предложить не могут. А он тормозящую систему добьёт. И всё время жалуются на сеть, СХД и базы :)
Мониторинг сети и схд - это мониторинг железа, причём тут разработчики? Так же как и в любом другом стеке - забикс/прометеус
1с сервер отдаёт счётчики производительности, в последних версиях даже в json. Для метрик конфигурации существует подсистема оценки производительности, где можно развесить ключевые операции по коду.
Спасибо! А это фича для какой-то продвинутой лицензии? И может быть, Вы знаете, где можно без регистраций и ИТС про это почитать?
Счётчики производительности прямо с кластера - это фича КОРП, да.
https://v8.1c.ru/platforma/upravlenie-potrebleniem-resursov/
https://wonderland.v8.1c.ru/blog/mekhanizm-upravleniya-potrebleniem-resursov/
Ну и на итс с обычной девелоперской учеткой, раздел 5.2.15 https://its.1c.ru/db/v8327doc/bookmark/cs/TI000000183
Появление тезиса про отсутствие git и CI/CD в экосистеме 1С это уже само по себе проявление беспричинного хейта и демонстрация уровня полной неосведомлённости автора оного об этой самой экосистеме.
И то и другое есть. И тесты, и наборы готовых пайплайнов, и замеры покрытия, и инструменты сборки. И в Windows, и в Linux, и в Docker. Часть инструментария реализована вендором, часть сообществом.
Приходиться работать в 1С:PDM, 1С:Документнаоборот и 1С:УПП. У меня нет нормальных слов, чтобы описать испытываемые ощущения от взаимодействия с этими программными недоразумениями, особенно с этим как бы пдм и ублюдочным документнаоборот. От работы с ними получаешь ощущение, что их делали исключительно для того, чтобы кратно увеличить количество выполняемой работы.
Соглашусь по поводу 1С:PDM, то что это решение получило сертификат 1С:Совместимо является дискредитацией самой системы сертификации. Но тут дело наверное в том, что отсутствуют аналоги, а они отсутствуют в том числе потому, что все толковые специалисты заняты на проектах внедрения, выхлоп от которых гораздо больше. А тут нужно заморозить огромное количество денег с непонятной перспективой окупить вложения.
1С:УПП хороший продукт для своего времени, единственным недостатком которого являются обычные формы
Искренне не понимаю, какие могут быть претензии к 1С:Документооборот, т.к. продукт изначально разрабатывался на управляемых формах
К документообороту основная претензия к интерфейсу, такое ощущение что его делали альтернативно-одарённые инопланетяне из перпендикулярной вселенной. Написать и сопроводить в этом к примеру служебную записку - достаточно нетривиальная задача для пользователя, привыкшего и интерфейсам построенным на принципе от общего к частному. Хотя может это особенность нашей частной конфигурации, но других я не видел.
Задачи, падающие мне в документообороте - жуткая каша из кучи наслоений от разных подразделений. Связь с внешним миром отсутствует, приходится все задачи каждый месяц перебивать в отдельный файл отчёта о выполненной работе, при этом ещё отдельно держать файл с планом работ, потому как далеко не все задачи ставятся через документооборот. В общем проблем хватает.
И есть общая претензия ко всему сразу - весь этот зоопарк живёт отдельно, каждое само в себе, из взаимосвязей только общая учётная запись.
И, как обычно, плач Ярославны без конкретики. С высокой вероятностью проблема в "прокладке между рулем и сиденьем" (я и про ответственного за эксплуатацию систем в том числе)
Ну да ну да, конечно. 1С:PDM это не пдм, это абсолютно ручная база данных, которая ничего не умеет и стоит в позиции к начальству передом к инженеру задом. И вот через вот этот вот зад мы и удаляем гланды.
Интеграция с CAD системой нулевая, даже одни и те же атрибуты одного документа приходится заполнять руками несколько раз в разных местах. Прочитать что-то из файла чертежа или записать в него - ни в коем случае. У тебя имеется вылизанная 3д сборка изделия со всей структурой - набивай структуру ручками заново и заполняй её файлами моделей/чертежей. Не забудь забить все атрибуты по десятому разу и не допустить при этом ещё ошибок. Провести извещение - адовый квест по ловле блох (не дай боже извещение будет сложнее 5-10 документов) во всем этом болоте. Все изменения - ручками, ручками, никакой автоматизации. Этот список можно продолжать бесконечно.
Автоматически формируемые документы отчётов из руками набитых составов (спецификации и т.п.), которые после формирования приходиться править руками и загружать обратно в эту систему - отдельная вишенка на тортике.
Поддержу. Чтобы разрабатывать под это говнище нужно заниматься ТОЛЬКО экосистемой 1С, потому что там всё сделано криво-косо и работает соответствующе.
Как там, нормальную интеграцию с их же собственным Битриксом они уже вывезли сделать? Насколько я знаю, только костыльную и частичную.
Если 1С - это ERP, то каким образом она решает основную задачу ERP - непрерывную балансировку и оптимизацию ресурсов предприятия?
Какой солвер используется для непрерывной оптимизации? Gurobi? Или самописный SIMPLEX метод?
Ну вы так то не гоните. Каким способом мотолок решает задачу постройки моста? 1С ERP это система учета в которой так же есть система планирования. Со своей механикой. Если вы говорите об оперативном контуре планирования это RPS или MES системы, если о стратегии - в бизнесе все сильно проще - драйверная модель. Не нужно рассказывать что хоть одна из существующих ERP умеют в simplex без шаманизма и с ясными результатами. По факту покажите где это используется в мировой практике в хотя бы среднем бизнесе. Стартапы и так понятно - они пока на не заработали на финансиста, который pl и cf не путают.
Я говорю о ERP по определению. Не об MRP или MRP II, а именно о ERP. Вы хоть в курсе, что это расшифровывается как Enterprise Resource Planning?
SAP в качестве солвера для оптимизации использует Gurobi, OEBS еще несколько лет назад - IBM CPLEX. Возможно, тоже ушли на Gurobi.
В SAP им кто-то пользуется кроме транскорпораций со штатом математиков которые могут корректно настроить этот солвер? И это при статичной финансовой модели. Давайте честно ERP не обязан иметь солвер как таковой. Если вам им удобно пользоваться я рад за вас, но бизнес обычно решает совершенно другие учетные задачи в быту. И поверьте, когда бизнес дойдет до потребности "солвера" в 1С:ERP то совершенно без проблем он прикручивается снаружи. Только вот в реальности порванные цепочки документов поставки, нестабильность финансовых моделей и особенности "учетной политики" доставляют больше проблем и требуют больше решений. Вы как и гики из разработки носитесь с солвером, как они с гитхабом и кубернатисом. Сходите в ретеил или производство крупное с взаимозаменяемостью а потом расскажите там про солвер. Я посмотрю как вас будут ссаной тряпкой гонять по складу или торговому залу.
У нас одна из самых крупных опербаз 1С в РФ. 10 тб. И что яхочу сказать - автор вообще прав во всем. Истина проста и неказиста - разработка на языке для бизнеса на посути смеси ооп, скрипта и бсл это нормально. Вы же не учите английский по Шекспиру для того чтобы спросить сколько стоит чашка кофе? И даже в 1С есть свой стек сеньоров и экспертов которые могут и умеют в производительность языка запросов (а в крупных или сложных 1С решениях это 80% разработки). Но тут даже дело не в этом. Сча в меня полетят камни. 1Сник это не ит гик в классическом прохабровском исполнении. Это в первую очередь человек который на листочке может написать схему данных для партионного и серийного учета товаров на складе даже не задумываясь ни на минуту. Для айти специалиста это очерзадача, в которой нужно тз, архитектор, датаархитектор, продакт, бизнес-аналитик, системный аналитик и бригада пояснения.
Как вы оцениваете стоимость владения такой базой 1С? Оно точно того стоит?
P. S. Работал с базой 25 ТБ.
Поднять свой продукт с товарным оперучетом будет на порядки дороже как инвестиционно, так и операционной так и рисково
Обычно рассказы про многотерабайтные базы сводятся к тому, что весь объем и соответствующие проблемы дают 1-3 таблицы, с которыми команда эксплуатации и носится как с писаной торбой, безуспешно мечтая хоть что-то с этим сделать.
25Тб - ДНС?
Всегда вызвало улыбку, кто гордится объемом базы. 98% это мусор в виде прикрепленных файлов и не нужной информации которой никто не пользуется, либо очень редко ей пользуется. Некоторые вообще увязывают больший объём данных с highload. Так же как куча пользователей большая часть которых вообще не влияет на нагрузку на сервер.
Практический вопрос про вашу супербазу. Без открытия служебных секретов можете сказать много ли одновременно работающих пользователей, какие клиенты используются по преимуществу (web или тонкий), практикуете ли оптимизацию трафика через прослойку серверов среднего звена и как делаете архивирование данных, сколько оно времени занимает?
разработка на языке для бизнеса на посути смеси ооп, скрипта и бсл это нормально
Нет в этом ничего нормального, когда системе (и её разработчикам) срать на тех, кто будет их говно поддерживать, это скотство.
А то что вы к этому скотству привыкли и считаете нормой, ну... ваше дело, чего уж.
У 1С БП (по большей части именно в ней) есть огромный косяк - туда пихают все, что не нужно. Пустая база весит почти 2Гб, хотя с бух точки зрения там ничего нет, никаких данных. Больше половины сервисов среднестатистическому бухгалтеру вообще не нужны, но их не отключить. Даже банальный список счетов на оплату постоянно выполняет какие неведомые процессы. И к этому еще и прибавляется модуль рекламы. И проблема в том, что именно БП требует поддержания версий актуальными, ибо законодательство, и все новые "фишки" попадают на обзор тем, кому они не нужны - бухгалтерам....
Я обслуживаю бух аутсорсинговую контору, у нее 150+ баз. Есть обычные корп клиенты, бухгалтерам которой, управленческие финтифлюшки не нужны, ибо фин отдел работает в УПП, которой уже тыща лет.
Пустая база весит почти 2Гб, хотя с бух точки зрения там ничего нет, никаких данных.
Примерно 1Гб из них весят драйверы торгового оборудования из состава БПО.
Да, никогда не мог понять, на кой пихать драйвера во все дистрибутивы безусловно...
Не только драйверы, но и куча остального функционала. Видимо, дело в сложности дальнейшей поддержки. Те, кто пытался внедрять стандартные библиотеки частичным внедрением, опуская ненужные подсистемы, знают, какой это потом гемор поддерживать при каждом новом обновлении.
Как будто бы БСП и должна решать проблемы универсальности, когда в одном месте этот функционал нужен, а в другом нет. Было бы удобней подключать подсистемы как плагины в тех же CMS системах, а не пихать все и постоянно обращаться к ним. У клиента со 150 базами около половины - нулевки, им вообще ничего кроме 1С:отчетность не надо.
При этом я, как предприниматель, не могу использовать БП для работы, потому что она не поддерживает серийные номера (расширения вариант, но опять же, вечная поддержка).
Последний аргумент убрал все сомнения (про пакет)
1С — архаика или рабочий инструмент? Разбор горячего анти-хайпа