image


Друзья и коллеги, в последнее время на Хабре участились статьи с хейтом в адрес 1С, как платформы для разработки, и выступлениями ее защитников. Эти статьи обозначили одну серьезную проблему: чаще всего, критики 1С критикуют ее с позиции "не осиливших", ругая проблемы, которые де-факто, легко решаются, и, напротив, не задевая проблемы, которые действительно важны, стоят обсуждения и не решаются вендором. Полагаю, что имеет смысл провести трезвый и взвешенный обзор платформы 1С. Того, что она умеет, того что она не умеет, того что она должна бы делать, но не делает и, на сладкое — то, что она делает на ура, а ваши разработчики на %technology_name% будут делать стопицот лет, выкинув на ветер не один годовой бюджет.


В результате, вы, как руководитель или архитектор сможете получить четкое понимание — для какой задачи вам будет выгодно взять 1С, и где ее надо выжигать каленым железом. Как разработчик мира "не 1С" вы сможете посмотреть, а что же там такого в 1С есть из-за чего сыр-бор. А как разработчик 1С — сможете сравнить свою систему с экосистемами других языков и понять свое расположение в системе координат софтверной разработки.


Под катом — масса толстых набросов на 1С, на критиков 1С, на Java, .NET и вообще… Вентилятор заправлен, добро пожаловать!


О себе


Я знаком с предметом разговора примерно с 2004 года. Программирую наверное лет с 6, с того самого момента, как у меня появилась книжка про профессора Фортрана с комиксами про кота, воробья и гусеницу. Я разбирал программы, которые писал кот с картинок в книжке и выяснял, что они делают. И да, настоящего компьютера у меня тогда не было, но на развороте книжки был нарисованный и я честно нажимал бумажные кнопки, вводя команды, подсмотренные у кота Икса.


Далее был БК0011 и Бэйсик в школе, С++ и ассемблеры в универе, потом 1С, а потом столько всего, что уже и вспоминать лень. Последние 15 лет я, в основном, занимаюсь 1С, не только в части кодинга, а вообще 1С. Постановка задач, админство и девопс сюда же. Последние лет 5 занимаюсь общественно полезной деятельностью в плане развития инструментов разработки и автоматизации для других 1С-ников, пишу статьи и книжки.


Определимся с предметом обсуждения


Для начала давайте определимся о чем пойдет речь, поскольку под буквами "1С" можно понять много всего. В данном случае, под буквами "1С" мы будем понимать исключительно фреймворк разработки "1C: Предприятие" современной, восьмой версии. Мы не будем много говорить о фирме-производителе и ее политике (но немного-таки придется), Мы не будем обсуждать конкретные приложения, написанные с применением этого фреймворка. Технология отдельно, приложения a.k.a конфигурации — отдельно.


Высокоуровневая архитектура 1С: Предприятия


Я не зря упоминаю слово "фреймворк". С точки зрения разработчика платформа 1С это именно фреймворк. И относиться к нему надо именно как к фреймворку. Считайте, что это Spring или ASP.NET, выполняемый некоторой средой выполнения (JVM или CLR соответственно). Так получилось, что в мире обычного программирования ("не 1С") разделение на фреймворки, виртуальные машины и конкретные приложения получается естественным, в силу того, что эти компоненты обычно разрабатываются разными производителями. В мире 1С же не принято выделять в явном виде фреймворк разработки и собственно рантайм, кроме того, конкретные приложения, написанные с применением фреймворка, в-основном, также разработаны самой же фирмой 1С. В результате и возникает некая путаница. Поэтому, в рамках статьи нам придется рассмотреть 1С сразу с нескольких сторон и классифицировать ее по нескольким координатным осям. И в каждой оси координат мы положим по лопате коричневого вещества рассмотрим особенности, преимущества и недостатки имеющегося решения.


Точки зрения на 1С


1С для покупателя


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


Для покупателя 1С это быстрый time-to-market. Быстрый. Быстрее чем на Java, C# или JS. В среднем. По больнице. Понятно, что сайт-визитка на реакте получится лучше, но бэкенд WMS-системы — быстрее запустится на 1С.


1С как инструмент


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


  • серверное приложение
  • приложение, где фигурируют финансы
  • с готовым UI, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
  • с поддержкой фоновых процессов и заданий
  • с системой безопасности на основе ролей
  • со скриптуемой бизнес-логикой
  • с возможностью быстрого создания прототипа и низким time-to-market

1С вам не нужно, если вы хотите:


  • машинное обучение
  • расчеты на GPU
  • компьютерная графика
  • математические расчеты
  • CAD-систему
  • обработка сигналов (звук, видео)
  • highload http-вызовы с сотнями тысяч rps

1С как фирма-производитель


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


  • учет финансов
  • легкая кастомизация бизнес-логики
  • широкие возможности интеграции в гетерогенных IT-ланшафтах

Как производитель, фирма 1С считает, что именно такая стратегия позволяет работать с партнерами и клиентами в режиме win-win. Можно спорить с этим, но примерно так фирма себя продвигает: готовые решения проблем бизнеса, которые можно быстро кастомизировать силами партнеров и встроить в любой IT-ландшафт.


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


— Эй, бизнес, хочешь, чтобы в твоей 1С было ООП?
— Это поможет мне решить мои проблемы?
— Как знать…
— Тогда не нужно


Это подход может быть хорошим или плохим, в зависимости от того кто на него смотрит, но он просто такой. Говоря о том, что в 1С нет фичи Х, надо понимать, что ее нет там не просто так, а в контексте выбора "стоимость реализации vs размер профита".


Технологическая классификация


"На самом деле одинэсники вовсю используют самые лучшие паттерны, тщательно отобранные заботливыми методистами и разработчиками платформы 1С.
Когда ты пишешь свой тупой код для простенькой управляемой формы, на самом деле ты юзаешь model-view-controller с double-way data binding в three-layered-data-app-engine, сдобренный high level object-relation-mapping на базе declarative metadata description, имеющей свой platform-independent query language, c declarative data-driven user interface, complete transparent serialization и domain-oriented program language.

В чём разработчики 1С отличаются от западных коллег, так это в пиаре. Те любят любой фигне дать громкое имя и носиться с ней, как с писаной торбой."
А. Орефков

Платформа 1С имеет классическую 3-звенную архитектуру, в центре которой сервер приложений (или его эмуляция за мало денег для мелких лавочников). В качестве СУБД применяется или MS SQL или Postgres. Есть еще поддержка Oracle и IBM DB2 но это, скорее эзотерика, никто не знает что будет, если внедрять 1С на этих базах под средней и высокой нагрузкой. Полагаю, не знает этого и сама фирма 1С.


В качестве клиентской части выступает либо тонкий клиент, устанавливаемый на машину пользователя, либо веб-клиент. Ключевая особенность — программисты не пишут 2 разных кода, они пишут одно приложение, на одном языке, а вы можете выставить его в браузере, если есть желание или потребность. Кто там хотел подлинного фулстэка и единый язык для фронта и бэкенда, node.js? У них до конца так и не получилось сделать совсем одинаково. Настоящий фулстек существует, но писать придется на 1С. Ирония судьбы, такие дела :)


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


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


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


Фреймворк прикладной разработки использует собственный язык программирования, который примерно напоминает слегка улучшенный VB6, переведенный на русский язык. Людям, ненавидящим все русское, которые не верят, что "if" переводится, как "если" предлагается второй вариант синтаксиса. Т.е. при желании на 1С можно писать так, что с виду от VB не отличить.


image


Вот этот самый язык программирования и является основной причиной хейта 1С-ников в сторону своей платформы. Скажем прямо, не безосновательно. Язык задумывался, как максимально простой, призванный выполнить мантру "DEVELOPERS,DEVELOPERS" в масштабах хотя бы СНГ. Коммерческая суть такого решения, на мой взгляд, просматривается четко: больше разработчиков, больше охват рынка. Это сбылось по разным оценкам от 45% до 95%. Сразу скажу, что писать на том языке, на котором думаешь — реально легче. А я знаю довольно много языков программирования.


С языка, пожалуй и начнем.


Язык программирования 1С


Одновременно сильное и слабое место системы. Обеспечивает легкое вхождение, читабельность. С другой стороны, не обновлялся с момента выхода версии 8 в 2002 году и морально устарел. Кто-то скажет "главный недостаток — нет ООП" и будет неправ. Во-первых, ООП не любит не только Нуралиев, но и Торвальдс. А во-вторых, ООП все-таки есть.


С точки зрения разработчкика, в его распоряжении есть фреймворк с базовыми классами, отображаемыми на СУБД. Разработчик может взять базовый класс "Справочник" и отнаследовать от него справочник "Клиенты". Может добавить к нему новые поля класса, например, ИНН и Адрес, а также, если нужно — может переопределить (override) методы базового класса, например метод OnWrite/ПриЗаписи.


Фреймворк составлен таким образом, что более глубокое наследование требуется редко, и ограничение в ООП, на мой взгляд, имеет смысл. 1С ориентируется на Domain Driven Development и заставляет думать, в первую очередь, о предметной области разрабатываемого решения и это хорошо. Отсутствует не только соблазн, но и необходимость писать 10 разных DTO и ViewModel только для того, чтобы где-то показать какие-то данные из домена. Разработчик 1С оперирует всегда одной сущностью, не забивая себе контекст восприятия десятком классов с похожими названиями, представляющими одну и ту же сущность, но с другого боку. Любое .NET приложение, например, будет обязательно содержать пяток-другой ViewModel-ей и DTO для сериализации в JSON и передачи данных с клиента на сервер. И примерно 10-15% кода вашего приложения займет перекладывание данных из одного класса в другой ручками или костылями вроде AutoMapper. Этот код надо написать и программистам заплатить за его создание и сопровождение.


Выходит, что язык 1С сложно развивать, не усложнив его до уровня мейнстримных языков, потеряв таким образом преимущество простоты. Какая ведь по сути решается задача вендора: выдать типовое решение, которое сможет кастомизировать любой отловленный на улице студент с должным уровнем качества (т.е. кейс охвата от ларька до крупного завода выполняется). Если ты ларек — возьми студента, если ты завод — возьми гуру у партнера-внедренца. То, что партнеры-внедренцы продают студентов по цене гуру, это не проблема фреймворка. Архитектурно фреймворк должен решать задачи и тех, и других, код типовых конфигураций (которые мы продали бизнесу с обещанием кастомизации) должен уметь понимать студент, а гуру и так что хочешь поймет.


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


  • Возможность типизации на уровне, например, TypeScript (как следствие более развитые средства анализа кода в IDE, рефакторинг, меньше обидных косяков)
    Наличие функций как объектов первого класса. Чуть более сложная концепция, но количество boilerplate-code из типовых можно было бы сильно сократить. Понимание кода студентом, имхо, даже повысилось бы за счет сокращения объема
  • Литералы универсальных коллекций, инициализаторы. То же самое — снижение объема кода, который надо написать и/или просмотреть глазами. Наполнение коллекций это over 9000% времени программирования на 1С. Писать это без синтаксического сахара долго, дорого и error-prone. Вообще, количество LOC в решениях на 1С превосходит все мыслимые пределы по сравнению с доступными открытыми фреймворками и вообще, всех ваших энтерпрайз Джав вместе взятых. Язык многословен, а это вырождается в объем данных, память, тормоза IDE, время, деньги….
  • конструкции finally У меня есть гипотеза, что эта конструкция отсутствует из-за того, что не подобрали удачного перевода ее на русский язык :)
  • Собственных типов данных (без ООП), аналогов Type из VB6. Позволит не типизировать структуры с помощью комментариев в БСП и волшебных методов, конструирующих эти структуры. Получаем: меньше кода, подсказку через точку, более быстрое решение задачи, меньше ошибок по опечаткам и отсутствующим свойствам структур. Сейчас типизация пользовательских структур лежит полностью на команде разработки Библиотеки Стандартных Подсистем, которая, к честью для себя, тщательно пишет комментарии по ожидаемым свойствам передаваемых структур параметров.
  • Отсутствие сахара при работе с асинхронными вызовами на веб-клиенте. callback-hell в виде ОбработкаОповещения это временный костыль, вызванный внезапным изменением API основных браузеров, но жить так все время — нельзя, преимущество "понимания студентом" асинхронного кода теряется все сильнее. Добавьте сюда никакую поддержку этой парадигмы в основной IDE и все станет еще хуже.

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


Программисту, который уже много поработал с этим языком, заглянул в js или c# становится скучно в рамках этого языка. Это факт. Ему необходимо развитие. На другой чаше весов у вендора лежит стоимость реализации указанных фич vs увеличение выручки после их внедрения. Тут у меня нет никакой информации о том, что в глазах фирмы в данный момент перевешивает.


Среда разработки


Здесь все тоже не гладко. Сред разработки существует две. Первая, это входящий в состав поставки Конфигуратор. Вторая — разрабатываемая на базе Eclipse среда Enterprise Development Tools, сокращенно EDT.


Конфигуратор обеспечивает полный спектр задач разработки, поддерживает все фичи и является основной средой на рынке. Тоже морально устарел, не развивается, по слухам — из-за объема техдолга внутри себя. Ситуацию могло бы улучшить открытие внутреннего API (в виде дружбы со Снегопатом А. Орефкова или на самостоятельной основе), но этого нет. Практика показала, что сообщество само напилит себе фич в IDE, лишь бы вендор не мешал. Но имеем что имеем. Конфигуратор был прекрасен в 2004-2005, очень напоминал Visual Studio тех времен, местами даже был круче, но так и застрял в тех временах.


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


Как альтернатива предлагается написанная с нуля IDE, построенная на базе Eclipse. Там исходники, как и в любом другом софте живут в виде текстовых файлов, хранятся в GIT, ветки-пулреквесты, все вот это вот. Из минусов — уже который год не выходит из статуса беты, хотя с каждым релизом становится все лучше. Про минусы EDT писать не буду, что сегодня минус, завтра исправленная фича. Актуальность такого описания быстро сойдет на нет. На сегодняшний день разрабатывать в EDT можно, но непривычно, нужно быть готовым к некоторому количеству багов IDE.


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


Управление разработкой


Здесь все существенно лучше, чем в написании кода, особенно в последнее время, когда стараниями сообщества на свет были вытащены проблемы автоматизации администрирования, запущены прототипы, призывающие выкинуть на свалку хранилище 1С и пользоваться git, быстрым blame, code-review, статическим анализом, автодеплоем и etc. В платформу были добавлены многие фичи, повышающие уровень автоматизации задач разработки. Однако, все эти фичи были добавлены только и исключительно для разработки собственных крупных продуктов, когда стало очевидно, что без автоматизации уже никак. Появились авто-слияния, трехстороннее сравнение KDiff-ом и всякое такое. На гитхабе запущен gitconverter, который, положа руку на сердце, был идеологически утянут с проекта gitsync, но доработан под процессы компании-вендора. Благодаря упоротым парням из open-source автоматизация разработки в 1С сдвинулась с мертвой точки. Открытое API конфигуратора, имхо, сдвинула бы и моральную отсталость основной IDE.


На сегодняшний день, хранение исходников 1С в git с привязкой коммитов к задачам в Jira, ревью в Crucible, накатка кнопкой из Дженкинса и отчеты Allure о тестировании кода в 1С и даже статический анализ в SonarQube — это уже далеко не новость, а, скорее, мейнстрим в компаниях где есть много разработки на 1С.


Администрирование


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


Проблему здесь составляет то, что вендор не предлагает ничего особенного в части готовых решений для этой самой диагностики. Да, есть 1С: КИП и ЦУП, они даже и неплохи, но сильно платные и есть не у всех. В сообществе есть ряд наработок по подключению графаны, заббикса, ELK и прочего из типового набора админа, но единого решения, которое устроит большинство — нет. Задача ждет своего героя. А если вы бизнес, который планирует запуститься на кластере 1С — вам нужен Эксперт. Свой внутри или со стороны, но нужен. Это нормально, что есть отдельная роль, с компетенциями по работе сервера, не каждый 1С-ник должен это знать, просто надо понимать, что такая роль нужна. Возьмем к примеру SAP. Там программист, скорее всего, даже со стула не встанет, если ему на сервере приложений предложат что-то настроить. Он может тупо не уметь и ему стыдно не будет. В методологии SAP есть отдельная роль сотрудника под это. Почему-то в отрасли 1С считается, что это должно сочетаться в одном сотруднике за ту же зарплату. Это заблуждение.


Минусы сервера 1С


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


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


Docker


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


Коммерческая составляющая


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


Например, задача послать клиенту счет в PDF решается за час работы студента. Та же задача на .NET решается покупкой проприетарной библиотеки, либо парой дней или недель кодинга сурового бородатого разработчика. Иногда, и то и другое сразу. И да, я говорил только про формирование PDF. Мы не сказали, откуда этот счет вообще появится. Веб-фронтендер должен наверстать формочку, куда оператор вобьет данные, бэкендер должен будет создать dto-модели в для передачи JSON, модели для складирования в базу данных, структуру самой базы данных, миграции на нее, формирование графического отображения этого самого счета и только потом — PDF. На 1С, вся задача целиком, с полного нуля делается за час ровно.


Полноценная учетная система мелкого ларька с одним бизнес-процессом купил/продал делается часа за 3. С отчетностью по продажам, учетом товара по покупной и продажной ценам, в разбивке по складам, контролем прав доступа, веб-клиентом и мобильным приложением. Ладно, про приложение загнул, с приложением не за 3 часа, за шесть.


Сколько времени займет эта задача у разработчика .NET с момента установки visual studio на чистый комп до демонстрации заказчику? А по стоимости разработки? То-то же.


Сильные стороны 1С, как платформы


1С сильна не потому что в ней что-то конкретное лучшее в мире. Напротив, в каждой отдельной подсистеме можно найти более интересный аналог в мировом софте. Однако, по совокупности факторов я не вижу платформы аналогичной 1С. Именно в этом заключается коммерческий успех. Плюсы платформы раскиданы по ней и наиболее хорошо видны, когда видишь, как это делается в других платформах. В-основном, это даже НЕ фичи, а наоборот — отказ от фич в пользу одной конкретной парадигмы. Несколько примеров:


  1. Unicode. Что, блин, может быть проще? Не надо в 2019 году использовать однобайтные ASCII кодировки (кроме интеграции с дремучими legacy). Ни за что. Но нет же. Все равно кто-то в какой-нибудь таблице использует однобайтный varchar и приложение поимеет проблемы с кодировками. В 2015 году у gitlab отваливалась LDAP-авторизация из-за неправильной работы с кодировками, у JetBrains IDE до сих пор не везде работает с кириллицей в именах файлов. В 1С качественная изоляция прикладного кода от слоя работы с БД. Там нельзя типизировать таблицы на низком уровне и косяки малокомпетентных джуниоров на уровне БД там невозможны. Да, там возможны другие косяки малокомпетентных джуниоров, но разнообразие проблем сильно меньше. Вы мне сейчас скажете, что у вас-то приложение спроектировано правильно и слой доступа к БД изолирован как положено. Посмотрите в свое корпоративное самописное Java-приложение еще раз. Пристально и честно. Совесть не мучает? Тогда я за вас рад.
  2. Нумерация документов/справочников. В 1С она точно не самая гибкая и не самая лучшая. Но что делают в банковском софте и в самописных системах учёта — ну это же просто мрак. То identity воткнут (и потом "ой, а почему у нас дырки"), то наоборот, сделают генератор, который работает с блокировкой на уровне СУБД (и станет узким местом). На самом деле, довольно сложно сделать эту, казалось бы, простую задачку — сквозной нумератор сущностей, с разрезом уникальности по некоторому набору ключей, префиксацией, так чтобы это не блокировало базу при параллельном вводе данных.
  3. Идентификаторы записей в БД. 1С приняла волевое решение — все идентификаторы ссылок абсолютно синтетические и всё тут. И нет проблем с распределенными базами и обменами. Разработчики других систем упрямо лепят что-то типа identity (она же короче!), тащат их в GUI, пока не придёт пора делать несколько связанных инстансов (и тут их ждёт открытие). У вас такого нет? Честно?
  4. Списки. В 1С есть достаточно удачные механизмы листания (больших) списков и навигации по ним. Сразу оговорюсь — при правильном применении механизма! Вообще тема достаточно неприятная, она идеально не решается: тут либо интуитивно и просто (но риск огромных рекордсетов на клиенте), либо той или иной кривизны пейджинг. Те, кто делают пейджинг часто делают его криво. Те, кто делает честный скроллбар — кладут базу данных, канал и клиента.
  5. Управляемые формы. Спору нет, в веб-клиенте интерфейс работает не то чтоб идеально. Но работает. А вот для многих других учётных и банковских систем сделать удалённое рабочее место — это проект уровня предприятия. Оговорка: к счастью для тех, кто изначально сделал на вебе это не коснется.
  6. Мобильное приложение. С недавних пор вы можете писать и мобильные приложения, находясь в той же самой экосистеме. Тут чуть сложнее, чем с веб-клиентом, специфика устройств заставляет писать специально под них, но, тем не менее — вы не нанимаете отдельную команду мобильных разработчиков. Если нужно приложение для внутренних нужд компании (когда мобильное решение корпоративной задачи важнее желтого дизайна UI) — просто пользуетесь той же платформой из коробки.
  7. Reporting. Под этим словом я понимаю не BI-систему с большими данными и лагом на ETL-процесс. Имеются в виду оперативные отчеты персонала, позволяющие оценить состояние учета здесь и сейчас. Остатки, взаиморасчеты, пересортицу и т.п. В 1С из коробки поставляется система отчетов с гибкой настройкой группировок, фильтров, визуализации на стороне пользователя. Да, на рынке есть аналоги круче. Но не в рамках решения все-в-одном и за цену порой выше, чем решение все-в-одном. А чаще даже наоборот: только reporting, но дороже, чем платформа целиком, и хуже по качеству.
  8. Печатные формы. Ну-ка решите на .NET задачу отправки зарплатной ведомости в PDF сотрудникам на почту. А теперь задачу печати товарных накладных. А с сохранением их копий в тот же PDF? Для 1С-ника вывод в PDF любого макета это +1 строка кода. А значит + 40 секунд рабочего времени, вместо дней или недель на другом языке. Макеты печатных форм в 1С потрясающе удобны в разработке и достаточно мощны, чтобы конкурировать с платными аналогами. Да, наверное, в табличных документах 1С не так много возможностей по интерактиву, нельзя быстро получить 3D диаграмму с масштабированием при помощи OpenGL. Но оно точно надо?

Всё это лишь горстка примеров, когда ограничение функциональных возможностей или реализация с компромиссами оказывается важным архитектурным преимуществом в будущем. Даже компромиссный или не самый эффективный вариант — он уже есть в коробке и принимается как данность. Его самостоятельная реализация будет либо невозможной (потому что такие решения надо принимать в начале проекта, а там не до того, да и вообще архитектора нет), либо несколькими дорогими итерациями. В каждом из перечисленных пунктов (а это далеко не полный перечень архитектурных решений) можно накосячить и заложить ограничения, блокирующие масштабирование. В любом случае, вам, как бизнесмену, надо убедиться, что ваши программисты, делая "систему с нуля", имеют прямые руки и сделают тонкие системные моменты сразу хорошо.


Да, как и в любой другой сложной системе сама 1С точно так же имеет решения, которые в тех или иных аспектах блокируют масштабирование. Однако, повторюсь, по совокупности факторов, по стоимости владения, по количеству уже заранее решенных проблем — я не вижу на рынке достойного конкурента. За одну и ту же цену вы получаете фреймворк финансового приложения, кластеризуемый балансируемый сервер, с UI и веб-мордой, с мобильным приложением, с отчетностью, интеграцией и кучей еще чего. В мире Java вы нанимаете команду фронт-енда, бэкенда, отлаживаете низкоуровневые косяки самописного серверного кода и отдельно платите за 2 мобильных приложения под 2 мобильные ОС.


Я не говорю, что 1С решит все кейсы, но для внутреннего корпоративного приложения, когда не надо брендировать UI — что еще нужно?


Ложка дегтя


Наверное, сложилось впечатление, что 1С спасет мир и все другие способы написания корпоративных систем — неправильны. Это совсем не так. С точки зрения бизнесмена, если вы выбираете 1С, то помимо быстрого time-to-market необходимо учесть и следующие минусы:


  • Надежность сервера. Требуются действительно качественные специалисты, способные обеспечивать его бесперебойную работу. Мне неизвестна готовая программа подготовки таких специалистов от вендора. Есть курсы для подготовки к сдаче экзамена "Эксперт", но этого, на мой взгляд, недостаточно.
  • Поддержка. Смотри предыдущий пункт. Чтобы иметь поддержку от вендора, ее надо купить. Почему-то в отрасли 1С это не принято. А у SAP — почти обязательно к приобретению и никого это не смущает. Без корпоративной поддержки и без эксперта в штате — с глюками 1С можно остаться один-на-один.
  • Все-таки на 1С нельзя сделать совсем все. Это инструмент и как у каждого инструмента у него есть границы применимости. В ландшафте с 1С очень желательно иметь "не 1С-нутого" системного архитектора.
  • Хорошие 1С-ники стоят не дешевле хороших программистов на других языках. Хотя, плохих программистов нанимать дорого независимо от языка, на котором они пишут.

Расставим точки


  • 1С это фреймворк быстрой разработки приложений (RAD) для бизнеса и заточен под это.
  • Трехзвенка с поддержкой основных СУБД, клиентским UI, весьма неплохим ORM и репортингом
  • Широкие возможности по интеграции с системами, которые умеют то, чего 1С не умеет. Хотите машинного обучения — возьмите Python, а результат слейте в 1С по http или RabbitMQ
  • Не надо стремиться делать все на 1С, надо понимать ее сильные стороны и использовать их в своих целях
  • Разработчики, которые тяготеют к копанию в технологических фремворках-гаджетах, и к переделыванию каждые N лет на новый движок — в 1С скучают. Там все очень консервативно.
  • Скучают разработчики и в силу очень маленькой заботы о них со стороны фирмы производителя. Скучноватый язык, слабая IDE. Они требуют модернизации.
  • С другой стороны, разработчики, которые не могут найти себе развлечение посредством применения и изучения другой нравящейся технологии — плохие разработчики. Они будут ныть и перейдя в другую экосистему.
  • Работодатели, не позволяющие своим 1С-никам запилить что-то на Питоне — плохие работодатели. Они потеряют сотрудников с пытливым умом, а на их место придут monkey-кодеры которые, будучи со всем согласны, затащат корпоративный софт в болото. Его все равно придется переписать, так может было б лучше чуть ранее немного инвестировать в Питон?
  • 1С коммерческая компания и внедряет фичи исключительно исходя из собственных интересов и целесообразности. Её нельзя в этом винить, бизнес обязан думать о прибыли, такова жизнь
  • 1С зарабатывает тем, что продает решения проблем бизнеса, а не проблем разработчика Васи. Два эти понятия коррелируют, но приоритет именно такой, который я сказал. Когда разработчик Вася станет готов платить за личную лицензию на 1С: Решарпер — он появится довольно быстро, "Решарпер" А. Орефкова тому подтверждение. Если бы вендор поддерживал его, а не боролся с ним — глядишь возник бы рынок софта для разработчиков. Сейчас на этом рынке полтора игрока с сомнительными результатами и все из-за того, что интеграция с IDE отрицательная и все делается на костылях.
  • Практика специалиста-многостаночника уйдет в небытие. Современные приложения слишком объемны чтобы помнить их и со стороны кода и со стороны бизнесового использования. Сервер 1С также усложняется, удержать все виды экспертизы в одном сотруднике будет нельзя. Это должно повлечь за собой востребованность специалистов, а значит привлекательность профессии 1С-ника и рост окладов. Если раньше Вася три-в-одном работал за одну зарплату, то теперь нужно нанимать двух Вась и конкуренция среди Вась может подстегнуть общий рост их уровня.

Заключение


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


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


Отдавайте себе отчет, что идеального фреймворка не существует и берегите себя.
Всем добра!


P.S.: огромное спасибо speshuric за помощь в подготовке статьи.

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


  1. k2589
    18.12.2019 00:03

    Я надеюсь, что все больше разработчиков 1с будут смотреть на мир через парадигму «я знаю, какой язык лучше подойдет для этой задачи», не боясь изучать и применять python, js, c++, c# или java. Кроме того, хочется, чтобы и новые разработчики приходили с таким отношением, это во многом зависит от того, на сколько привлекательной будет инфраструктура разработки для молодых разработчиков, которые не боятся нового, не боятся совмещать.

    Мой кейс таков: я начал «разрабатывать» год назад с 1с, а благодаря знакомству с oscript за последние полгода успел решить бизнес задачи на python и js, познакомишись с bootstrap, mvp, docker.


    1. pfihr
      18.12.2019 19:56

      Никто не заметил тут пропаганду oscript, ага. Еще одна поделка сбоку к 1с, не поддерживаемая вендором. И бизнес 1с автор не знает и не понимает. Бизнес в том, чтобы создать массовый спрос на работу фирм партнёров, которым выгодно массово продавать клиентам коробки и лицензии и попутно — бесконечные обновления, доработки и «работу» недоученных специалистов, сменяющих друг дружку каждый день (ибо их легион). Клиентам, кроме траты денег, это не приносит ничего хорошего, но и альтернатив не много (и неспроста). Лишь бухгалтерия и ЗУП могут считаться относительно полезными решениями, помогающими бизнесу отчитываться перед государством. Все остальные решения и их перепиленные армиями одинесников вариации — создают лишь проблемы бизнесу, которые нужно постоянно решать, постоянно оплачивая труд радующихся такому положению вещей «недоучек». Это всегда намного дороже, чем профильные облачные решения и сервисы, покупаемые в аренду.


      1. Ta_Da
        18.12.2019 20:26

        Еще одна поделка сбоку к 1с, не поддерживаемая вендором

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

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

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


        1. CrushBy
          18.12.2019 21:53

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

          Конечно хорошо для 1С. Монополия всегда хороша для монополиста.


          1. Ta_Da
            18.12.2019 23:10

            Как же монополия? Вон, смотрите и ls fusion есть, и ofBiz, и SAP, и Dynamics, и на C# вон кто-то сам себе написал решение. И все лучше чем 1С.
            Просто бизнес он глупый. Продолжает есть кактус за свои деньги.

            Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.

            Как там у Гоголя?
            «Год 2000 апреля 43 числа. <...>Теперь передо мною все открыто. Теперь я вижу все как на ладони. А прежде, я не понимаю, прежде все было передо мною в каком-то тумане.»


            1. CrushBy
              18.12.2019 23:38

              Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.


              Как раз проблема именно в сложном законодательстве. В частности, в области бухгалтерского учета (неоправданная сложность) и начисления заработной платы (во многом из-за того, что налоги на зарплату платит организация, а не сотрудник, но и опять же ненужная сложность). Плюс нет стандартной, для всего мира, разделения на финансовые (Bil / Invoice) и товарные (Receipt / Shipment) документы, так как ТОРГ-12 в себе совмещает оба документа сразу.

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


              1. Provlax
                19.12.2019 00:12

                О да, сложное законодательство только в РФ. В США, например, совсем простое. Наверное именно по этой причине многие производители ПО для бизнеса там даже ни не берутся самостоятельно посчитать, например, Sales Tax. Он всего навсего зависит от Штата, дня недели, месяца, времени суток, типа товара, наличия льгот, лиценщий, праздников и т.п.


                1. Ta_Da
                  19.12.2019 00:54

                  Так вот откуда списали драконий покер:

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


                1. Mykola_Von_Raybokobylko
                  19.12.2019 12:05

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


                  1. stilic
                    19.12.2019 18:02

                    Насколько помню в мире «белых людей» прайс производителей софта ExVAT то есть в прайсе не учитываются локальные налоги. Я считаю это правильно. По какой окончательной формуле будет показана для меня цена это вопрос к торговой площадке. Если производитель желает продать мне напрямую, то заморачиваются с платежной системой. НДС, доставка до меня и прочее.


                    Это вынуждено.
                    Если вы про ЕС — банально — там НДС очень разный в разных странах. Если про США, то там налог с продаж разный в разных местах.
                    В РФ в этом нет необходимости — ибо всё едино.
                    Загадка почему в Японии налог с продаж нужно самому добавлять, там вроде нет сложных исключений.


              1. stilic
                19.12.2019 17:54

                Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.

                Как раз проблема именно в сложном законодательстве


                Е-рун-да.

                Как человек со всем этим работающий утверждаю.

                На предприятиях зачастую:

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

                И т.п.

                Так вот основное, от чего зависит ежедневная работа фирмы — это именно производственная или торговая конфигурация или иная конфигурация для оперативного управленческого учета. Которые не обновляются и по несколько лет (старейшие в строю из мне лично известных — аж с 2004 года в эксплуатации). Не обновляются — имеется ввиду, свежими версиями от самой 1С, где все последние веяния законодательства учтены.

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

                Чувствительной к законам является только бухгалтерская 1С. Да, та обновляется часто.

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

                Онлайн-кассы, учет алкоголя. Корректировочные счета-фактуры — да и то не для всех, многие делают их в бухгалтерской 1С. Изменение транспортных документов, но это не такое уж и сложное изменение. И… да пожалуй все. Мелкие изменения форм документов, типа добавить ГТД в счет-фактуру — ну такого плана изменения еще раза 10 за 20 лет были критичны, но я не считаю это за серьезную проблему. На этом всё.

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

                К чему я это?

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

                А ведь, утверждаю из опыта, именно там и основные деньги. Если вещи нужны фирме как воздух. Это ее ежедневная деятельность. Это её конкурентное преимущество и пр. и пр.

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

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


                1. CrushBy
                  19.12.2019 18:15

                  Полностью с Вами согласен насчет относительной неважности бухгалтерского и фискального учета.

                  Но тут другая проблема. Я сейчас достаточно подробно изучаю западные решения (в большей степени Odoo) — хочется сделать открытое и бесплатное решение, которое подойдет как к западной модели, так и к постсоветской. И есть принципиальное отличие в плане документов. Я это уже упоминал выше.

                  У них во всех решениях всегда три документа: Order / Invoice / Shipment. У них нормально, когда Вам поставляют товар в течение месяца без каких-либо документов с ценами. Вы их приходуете по какой-то условной цене из заказа. А потом вам выставляют на них счет (причем цена может не совпасть с ценой в заказе). В постсовке же вы не можете без финансового документа (например, ТОРГ-12 или ТТН, в котором есть цены) оприходовать товар.

                  И, например, вот это обстоятельство достаточно сильно влияет на логику процессов приемки и отгрузки. По этой причине тот же Odoo из коробки под РФ ну никак не подходит. Если конечно, не делать двойной ввод в 1С и иметь разную себестоимость в Odoo и 1C.


                  1. stilic
                    19.12.2019 18:37

                    И, например, вот это обстоятельство достаточно сильно влияет на логику процессов приемки и отгрузки. По этой причине тот же Odoo из коробки под РФ ну никак не подходит. Если конечно, не делать двойной ввод в 1С и иметь разную себестоимость в Odoo и 1C.


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

                    Их можно считать сразу, а можно и не сразу — зависит от бизнес-требований.

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

                    Эта вещь не всегда связанная с отгрузкой.

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

                    Прежде чем браться за такой проект вам следут поработать полноценным разработчиком для той же 1С (нормальным, а не обновляльщиком типовых конфигураций) хотя бы года 3 (лучше 5-7), причем в разных придприятиях с разным учетом (или у франча, что разные предприятия обслуживает), чтобы начать понимать такие вещи.

                    Которые специалисту очевидны.


                    1. CrushBy
                      19.12.2019 19:15

                      Вы не поняли меня. Чтобы было понятнее, ответьте мне на простой вопрос:

                      Могу ли я в РФ ЗАКОННО отгрузить покупателю товар без каких-либо документов, в которых указаны цены, а он в свою очередь принять его (в том числе и по бухгалтерскому учету)? Документы на оплату с ценами при этом ему выставить через месяц.

                      А в англосаксонских и европейских моделях учета — это в порядке вещей.


                      1. stilic
                        19.12.2019 19:24

                        Могу ли я в РФ ЗАКОННО отгрузить покупателю товар без каких-либо документов, в которых указаны цены, а он в свою очередь принять его (в том числе и по бухгалтерскому учету)? Документы на оплату с ценами при этом ему выставить через месяц.


                        Это вообще не проблема софта и программиста.
                        Это проблема юриста и бухгалтера.

                        Знаю многих что так делают. С 1С.
                        Как это соответствует закону — не знаю.
                        Спросите лучше на форуме бухгалтеров.

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


                        1. CrushBy
                          19.12.2019 19:47

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

                          А в других странах — это стандартная схема. И поэтому там во многих местах другие процессы, под которые и заточены у них многие программы. По этой причине большинство из них не подходит для РФ из коробки и требует, как минимум, адаптации.


                          1. stilic
                            19.12.2019 20:05

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


                            Ваш большой опыт не знает что такое договор ответственного хранения и агентский договор?

                            А в других странах — это стандартная схема. И поэтому там во многих местах другие процессы, под которые и заточены у них многие программы. По этой причине большинство из них не подходит для РФ из коробки и требует, как минимум, адаптации.


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

                            Но упомянутая вами схема с осуществлением сначала отгрузки, а уже потом отложенной реализации — вполне себе реализуема.

                            Проблема скорее будет в печатных формах документов, если их изменение не предусмотрено в «импортном» решении.

                            Но не в самой сути учета.


                            1. CrushBy
                              19.12.2019 20:11

                              уже потом отложенной реализации — вполне себе реализуема

                              Как она может быть реализуема, если незаконна?

                              Как Вы сделаете печатную форму документа в Odoo для Delivery Order, если там в документе цен нет вообще? Что Вы там напечатаете?

                              Ваш большой опыт не знает что такое договор ответственного хранения и агентский договор?

                              Какое отношение договор ответственного хранения и агентский договор имеет к обычной продаже компанией А компании В? Давайте только, без костылей.


                              1. stilic
                                19.12.2019 20:19

                                уже потом отложенной реализации — вполне себе реализуема


                                Как она может быть реализуема, если незаконна?

                                Как Вы сделаете печатную форму документа в Odoo для Delivery Order, если там в документе цен нет вообще? Что Вы там напечатаете?


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

                                Да и не только. Вы забываете, что отгрузка товара != переход прав собственности.

                                Обычно это так, да. Это и ввело вас в заблуждение.


                                1. CrushBy
                                  19.12.2019 20:40

                                  То есть Вы предлагаете при внедрении Odoo со всеми покупателями заключать договора комиссий / ответственных хранений? Даже если им просто пачку бумаги продаете?


                                  1. SwingoPingo
                                    20.12.2019 22:09

                                    а потом вы за эту пачку выставляете цену равную в пропорции НДС уплаченному за квартал и требуете с государства возмещения ибо доверие между бизнесом и государством? Имхается мне за такие схемы в любом государстве будут ожидать проблемы.
                                    Вопросы определения НДС и прибыли. Прибыль считается как разница выручки и затрат. Затраты >= себестоимость. Если себестоимость is null то Прибыль is null тоже, а это не тот ответ, который устроит ФНС в конце налогового периода. Схема с определением себестоимости и НДС входящего в конце налогового периода мысль конечно заманчивая, но см. п.1


                                    1. CrushBy
                                      20.12.2019 22:37

                                      Посмотрите вот эти ссылки:
                                      https://www.odoo.com/documentation/user/13.0/inventory/management/reporting/valuation_methods_anglo_saxon.html
                                      https://www.odoo.com/documentation/user/13.0/inventory/management/reporting/valuation_methods_continental.html

                                      Там внизу примеры, когда цены в заказе (PO) отличаются от цен в накладной/счете(Invoice). И посмотрите, как у них вообще проводки разносятся по счетам, и какие там счета есть.

                                      Например, как Вам такой классный счет, как:
                                      23000 Goods Received Not Purchased

                                      Какой его аналог в РФ (это именно не неоплаченные, а некупленные товары)?


                          1. SwingoPingo
                            20.12.2019 22:03

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


      1. EvilBeaver Автор
        18.12.2019 22:28

        Пропаганда, какое прекрасное слово!


        1. pfihr
          18.12.2019 22:43
          -1

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


          1. Igor_O
            20.12.2019 00:07

            А теперь просто посмотрите на ситуацию глазами студента, которому нужно купить квартиру, т.к. после вечеринки студентка от него залетела и жениться — придется:
            25 килорублей «стажер» на частичной занятости, пока диплом не получил. 60-80 килорублей — «помошник программиста 1С» на первый год после института. 150-200 килорублей с примерно третьего года после института до пенсии. Стабильно. Независимо от кризисов. Не надо каждый год осваивать новый фреймворк. Не надо шесть раз в год разбираться как в новомодной парадигме правильно делать 3-д эффекты при открытии формы ввода… Никаких нервотрепок, никаких авралов, при желании — все свободное время можно посвятить подработкам, которые дают хорошую «прибавку к пенсии», т.к. очень много мелких фирм, которые не могут себе позволить платить ежегодную мзду интегратору, но которым пару раз в год что-то надо в 1С подправить…
            Я бы сам уже лет десять бы как подался бы в 1С, но лично у меня любое соприкосновение с финансами и бухгалтерией вызывает уверенность, что они должны быть запрещены как особо извращенные виды пыток. Но я был знаком с несколькими людьми, у которых подобная работа вызывает радость, экстаз и чувство глубокого удовлетворения.


            1. bonv
              20.12.2019 00:18

              Никаких нервотрепок, никаких авралов

              Очень смешно))

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

              Ну с такими обычно и проблем больше. Вам же они тоже не захотят платить

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

              А еще там есть жесткие дедлайны. Зайдите как-нибудь в бухгалтерию в последний день сдачи отчетности по НДС


              1. Igor_O
                20.12.2019 01:11

                Зайдите как-нибудь в бухгалтерию в последний день сдачи отчетности по НДС

                Гы! Я однажды пытался жениться на девушке-бухгалтере. И свидания в очереди на Главпочтамте, т.к. ей надо успеть отправить конверты с отчетами в налоговую до полуночи, а другие отделения, естественно, давно закрыты, были далеко не самой большой экзотикой.

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

                Очень смешно))

                Ага. То, что у 1С-ника считается авралом, у ГИПа и ПМа на строительстве, например, ЦОДа называется «как здорово, что отпуск, и тебя никто не дергает!»
                Я когда гиповал, «в отпуске» обычным делом было штук пять звонков в день с необходимостью принять решение, ошибка в каждом из которых (все ещё) может вылиться в пару лет отсидки…


            1. Ta_Da
              20.12.2019 00:37

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

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

              А вот сопутствующие задачки (с финансами связанные косвенно) типа WMS | логистики | интеграций с удовольствием решаю. Так что там не все так плохо.

              Иногда возникает вопрос: «а чего бы все это не делать на java», но один из ответов — внезапно, некоторые собственники не хотят решений не на 1С. Не потому что «1С это супер, ничего лучше нет», а потому что они на подсознательном уровне не хотят плодить зоопарк систем, т.к. чувствуют, что поддержку если что, им будет искать сложнее/дороже.
              Плюс у некоторых есть негативный опыт с проваленными внедрениями и при этом позитивный при работе/внедрении 1С (это примерно как у некоторых комментаторов в этой статье, но с противоположным знаком).


            1. vvbob
              20.12.2019 12:04

              Попервости тоже 1С-ом зарабатывал. Потом на С перешел и сейчас Java-Kotlin. На яве стрессов и дедлайнов хватате, но от работы во франче 1С у меня самые жуткие воспоминания остались в плане нервотрепок. Весь негатив (зачастую вполне заслуженный) по поводу 1С и фирмы которую ты представляешь — на тебя изливается. А народ, который пользуется услугами франча весьма… специфичный… за копейку удавятся и тебе весь мозг съедят, а от этих копеек твой доход напрямую зависит.
              Когда ушел оттуда — мне обычная разработка показалась просто заповедником спокойствия и околонулевого стресса. Я уж лучше буду фреймворки каждый год изучать, тем более что мне это интереснее чем изучать очередные нововведения в бухучете.
              Да и не нужно это так часто делать, тот-же спринг, например, один из основных используемых фреймворков на Яве, он вполне эволюционно развивается, новые важные изменения в нем не так часто происходят, что-бы их изучение как-то напрягало. А большинство хайповых тем вообще в IT, и изучать нет особого смысла — бабочки однодневки.


              1. Ta_Da
                20.12.2019 12:22

                Ну опять же, «Работа с 1С != Работа во франче» и «Работа с 1С != Работа с бухгалтерией». Так-то да, франч это бизнес по продаже коробок + потогонка с простыми задачами за мелкий прайс, в большинстве своем. Но в какой-нибудь условной веб-студии будет плюс минус тоже самое.
                Стоит только перейти к разработке условно-коробочного решения или проектным работам и появляется спокойствие, время на изучение и использование современных технологий (в т.ч. и не 1С) и т.д.


      1. Diversus
        18.12.2019 22:58

        Самое интересное, что автор этого поста и автор oscript — это одно и тоже лицо :)
        Андрей, спасибо тебе за твою работу! Реально в одиночку сделал просто мега инструмент. Используем oscript для сборки и тестирования своего решения.
        Теперь что касается: «бизнес 1с автор не знает и не понимает». Наоборот! Все достаточно точно и по делу. Бизнес сам решает платить вендору или партнёрам или нет. Верно? Если бизнес платит, значит его все устраивает и у него нет других альтернатив. Да, все далеко не идеально, но есть вещи, которые очень удобны. Помню, как в 2007 знакомился с 1С и был впечатлён в 1С 7.7 табличным документом и посекционным выводом в отчетах (до этого имел счастье работать с Fast Report в Delphi), а тут все было настолько просто и функционально, что я был просто шокирован.


        1. EvilBeaver Автор
          19.12.2019 08:20

          Спасибо!


      1. zurapa
        20.12.2019 09:43
        +1

        Легионы недоучек, проблемы бизнесу решениями от 1С…
        Суть в том, что за такие деньги других вменяемых альтернатив нет. И бизнес выбирает 1С за то, что есть уже готовые решения их проблем, которые можно довольно-таки легко подпилить. И есть масса специалистов, пусть даже недоучек и, кого вы там назвали…
        Возьмите Java, вы даже недоучку с трудом найдёте, а готового решения для бизнеса российского вообще нет.
        На самом деле все понимают, что 1С то подвинуть не сложно: сделайте аналогичные решения позволяющие автоматизировать учёт и отчётность. Да хотя бы отчётность автоматизируйте, а учёт, как показывает практика, всё равно, кто во что гаразд делает у себя. Однако, воз и поныне там. Ни кто напрягаться не хочет. Потому что это затратно на первоначальном этапе. Чтобы написать и выкатить в массы такой продукт и приучить бизнес к нему, нужно десятилетие. Мало кто может себе позволить 10 лет работать в убыток, чтобы потом получать какие-то крохи в конкуренции с «монополистом».
        Монополии то нет у 1С. Ну, может быть тот факт что наше законодательство налоговое сильно извращено и постоянно меняется, и за это кто-то приплачивает — это может такое быть в нашей стране. Но в остально, ни кто не припятствует выйти на рынок и сразиться с 1С. Но желающих не возникает. Бизнес устраивает то, что есть.
        Отдельно от лица недоучек вам отвечу. В станах python, java и проичих хватает также недоучек, которых берут, за неимением лучшего, или же по знакомству, и в довольно-таки крупных компаниях, даже государственного сектора процветает такой говнокод, за такие деньги высокие, что 1С'ники отдыхают, даже самые занюханные франчи. А, кстати, и про аутсорсеров от java тоже наслышан. Там тоже процветает схема, продавать за дорого стажоров, под видом крутых специалистов. А специалистов, только на презентациях показывают заказчикам, чтобы пыль в глаза бросить.

        Автор весьма качественно, хорошо описал общий взгляд на ситуацию. Хоть и сам мне этот человек не вызывает тёплых чувств, но следует отдать должное — статья хороша. И рекламы оскрипта я не увидел. Хоть, и знаю о скрипт. Более того, пока не дочитал до конца и не увидел автора, даже не догадался, что это за личность в мире 1С. А я слежу за ними. Не нужно свою желчь выплёскивать везде. Аргументируйте свою критику более детально, в характере написанной статьи.


      1. Dementor
        20.12.2019 11:25

        И бизнес 1с автор не знает и не понимает. Бизнес в том, чтобы создать массовый спрос на работу фирм партнёров

        А может господин комментатор не знает и не понимает бизнес 1с? В 90-е и 00-е вендору было экономически выгодно развивать партнерскую сеть в целях экспансии. Но уже в конце 00-х началась политика покупки крупных партнеров.

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

        А думаете франчам интересно быть просто «кузнецей кадров» для рынка и превращать за свой счет вчерашних студентов в завтрашних штатных сотрудников для своих же клиентов? Думаете выгодно вместо использования налаженного конвейера продаж вкалывать за каждую копейку?


    1. apapacy
      20.12.2019 00:30

      Интересно. Какое может быть типичное использование у oscript?


      1. Ta_Da
        20.12.2019 00:43

        Вообще, его довольно успешно «продали» 1С-никам как замену powershell — т.е. вроде и решаешь задачи вне 1С, а вроде как и на привычном языке пишешь.
        В итоге на нем реализовали ряд решений из мира «взрослого DevOps и CI/CD», только с местным, так сказать, колоритом. Фактически — снизили порог входа для 1С-ников в мир современных технологий.


  1. Neikist
    18.12.2019 00:42

    Редкая статья про 1с от 1сника с которой я согласен за исключением некоторых спорных пунктов но которые обсасывали во всех спорах по 10 раз и повторяться бессмысленно. Упомяну разве что пару мелочей

    На сегодняшний день, хранение исходников 1С в git с привязкой коммитов к задачам в Jira, ревью в Crucible, накатка кнопкой из Дженкинса и отчеты Allure о тестировании кода в 1С и даже статический анализ в SonarQube — это уже далеко не новость, а, скорее, мейнстрим в компаниях где есть много разработки на 1С.

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

    Мобильное приложение. С недавних пор вы можете писать и мобильные приложения, находясь в той же самой экосистеме. Тут чуть сложнее, чем с веб-клиентом, специфика устройств заставляет писать специально под них, но, тем не менее — вы не нанимаете отдельную команду мобильных разработчиков. Если нужно приложение для внутренних нужд компании (когда мобильное решение корпоративной задачи важнее желтого дизайна UI) — просто пользуетесь той же платформой из коробки.

    Как человек делавший (по крайней мере на то время 17-18 год) самый крупный проект на мобильной 1с для предприятия (магнит тогда 3к лицензий на мобильную платформу купил) — в этом пункте вы ну ооооочень лукавите. Во первых разработка рест апи и механизма синхронизации при больших объемах справочников, необходимости работы оффлайн и невозможности удобно собирать логи — та еще боль, а для среднестатистического 1сника и вовсе задача с которой он ни разу не сталкивался. Во вторых — все равно пришлось начинать вникать в нативную разработку чтобы реализовать рядом пару других приложений мобильных для общения с мобильной 1с чтобы удовлетворить требования. В третьих из за ограничений платформы мы вообще едва не попали на необходимость писать все на нативе с нуля поскольку 1с не проходила аудит безопасников магнита. Им нужна была довольно тесная интеграция приложения с мдм системой, шифрование базы и прочее, а все это возможно только через подключение SDK вендора к приложению. И внешней компонентой это не решалось ибо требовало именно что встроить очень крепко, прямо в платформенный код. Да, сейчас, когда я уже год только и занимаюсь нативной разработкой под андроид я бы это осилил, но боюсь это бы противоречило лицензионному соглашению с 1с, сделало бы практически невозможной обновление (ибо не факт что патч бинарника одной платформы подошел бы к другой) и заняло бы дофига времени. В итоге аудит мы прошли, но чисто административными методами, а бодания заняли примерно год.


    1. EvilBeaver Автор
      18.12.2019 00:57

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


    1. EvilBeaver Автор
      18.12.2019 08:07
      +1

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


      1. Neikist
        18.12.2019 08:35

        Да собственно уже почти все рассказал. Мобильный клиент это они придумали годно, но мобильное приложение — жесть. Сейчас может получше — но еще в 18 году было все до сих пор дико забаговано, разработка неудобна, и ни за что серьезное без знаний нативной разработки лучше не браться, выйдет все равно фигня.


        1. Necessitudo
          18.12.2019 15:20

          Тоже занимаюсь разработкой и поддержкой мобильного приложения на платформе 1С. Ничего не изменилось:)


          1. Neikist
            18.12.2019 15:33

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


            1. Necessitudo
              18.12.2019 15:38

              Веселая была история, когда гугл плэй вывалил требование — теперь только x64 приложения! — а сборщик мобильных приложений умел только x32. Пришлось допиливать сборщик, а фирма 1С новый сборщик выкатила только спустя сколько-то месяцев.


              1. stilic
                18.12.2019 15:42

                Веселая была история, когда гугл плэй вывалил требование — теперь только x64 приложения!

                Это зачем им?
                Ведь полное еще 32-битный аппаратов.


                1. fleshold
                  18.12.2019 16:19

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


                1. alekciy
                  18.12.2019 16:20

                  Так и камней еще предостаточно. Но… "каменный век закончился не потому, что закончились камни" (с)


      1. PS_erg
        18.12.2019 15:22
        +1

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


        1. pfihr
          18.12.2019 20:04

          Дешевле было (а на самом деле, бесплатно) просто в фигме прототипировать.


  1. ser-mk
    18.12.2019 02:19
    +1

    И еще — если к вам пришел наниматься 1С-ник, то 1С-ника можно смело ставить на должность лида аналитиков.

    Похоже у кого-то скоро собеседование… </мысли в слух>


    1. EvilBeaver Автор
      18.12.2019 15:23

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


  1. Honomer
    18.12.2019 06:39

    Редкой объективности статья про 1С. Впрочем, видя кем она написана — не удивительно. Респект.


    Хочется добавить, что если очень нужно, брендировать интерфейс 1С теперь тоже умеет, просто это отдельная фича и не для всех.


    1. o4karek
      18.12.2019 10:28

      Цвета перекрасить — вполне для всех. Стили в управляемом приложении стали доступны (с 8.3.13) и перекрасить приложение можно.


      1. EvilBeaver Автор
        18.12.2019 10:31

        Перекрасить можно, но оно все равно будет узнаваемой 1С-кой. Иногда корп-дизайн это ключевой фактор для UI. А иногда наоборот — не имеет значения. Я лишь обозначил этот момент, чтобы было проще принимать решение.


        1. o4karek
          18.12.2019 11:16

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


    1. bolonov
      18.12.2019 10:28

      Поддерживаю


  1. vis_inet
    18.12.2019 06:57

    Опят показывает, что в обсуждениях про 1С никогда не удаётся поставить точку )


    1. pfihr
      18.12.2019 23:28
      +1

      Скоро все закончится. Сейчас тренд — облачные решения и сервисы, работа с большими данными, микросервисы и т.п. В этих сферах 1с пролетает мимо и с большим свистом. Архитектура микросервисов позволяет взять и переписать любой сервис на НОВОЙ технологии, если она появилась, на ЛЮБОМ языке или фреймворке, если он лучше старого. Это избавляет от ловушек легаси, в которой застряла 1с и скоро просто утонет после того, как появятся государственные облачные сервисы, решающие задачи с учетом и отчетностью. Непонимание этой тенденции не оставляет в покое многих пытаться безуспешно выходить с технологиями прошлого века на международные рынки и тягаться там на поле с местными мастодонтами. Это глупо, как и глупо пытаться искать программистов 1с в среду, где зарабатывают на консалтинге и продажах коробок/лицензий.


      1. gecube
        18.12.2019 23:43

        Да, но два нюанса.
        Первый — для того, чтобы клиент (маленькая шаражка на 10 человек) ощутила от этого выгоды — она должна быть клиентом SaaS сервиса (в котором внутри и отказоустойчивость, и микросервисы и все-все-все), но тут внезапно выясняется, что, во-первых, Ваши данные — не Ваши (они в облаке и принадлежат ему), а, во-вторых, если Вам очень нужна какая-то функциональность, то ее могут реализовывать годами, ибо Вы — не в приоритете. В случае НОРМАЛЬНЫХ SaaS (типа Slack) это решается богатым АПИ, которое клиент может использовать и тягать любые данные к себе. И наоборот.
        Второй момент — получается, все эти микросервисы и прочее могут позволить только большие клиенты, т.к. у них есть возможность отстегивать за это кучу денег. Это реально дорого. Сложность программного обеспечения перемещается из одного уровня (в монолите вся сложность где-то внутри) на уровень связи между всеми этими микросервисами. С одной стороны, это позволяет быть просто супер-гибкими (действительно -не нравится микросервис — взяли, выкинули, внедрили новый). С другой — шаурмячная себе это позволить в принципе не сможет, но это ей и не нужно.

        > как появятся государственные облачные сервисы, решающие задачи с учетом и отчетностью.

        Это вообще мечта всех, наверное… Чтобы были качественные облачные гос. сервисы… экономящие деньги и силы граждан и других клиентов.


        1. pfihr
          18.12.2019 23:56
          +1

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


        1. Ta_Da
          18.12.2019 23:58
          +1

          шаурмячная себе это позволить в принципе не сможет, но это ей и не нужно

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

          А если серьезно, то как раз в мелким клиентам всякие «1С:Fresh», «МойСклад» и т.д. легче заходят. Без всякой доработки. Такой парадокс, что те кто может себе позволить платить деньги за доработку SAAS решения, предпочитает сервер держать поближе к себе (ну или в каком-нибудь надежном далеком датацентре, но на своем выделенном сервере).


  1. gecube
    18.12.2019 08:20

    Спасибо! Отличный обзор! Очень посмеялся, очень хорошо написано, жизненно.


    конструкции finally У меня есть гипотеза, что эта конструкция отсутствует из-за того, что не подобрали удачного перевода ее на русский язык :)

    можно было сделать


    ПОПРОБУЙ
      здесь_код
    ИСКЛ
      обработка_ошибок
    НАКОНЕЦ
      обработка_finally

    видимо, выглядит некрасиво


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

    не хватает сравнения с "великим и ужасным" SAP.


    1. inot
      18.12.2019 08:27
      +3

      «накряйняк» прикольней)


    1. gyzl
      18.12.2019 10:36
      +1

      Лучше так: :)

      ПОПРОБУЕМ
        здесь_код
      НЕВЫШЛО
        обработка_ошибок
      ИВСЁТАКИ
        обработка_finally
      


    1. Bronx
      18.12.2019 11:47
      +1

      Есть ещё слова "эпилог", "финал" (или "финиш"), "исход", так же по смыслу может подойти слово "однако".


    1. Muzzy0
      18.12.2019 17:56

      конструкции finally У меня есть гипотеза, что эта конструкция отсутствует из-за того, что не подобрали удачного перевода ее на русский язык :)
      В конце концов,


      1. Danik-ik
        18.12.2019 21:20

        Пока читал, в голове вертелось "ПОЛЮБОМУ", что соответствует целевому смыслу применения, а не подстрочнику. Ну или "ОБЯЗАТЕЛЬНО". Предложенные выше варианты, мне кажется, этому критерию не соответствуют, кроме разве что "финиша".


    1. zhenyat
      18.12.2019 22:16

      Попытка
      Исключение
      ПослеПопытки
      КонецПопытки


  1. stone_evil
    18.12.2019 08:33

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


    1. gecube
      18.12.2019 08:45
      +2

      как прогрессивное человечество запрыгивает на микросервисную платформу.

      Только почему-то все забывают цену "впрыжка" туда....


      1. gibson_dev
        18.12.2019 11:47
        +2

        И то что есть цена выпрыгивания обратно, микросервисы — не панацея вообще ни разу


    1. akabrr
      18.12.2019 10:36

      Не всё можно загнать в микросервисы


      1. EvilBeaver Автор
        18.12.2019 10:36
        +1

        поправка: не все НУЖНО загонять в микросервисы


    1. m-rv
      18.12.2019 10:49

      я кстати думал об этом. это не невозможно. над CI/CD нужно будет конечно поработать, плюс нужна совершенно иная система обмена данными (на нормальных технологиях и отличных от текущих принципах), плюс облачную интеграцию закостылить (сквозная авторизация, балансировка и пр), но в целом, думаю, я смог бы запилить систему с нормальным откликом. Другое дело — кто готов вывалить мешок денег за это? ))


    1. speshuric
      18.12.2019 23:46

      А много ли в мире учётных систем на микросервисах? Ну то есть не чтоб мелочёвка сбоку, а чтобы прямо главную книгу банка или что-то подобное на микросервисах?


      1. fcoder
        19.12.2019 04:32

        А 1С предназначена исключительно для "главной книги банка"?


        А ещё разные системы могут быть взаимно-интегрированы или пользоваться одними и теми же данными. Ещё здорово разделять сервисы для дополнительной устойчивости. Если система подсчёта кредитного рейтинга упала, то система работы с дебетовым счётом не должна от этого сильно страдать.


        Аргумент "НЕ НУЖНО" выглядит по меньшей мере странно.


    1. Mykola_Von_Raybokobylko
      19.12.2019 12:28

      Не совсем монолит, но в силу изначального рождения как продукт исключительно для учёта, дальнейшие "мутации" не могли ослабить доминанту. 1С это очень хорошее решение для учета. В первую очередь для учета в торговли в РФ. Это было заложено в продукт "с рождения".
      В силу этой генетической особенности решения, игрища с разными подходами к эволюционному развитию мало применимы и вредны. 1С это не нужно от слова совсем.


      Даже отдельные разработки которые велись в стране не на базе 1С, но могли интегрироватся не могли улучшить ситуацию. Отдельные разрабатываемые модули "взлетели" и даже есть удачные примеры внедрения, но массового интереса к этим продуктам нет, и не планируется быть массовым.
      Аналогично с Дамгаардом. Решение было с рождения приспособлено для учета и планирования на производственно-сбытовых предриятиях.


  1. nirom
    18.12.2019 08:39

    Не упомянут очень важный минус. Все современные типовые конфигурации 1С очень громоздкие и неповоротливые, сделаны по принципу «пихай всё что только можно сразу в типовое решение». Отсюда страшнейшие проблемы с производительностью. Причем как-то это исправить со стороны программиста 1С не возможно: в 1С не знают что такое модуляризация и внедрение зависимостей. Ну т.е. совсем не знают.
    Есть функционал подсистем и функциональных опций, но он прямо скажем очень слабо развит.
    В результате этой раздутости, помимо проблем производительности, возникают проблемы и с касомизацией под конкретного заказчика, любая доработка, даже казалось бы не значительная, выливается очень серьёзными трудозатратами — посмотрите стоимости внедрений современных ERP-УПП-БУ-УТ где-нибудь на тендерных площадках.


    1. stilic
      18.12.2019 09:18

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


      На самом деле, нет.

      Проблема, безусловно, касается монстроидальной УПП, но УПП уже почила в бозе (более развиваться не будет, только поддержка).

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

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

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

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


      1. nirom
        18.12.2019 09:22

        Да, это практически именно то, что я хотел сказать.


      1. nirom
        18.12.2019 09:46

        «сел и сразу поехал» это принципиальный момент.

        Посчитайте стоимость серверного железа и лицензий на серверное ПО (1С, MS, MS SQL) при нагрузке хотя бы в 100 человек online. Чтобы на типовом решении «сесть и сразу поехать» нужен очень большой бюджет. И становится весьма спорно, а перевешивают ли плюсы минусы.


        1. EvilBeaver Автор
          18.12.2019 09:58
          +1

          Ну серверное железо в любом случае нужно, независимо от стека технологий. Без сервера не заработает. Железо на "100 человек онлайн" нужно весьма скромное. Лицензии да, нужны, но тут какое дело — если надо 100 человек но нет денег на лицензии, значит не нужно 100 человек. Обычно, если решение делается под сотни пользователей — покупаются ключи по 500 и бюджет особо не смущает. А когда нет денег на сотку, то скорее всего, конторка слабовата, хоть и хочет себе "большой" сервер.


          1. nirom
            18.12.2019 13:30

            Если вам продали клиентские лицензии по 500 рублей, вас, я извиняюсь, обманули. Ну и, соответственно, вся дальнейшая математика неверна.

            Железо на «100 человек онлайн» нужно весьма скромное
            Это либо у нас разные представление о скромности, либо вас обманули дважды.


            1. Ta_Da
              18.12.2019 13:34

              «по 500» это не «по 500 рублей», а «комплект лицензий по 500 штук».


              1. nirom
                18.12.2019 13:41

                Ну так и пишите, а то не совсем понятно. Там выгода получается: 3552 руб. против 6300 руб. Так понятнее было бы всем.


            1. stilic
              18.12.2019 13:36

              Железо на «100 человек онлайн» нужно весьма скромное


              Это либо у нас разные представление о скромности, либо вас обманули дважды.


              Зарплата, налоги, офис на 100 человек — это порядка 10 000 000 рублей ежемесячно из расчета средней 50 000 зарплаты на человека.

              И что по сравнению с 10 000 000 рублей ежемесячных трат вы считаете дорогим в вопросе одноразовых трат на покупку сервера?

              Это простому человеку сумма кажется большой.
              А для предприятия со 100 сотрудниками — покупка серверного оборудования вовсе не самая значительная трата в течение года. На фоне то же зарплаты или аренды помещений стоимость сервера теряется.


              1. nirom
                18.12.2019 13:55

                Тут у вас слишком грубые расчеты, смысла нет. Это с одной стороны, а с другой стороны, внедряя типовое решение на более-менее сложном объекте, вы столкнетесь с необходимостью доработок и кастомизации под заказчика, и тут все прелести типового решения как универсального и подходящего всем (как позиционируется), опять же выльются очень серьёзными трудозатратами, а это время и деньги к которым нужно быть готовым.


                1. stilic
                  18.12.2019 14:07

                  Тут у вас слишком грубые расчеты, смысла нет.


                  Затраты в 10 млн. рублей в месяц на 100 сотрудников, на запрату, налоги, офис — даже заниженные.

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


                  Я этими разработками занимаюсь профессионально уже очень много лет.
                  Нет ничего страшного.

                  Главное:

                  По сравнению с 100% разработкой под себя — доработка типового решения это тьфу, копейки. Ну и времени куда как меньше. И результат гарантированее.

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


                  1. nirom
                    18.12.2019 14:16

                    доработка типового решения это тьфу, копейки… Я этими разработками занимаюсь профессионально уже очень много лет.
                    Нет ничего страшного.

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


                    1. stilic
                      18.12.2019 14:46

                      Так что, получается, мы с вами живем на копейки…

                      Разумеется.
                      Бизнес не стал бы платить, если ли бы для него это были действительно существенные деньги.

                      Фокус в том, что «для предприятия копейки, а для человека очень даже дофига».

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


                      Не вижу никакой неразрешимой проблемы.

                      Есть только одна-единственная сложность: всё дело только в том, что за человек занимается принятием решений — где брать типовую, а где пилить своё.

                      Какова квалификация этого конкретного человека и каковы конкретные требования бизнеса.


                  1. nirom
                    18.12.2019 14:32

                    доработка типового решения это тьфу, копейки

                    В корне неверное мнение, покупка коробки — это да, тьфу копейки. Но на этом только все начинается. Я знаю очень много заваленных примеров внедрения решений 1С, тут можно назвать и УТ, и УПП, и ERP, местами даже ЗУП умудряются завалить. Вот в чем проблема.


                    1. stilic
                      18.12.2019 15:03

                      В корне неверное мнение, покупка коробки — это да, тьфу копейки. Но на этом только все начинается. Я знаю очень много заваленных примеров внедрения решений 1С, тут можно назвать и УТ, и УПП, и ERP, местами даже ЗУП умудряются завалить. Вот в чем проблема.


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

                      Утверждаю, что типично — всего лишь очень небольшие изменения вносятся в код. Этого достаточно подавляющему большинству предприятий для начала эксплуатации 1С: Предприятия.

                      Потом, возможно, будут еще доработки. Но для начала эксплуатации множество доработок при внедрении — не типичная ситуация.

                      Не означает, конечно, что описанной вами ситуации нет в принципе. Отчего же — есть. Но нечасто.

                      Я эти ситуации в своей карьере хорошо помню, так как это хорошие деньги мне лично. К сожалению они не типичны, не часты.


        1. stilic
          18.12.2019 09:59
          +1

          Посчитайте стоимость серверного железа и лицензий на серверное ПО (1С, MS, MS SQL) при нагрузке хотя бы в 100 человек online. Чтобы на типовом решении «сесть и сразу поехать» нужен очень большой бюджет. И становится весьма спорно, а перевешивают ли плюсы минусы.


          1) Почему MS-SQL, а не бесплатный PostgreSQL, с которым 1С уже много лет умеет работать?

          2) Давайте посчитаем на 100 человек ежемесячный бюджет. Зарплата + налоги + физические рабочие места. При зарплате в 50 000 рублей в месяц — это около 10 000 000 рублей расходов в месяц. Ежемесячно. Что на этом фоне разовая стоимость внедрения (последующая тех. поддержка уже значительно дешевле чем первичное внедрение)?

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

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

          И становится весьма спорно, а перевешивают ли плюсы минусы.


          Фирму интересуют не столько деньги, сколько сроки. Ибо не успел — и потерял кучу потенциальной прибыли.

          «Сел и поехал» VS «Разрабатывать своё в течение пары лет» (с рисками что не получится, что специалист уйдет)?

          Бизнес уже дал ответ на это.

          Лет 20 назад не пилил своё только ленивый. Сейчас — типично как раз что подавляющее большинство сидит на готовых решениях (в большинстве это 1С: Предприятие).

          Разумеется, не типовые решения имеют место быть. И платят за них хорошо.
          Я как раз этим и занимаюсь — очень не типовой автоматизацией.

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

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


          1. nirom
            18.12.2019 10:06

            Почему MS-SQL, а не бесплатный PostgreSQL, с которым 1С уже много лет умеет работать?

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


            1. EvilBeaver Автор
              18.12.2019 10:08

              Да ладно! Господин Дорошкевич, если вы нас слышите, не могли бы вы набросать зачетных примеров внедрения на постгресах?


              1. nirom
                18.12.2019 10:21

                Сомневаюсь, что он что-то толковое ответит… Франчи обычно работают по принципу — выставил клиенту побольше заоблачных часов и свалил поскорее и подальше, пока тот не опомнился. А разгребать будут совсем другие ребята.
                Если вы думаете, что PostgreSQL — это серебряная пуля, поздравляю, вы молоды и только в начале пути.


                1. EvilBeaver Автор
                  18.12.2019 10:29
                  +1

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


                  1. Miller777
                    18.12.2019 10:57

                    А есть толковые мануалы для людей уровня сисадмина — как тюнить Postgress для 1С? Сталкивались с тем, что на Postgress проблемы с производительностью, переходишь на MS SQL — проблемы уходят.

                    У нас нет опыта тюнинга Postgress, рекомендуем приобретать MS SQL. Клиент приобретает.

                    Возможно, это неправильно, но клиенту надо работать здесь и сейчас, он не будет ждать, пока мы найдем причину тормозов в связке Postgress + 1С, а MS SQL вполне отработан.


                    1. EvilBeaver Автор
                      18.12.2019 11:02

                      Толковые мануалы — мануалы по постгресу и иногда ради любопытства заглядывание в планы запросов. Обычно все решаемо. Запросы очень часто могут работать на разных СУБД с разной скоростью, это норма. Вполне себе бывают запросы, которые ложатся на MS, но работают на PG. Кроме того, для нагруженных 1С существует коммерческая версия PostgresPro, которая по бенчмаркам уделывает коммерческий же MS SQL (но я ее не щупал).


                      он не будет ждать, пока мы найдем причину тормозов в связке Postgress + 1С, а MS SQL вполне отработан.

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


                      1. nirom
                        18.12.2019 19:31

                        Открою вам пару секретов:
                        1) Тюнингом параметров всех проблем производительности не решить. Бенчмарки дело хорошее, но если бы всё было так просто, никто бы и не смотрел в сторону MS SQL.
                        2) Цена коммерческой версии PostgresPro сопоставима с ценой MS SQL, политика лицензирования также похожа (есть варианты на ядра, есть на пользователей). Думаю, очевидно, почему так.


                        1. EvilBeaver Автор
                          18.12.2019 22:29

                          Хм… тюнингом не решить, переписыванием запросов не решить, а чем решить?


                          1. akryukov
                            18.12.2019 23:14

                            В прошлом холиваре один внедренец предлагал сначала реорганизовать бизнес-процесс клиента, а только потом лезть в оптимизацию.


                            1. Ta_Da
                              18.12.2019 23:25

                              В зависимости от степени неадекватности существующих процессов у клиента это может быть и не самый плохой путь.

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

                              P.S. вот пока писал, вспомнил, что на одном из мест работы похожим образом была организована работа фин. отдела, потому что много лет назад обмен между ИС запускали вручну. и пару раз в день («так исторически сложилось»). Меняли процесс в обратную сторону — запустили регулярный автоматический обмен, но так и не нашли понимания у привыкших к старому режиму финансистов, даже просили «вернуть как было».


                              1. Neikist
                                18.12.2019 23:34

                                У того комментатора посыл был в том что если запросы тяжелые или их нужно делать часто — значит нужно менять бизнес процессы чтобы их не было. Всегда. А оптимизировать запросы бессмысленно и неправильно поскольку на его взгляд разрабатывать качественную с технической точки зрения систему дорого и долго. Нужно брать коробку и подгонять бизнес процессы к ней. Если бизнес процессы не укладываются в коробки — значит они неправильны.


                                1. Ta_Da
                                  18.12.2019 23:42

                                  Ну, если заменить «всегда нужно» на «возможно нужно», то мнение имеет право на жизнь.


                                1. EvilBeaver Автор
                                  19.12.2019 09:02

                                  Так делает сап, это их прямо методичка: наши процессы выверены и непогрешимы, если у нас чего то нет — вам это не нужно. Ну а то, что склад называется "завод" это надо просто принять и поверить. С вас $2 млн


                            1. EvilBeaver Автор
                              19.12.2019 08:59

                              Это, кстати часто правильно.


                              1. akryukov
                                19.12.2019 09:42

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


                  1. LeshaLS
                    18.12.2019 11:48

                    Проблема в том, что там не просто тюнинг. Там иногда надо запросы полностью переписывать для быстрого выполнения (у них оптимизиторы по разному работают). А, учитывая, что типовые сплошь на плоском псевдо-SQL, то очень тяжело сделать, чтобы они одновременно эффективно выполнялись на обоих базах. Поэтому видимо в 1С просто тюнингуют их под MS SQL, а на PostgreSQL — как получится. Понятно, что франчам тогда логичнее не связываться с PostgreSQL.


                    1. nirom
                      18.12.2019 12:29

                      Да, согласен с вами.


                    1. mineralkeee
                      19.12.2019 09:47

                      Не забывайте за развивающуюся тематику "импортозамещения". Все госы в ближайшее время уйдут с MS, а это — огромные бабки для 1С. Поэтому взаимодействие типовых решений с PG тоже будет развиваться, нет сомнений


                      1. CrushBy
                        19.12.2019 10:07

                        Сомнений может и нет, но в типовых как будет? Если MSSQL, то такой запрос, а иначе вот такой? Там и так жесть творится, когда строка запроса «собирается» из кучи мест, а будет еще жестче?


            1. ZEEGIN
              18.12.2019 10:13

              Ну прям очень странно так говорить.
              Открываешь справочник внедренных решений, содержащий отчеты от фирм партнеров и смотришь.


              Любому клиенту или внедренцу можно позвонить и спросить действительно ли это так.


              http://1c.ru/rus/partners/solutions/search.jsp?q=&Version=8&workingMode=2&dbServer=2&small=&big=&smallDbConns=&bigDbConns=&smallThinClientConns=&bigThinClientConns=&smallWebClientConns=&bigWebClientConns=&labelgeo_id=&geo_id=&DateSince=&DateTill=&isArchive=1&showParams=0


              1. nirom
                18.12.2019 10:27

                А что тут странного. Приведите пример УТ, ERP, БУ, где 100+ рабочих мест на PostgerSQL. Ну есть ДО 300 рабочих на PostgreSQL 1c.ru/rus/partners/solutions/solution.jsp?SolutionID=968986. Но это документооборот всего лишь. Сравнение вообще ни о чем, не та интенсивность работы, ни тот функционал.


                1. EvilBeaver Автор
                  18.12.2019 10:32

                  Мне известно внедрение в одном федеральном министерстве на 1000+ пользователей на постгрес.


                  1. nirom
                    18.12.2019 10:43

                    Ооо… Слова красивые, но покажите цифры.
                    Что за конфигурация, сколько документов одного вида, какая интенсивность работы док/час. И главное, бюджет…
                    Вы думали, какого-то впечатлили фразой «в одном федеральном министерстве»…


                    1. EvilBeaver Автор
                      18.12.2019 10:47

                      Есть такое слово — коммерческая тайна. Иногда лучше помолчать, уж извините. Не верите — я переживу.


                      1. nirom
                        18.12.2019 11:16

                        Я бы сказал, есть такое красивое слово…


                1. ZEEGIN
                  18.12.2019 10:44

                  Фрешик https://1cfresh.com


    1. Neikist
      18.12.2019 09:26

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


      1. nirom
        18.12.2019 09:52

        Да, БСП следует упомянуть как безусловный плюс. Но и это не решает всех проблем.


        1. Neikist
          18.12.2019 09:54

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


  1. m-rv
    18.12.2019 08:46
    +1

    критики 1С критикуют ее с позиции «не осиливших»
    не очень вяжется с правосудием на картинке, хотя наличие пункта «1С должна умереть» в голосовалке заставляет признать мужество автора )


    1. EvilBeaver Автор
      18.12.2019 09:05

      Т.е. trollface вам ни на что не намекнул?


      1. m-rv
        18.12.2019 09:33

        поскольку он стоит на другой чаше весов — я подумал, что он символизирует тех, кто тролит 1С, а не автора, тролящего тролей 1С )


        1. EvilBeaver Автор
          18.12.2019 10:01

          Там в картинке много смыслов, в том числе и такой, как вы сказали. Еще на картинке не виден момент добавления тролля на чашку. А ну как она резко пойдет вниз? :)


  1. dance000
    18.12.2019 08:51

    Спасибо автору, после такой статьи, можно перестать скрывать что пишешь на русском )


    1. EvilBeaver Автор
      18.12.2019 09:06

      А зачем было скрывать? Даешь каминг-ауты! ))))


      1. dance000
        18.12.2019 09:24
        +1

        Всем добрый день, я Денис и я программирую на 1С с 2007 года
        *Вялые аплодисменты и вздохи сочувствия


      1. m-rv
        18.12.2019 09:34

        угу. т.е. 1Сники, по вашей логике, должны совершить каминг-аут? вы на чьей стороне??? )))


        1. EvilBeaver Автор
          18.12.2019 10:03

          На стороне 1С-ников, безусловно. :) На дворе 2019 год и делать каминг-ауты модно и почетно. Никаких "вздохов сочуствия", только всеобщее одобрение и восторги :trollface:


    1. Neikist
      18.12.2019 09:45

      Если бы проблемой языка была русскоязычность… Автор как раз вполне верно описал минусы языка. Вот без шуток — из современных языков вижу наиболее подходящим для платформы дарт. Многопоточности нет, есть изоляты работающие по модели акторов и встраивающиеся в механизм асинхронности через async/await. Типизация по умолчанию статическая, но есть простенький вывод типов позволяющий меньше кода писать. Причем работает не только для переменных но и для параметров функций. Также есть тип dynamic для совсем маргинальных случаев. Очень удобные методы работы с коллекциями

      например collection if/for вообще до того ни в каких языках не видел
      Dart 2.3 also introduced collection if and collection for, which you can use to build collections using conditionals (if) and repetition (for).

      Here’s an example of using collection if to create a list with three or four items in it:

      var nav = [
      'Home',
      'Furniture',
      'Plants',
      if (promoActive) 'Outlet'
      ];


      Here’s an example of using collection for to manipulate the items of a list before adding them to another list:

      var listOfInts = [1, 2, 3];
      var listOfStrings = [
      '#0',
      for (var i in listOfInts) '#$i'
      ];
      assert(listOfStrings[1] == '#1');


      1. EvilBeaver Автор
        18.12.2019 10:04

        Вот функции первого порядка — однозначно нужны. Насчет лямбд и сложностей с областями видимости замыкаемых переменных — уже не уверен на все 100.


        1. Neikist
          18.12.2019 10:17

          Ну лямбда не обязательно должна контекст замыкать. Часто этого и не нужно. Впрочем и замыкания нередко бывают полезны. В той же java замыкание может только final переменные захватывать, сами понимаете — сложностей тут немного. В котлине вот правда можно любые переменные и свойства захватывать — но как то тоже проблем не возникало.


          1. EvilBeaver Автор
            18.12.2019 10:33

            Ну лямбда по-определению может что-то захватывать. Т.е. если в языке есть лямбды — они должны предоставлять такую возможность, или нельзя заявлять, что в языке есть лямбды.


            1. Neikist
              18.12.2019 10:52
              +1

              Как минимум вики-чан и stackoverflow с вами не согласны.

              wiki
              In computer programming, an anonymous function (function literal, lambda abstraction, or lambda expression) is a function definition that is not bound to an identifier. — условия о замыкании нет.


              1. EvilBeaver Автор
                18.12.2019 10:59

                Я перед каментом почитал википедию: "Применяется как правило для объявления анонимных функций по месту их использования, и обычно допускает замыкание на лексический контекст, в котором это выражение использовано." Это определение совпадает с тем, как я себе понимал отличия собственно лямбда-функций от просто функций, как объектов первого класса. Я, конечно, могу ошибаться, но и в достоверности камента на stackoverflow тоже позволю себе усомниться.


                1. Neikist
                  18.12.2019 11:08

                  Замыкание контекста собственно допускают замыкания, которые могут быть как анонимными функциями (лямбдами) так и неанонимными. Это не неотъемлимое свойство лямбды. Насколько помню всю эту мутную теорию лямбда исчисления (неплохо разбиралось в подкасте «Мысли и методы», пусть поверхностно, но мне глубже и не надо) — там вообще не описывается прикладная реализация, но параметры в записи лямбды там указываются вроде явно, как параметры анонимной функции это все выглядит. Плюс те же анонимные функции в java вполне себе считаются лямбдами хотя не могут захыватывать изменяемые переменные, например.


                  1. EvilBeaver Автор
                    18.12.2019 11:16

                    Окей, тогда я поясню мысль: функции первого порядка в 1С нужны. Замыкания — не уверен.


                    1. Neikist
                      18.12.2019 11:18

                      Анонимные функции нужны тоже. Иначе будет скоуп замусориваться функциями нужными только в одном месте.


                      1. EvilBeaver Автор
                        18.12.2019 11:19

                        Да, нужны. Но нужна ли им возможность захвата внешнего контекста?


                        1. Neikist
                          18.12.2019 11:20

                          В 1с под вопросом. Все таки в массе квалификация разработчиков около нуля и они не факт что осилят. А вообще нужна, имхо)


                          1. gatoazul
                            18.12.2019 14:01

                            Зачем это осиливать? Это как раз естественное поведение, которое разработчик ждет. Если он упоминает внешнюю переменную, то ждет, что именно она и будет в лямбда-функции.


                            1. Neikist
                              18.12.2019 14:06

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


                            1. EvilBeaver Автор
                              18.12.2019 14:12

                              Вам нагуглить классический пример с лямбдой и циклом for по замыкаемой переменной?


                        1. Fragster
                          18.12.2019 11:32

                          ОбработкаОповещения + ДополнительныеПараметры.
                          В php решено конструкцией use, в js — доступностью всего контекста. Или как это правильно написать?


                          1. EvilBeaver Автор
                            18.12.2019 11:32

                            толсто. слишком толсто и больно. ушел плакать


        1. VSOP_juDGe
          20.12.2019 14:11

          Да ну, в 1с (как и в общем случае в обычной бизнес-логике) половина кода — это унылое перекладывание данных в коллекциях в циклах. Лямбды и мапы типа laravel collections сделали бы это занятие гораздо приятнее и веселее.
          Вторая половина — это запросы, и аналог linq to sql тоже очень бы пригодился. Причем 1с вроде бы тоже так думает и даже что-то сделала, но настолько неудобное, что этим никто не пользуется.


  1. stilic
    18.12.2019 09:08

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


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

    Из чего последовало: а почему бы не попиариться за счет хейта такого продукта?
    Ровно то же происходило и с MS, когда положение MS было не поколебимо на рынке ОС. Не пинал MS только ленивый.

    Ну банально: сколько я соберу комментов/лайков под статьёй про какую-нибудь MyCRM (название выдумано)? 1-2-5?
    А стоит написать про 1С, да обкакать покрасивше — так я только для начала заполучу сходу десятки комментариев от тех, кто 1С действительно знает и способен объективно мне возражать. Так и тех, кто не в теме и просто пришёл поесть попкорна понаблюдать за срачем. Гарантировано.


    1. alekciy
      18.12.2019 09:40
      +1

      Если человек хорошо представляет о чем говорит, то почему бы ему про это не написать? Грамотная и годная техническая статья.
      Я вообще за большее количество статей от людей с большим опытом, а не от "двадцатитрехлетних синьеров" пишухих очередную CMS/убийцу_гугла/фрейворк.


      1. stilic
        18.12.2019 09:51

        Если человек хорошо представляет о чем говорит, то почему бы ему про это не написать? Грамотная и годная техническая статья.


        Да, конкретно этот человек — представляет то, о чем он пишет.

        Я про другие статьи.
        Например:

        О сравнении специализированного решения 1С с языками программирования общего назначения.

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

        В этих статьях почему-то не пишется о том, что типовая задача «БД + форма ввода данных» полноценно решается в 1С за 10 секунд (буквально, без преувеличения). Наверное, потому что в языках общего назначения это решается за в десятки раз большее время в самом оптимистичном случае? И хайпа на такой статье не словишь — ведь ты покажешь не плюсы, а минусы языков, на которых пишет большая часть Хабра?


        1. alkresin
          18.12.2019 10:31

          Я про другие статьи.
          Например:

          Можно конкретный пример, со ссылкой на статью?


        1. alekciy
          18.12.2019 11:03

          Я про другие статьи.

          В других возможно. Но тут то мы обсуждаем именно эту статью.


    1. Neikist
      18.12.2019 09:48

      А вы действительно думаете что microsoft не за что ругать что тогда что сейчас? Вы их продукцией не пользуетесь?


      1. stilic
        18.12.2019 10:15

        А вы действительно думаете что microsoft не за что ругать что тогда что сейчас? Вы их продукцией не пользуетесь?


        Бездумная ура-риторика типа «MS говно делает, даешь Linux, он заведомо хорош просто потому что бесплатен и открыт и наплевать на корявый графический интерфейс Linux»? Я про такое.

        Ругают MS только потому что она на верху пищевой цепочки.
        Альтернативы уступают по универсальности Винде, умеют значительно меньше, но при этом все равно содержат огромное количество косяков.

        Только крайне узкоспециализированные, ограниченные решения (типа голой командной строки Linux, без GUI) не конкурируют с Windows по количеству косяков.


        1. Neikist
          18.12.2019 10:20

          Я люблю десятку винду (хотя пишу это сообщение из под manjaro). Но то что кто то по каким то причинам является лидером рынка не повод его не ругать. Линукс выигрывает в одних аспектах, мак в других. Винда что то среднее со своими плюсами и минусами, но ругать ее можно очень много за что и нужно. Как и линкусы с маками. По крайней мере я регулярно все три системы поливаю.


          1. stilic
            18.12.2019 11:07

            Но то что кто то по каким то причинам является лидером рынка не повод его не ругать.


            Вопрос как ругать.
            Вот статья автора вполне себе объективна.

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


  1. Kwisatz
    18.12.2019 09:31

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

    Запросто это делается.

    И еще — если к вам пришел наниматься 1С-ник, то 1С-ника можно смело ставить на должность лида аналитиков.

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

    Кроме того, вы ка кто элегантно обошли тот факт, что 1с использует СУБД как тупую хранилку.
    Забыли упомянуть про фантастический оверхед выборок.
    А как весело 1с обращается с тем же pg, это просто нечто: когда я увидел lock на information_schema да еще с таймаутом в 5 минут, мне хотелось убивать.

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


    1. alekciy
      18.12.2019 09:45

      Запросто это делается.

      Если учесть контекст "(и потом «ой, а почему у нас дырки»)", то задача
      сквозной нумератор сущностей, с разрезом уникальности по некоторому набору ключей, префиксацией, так чтобы это не блокировало базу при параллельном вводе данных.

      становиться сложнее.


      1. Kwisatz
        18.12.2019 10:56

        Берете общий sequence и вперед, как первый вариант.


        1. EvilBeaver Автор
          18.12.2019 11:06

          Окей. Отмасштабируйте решение на 4 движка СУБД и добавьте периодичность нумерации по ключам "Год/месяц/день", "Вид сущности" и возможность указания произвольного префикса в начале генерируемого номера.


          1. Kwisatz
            18.12.2019 11:35

            Про движки ответ у меня простой: любой каприз за ваши деньги. Oracle/MSSQL/PostgreSQL имеют схожий функционал, я думаю разобраться можно.

            create table my_precious_docs(
               id serial,
               doc_number varchar not null,
               doc_year char(4) not null default to_char(current_date, 'YYYY'),
               doc_sum decimal(18,2) not null default 0,
               primary key(id),
               unique(doc_year,doc_number)
            );
            
            create or replace function id_for_year() returns trigger
               language plpgsql AS
            $$
            declare
               seqname text := 'seq_' || new.doc_year;
               prefix char(1) := 'Н'; -- можно и в справочник
            begin
               if seqname is not null then
                  execute 'create sequence if not exists ' || seqname;
                  execute 'select $1||nextval($2)' into new.doc_number using prefix,seqname::regclass;
               end if;
            
               return new;
            end;$$;
            
            
            create trigger id_for_year before insert on my_precious_docs for each row
               execute procedure id_for_year();
            


            1. alekciy
              18.12.2019 12:09

              В соединение1 выполнили insert. Выполнился инкремент sequence. В соединении2 происходил такой же процесс. Они выполнялись транзакционно (допустим на уровне serializable). Соединение1 долго тупило и в итоге получили rollback. Вопросы:
              1) возникла ли при этом блокировка?
              2) возникла ли при это дыра в сквозной нумерации?


              1. Kwisatz
                18.12.2019 12:25

                1. нет
                2. да

                По дырки я ответил ниже.

                Зы serializable не сильно сурово?


                1. alekciy
                  18.12.2019 12:29

                  не сильно сурово?

                  В денежных вопросах не сильно.


          1. mi76554
            19.12.2019 10:58

            >Отмасштабируйте решение на 4 движка СУБД и добавьте периодичность нумерации

            ANSI SQL вам в помощъ.

            Но зачем такое в трезвом уме и памяти?
            Это такое извращенное видение мира одноэсника?
            Делает так, потому что может?


        1. alekciy
          18.12.2019 11:10

          Он не решает задачу «без дырок» в условиях конкурентного доступа и минимизации блокирования.


          1. Kwisatz
            18.12.2019 11:44

            Тогда в примере выше ставим default для doc number а тригер переделываем под after insert


            1. alekciy
              18.12.2019 12:10

              Т.е. когда произошел commit, так?


              1. Kwisatz
                18.12.2019 12:23

                Нуда


            1. ZEEGIN
              18.12.2019 12:16

              Усложним задачу: нужна сквозная нумерация на несколько таблиц, например счета-фактуры и счета-фактуры на аванс — это разные сущности, хранящиеся в разных таблицах с разной структурой данных, которые должны иметь общий нумератор.


              1. ZEEGIN
                18.12.2019 12:20

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


                1. ZEEGIN
                  18.12.2019 12:22

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


                  1. Kwisatz
                    18.12.2019 12:24

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


                    1. EvilBeaver Автор
                      18.12.2019 12:29

                      Имя, сестра, имя даешь статью "как правильно сделать энумератор с заданными условиями". И посмотрим.


                      1. Kwisatz
                        18.12.2019 12:32

                        А что смотреть, тут по моему все ваши случаи описаны. Вы поймите, что заданные условия у всех разные, у меня сейчас структура сложнее и я в первую очередь думаю о том, чтобы не накосячил тот кто полезет в саму структуру БД.

                        Если выдадите списочком условия то вполне можно подумать, даже с плюсами и минусами подходов.


                        1. EvilBeaver Автор
                          18.12.2019 12:37

                          И мы придем к выводу, что я прав насчет "задача сделать энумератор становится не такой простой, как кажется на первый взгляд"


                          1. Kwisatz
                            18.12.2019 12:51

                            Обычная рядовая задача. С моей точки зрения я ее решил 8 коментариев назад.

                            Зы вы кстати этой «отпиской» уклонились от ответа на сотальные доводы)


                            1. EvilBeaver Автор
                              18.12.2019 12:56

                              Наверное решили, я не проверял под нагрузкой. Осталось портировать на синтаксис 3-х других СУБД и вы молодец. А задача автоматически становится не такой уж простой.


                              1. Kwisatz
                                18.12.2019 13:01

                                Под нагрузкой не измениться вообще ничего.

                                Портировал:

                                Oracle: Sequence, Trigger
                                T-SQL: Sequence, Trigger


                            1. funny_falcon
                              20.12.2019 09:09

                              Нет, не решил:


                              • after insert — это не тоже самое, что before commit. Между after insert и commit есть промежуток времени, в который может прилететь rollback.
                              • если используете честный before commit, то не можете в одной транзакции вставить связанные документы. Не знаю, правда, нужно ли это в контексте 1С и подобных систем.


              1. Kwisatz
                18.12.2019 12:22

                Сиквенс вы можете использовать в разных таблицах.
                Второй вариант:

                create table documents(
                document_id serial not null
                )
                
                create table orders(
                order_specific field varchar
                )
                inherits documents
                


                1. funny_falcon
                  20.12.2019 09:10

                  Вот такой serial точно дырки будет иметь т.к. он не before commit.


    1. EvilBeaver Автор
      18.12.2019 10:06

      Прямо-таки запросто? Ну-ка ну-ка? Слабо оформить в виде туториала на Хабре или хотя бы основную идею здесь в каменте пояснить?


      1. Kwisatz
        18.12.2019 11:09

        выше пояснил один из путей


        1. EvilBeaver Автор
          18.12.2019 11:18

          Это отписка, а не путь решения. Вопрос был — сможете ли вы написать более развернутое решение/описание идеи в виде статьи, с возможностью критики сообществом Хабра. Попробуйте и увидите, что sequence не подойдет.


          1. Kwisatz
            18.12.2019 11:43

            В виде статьи точно нет, у меня просто нет времени пока. А решение вон сверху, критикуйте


            1. alekciy
              18.12.2019 12:13

              Ну например я ничего плохого в дырках не вижу

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


            1. o4karek
              18.12.2019 12:23

              Ну например я ничего плохого в дырках не вижу

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


              1. Fragster
                18.12.2019 12:25

                Никогда такого не было. Она должна быть возрастающей. Но про отсутствие пропусков речи не было. Свое положение о нумерации выпускаем и вуаля. У нас так идет: ГГГГММДДННН


              1. alekciy
                18.12.2019 12:33

                Это в каком из законов такое написано?


                1. o4karek
                  18.12.2019 12:35
                  +1

                  Выше уже сказали, что я не прав. Возможно, это наведенное воспоминание.


            1. ZEEGIN
              18.12.2019 12:26

              Ну например я ничего плохого в дырках не вижу
              Зато это хорошо видит налоговая, которая придет в компанию с вопросом, куда делить документы между номерами и почему их нет в декларации!


              1. Kwisatz
                18.12.2019 12:27

                Нет у налоговой такого требования.


            1. alekciy
              18.12.2019 12:27
              +1

              Внесу финальных пять копеек.
              На технарям конечно кажется, что «ну чего страшного, ну дырка и дырка». Но взгляните на это с другой стороны. Бух. отчетность это кипы физической бумаги. И вот наша условная МарьВанна делает сверку листая бумажные доки смотря при этом на нумерацию: "1… 2… 4… Ой, 3 нет… это документ не распечатали? Потеряли? Сейчас поищем...". И начинаются раскопки в недрах учетной системы с целью понят, был ли вообще документ 3. При сквозной последовательной нумерации наличие дырки сразу говорит о том, что документ где-то продолбали без заглядывания в учетную систему.


              1. Kwisatz
                18.12.2019 12:30

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

                ЗЫ Бух отчетность это вовсе не кипы физической бумаги.


    1. stilic
      18.12.2019 10:25

      Я уже более сотни раз ловил на вещах типо привязки обработки пользователей к их расположению в дереве.


      Речь видимо о том, когда группа пользователей (ветка в вашей терминологии), в которую входит пользователь, выполняет конкретные функции? Скажем, стоит поместить пользователя в группу «Бухгалтера» и он автоматически получает доступ к финансовым документам.

      К минусам можно отнести недостаточно гибкую настройку (которая при этом вполне себе может быть реализована дополнительно).

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

      Вывод: вполне разумное решение для небольшого предприятия без выделенного сисадмина.


      1. Kwisatz
        18.12.2019 10:57

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


        1. garageman
          19.12.2019 14:56

          Если есть отдельный справочник, в котором расписано соответствие «папочки» свойствам пользователя — то почему нет? Это нормально и хорошо. Плохо когда оно (имя элемента) действительно захардкожено.


          1. Kwisatz
            19.12.2019 15:25

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


            1. stilic
              19.12.2019 18:07

              и никто не в курсе, потому что документации нету от слова совсем.

              Все денег стоит.

              Хорошее документирование — существенно поднимает стоимость разработки и снижает скорость. А в бизнесе крайне важно «сделать еще вчера».

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

              А иногда и талмуд с документацией (там другая проблема — и как в ней найти нужное в подробнейшей документации).

              Универсального на все случаи идеального варианта решения нет.


              1. Kwisatz
                19.12.2019 18:18

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


                1. stilic
                  19.12.2019 18:41

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


                  Проблема высосана из пальца.

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

                  Ну а то что Вы никогда не косячите, я уже понял.
                  Впрочем, в это не верю.


                  1. Kwisatz
                    19.12.2019 19:20

                    Сделайте галку, создайте справочник, регистр сведений, да что угодно, но делать так — последнее дело.


  1. CrazysAlien
    18.12.2019 09:36

    и? на что 1с в бухгалтерии заменить предлагается?


    1. EvilBeaver Автор
      18.12.2019 10:09

      Вы сейчас кого спрашиваете?


  1. OlehR
    18.12.2019 09:41

    В 1С качественная изоляция прикладного кода от слоя работы с БД. Там нельзя типизировать таблицы на низком уровне и косяки малокомпетентных джуниоров на уровне БД там невозможны.

    Так ето и беда 1С для средних и крупных баз.
    Использование БД как хранилища таблиц, не учитивая возможности БД катие как партиции форенкеи, тригери и тд. Сколько костилей из за етого.
    Работа с БД для меня одина из наиболее слабых сторон в 1С


    1. EvilBeaver Автор
      18.12.2019 10:12

      Партиции-то почему нельзя использовать? Секционирование — сколько угодно. Отсутствие хранимок обусловлено необходимостью поддержки 5 разных движков СУБД (включая файловый), это понятное ограничение, может хорошее, может плохое, но понятное. то же с триггерами. А уж про форейнкеи я вообще помолчу. Только ленивый не говорил, что это довольно спорное изобретение при всех кажущихся плюсах.


      1. alekciy
        18.12.2019 11:17

        FK спорен? Это в каком смысле? Нормальная РСУБД решает вопрос консистентности данных на своем уровне и не приходится тащить эту логику в рантайм приложения. Какие тут могут быть сомнения в полезности данного механизма?


        1. EvilBeaver Автор
          18.12.2019 11:20

          Лень искать критику FK, думаю вы сможете ее найти. Общий смысл — FK нужны там где они нужны, а не просто "везде, где есть связи".


          1. alekciy
            18.12.2019 11:24

            Ну тогда оно ни сколько не спорное при использовании там, где они нужны.


            1. EvilBeaver Автор
              18.12.2019 11:27

              Ну вот в кейсах применения 1С — не нужны. Вернее не так, минусы от их использования перевешивают плюсы.


              1. OlehR
                18.12.2019 11:32

                И какие минуса (отсуствие битих ссилок)?
                А с партиции 1с не поддерживает, ви их создаете на уровне БД, что кстати запрещено лицензионним соглашением. Ну и они чудно пропадут при перестроении.


                1. EvilBeaver Автор
                  18.12.2019 11:38

                  У вас кнопка ы поломалась )
                  Минусы, если не ошибаюсь, были описаны в одной из статей Сергея Нуралиева о том, почему в 1С нет FK. Эти доводы весьма объективны, можно поискать статью.


                  А так — да, иногда битые ссылки это не плохо, а наоборот — хорошо. Вопрос компромисса между бизнес-кейсами и минимально-достаточной непротиворечивости данных. Еще можно вспомнить такие вещи, как шардинг, например. Это не в 1С, но в таких системах FK тоже часто лишний груз.


                  1. OlehR
                    18.12.2019 12:32

                    Вот и главное. Для меня даные в БД должны быть достоверными, а не с формолировкой

                    минимально-достаточной непротиворечивости данных
                    . Да и выбор в етом 1С мне не дал.
                    По поводу FK — они берут на себе огромную часть БЛ. Имеют оверхед в виде необходимости индексов.
                    Ну и поверхносное гугление статью не дало.
                    Ну а поддержка многих баз — ето лиш говорит о том что 1С нормально не поддерживае ни одну.
                    А и да «ы» у меня нет. пользуюсь буфером обмена :)


                    1. EvilBeaver Автор
                      18.12.2019 12:39

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


                      1. Kwisatz
                        18.12.2019 16:21
                        -1

                        Вы бы не могли, для разнообразия, отвечать по существу?


                        1. balexa
                          19.12.2019 11:16

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

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


                          1. Kwisatz
                            19.12.2019 11:20

                            Все равно что человек заявляет, я бы с удовольствием услышал другую точку зрения. Вы говорите FK не нужны? ок, можно аргументы? Без посылов в гугл

                            Про партиционирование сейчас из каждого утюга, но по сути 99% фирм оно нафиг не сдалось.


                            1. stilic
                              19.12.2019 18:15

                              Вы говорите FK не нужны? ок, можно аргументы?


                              Да запросто.

                              С голыми FK не столь гибко получается.

                              В 1С есть несколько способов перехвата записи/удаления объекта — выбирай удобный.

                              Там можно куда как более извращенную бизнес-логику реализовать. Что полезно при этом: в момент этой проверки вы имеет доступ ко всей прикладной сути.

                              В терминах СУБД этот функционал называется trigger.

                              P.S.:
                              В каком-то виде FK в 1С имеются, кстати.

                              Не скажу на уровне СУБД или на уровне движка платформы — не проверял/или проверял давно и не помню.

                              Но вы далеко не во всех случаях можете удалить объект из БД, если он где-то еще используется.

                              Другой довод против FK — зависимость от той или иной нормализации. А нормализация влияет на производительность и на удобство. То есть опять таки малая гибкость. Чтобы сделать FK нам нужно заточиться на определенную структуру.

                              Что вступает в противоречие с концепциями 1С: быстрая разработка, удобство, оперативные изменения под постоянно изменяющиеся бизнес-процессы.

                              Когда вы делаете отдельную таблицу только, чтобы включить FK, а для иного дела таблица и не нужна — это не гуд.

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


                              1. Kwisatz
                                19.12.2019 18:24

                                С голыми FK не столь гибко получается.

                                Не столь гибко что? Неконсистентные записи создавать? Ну это да, бедаа…

                                В терминах СУБД этот функционал называется trigger.

                                всю жизнь мечтал осуществлять контроль целостности ручками)

                                Не скажу на уровне СУБД или на уровне движка платформы

                                На уровне движка, с бд 1с обращается как с тупой хранилкой.


                                1. stilic
                                  19.12.2019 18:43

                                  всю жизнь мечтал осуществлять контроль целостности ручками)


                                  Видимо, вы только начинаете карьеру и еще не сталкивались с сколько нибудь сложными бизнес-процессами, когда без этого никуда.

                                  На уровне движка, с бд 1с обращается как с тупой хранилкой.


                                  И это правильно.
                                  Позволяет реализовать крайне гибкие бизнес-процессы, которые контролировать одними только средствами СУБД или невозможно или гораздо более трудоемко.


                                  1. Kwisatz
                                    19.12.2019 19:28

                                    Видимо, вы только начинаете карьеру и еще не сталкивались

                                    Если вы архитектуреные споры переводите на личности то вам пора заканчивать с карьерой.

                                    с сколько нибудь сложными бизнес-процессами, когда без этого никуда.

                                    Пример в студию.

                                    когда без этого никуда

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


                                    1. stilic
                                      19.12.2019 19:33

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

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

                                      Пример в студию.

                                      Вы и сами привели такой пример:

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


                                      Вот именно поэтому это и плохое решение.
                                      Вариант предлагаемый 1С гораздо удобнее в модернизации при отличной гибкости.

                                      даже тронуть страшно

                                      Ага. Сложность на голых FK разрастается крайне радикальными темпами.


                                      1. Kwisatz
                                        19.12.2019 19:39

                                        Поглядите код модулей регистров в 1С в типовых,

                                        точнее, каких? там все примитивно.

                                        Вот именно поэтому это и плохое решение.

                                        Это как раз ручные проверки целостности данных.

                                        Ага. Сложность на голых FK разрастается крайне радикальными темпами.

                                        Что такое голых? А есть одетые? И с чего бы вдруг им разрастаться? Ну конкретно, пример, один.


                                        1. stilic
                                          19.12.2019 19:55

                                          точнее, каких? там все примитивно.

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

                                          Поглядите те из них, где бизнес-логика посложнее, где кода побольше.


                                          1. Kwisatz
                                            19.12.2019 19:58

                                            «Там есть сложные штуки, но где — не скажу», классный разговор.


                                        1. stilic
                                          19.12.2019 20:02

                                          Что такое голых? А есть одетые? И с чего бы вдруг им разрастаться?


                                          «Одетые» — это те, что аналоги решения 1С, trigger, где можно куда как больше фантазии реализовать.

                                          «Голые» — это только foreign key

                                          И с чего бы вдруг им разрастаться?

                                          Вы же сами написали:
                                          обмазано все сверху донизу в таком объеме, что даже тронуть страшно, а нужно.

                                          Вам виднее, где это.

                                          Это как раз ручные проверки целостности данных.

                                          Ну конкретно, пример, один.

                                          Я уже дал вам отсылку — см. модули регистров. Возьмите тот, что побольше.

                                          И представьте что вы это реализуется только через FK.

                                          «Там есть сложные штуки, но где — не скажу», классный разговор.


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

                                          Если есть доступ к типовой конфурации — просто поглядите.

                                          Если вы действительно понимаете о чем речь — там и искать ничего не нужно.

                                          Сразу заходите в модули регистров и просто смотрите.


                                          1. Kwisatz
                                            19.12.2019 20:13

                                            Я уже дал вам отсылку — см. модули регистров. Возьмите тот, что побольше.

                                            Офигенная ссылка, может в ленинскую библиотеку сразу?

                                            И представьте что вы это реализуется только через FK.

                                            Делал

                                            Если у вас нет доступа к конфигурации 1С

                                            Во первых есть во вторых я итак помню половину ее структуры.

                                            Сразу заходите в модули регистров и просто смотрите.

                                            Смотрю, не вижу ничего сверхъестественного.


                                            1. stilic
                                              19.12.2019 20:24

                                              Офигенная ссылка, может в ленинскую библиотеку сразу?


                                              Для того, что понимает тот аспект, что мы тут с вами обсуждаем — ссылка вполне конкретная.

                                              Модуль именно что регистра.
                                              В типовой конфигурации.
                                              Той что у вас под рукой.

                                              Это вполне конкретное место.
                                              И представьте что вы это реализуется только через FK.

                                              Делал

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

                                              Так вот в варианте предлагаемом 1С — не страшно.
                                              Даже с вычурной бизнес-логикой.

                                              Смотрю, не вижу ничего сверхъестественного.

                                              Именно!
                                              Потому что в варианте предлагаемом 1С это выглядит удобно для программиста.

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


                                              1. Kwisatz
                                                19.12.2019 20:48

                                                Для того, что понимает тот аспект, что мы тут с вами обсуждаем — ссылка вполне конкретная.

                                                Нет не конкретная, потому что регистры — примитивные структуры данных.

                                                И представьте что вы это реализуется только через FK.

                                                И ничего страшного. Аргументов от вас как небыло так и нет

                                                И вы сами прокомментировали ситуацию так:

                                                Этот коммент относился к контролю целостности в ручном режиме, и выше это уже указано, дважды.

                                                Даже с вычурной бизнес-логикой.

                                                Пример «вычурной» бизнес логики я тоже так и не увижу?

                                                Конечно. Потому что в варианте предлагаемом 1С это выглядит удобно для программиста.

                                                А в каком варианте это неудобно? Когда база контролирует это дело? Вы как видите внешние ключи сразу потом обливаться начинаете?

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


                    1. speshuric
                      19.12.2019 00:00

                      Распределённые базы попроектируйте. Как раз до этого момента многие в FK верят. :)


                1. Fragster
                  18.12.2019 11:44

                  Например при распределенной БД (мега фича 1с, которой нигде больше не видел) можно сделать узел на складе, в который будут прилетать только складские ордера, и вместо документов оснований для них — будут битые ссылки. При этом сама база узла будет работать на десктопного уровня компьютере и размером быть в единицы процентов от основной. Вообще эта технология позволяет вместо одного сервера на 2000+ сотрудников по стране сделать 10-100 серверов по филиалам и суммарно нехило сэкономить на железе. Да и в надежности тоже. Те же каналы связи в каком-нибудь Сыктывкаре часто оставляют желать лучшего. А в случае поломке на месте можно пустить (временно) в базу на уровень выше по иерархии и отпочковать клон нужного узла после починки сервера на месте.


                  1. CrushBy
                    18.12.2019 16:42

                    В надежности? То есть когда у вас в Сыктывкаре навернется сервер, то кто его там поднимать будет? Кто свежие данные оттуда на резервные перенесет?
                    Сейчас основной тренд на облака, а Вы — про распределенки…


                1. fleshold
                  19.12.2019 05:16

                  Я не Сергей Нуралиев, и не видел его статью. Поэтому скажу две вещи, из жизни так сказать.
                  1. Foreign Keys имеют цену.
                  2. «Так» делали и 25 лет назад. Так — это когда пользователю предоставлена закрытая система, то есть он не может залезть прямо в таблицы данных и что то ручками поправить, за всё что касается ссылок отвечает приложение. Любой, кто хотя б прочитал книжку «СУБД для чайников» или «SQL для чайников» найдёт по меньшей мере 4 довода, что это ну очень плохая практика. Но это было, и… есть. Не ошибусь если скажу что большинство стартапчиков (ну например, какой нибудь Инстаграм) использовали в проекте на старте нормализованную СУБД с FK и прочими правильными вещами. Всё по книжкам, всё как учили преподы в универах. Но как только мощностей того условного ноутбука, на котором был запущен проект не хватало, сразу же и избавлялись от узких мест типа FK. Кто позже, кто раньше. Потому что см. п. 1.


                  1. Kwisatz
                    19.12.2019 11:23

                    1. Вы про индексы?
                    2. Тогда нужно продолжать мысль. И запилили свой контроль целостности и добавили к нему «проверку структуры дб», «исправление структуры бд» или просто на консистентность данных им плевать.

                    1с отказывается от контроля целостности не изза «цены». Ключи являются ценой использования их абстракции.


  1. alekciy
    18.12.2019 09:46

    А кто по вашему претендует на место №2 или является таковым?


  1. andrew_zola
    18.12.2019 10:14

    Тремя руками голосую за ту часть, которая касается развития языка (то что надо и что не надо). Умри Денис, лучше не предложишь!


    1. EvilBeaver Автор
      18.12.2019 10:14

      Кто такой Денис, позвольте спросить?



      1. andrew_zola
        18.12.2019 10:37

        случайно продублировал


  1. CrushBy
    18.12.2019 10:22

    А можно более подробно, что плохого в ООП в бизнес-приложениях?

    Например, вот логика. Есть класс Контрагент. Документы вроде Счет должны ссылаться на Контрагент. От него наследуется Физическое лицо и Организация. У первого есть свойства Имя, Отчество и Фамилия, а у Организация — Форма собственности, ИНН, ОКПО и т.д.

    Альтернатива этому без ООП — просто закинуть все свойства в Контрагент и показывать и использовать их в зависимости от какого-то boolean (или типа). Но это тоже самое, что говорить, что зачем нужен полиморфизм, если все можно сделать на if'ах.


    1. Neikist
      18.12.2019 10:27

      Почему если говорят про ооп в бизнес приложениях так любят бизнес домен вспоминать? Причем почему то обязательно про наследование. ООП оно же чисто для служебного кода основные плюшки дает. DI, композиция объектов с поведением, повышенное удобство переиспользования и прочее. И вот для бизнес логики его не хватает. А бизнес сущности — уж фиг с ними, раз так большинство желает.


    1. ZEEGIN
      18.12.2019 10:37

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


      В каких случаях для какого решения надо от каких классов базовых наследоваться можно почитать в стандарте:
      https://its.1c.ru/db/v8std#content:683:hdoc


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


      1. CrushBy
        18.12.2019 10:39

        Организация, Контрагент и ФищЛицо это классы унаследованные от базового класса Справочник


        Вы не поняли логики. ФизЛицо наследуется от Контрагент, так как ФизЛицо является Контрагентом, также как и Организация. Это не 3 разных сущности.


        1. EvilBeaver Автор
          18.12.2019 10:42

          Такое наследование потом в базу складывать — то еще удовольствие. И всякие костыли в ORM-фреймворках типа EF, которые авторы усложняют и закостыливают ради обеспечения гибкого наследования в языке. 1С же наоборот — отказалась от наследования ради снижения сложности и повышения адекватности ORM.


          1. CrushBy
            18.12.2019 10:46

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

            И всякие костыли в ORM-фреймворках типа EF

            Все зависит от конкретной платформы. Где-то наследование может быть сделано костылями, а где-то — нет.


            1. EvilBeaver Автор
              18.12.2019 10:51

              Я хорошо знаю Entity Framework. Там это костыли. Но я сильно, очень сильно сомневаюсь, что ближайший конкурент hibernate сделал как-то иначе и лучше.


              Разработчику должно быть все равно какие запросы при этом генерируются

              это прекрасно. Да, разработчику, как правило и все равно. А потом сервера ложатся под нагрузкой. И EF-Core генерирует гораздо более говенные запросы, чем тот же 1С. И да, что в 1С, что в .NET рядовой разработчик даже не задумывается над тем, что пойдет в СУБД.


              Однако, мой опыт (безусловно субъективный) показывает, что 1С-ники гораздо сильнее заморачиваются с оптимизацией запросов, чем их коллеги из мира .net


              1. CrushBy
                18.12.2019 11:05

                Если в EF сделали плохую оптимизацию запросов, то это не значит, что во всех платформах и ORM кривые запросы. А в том же 1С автоматически даже не делается JPPD, и его надо делать вручную 1С-разработчику.


                1. EvilBeaver Автор
                  18.12.2019 11:07

                  Я не говорил, что во всех плохо. Расскажите, в какой это делается хорошо?


                  1. CrushBy
                    18.12.2019 11:12

                    В lsFusion, например, мы очень много времени и сил потратили на то, чтобы оптимизировать все запросы под выполнение их СУБД (пока только в PostgreSQL). Автоматическая поддержка JPPD — это самая простая из оптимизаций.


                    1. EvilBeaver Автор
                      18.12.2019 11:22

                      lsFusion это не ORM общего назначения, уж простите. Допускаю, что там что-то оптимизировано, но, без обид, я смотрел вашу демку. Впечатляет ровно никак. Я буду рад, если у вас получится, конкуренция это хорошо, это путь к развитию.


                      1. CrushBy
                        18.12.2019 11:36

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

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


                    1. ZEEGIN
                      18.12.2019 12:13

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


                      1. Fragster
                        18.12.2019 12:17

                        Это вы ультиму erp пропустили.


                        1. Ta_Da
                          18.12.2019 12:43

                          Да ладно, отличная ж была система. Жаль не сохранились статьи про «слабосильные 1С и SAP» — согревали кресло холодными зимними вечерами.
                          Но зато на их новом сайте diaspar.business можно в буллшит-бинго играть, например.


                          1. KReal
                            19.12.2019 20:28

                            you made my day! вот это пафос!


                      1. EvilBeaver Автор
                        18.12.2019 12:27

                        Лично у меня встреча в тексте lsFusion ассоциируется с тем, что скоро будет вброс какой-то ненужной бесполезной хрени.

                        И как правило, так и происходит, бгггг


                      1. CrushBy
                        18.12.2019 12:37
                        -1

                        Понимаете, нужно/не нужно — относительное понятие. Если Вы считаете, что ООП в бизнес-приложениях не нужно, то это Ваше право. Но у других людей может быть другая точка зрения.


                      1. Ta_Da
                        18.12.2019 12:41

                        Я бы сказал не «негатив к продукту», а «негатив к команде».


        1. Fragster
          18.12.2019 10:51

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


          1. EvilBeaver Автор
            18.12.2019 10:53

            Депенденси инжекшен (офигеть, как сложно это написать кириллицей) — это когда ты вместо базы данных втыкаешь "Новый Массив" и делаешь перебор не таблицы, а этого массива, чтобы потестировать свой модуль. Вот это инжекшен. А составные типы — не про то.


            1. Fragster
              18.12.2019 10:55

              Ну ладно, пусть будет «композиция вместо наследования». Писалось именно ради

              офигеть, как сложно это написать кириллицей
              мы ж про 1с говорим :)


        1. ZEEGIN
          18.12.2019 10:52

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


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


          То, что вы имеете ввиду: определение типа контрагента решается добавлением реквизита перечисления: ЮрЛицо, ФизЛицо, ИП, НеРезидент. С точки зрения бизнеса людей пришедших брать за нал надо отделять от тех, кто имеет ИП и ставит подпись с печатью. Так же как не резиденты юридические оформляют сделки иначе чем простые ооошки.


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


          1. EvilBeaver Автор
            18.12.2019 10:55

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


  1. bolonov
    18.12.2019 10:33

    Очень дельный дельный разбор. Спасибо большое


  1. CrushBy
    18.12.2019 10:37

    Идентификаторы записей в БД. 1С приняла волевое решение — все идентификаторы ссылок абсолютно синтетические и всё тут. И нет проблем с распределенными базами и обменами.


    Производительность и место таблиц и индексов. Разве нет?
    Одно дело, когда ключами являются LONG (как в lsFusion), другое дело, когда, например, 32-байтные строки. Понятно, что JOIN'ы по LONG'ам будут гораздо быстрее и потреблять меньше памяти, чем по 32-байтной строке.


    1. EvilBeaver Автор
      18.12.2019 10:45

      стоп-стоп, чейта UUID вдруг стал 32-БАЙТНОЙ строкой? В LsFusion, раз уж вы упомянули, авторы заранее заложили сложность создания распределенных баз данных и обменов между системами. Да, памяти меньше. Если критерием оптимизации является память — long хорошее решение. Если критерием оптимизации является стоимость реализации бизнес-кейса — long ужасное решение.


      Если ваше решение доживет до необходимости запуска распределенных обменов на нем — вас ждет сюрприз.


      1. CrushBy
        18.12.2019 10:53

        Я же написал: «например». Преимущества long, что это тип, который нативный для процессора и лучше всего обрабатывается на низком уровне. Понятно, что UUID занимает всего в 2 раза больше, но архитектура процессора 64-битная пока-что.

        Если ваше решение доживет до необходимости запуска распределенных обменов на нем — вас ждет сюрприз.

        В современном мире необходимости распределенных баз уже значительно меньше. У нас есть клиент на 570 магазинов в деревнях и селах и даже там, нет проблема с интернетом. Но, в целом, сделать UUID вместо LONG — достаточно несложно.


        1. Kwisatz
          18.12.2019 16:26

          1с идентификаторы это не UUID это поля типа bytea, где в hex живет одинэсовский айди с перестановками.


          1. CrushBy
            18.12.2019 16:43

            А сколько он занимает? И получается, что в запросах идет JOIN по bytea?


            1. anko__2000
              18.12.2019 17:13

              [_IDRRef] [binary](16)


            1. Kwisatz
              18.12.2019 17:20

              4 байта плюс 32 шестнадцатеричных символа. Два шестнадцатеричных символа на байт, итого 20 (наврал вначале, забыл что там два на байт)
              Да джоин идет по нему, плюс ко многим ключам есть еще 2 поля с указанием на тип таблицы и ее id.


              1. EvilBeaver Автор
                18.12.2019 17:25

                Это вы как так лихо посчитали?


                1. CrushBy
                  18.12.2019 17:31

                  Мне вот тоже интересно, и я засомневался. Но это же несложно проверить — достаточно посмотреть в SQL Server Management Studio. У меня просто нет инсталляции 1С под рукой. А Вы можете глянуть?

                  binary(16) должно быть 16 байт, а не 36.


                  1. Kwisatz
                    18.12.2019 17:33

                    Тфу е мое, конечно 20. Думаю одно, руки пишут другое)


                1. Kwisatz
                  18.12.2019 17:32
                  -1

                  upd понял, поправил


              1. CrushBy
                18.12.2019 17:29

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


                1. Kwisatz
                  18.12.2019 17:37

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


                  1. Kwisatz
                    19.12.2019 11:26

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


    1. speshuric
      19.12.2019 00:11

      Разница в производительности на выборках и джойнах ключа 8 байт (long) и 16-байтного binary настолько мала на общем фоне, что это точно можно не учитывать. Так-то посмотреть и строки в однобайтных кодировках меньше занимают. И binary collation быстрее. И тот же RCSI гораздо дороже для отдельных запросов, но его точно надо включать в MS SQL.


  1. alkresin
    18.12.2019 10:38

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

    Можно хотя бы пару ссылок для примера?


    1. CrushBy
      18.12.2019 10:40

      Вот, например, статья от открытой и бесплатной альтернативы: Почему не 1С


      1. alkresin
        18.12.2019 10:58

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


        1. CrushBy
          18.12.2019 11:08

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


  1. a1ex322
    18.12.2019 10:38
    +1

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


  1. Fragster
    18.12.2019 10:53

    Зачем вообще finally? Если посмотреть на поток выполнения программы, от него ни жарко ни холодно (особенно когда нет типа перехватываемого исключения):

    Скрытый текст
    image


    1. lair
      18.12.2019 11:11

      Изначально — для контроля ресурсов. Потом там много интересного навертели, особенно в части логирования и трассировки.


    1. EvilBeaver Автор
      18.12.2019 11:23

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


      1. Fragster
        18.12.2019 11:36

        И чем это отличается освобождением ресурсов после КонецПопытки? А уж сколько шишек набито из-за ТранзакцияАктивна — не пересчитать. Больше, наверное, только с НПП в преставлениях чисел.


        1. EvilBeaver Автор
          18.12.2019 11:43

          Тем, что за "КонецПопытки" в случае исключения не всегда надо заходить. А коли так — то надо писать освобождение ресурсов 2 раза — внутри Попытки и внутри Исключения. Странно, что вы до сих пор с этим не столкнулись, будучи 1С-ником.


          <troll-mode>возможно вы не паритесь из-за не освобожденных ресурсов</troll-mode>


          1. Fragster
            18.12.2019 11:46

            А зачем за него не заходить? Пишите освобождение ресурсов один раз — после КонецПопытки и с высокой долей вероятности в него попадете. См. картинку в исходном комментарии.


            1. EvilBeaver Автор
              18.12.2019 11:53

              Хм… мне сложно это прокомментировать. Вы точно программист?


              1. Fragster
                18.12.2019 12:23

                Я просто не пойму чем принципиально отличаются картинки в исходном комментарии, учитывая, что в любой квадратик можно закинуть любое количество строк кода. Мы же про логический (да и не только) поток выполнения программы говорим. Если картинка с finally должна быть другой, то нарисуйте (почему на вы? столько раз общались на ISevent и та ты) нужную. Быстро можно прям онлайн plantuml.com, исходный вариант моей картинки:

                Скрытый текст
                @startuml

                start

                :Программа;
                if (Попытка) then (Исключение)
                :Обработка исключения;
                endif
                :Программа;

                stop

                start

                :Программа;
                if (Попытка) then (Исключение)
                :Обработка исключения;
                endif
                :Finally;
                :Программа;

                stop

                @enduml


                1. retran
                  18.12.2019 13:23

                  Что будет если «Обработка исключения» тоже бросит исключение? А что делать если я в «Обработка исключения» просто хочу залоггировать исключение и пробросить его выше по стеку?


                  1. Fragster
                    18.12.2019 13:32
                    -1

                    >Что будет если «Обработка исключения» тоже бросит исключение?
                    будет необработанное исключение
                    >А что делать если я в «Обработка исключения» просто хочу залоггировать исключение и пробросить его выше по стеку?
                    в Исключение надо залогировать ошибку и вызвать оператор ВызватьИсключение. Если без параметров — то прокинется исходное исключение, если с параметром — то будет исключение с текстом, который мы передадим.
                    Это не относится к обсуждению, нужен ли finally в 1с и вообще. Это относится к языку 1с.


                    1. retran
                      18.12.2019 14:27

                      будет необработанное исключение

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

                      в Исключение надо залогировать ошибку и вызвать оператор ВызватьИсключение. Если без параметров — то прокинется исходное исключение, если с параметром — то будет исключение с текстом, который мы передадим.


                      И если я например хочу освободить какую-нибудь блокировку при выходе из функции, то мне надо это освобождение написать в нескольких местах и следить за тем, чтобы случайно ее не забыть?


                      1. Fragster
                        18.12.2019 14:49

                        Ну тут можно долго спорить. В 1с, например, есть вложенные попытки исключения. Да и вообще обойти без finally практически любой случай можно (а то продолжая вопросы можно задать вопрос: а если в finally будет исключение, то что...). Отсутствие finally меня беспокоит намного меньше отсутствия async/await или хотя бы анонимных функций.


        1. lair
          18.12.2019 11:59
          +2

          И чем это отличается освобождением ресурсов после КонецПопытки?

          Тем, что мы хотим вернуть результат сразу, как мы его получили.


          var q = new SomeResource()
          try
            return q.Process()
          finally
            q.Dispose()

          (да, я знаю, что using читаемее, но внутри using тот же finally)


          1. Fragster
            18.12.2019 12:24

            А после получения результата вам не надо освобождать ресурсы?


            1. lair
              18.12.2019 12:24
              +1

              Так они и освобождаются. В finally.


              1. Fragster
                18.12.2019 12:26
                -2

                Разрыв потока выполнения похож на goto, вы не находите? Лично я так не делаю (по этой причине). А скрыть ненужные куски кода помогает code folding в IDE или вынос в отдельный метод.


                1. lair
                  18.12.2019 12:27
                  +1

                  Нет, не нахожу.


  1. CryptoTyan
    18.12.2019 11:12

    1С с Oracle не складывается. совсем, никак, вообще. Бились-бились, и оставили эхпорт XML через api-сервисы с одной и другой стороны. Иначе, увы, никак это не сложить.
    Костыли, но работают.
    Мне в 1С не нравится только то, что она заточена исключительно под СНГ, если у вас бизнес с замашкой на международный, то 1С тут не подходит. Ну и мои личные заморочки, так как в предыдущей компании все бизнес процессы были построены вокруг самописной SQL DB? и webapp вокруг нее. А с 1С я как бизнес-аналитик столкнулась не так давно и после простой самописной SQL+JAVA + C# — 1C сервер это гребаный черный ящик, в который и заглянуть то страшно, хотя бизнес-процессы ни разу не сложнее.
    Грамотный 1С разработчик может из коробки сваять что угодно, от CRM до полноценного бекэнда web app с фин-потоками через него. но хороших разрабов в этой сфере мало, на питоне процент хороших разработчиков повыше будет.


    1. EvilBeaver Автор
      18.12.2019 11:15

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

      Если вы про фреймворк "1С:Enterprise", то при чем тут какая-либо страна? Это же база данных+сервер+набор классов для складывания денежных сумм. Что хочешь, то и пиши. Конкретные приложения, написанные на этом фреймворке, с бизнес-логикой под СНГ — да, они для СНГ, но это же конкретные приложения, а не платформа. Их так писали специально.


      Вот приложение не для СНГ, но на 1С, например: https://www.accountingsuite.com/


    1. bolonov
      18.12.2019 11:21

      >А с 1С я как бизнес-аналитик столкнулась не так давно и после простой самописной SQL+JAVA + C#

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


      1. CryptoTyan
        18.12.2019 15:50

        перестроиться с голых баз, где вся архитектура простая, самописная и изучена вдоль и поперек на коробочную 1С не очень просто. Хотя аналогии с фреймворками шикарны.
        В работе столкнулась с кейсами, что WS на 1С делают невозможной обновление конфигурации. Тут или WS и интеграция с голыми базами, или костыли из регламентыных заданий зато с возможность обновления продуктов. Для Бух и Зуп возможность быстрого обновления особенно важна.


    1. o4karek
      18.12.2019 11:22

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

      А вы говорите про а) какую-то конфигурацию или б) платформу без конфигурации?
      Если б) — можете немного развернуть тезис? Почему не подходит?


      1. CryptoTyan
        18.12.2019 15:42

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


        1. EvilBeaver Автор
          18.12.2019 15:49

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


          1. Neikist
            18.12.2019 15:51

            В смысле не лицензируются? А как же СЛК? Да и вообще что то не помню я конфигураций для которых лицензии не нужны.


            1. EvilBeaver Автор
              18.12.2019 15:53

              СЛК это левая херня, по-моему deprecated давно. Хотя допускаю, что региональная конфа для Израиля могла быть и с отдельным ключом, встроенным разработчиками. Но это вопрос к авторам приложения, а не к платформе.


              1. Neikist
                18.12.2019 15:54

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


            1. o4karek
              18.12.2019 15:53

              СЛК к типовым конфам от 1С — не применяется. СЛК — это партнерские конфигурации (включая совместные и т.д.).


              1. Neikist
                18.12.2019 15:55

                Уточнения про партнерские не было. Да и тем не менее лицензии нужно покупать что на партнерские что на от 1с конфигурации.


                1. o4karek
                  18.12.2019 16:03

                  Лицензии нужно покупать не на конфигурации, а на платформу.
                  Лицензирование очень простое:
                  1. лицензия на сервер (по количеству серверов)
                  2. лицензии на пользователей (по количеству одновременных пользователей)
                  [3. лицензии на конфигурации — СЛК и аналоги]
                  Другими словами, если вы используете ERP на 64-разрядном сервере, и в этой конфе работает 1050 пользователей, то вам надо купить:
                  1. 1 лицензию на 64-разрядный сервер
                  2. 1050 платформенных клиентских лицензий
                  Больше ничего.
                  Если используется партнерская конфигурация, там может потребоваться(!) купить еще сколько-то лицензий на саму конфигурацию, которые (конфигурации) тоже лицензируются по рабочим местам.
                  Платформенные лицензии, действительно, не зависят от того, что используется: хоть полностью собственная конфигурация, хоть полностью типовая.


                  1. EvilBeaver Автор
                    18.12.2019 16:05

                    N лицензий на сервер, если кластер отказоустойчивый, по-моему


                    1. o4karek
                      18.12.2019 16:09

                      Да, поэтому я и написал:

                      лицензия на сервер (по количеству серверов)
                      .


                  1. Neikist
                    18.12.2019 16:09

                    А вот на этой страничке ни цены ли на лицензии конфигураций указаны? В т.ч. и от 1с.


                    1. o4karek
                      18.12.2019 16:32

                      Нет, там комплекты с клиентскими лицензиями для платформы.
                      Т.е. сама по себе конфигурация денег стоит, но к ней пользовательских лицензий нет.
                      ЗЫ: Если я непонятно излагаю — лучше сразу спросите, что непонятно :)


                      1. Neikist
                        18.12.2019 16:38

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


    1. CrushBy
      18.12.2019 11:37

      если у вас бизнес с замашкой на международный, то 1С тут не подходит


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


      1. EvilBeaver Автор
        18.12.2019 11:44

        Интересно, как эти 2 истории у вас коррелируют? После истории с Касперским — возможно, но после nginx-то почему?


        1. bolonov
          18.12.2019 11:57
          +1

          Потому что в РФ государству (в широком смысле) очень легко разушить бизнес. Нет нормальных сдержек (независимый суд, политическая конкуренция, институт репутации, наконец), как в странах наших западных партнеров.
          Ситуация с ngnix модельная — захотелось кому-то прессануть коммерсов от ИТ в надежде отжать баблишка, например — наслали маскишоу с автоматами с обыском домой. Почему — а потому, что ничего серьезного в случае даже если дело не взлетит силовикам не будет. Это ж не Запад какой-нибудь, где б если такая история произошла, то было бы всестороннее рассмотрение дела — кто заказывал, кто принимал решение автоматчиков домой к программисту приводить, со встречными исками, с послед-ми потерями постов высоких чинов. А тут в лучшем случае (стучу по деревяшке, т.к. еще не факт) просто дело прикроют, мол, чуваки, обознались, сорян.


          1. EvilBeaver Автор
            18.12.2019 12:02

            Хорошо, но как это отвечает на мой вопрос и диалог о том, что 1С-у сложно будет выйти на международный рынок из-за истории в nginx.


            Ну и да, представительства 1С и партнеров уже есть в Турции, Канаде, США, Германии, Испании и еще где-то. Это считается неким выходом на международный рынок?


            1. bolonov
              18.12.2019 12:09
              +1

              Представьте, что вы средней руки компания, например, из Польши или Германии. И у вас есть нужда в автоматизации бизнеса. История эта обычно довольно мозгоемкая, а иногда и капиталоемкая. В любом случае вам хочется решения «всерьез и надолго». А в России вы знаете, что не очень стабильно все. Точнее так — то, что там стабильно (перекос в строну гос-ва), то не располагает к стабильности бизнесов, населяющих ее. Вот и подумаете вы, а стоит ли с ИТ-компанией из такой страны связываться.


              1. stilic
                18.12.2019 15:49

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


                Разработка будет вестись местными партнерами.
                От того, что головное подразделение, которое разаботкой платформы (типовые конфигурации из РФ не нужны за границей) занимается вдруг сменится собственник — вы даже не факт что заметите.

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

                На Хабре есть статьи сети стройматериалов из Франции, если не ошибаюсь.
                Там процесс разработки расписан и доводы, почему поручили нашему подразделению (тому ИТ-подразделению сети французской, что в РФ). А потом им и Казахстан поручили. Просто потому что отдел сильный. Просто потому что им проще с казахстанцами разговаривать.

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


                1. bolonov
                  18.12.2019 16:50

                  >От того, что головное подразделение, которое разаботкой платформы занимается вдруг сменится собственник — вы даже не факт что заметите

                  Это было бы правдой, если бы платформа была:
                  1. открытой, как какой-нибудь Хром
                  2. с большим международным (а не только русскоязычным) сообществом

                  >эмоциональных факторов, которые вы тут привели

                  Этот «эмоциональный», как вы метко выразились, фактор называется политический риск (https://en.wikipedia.org/wiki/Political_risk). В нашей стране он, к сожалению, выше чем в среднем по Европе, например. И истории типа ngnix'а его точно не уменьшают.


                  1. stilic
                    18.12.2019 16:59

                    Это было бы правдой, если бы платформа была:
                    1. открытой, как какой-нибудь Хром
                    2. с большим международным (а не только русскоязычным) собществом


                    Вы привели не более чем эмоциональный аргумент.
                    Не рациональный.

                    В противном случае проприетарного софта давно бы не существовало как класса.

                    Нет.
                    Собственники регулярно сменяются.
                    Лично Вы даже не знаете этого, и лично продолжаете пользоваться теми же продуктами.

                    Новый собственники мечтает заполучить себе бизнес чтобы продолжить его эксплуатировать.

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

                    Возможны ньюансы, что изменится сам продукт постепенно и очередная версия вам не понравится. Но вам то что? У вас уже есть старая налаженная версия. А переход на новую все равно бы потребовал серьёзнейших работы по переработке кода.

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

                    Да и то, что собственник один и тот же — отнюдь не гарантирует, что ему не надоело, что он не потерял деловую хватку, что он не проводит 100% времени на Гавайах или Канарах, а его бизнес в это время постепенно отстает от конкурентов всё больше и больше.


                    1. bolonov
                      18.12.2019 17:23

                      > Собственники регулярно сменяются.

                      В ИТ это часто связано с послед-м закатом технологий, разработанных исходным собственником. Примеры:
                      DEC > Compaq > HP (где VAX? VMS? PDP?)
                      Sun Microsystems > Oracle (где SPARC?)
                      Sybase > SAP (где одноименная СУБД?)

                      >Новый собственники мечтает заполучить себе бизнес чтобы продолжить его эксплуатировать.

                      Ваша категоричность суждений умиляет :)

                      Это не всегда так. В мире ИТ есть много примеров, когда бизнес приобретался для
                      — убийства конкурента и включения его наработок в продукты покупателя
                      — покупки чисто его клиентской базы


                  1. stilic
                    18.12.2019 17:13

                    И истории типа ngnix'а его точно не уменьшают.


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

                    Это банальные разборки из-за денег.

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

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

                    Ведь даже если суд присудит 10% от 40 миллиардов — это уже неплохо, это уже выгодно.

                    Но это не политические разборки. Это банальные разборки из-за больших денег между возможными владельцами интеллектуальных прав.


                    1. Neikist
                      18.12.2019 17:18

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


                      1. stilic
                        18.12.2019 17:33

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


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

                        Или вы предполагает, что всё должно было ограничиться личными звонками Мамута Сысоеву? Чтобы Мамут канючил: «Игореша, ну отдай деньги». Так что ли?

                        Конечно, в данном конкретном случае смысл обысков непонятен. Что там хотели изъять с компьютеров? Исходники nginx, которые давным-давно уже по всему миру разбросаны?

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

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

                        И, кстати, кто-нибудь может пояснить — а за что конкретно Сысоев со товарищами получили 40 миллиардов? За исходники nginx? За право нанимать Сысоева? Да каким бы крутым разработчиком он ни был — не стоит это право столько. nginx не настолько сложный софт.


                        1. Neikist
                          18.12.2019 17:38

                          «nginx+» и другие коммерческие продукты и да, команда. IBM вот ред хат за миллиарды долларов купил многие полагают только из за команды а не из за технологий.
                          Силовики может и поступили как привыкли, но тот кто принимал решение возбудить уголовное дело без доказательств (не верю что они есть у рамблера) он чем думал?


                          1. stilic
                            18.12.2019 18:16

                            Силовики может и поступили как привыкли, но тот кто принимал решение возбудить уголовное дело без доказательств (не верю что они есть у рамблера) он чем думал?


                            А почему тот человек должен думать об виновности Сысоева или невиновности?
                            Точку в этом деле должен ставить суд. И только суд.

                            Есть заявление.
                            Проводятся, направленные на сохранения улик. Если Сысоев злоумышленник, то запросто может и документы уничтожить.

                            Пусть даже Сысоев и не виноват, но априори, до суда, все равно меры по сохранению улик принять нужно.

                            А до решения суда следственные органы не знают злоумышленник ли Сысоев. Была бы у них машина времени — не делали бы лишней работы, узнав, что в будущем суд выиграет Сысоев.

                            (не верю что они есть у рамблера)

                            Еще раз:
                            Есть заявление.
                            Но решить существенны ли доказательства или нет — может только суд.
                            Что думаете вы — неважно.


                            1. Neikist
                              18.12.2019 18:42

                              А почему тот человек должен думать об виновности Сысоева или невиновности?
                              Точку в этом деле должен ставить суд. И только суд.

                              Есть заявление.

                              Ага, а по заявлению от меня в офис рамблера тоже маски шоу прискачут?


                              1. stilic
                                18.12.2019 18:58

                                Ага, а по заявлению от меня в офис рамблера тоже маски шоу прискачут?


                                Если вы можете позволить себе действительно квалифицированных юристов, которые знают как это оформить правильно.

                                Мы многое не знаем в той сфере, просто мы не специалисты в тех областях. Вот нам и кажется, что это неествественно быстро.

                                Я как-то интересовался у юриста — приостановить сделку по квартире, заблокировать счета и т.п. вещи можно и простому человеку сделать почти мгновенно (ну день-два), если знать как это оформить.

                                Другое дело — последствия.
                                Во встречном иске убытки от приостановления деятельности Рамблера повешают на вас, если ваши доказательства окажутся не доказательствами.

                                Оно вам надо?

                                Конкретно в данном случае Мамут не так то и рискует. Иск то от ошфора, на котором, поди и нет никакого имущества. Захочет ли Сысоев дать сдачи по взрослому, судиться, пройти по цепочке до реального владельца ошфора?

                                Зачем это нужно Сысоеву при наличие 40 миллиардов? Тут Мамут ничем и не рискует. Сумма полученной Сысоевым компенсации будет смешной в масштабах 40 миллиардов.

                                Это вам будет не смешно, потому как убытки Рамблера и ваша зарплата несопоставимы.

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

                                Человек живет тем, что постоянно и непрерывно судится из-за всякой ерунды. Например, с ЖКЖ. Типа температура горячей воды на 1 градус меньше нормы. Отдельный судебный иск за каждый день такой температуры.

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

                                Скажем так, автомобиль у него не из дешевых.

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


                        1. andy_minsk
                          18.12.2019 18:14

                          Полагаю, что следователи, разумеется, не вникали в суть бизнеса nginx. И поступили ровно так же как и поступили бы с каким-нибудь торговым предприятиям — изъять документы поставщиков, покупателей и искать в них несоответствие по налогам, например.

                          Это то и плохо. Рядовое хозяственное дело — и уголовный процессв особокрупном. Это не неуплата налогов, не контрабанда, просто одно юрлицо решило что другое неправо. И что? Это дает такое право делать силовые акции?
                          И, кстати, кто-нибудь может пояснить — а за что конкретно Сысоев со товарищами получили 40 миллиардов? За исходники nginx? За право нанимать Сысоева? Да каким бы крутым разработчиком он ни был — не стоит это право столько. nginx не настолько сложный софт.

                          Это столько стоит, раз это купили. Это единственное мерило.


                          1. stilic
                            18.12.2019 18:28

                            Это то и плохо. Рядовое хозяственное дело — и уголовный процессв особокрупном. Это не неуплата налогов, не контрабанда, просто одно юрлицо решило что другое неправо. И что? Это дает такое право делать силовые акции?


                            Достаточно хорошо объясняющий комментарий из другой статьи на Хабре:
                            habr.com/en/news/t/480908/#comment_21029022
                            1. Т.е. основания есть. Достаточные или нет — другой вопрос, который должен решить суд.
                            2. Суду должно быть наплевать на мнение. Иначе — как раз беспредел и причина для возмущения.
                            3. Если есть дело, а оно есть, то должны проводится ОРМ, направленные в том числе на сохранение улик. Для это и нужны люди в форме. Не приятно, но увы иначе никак. Или думаете никто не прячет сервера, жёсткие диски и папки с документами? И да, неприятно и стрёмно, но жизнь есть жизнь. Собственно на такие случаи в крупных компаниях и есть юристы


                        1. gecube
                          18.12.2019 23:50

                          > Да каким бы крутым разработчиком он ни был — не стоит это право столько. nginx не настолько сложный софт.

                          Извините, но это чушь. Или зависть (да, я тоже в каком-то смысле завидую Сысоеву — он молодец). Насчет сложный — наверное, уже нет. Но в ТО время — это реально было ноу-хау.


                          1. stilic
                            19.12.2019 18:24

                            > Да каким бы крутым разработчиком он ни был — не стоит это право столько. nginx не настолько сложный софт.


                            Извините, но это чушь. Или зависть (да, я тоже в каком-то смысле завидую Сысоеву — он молодец). Насчет сложный — наверное, уже нет. Но в ТО время — это реально было ноу-хау.


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

                            Полноценное решение типа nginx можно реализовать и оттестировать с нуля и за в сотни раз меньшую сумму и за разумные сроки в 1-2 года.

                            При этом ничто вам не мешает пользоваться параллельно бесплатным nginx, пока идет разработка.

                            Причина, по которой F5 потратил на приобретение фирмы nginx столько миллиардов — совсем иная.

                            Вот эту причину и хотелось бы понять.

                            Насчет сложный — наверное, уже нет. Но в ТО время — это реально было ноу-хау.


                            Речь то вовсе не о донате в признание былых заслуг Сысоева. Зачем? Если продукт открытый? Ну хотели бы поблагодарить — обошлись бы меньшей суммой.

                            А о покупке чего-то. Но чего? Не открытых же исходников nginx.


                            1. andy_minsk
                              19.12.2019 18:34

                              Почему? А капитализация владельца? В руках F5 nginx — это дорогой актив. И то что он открытый — сути дела не меняет.


                              1. stilic
                                19.12.2019 18:44

                                Почему? А капитализация владельца? В руках F5 nginx — это дорогой актив. И то что он открытый — сути дела не меняет.


                                В смысле, пустить пыль в глаза инвесторам?


                                1. andy_minsk
                                  19.12.2019 19:05

                                  :) Почему пыль? Актив — это не только станок и стена из бетона. MS миллиарды стоит не из-за того что ее windows и office от копирования защищены, а потому что она их кодом владеет и пользователей дохрена. У гугла вон тоже все бесплатно, и что? На их продуктах полмира подсажено.


                                  1. stilic
                                    19.12.2019 19:15

                                    :) Почему пыль? Актив — это не только станок и стена из бетона. MS миллиарды стоит не из-за того что ее windows и office от копирования защищены, а потому что она их кодом владеет и пользователей дохрена. У гугла вон тоже все бесплатно, и что? На их продуктах полмира подсажено.


                                    Исходный код MS для большей части мира недоступен.

                                    И при попытке его использовать, если вы его заполучили как-то — вы столкнетесь с дорогими неприятностями юридического свойства.

                                    Гугль отдает в общее пользование только второстепенный код, который никак не могут повлиять на его бизнес. А вот логика работы поискового ядра — коммерческая тайна.

                                    Теперь объясните мне — что именно дает F5 владение общедоступным nginx? Лицензия которого прямо говорит, что, мол, «бери и используй на здоровье».


                                    1. gecube
                                      19.12.2019 19:39

                                      Я еще добавлю.

                                      >Теперь объясните мне — что именно дает F5 владение общедоступным nginx? Лицензия которого прямо говорит, что, мол, «бери и используй на здоровье».

                                      Есть же кейсы, когда всякие монги-редисы, почуяв, что деньги текут мимо них, переходят с условно «всеразрешающей» лицензии на «ограниченную». Это очень спорный вопрос с юридической точки зрения, т.к. опен сурс — дело коллективное и по идее нужно получить согласие ВСЕХ контрибьюторов на смену лицензии… Но это не выглядит НЕ РЕАЛЬНЫМ… Более того. Есть объективная проблема, что nginx БЕЗ ФИЧ и поддержки актуальных протоколов — будет не нужен. Вот будущее — выходит условный HTTP/3. В бесплатном nginx его поддержи очевидно сейчас нет. А коммерсы купив его тупо не будут вкладываться в развитие открытой ветки (как вариант). Зато в платном варианте будет все необходимое.
                                      Поясню, что то, что я написал — возможный, но не обязательно вероятный, сценарий. А может все будет совсем по-другому.


                                    1. andy_minsk
                                      19.12.2019 20:10

                                      Компания, за недорого, покупает рынок сбыта высоконагруженных решений для инета (30% всех сайтов). В этот канал теперь можно предлагать ПО, сервисы, поддержку, да массу всего. Это их рынок, их клиенты. Условный нетфликс обратится скорее к ним, чем к разработчику аналога, если только аналог не на порядок лучше, а вот это сделать уже и на порядок сложней. И зачем тогда тратиться на разработку аналога?


                                      1. stilic
                                        19.12.2019 20:28

                                        Условный нетфликс обратится скорее к ним, чем к разработчику аналога, если только аналог не на порядок лучше, а вот это сделать уже и на порядок сложней. И зачем тогда тратиться на разработку аналога?


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

                                        Netflix также имеет такую возможность.

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

                                        На более массовых рынках — согласен, покупка клиентской базы стоит того.

                                        Ваши аргументы серьезно уступают в основательности аргументации, что привел gecube


                                1. gecube
                                  19.12.2019 19:11

                                  Вы помните истории, когда покупали компании, только из-за того, что у них были патенты, коллектив или еще что-либо нематериальное?

                                  > Полноценное решение типа nginx можно реализовать и оттестировать с нуля и за в сотни раз меньшую сумму и за разумные сроки в 1-2 года.

                                  По Вашим словам могу предложить Вам самим написать продукт такого же уровня. Ну, а фигли — если это всего лишь 1 год и фикс прайс.
                                  Я сам не фанат nginx (по определенным причинам), вижу сильные альтернативы, которые появились буквально недавно — envoy, traefik.
                                  Но и не могу не отметить сильную сторону nginx — каждый школьник его знает, он уже проник во многие организации (клиентская база) и под него напилено уже очень много модулей и собрана масса экспертизы.


                                  1. stilic
                                    19.12.2019 19:19

                                    По Вашим словам могу предложить Вам самим написать продукт такого же уровня. Ну, а фигли — если это всего лишь 1 год и фикс прайс.


                                    Разделите 40 миллиардов на 100 и посчитайте скольким высококвалифицированнейшим программистам вы сможете оплачивать этот год.

                                    Я сам не фанат nginx (по определенным причинам), вижу сильные альтернативы, которые появились буквально недавно — envoy, traefik.


                                    Все правильно. Их не столь уж недоступно сложно сделать.

                                    Но и не могу не отметить сильную сторону nginx — каждый школьник его знает, он уже проник во многие организации (клиентская база) и под него напилено уже очень много модулей и собрана масса экспертизы.


                                    Безусловно.
                                    Но какой с этого прок F5?
                                    Она и без покупки nginx вполне себе могла это всё использовать.
                                    А брать деньги за всемирное использование nginx (как в своем время поступил хитрый немецкий институт, что держал патент на MP3) — лицензия не позволяет.

                                    Вы помните истории, когда покупали компании, только из-за того, что у них были патенты, коллектив или еще что-либо нематериальное?


                                    Может быть и так.
                                    Но какие патенты могут быть в открытом решение. Как минимум такие вещи в коде прописываются (в комментарии номер патента).


                                    1. gecube
                                      19.12.2019 19:23

                                      > Она и без покупки nginx вполне себе могла это всё использовать.

                                      Вы почему-то забываете про вполне коммерческий продукт NGINXPlus и возможность заказать у разработчиков поддержку.
                                      Это в России не принято платить разработчикам за консалт — сами с усами, «наши админы разберутся — им же зарплату платят»
                                      Мое мнение — F5 просто хочет консолидировать свои аппаратные решения и свежекупленный программный балансировщик (коим и является nginx) в некое пакетное предложение, новый продукт, с которым они в конечном счете вернутся на рынок.


                                      1. stilic
                                        19.12.2019 19:29

                                        Вы почему-то забываете про вполне коммерческий продукт NGINXPlus и возможность заказать у разработчиков поддержку.
                                        Мое мнение — F5 просто хочет консолидировать свои аппаратные решения и свежекупленный программный балансировщик (коим и является nginx) в некое пакетное предложение, новый продукт, с которым они в конечном счете вернутся на рынок.


                                        А это уже разумное объяснение. Довольно правдоподобное.

                                        В отличие от ерунды, что тут пишут про цель покупки другие комментаторы.

                                        Инвестиция в сырье для твоего продукта, чтобы потом это сырье переварить и продавать продукт созданный на его основе — это да.

                                        Затраты на такое не выглядят большими. Все равно отобьется при будущих продажах.


                    1. andy_minsk
                      18.12.2019 17:25
                      +1

                      Политика в том, что кому-то позволено мгновенно возбудить уголовное дело и выслать силовую поддержку, а кому-то, даже при наличии денег — нет.


                      1. EvilBeaver Автор
                        18.12.2019 17:27

                        Все верно, только, кажется, что при наличии денег — все таки "да" в любом случае. Вопрос размера денег


                        1. andy_minsk
                          18.12.2019 17:31

                          Я склонен к мысли, что в разных руках деньги в стране имеют разную стоимость


                      1. stilic
                        18.12.2019 17:40

                        Политика в том, что кому-то позволено мгновенно возбудить уголовное дело и выслать силовую поддержку, а кому-то, даже при наличии денег — нет.


                        Вы о чем вообще?
                        Разве Сысоев пытался возбудить уголовное дело, но ему и 40 миллиардов не помогли это сделать?

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


                        1. andy_minsk
                          18.12.2019 18:06

                          Ой ли? Пойти написать заявление на Рамблер что они 11 лет назад что-то сделали и делу так сразу резво дадут ход?


                    1. bolonov
                      18.12.2019 17:29

                      >Но это не политические разборки. Это банальные разборки из-за больших денег между возможными владельцами интеллектуальных прав.

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


                1. gecube
                  18.12.2019 23:48

                  > На Хабре есть статьи сети стройматериалов из Франции, если не ошибаюсь.

                  говорите напрямую — LEROY MERLIN. И это еще вопрос, что там осталось в нем французского (кроме названия)


                  1. stilic
                    19.12.2019 18:47

                    говорите напрямую — LEROY MERLIN. И это еще вопрос, что там осталось в нем французского (кроме названия)


                    Я не мог вспомнить. Наверное это они.
                    Там много чего из Европы — есть ПО общее с европейским офисом.

                    Но то ПО, что работает на нашей территории — там много уже нашего, ага.


        1. CrushBy
          18.12.2019 12:00

          А зачем, по-Вашему, F5 начал рассылать письма своим клиентам с уверением, что мы ничего кроме nginx в России не разрабатываем?

          История nginx о том, что интеллектуальная собственность в России нестабильна. А это всегда риски.

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


          1. EvilBeaver Автор
            18.12.2019 12:04

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

            Мне что-то подсказывает, что на решения судов РФ, особенно на сомнительные, западному бизнесу слегка положить. Но да, история неприятная, кто бы спорил.


  1. pereligins
    18.12.2019 11:43

    Также есть мнение, что бренд внедренной ERP системы помогает увеличить капитализацию компании. И этот фактор не в пользу 1С. Не знаю насколько капитализация при этом действительно вырастает, но знаю пару примеров компаний, которые купили SAP именно по этой причине. Болезненные попытки его внедрить особого успеха не имели, по факту все осталось работать на 1С, но зато можно смело заявлять инвесторам, что в «компании внедрено решение международного уровня».


    1. EvilBeaver Автор
      18.12.2019 11:43

      Есть такое дело, но это вопрос к маркетологам, а не к технарям.


    1. CryptoTyan
      18.12.2019 15:44

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


  1. Spaceoddity
    18.12.2019 11:43

    Я малость не в теме, но скажите — а Битрикс подпадает под обсуждение в статье? Потому что мне изредка приходилось иметь дело с этой платформой. Но сейчас я зарёкся…


    1. pereligins
      18.12.2019 11:44

      Битрикс это другое


    1. EvilBeaver Автор
      18.12.2019 11:46

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


  1. akryukov
    18.12.2019 12:03

    Любопытно, что в хотелки языка 1С записали сильную типизацию и функции первого класса.
    Что насчет зависимых типов?


    1. EvilBeaver Автор
      18.12.2019 12:05

      Зависимые типы — это как?


      1. akryukov
        18.12.2019 12:21

        Вот тут достаточно хорошо описано.


    1. Neikist
      18.12.2019 12:15
      +1

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


      1. akryukov
        18.12.2019 12:34
        -1

        В моем понимании, внедрение зависимых типов может сделать маленькие юнит-тесты ненужными. Плюс юнит-тесты не могут наверняка проверить даже такую функцию:


        def isSpecialCase(data:Int): Boolean = {
          data== 5
        }

        Ну не писать же нам в тестах


        (Int.MinValue to 4) ++ (6 to Int.MaxValue).foreach { v => assert(!isSpecialCase(v)) }
        assert(isSpecialCase(5))


  1. dbarabanshchikov
    18.12.2019 12:05

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

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

    Вопрос к автору вам за последние 15 лет никогда не хотелось пожить за пределами СНГ?
    Поработать в интернациональной команде? Иметь возможность переехать в любую точку планеты никак удалёнщик, а как востребованный специалист? Увидеть и разобраться как работает бизнес в других странах?


    1. EvilBeaver Автор
      18.12.2019 12:14

      Вопрос к автору вам за последние 15 лет никогда не хотелось пожить за пределами СНГ

      Нет, не хотелось. Я и сейчас могу уехать в любую точку мира и пожить там, в т.ч. как специалист. Или как турист. Но я не хочу. Мне достаточно отпуска в 10-15 дней чтобы погрузиться в атмосферу и начать скучать по дому.


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


      Если говорить про "не учи 1С, не сможешь свалить", то это, на мой взгляд, абсурдный довод. Востребованность айтишника измеряется не количеством фреймворков, которые он знает, а способностью решать задачи. Если ты кроме 1С ничего не смог изучить за время карьеры, то ты и в России так себе специалист. А 1С-ники очень сильны в анализе процессов, в построении моделей, в проектировании. Эти знания пригодятся в любой экосистеме.


      1. Neikist
        18.12.2019 12:17

        Вот не скажите. Это извечный спор, и хоть я сам придерживаюсь другого мнения — но большинству работодателей важен именно опыт на конкретном стеке к сожалению (З.Ы. можно еще выехать на алгоритмах, CS, дизайне систем и прочем, есть компании которые забивают на стек и смотрят на базу — но это нужно быть действительно гораздо выше среднего уровня и таких специалистов небольшие и средние фирмы не набирают).


        1. EvilBeaver Автор
          18.12.2019 12:36

          У меня просто есть знакомые ИТ-шники и в Канаде и Германии. Я бы не сказал, что они живут как-то лучше меня в повседневной жизни. Но это холиварный вопрос. Давайте про технологии.


          1. dgr
            18.12.2019 18:40

            Confirmed! ))


        1. Ta_Da
          18.12.2019 12:39

          Если работодатель формально подходит к вопросу (независимо от того, прав работодатель или «HR навставлял умных слов в вакансию») про «опыт на конкретном стеке», то нужно тогда вообще ориентироваться не на «только не 1С», а тупо мониторить на каком стеке больше всего вакансий и изучать только его. С точки зрения мат. ожидания хороший путь, да. Но со своими рисками.

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

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


          1. Neikist
            18.12.2019 12:54

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


      1. bolonov
        18.12.2019 12:50
        +1

        >Если говорить про «не учи 1С, не сможешь свалить», то это, на мой взгляд, абсурдный довод.

        Немного другая причинно-следственная связь. Я лично от нескольких молодых (до 30) спецов слышал аргумент типа — зачем мне учить 1С, если нигде в мире он не нужен. Все эти ребята и девчата рассматривали релокацию (Европа, Канада).

        И для понимания — я сам патриот 1C с 20 летним (без шуток) стажем. И мне искренне обидно, что так вот оно получается, причем совсем не вине 1C.


    1. Honomer
      18.12.2019 12:18
      +1

      Решения на базе 1С продаются в Китае, Турции, Вьетнаме, Канаде, Германии, США.
      Не так широко, как хотелось бы, наверное, 1С, но тем не менее процесс идёт.
      www.accountingsuite.com
      www.1ci.com/applications/1c-drive
      toronto.1cbit.ru


      1. Kwisatz
        18.12.2019 17:39

        Первая же ссылка, еле шевелится у них приложение. Вот потому я и стараюсь не юзать 1с.


    1. Nilpferd
      18.12.2019 12:25

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

      В таком ключе, я бы вообще не рекомендовал молодым людям становиться разработчиками. Есть и другие способы уехать на ПМЖ за границу.


  1. Nilpferd
    18.12.2019 12:25

    del


  1. vvbob
    18.12.2019 12:42
    +3

    Да уж. В плане консервативности у 1С все превосходно. Писал на 1С примерно до 8-го года, в принципе на свой кусок булки с маслом зарабатывал, но потом все-же соскочил — очень уж угнетало то что как разработчику там развиваться особенно некуда, слишком узкий мирок.
    Вот почитал эту статью — и смотрю в принципе с тех времен там мало что нового появилось (если с позиции рядового 1С-ника смотреть). А язык программирования, даже по сравнению с многословной Явой… В общем негатива ни к 1С ни к адептам платформы не испытываю, но очень рад что в свое время набрался смелости и соскочил (а это было не так просто).


    1. Ta_Da
      18.12.2019 12:48

      как разработчику там развиваться особенно некуда

      Это все-таки не совсем так. Или я не совсем понимаю, что такое «развиваться как разработчику».
      Решать сложные технические задачи? Развивать сложные системы (пользователей все больше, объемы все больше, нагрузка все выше), причем так, чтобы они не рассыпались при очередном обновлении? Какие-никакие новшества регулярно появляются (веб-, мобильный, внешние источники). Спектр задач достаточно широкий, вопросы интеграций опять-таки.

      Да, какие-то вещи на 1С сделать нельзя (часть упомянута в статье), но это ж не значит, что «нельзя развиваться»?


      1. vvbob
        18.12.2019 13:01

        Я не говорил про отсутствие задач. Я говорил о развитии именно как программиста. В 1С развитие — это в основном миграция либо в бизнес (внедрение 1С и налаживание бизнес процессов предприятия), либо в системное администрирование. Я эти направления не считаю чем-то недостойным или неперспективным — там может быть интереснее и выгоднее, но лично мне там неинтересно, а сидеть до пенсии и править формочки в Конфигураторе, подстраивая их под очередной каприз законодательства, пока в типовой не исправят… ну это такое… мягко говоря не то о чем я мечтал становясь программистом.


        1. Ta_Da
          18.12.2019 13:13

          1С это не только «1С: Бухгалтерия» или «1С: Зарплата», все таки. Посмотрите, допустим на «УНФ». Есть специализированные решения типа «1С: Интеграция» или «2is: Интеграция» (просто чтобы упомянуть еще и хотя бы одно не типовое решение).

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


          1. Neikist
            18.12.2019 13:17

            Говорю как человек работавший над разработкой коробки к законодательству не привязанной от слова совсем. Нишиша. Та же история, день сурка. Все развитие либо в девопс, админство, оптимизацию запросов и бд и подобное, либо в бизнес домен. Развития как программиста после какого то уровня — 0.


            1. Ta_Da
              18.12.2019 13:28

              Все равно не понимаю вашу логику.

              Берем двух разработчиков:
              Первый пишет, допустим, интеграционную шину на 1С. Начинает с простых вещей типа штатного плана обмена и выгрузки по правилам в XML, потом начинает накручивать поверх веб-сервисы, внешние источники, json, rabbitMQ и т.д. и т.п… Развивается. Допустим, в какой-то момент все что есть в платформе он уже изучил и использовал. Все возможные ситуации обработал. Развитие продукта закончилось, разработчику остается только править на этом проекте баги и заниматься оптимизацией под какие-то конкретные бизнес-кейсы.

              Вопрос, второй разработчик, который все то же самое будет пилить на Java/.Net/C++ разве не такой же путь пройдет? И точно так же не упрется разве в какой-то момент в потолок развития продукта? Ок, он будет каждые N лет заниматься переписыванием этого всего с Java X на Java X+10 и рефакторингом, ну так и на 1С тоже можно так же делать.

              Если не устраивает — и первому и второму нужно искать другой проект. Не улавливаю в чем разница-то?


              1. Neikist
                18.12.2019 13:37

                Вряд ли мы придем к одной точке зрения. Это ощущение довольно трудно формализуемо, но все что вы описываете — чисто прикладные, утилитарные вещи. В 1с что бы ты не делал — остаешься в рамках платформы, даже если что то сбоку прикручиваешь. Это не говоря о том что в основном пишешь на очень простом языке не дающем возможности разгуляться, на который очень плохо переносятся считающиеся лучшими практики от других программистов и прочее. А так же поголовное(за редкими исключениями) стремление работодателей задавить любой инженерный интерес и заставить разработчика идти изучать прикладные решения от 1с, сертификаты по ним получать и прочее (в свободное время!!), когда нормальному инженеру интереснее бы было почитать про новый подход в разработке, применение хороших практик, алгоритмы, ОС, математику, теорию ЯП и прочие интересные вещи.


                1. Ta_Da
                  18.12.2019 13:49

                  Это ощущение довольно трудно формализуемо, но все что вы описываете — чисто прикладные, утилитарные вещи

                  Разработка это в принципе «прикладные, утилитарные вещи». Давайте все-таки разделять «Software Engineering» и «Computer Science». Изучение «алгоритмов, теории ЯП» это не «развитие как разработчик», извините.

                  Приведу аналогию про врачей. Есть хирург, а есть анестезилог. И вот анестезиолог ходит и жалуется «не могу развиваться как врач, вон у хирурга столько всяких ножичков, он в кишочках копается, а мне только следить за внешними показателями типа дыхания надо и пару раз укол сделать за операцию, никакого развития». Ну или «работаю проктологом, каждый день одно и то же, а вот у меня друг грудные импланты ставит — сказка, а не работа». Кто гинеколог, проктолог, венеролог и т.д. в контексте разработки ПО решайте сами.
                  Возвращаясь к разговору о наших виртуальных программистах. Какой из перечисленных врачей «больше врач»? Какой из них «больше развивается как врач» в процессе своей работы?

                  заставить разработчика идти изучать прикладные решения от 1с, сертификаты по ним получать и прочее

                  Для компании-франчайзи — логичное желание. Компании из реального сектора на наличие сертификатов наплевать.


                  1. Neikist
                    18.12.2019 14:00

                    Но им не наплевать на знание прикладных решений 1с и партнеров.

                    Даже если вернуться к чисто утилитарным вещам — в 1с все очень ужасно с построением собственных абстракций, что тоже не способствует. Также жестко навязана архитектура системы. Это даже если забыть что программирование не ограничивается учетными системами, а в разработке других систем и подходы с паттернами и архитектурами другие. Где тут развитие если вечно в одной парадигме сидеть.


                    1. Ta_Da
                      18.12.2019 14:14

                      Но им не наплевать на знание прикладных решений 1с и партнеров.

                      Наплевать, если они их не используют. Из лично моего опыта — типовые (Бух, ЗУП) на поддержке у франчей, внутренний отдел разработки пилит внутренние решения. Знание типовых может являться плюсом, если нужно интеграцию подпилить, но не более.

                      Где тут развитие если вечно в одной парадигме сидеть

                      Если вы все время «прыгаете» между разными (принципиально) системами и предметными областями в других языках, то вы тоже не особо «развиваетесь», как бы. Наработка опыта и изучение вот этого всего тоже не бесплатна. В итоге вы либо вечный мидл (в лучшем случае, в худшем — манкикодер), либо выбираете-таки конкретное направление.
                      Про жестко навязанную архитектуру в принципе не соглашусь. Подходы, например, к обменам даже в упомянутых мной интеграционных решениях разные. Причем архитектурно разные. Да, есть определенные ограничения и необходимость действовать в рамках предоставленных базовых классов, но такими уж «жесткими» я бы эти ограничения не назвал.
                      Причем, на мой взгляд, как раз архитектурные паттерны на 1С вполне хорошо ложатся.


                      1. Neikist
                        18.12.2019 14:16

                        Ну в общем я уже говорил что вряд ли мы придем к единой точке зрения.


                        1. Ta_Da
                          18.12.2019 14:34

                          Ну я ж не проповедник, чтобы вас в свою веру обращать. Просто, ИМХО, вы путаете «академический интерес к программированию» и «разработка как инженерная дисциплина».

                          Первое, это про чтение Кнута, Танненбаума, реляционной алгебры и бог знает чего еще.
                          Но реально «без ограничений» развиваться и применять на практике (зарабатывая при этом) вы это сможете либо выступая на конференция/преподавая на курсах, либо уйдя в open source или разработку своего ЯП.
                          При этом, применять на практике (с ограничениями) все это можно и в рамках 1С фреймворка или любого другого фреймворка.

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


                          1. Neikist
                            18.12.2019 14:50

                            Вот серьезно, когда я заявляю каким угодно разработчикам о любопытстве к теории или расширению кругозора в программировании — мне качают головой с пониманием. Сами такие, другое дело что времени из-за изучения свежих фреймворков не всегда хватает. Когда заявляешь такое 1сникам — все крутят у виска и советуют лучше сходить курс по какой нибудь ERP посмотреть. Разница довольно заметна между коммьюнити. Это даже если забыть про довольно бурное постоянное развитие в сфере архитектур и подходов к построению систем или UI приложений. serverless, микросервисы, монолиты и еще разные вариации архитектур на беке. Распределенные системы. Большие данные. На клиенте же вечные споры декларативный vs императивный подход к построению UI, входящий в моду однонаправленный поток данных. MVI/MVP/MVVM/VIPER/MVC и прочее. Плюс бурное развитие языков программирования позволяющее все более удобные абстракции строить и писать более читаемый и надежный код. А оглядываясь на 1с в лучшем случае что то интересное при интеграциях разве что делать приходится, и то внутри 1с чаще всего, что сильно ограничивает.


                            1. EvilBeaver Автор
                              18.12.2019 14:51

                              Ну ты же знаешь, где найти правильное 1С-ное коммьюнити, разве нет? ;)


                              1. Neikist
                                18.12.2019 14:58

                                Знаю конечно, но это все же меньшая часть. К тому же физически сосредоточенная в паре городов. Почему то очень сомневаюсь что найду подобное в своем городе, ибо в самом крупном франче в нем я работал и там было именно как я описал. В отличие от — недавно был на локальном митапе где go разработчик рассказывал о пет проекте как раз на serverless архитектуре для общения с использованием шифрования на эллиптических кривых. Поскольку у меня до сих пор висит в списке на изучение флаттер который толком никак не потрогаю — есть небольшая вероятность что присоединюсь и сделаю на нем мобильную морду для этого пет проекта в целях любопытства. А казалось бы один город, одни люди, но кто то делает что то прикольное, а кто то сертификаты по конфигурациям получает.


                            1. Ta_Da
                              18.12.2019 15:02

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

                              Т.е. первые кивают («да, мы тоже такие продвинутые и в тренде»), но не делают («нет времени», «нет денег», «страна не та»), а вторые прагматично предлагают тратить время на что-то, что можно легко монетизировать? =)
                              Если 1С-ники будут кивать с пониманием, но не будут изучать, т.к. времени нет, это исправит для вас ситуацию?


                              1. Neikist
                                18.12.2019 15:06

                                «Не всегда хватает» != «Всегда не хватает». Т.е. в свободное время оно таки все действительно многими изучается.


                  1. vvbob
                    18.12.2019 14:06

                    Если уж использовать аналогии — это как работа фельдшера в деревне и хирурга в крупной больнице. Фельдшер тоже нужен, но если ему интересна хирургия — выше определенного уровня он не прыгнет, как бы не старался (оставаясь фельдшером).
                    Сколько с 1С работал — 99% задач было именно что-то из разряда: «у нас типовая на типовую не накатилась, иди разберись», «вышло постановление ФНСГРУФСБМЧСГКЧП о том что форма дока изменилась, и теперь нужно запятую поставить вот тут, а это подчеркивание перенести туда, типовая еще не обновилась — давай сделай»… Самое интересное было что-либо из разряда «у нас вот приходят письма по электронке с прайсами, надо бы их автоматически загружать».
                    Пока был джуном — это все было не то что-бы сильно интересно, но норм, а дальше…


                    1. EvilBeaver Автор
                      18.12.2019 14:14

                      Ну у меня уже лет 7 таких задач не было, я уже по ним заскучать успел. Может у вас в выборе задач что-то подправить?


                      1. vvbob
                        18.12.2019 14:15

                        Я уже поправил, спасибо.


                    1. Ta_Da
                      18.12.2019 14:19

                      Программист .net или java, сидящий на проекте поддержки legacy сталкивается ровно с теми же проблемами. Это вопрос проектов и задач, а не фреймворка/языка.
                      Я сильно подозреваю, что значительный процент разработчиков на всех языках, занимается именно поддержкой legacy. Это если не упоминать еще всяких разработчиков на фреймфорках типа workforce/salesforce, которые часто упоминаются как «та же 1С, только на английском».
                      Т.е. проблемы те же.


                    1. stilic
                      18.12.2019 14:27

                      Сколько с 1С работал — 99% задач было именно что-то из разряда: «у нас типовая на типовую не накатилась, иди разберись», «вышло постановление ФНСГРУФСБМЧСГКЧП о том что форма дока изменилась, и теперь нужно запятую поставить вот тут, а это подчеркивание перенести туда, типовая еще не обновилась — давай сделай»… Самое интересное было что-либо из разряда «у нас вот приходят письма по электронке с прайсами, надо бы их автоматически загружать».
                      Пока был джуном — это все было не то что-бы сильно интересно, но норм, а дальше…


                      Вы сейчас описали типичные задачи для джуна — не более.

                      Мне почему-то все больше попадалась «нестандартная интеграция с внешним софтом», «существенное изменение движения по регистрам для таких то целей», «навороченная система ценообразования, скидок и бонусов» и т.п.

                      Фактически вы работали в поддержке, а не в разработке.

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

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


                1. stilic
                  18.12.2019 15:28

                  Вряд ли мы придем к одной точке зрения. Это ощущение довольно трудно формализуемо


                  Вы вряд ли придете к одной точки зрения с вашим оппонентам.

                  Но по другой причине:

                  Эти вещи нужно рассматривать не столь абстрактно, а только относительно конкретной прикладной задачи. И с конкретными программистами.

                  А ощущения тут совершенно не при чём.


                  1. Neikist
                    18.12.2019 15:45

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


                    1. stilic
                      18.12.2019 15:52

                      «хочется заниматься развитием как программист»?

                      Кому-то нравится делать под веб, а кому-то под смартфоны.
                      Кому-то нравится делать игры, а кому-то СУБД оптимизировать.
                      И т.д.


                      1. Neikist
                        18.12.2019 15:53

                        А кому то нравится абстрактное программирование и хочется охватить побольше.


  1. nvv1970
    18.12.2019 12:50

    Жаль, что нет кармы плюсануть статью, но это лучший расклад по полкам!!!
    Андрей, очень круто и по делу!
    PS:
    — как «эксперт» считаю что сервер приложений не так уж плох как сказано в статье ))
    — действительно ли серверная часть других систем и решений работает так идеально, что 1с на ее фоне выглядит бледно?


    1. EvilBeaver Автор
      18.12.2019 12:51

      Спасибо за отзыв. Разве я сказал, что сервер плох? Напротив, я сказал, что он такой же сервер, как и любой другой.


  1. paranoya_prod
    18.12.2019 12:54

    Если сравнивать «фреймворк» 1С: Предприятия, то сравнивать надо с такими-же фреймворками, где отправить клиенту счёт в PDF по почте решается за две минуты написания строки в коде: отправить_по_почте_pdf(client). Если таковых фреймворков не существует, то лучше не сравнивать даже c .NET Framework, так как на .NET можно написать аналог 1С: Фреймерворк, а вот на 1С ну никак не напишешь .Net framework. Потому что .net фреймворк более низкого уровня.

    PS. Статья хорошая, мне понравилась, но база в xml… До сих пор считаю это непонятным решением.
    С точки зрения простоты — положил файл, где захотел и не нужен мне админ, это неплохое решение, по сравнению с каким-нибудь sql установленным локально. Но с точки зрения производительности и объёма… При этом у фирмы всегда есть какой-нибудь айтишник на подхвате и тут разницы нет в одном xml-файле база, или в файле sql. Проблемы есть со всеми вариантами, но вариант с sql выгоднее бизнесу конечного покупателя.


    1. EvilBeaver Автор
      18.12.2019 12:58

      но база в xml…

      что, простите? Какая база в xml?


      1. paranoya_prod
        18.12.2019 15:24

        Да, это я ляпнул глупостью. Даже не знаю, откуда у меня такая ассоциация возникла.


  1. CrushBy
    18.12.2019 12:59

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


    Вот тут Вы преувеличиваете. Не знаю, как в .Net, для Java есть, например, JasperReports. Бесплатная библиотека по формированию отчетов, с достаточно неплохой тулзой по редактированию шаблонов, которая один раз прикручивается и точно также, практически одной командой, прекрасно формируется PDF. А также еще поддерживает xlsx, docx, odt и много других форматах.


    1. CrushBy
      18.12.2019 13:03

      И в целом, не стоит забывать про важную проблему 1С — закрытость и проприетарность. Для Java можно часто найти бесплатную библиотеку практически под что угодно. Например, нужно было считать mdb формат (Access) — без проблем нашли.


    1. EvilBeaver Автор
      18.12.2019 13:04

      Jasper по сравнению с 1С уже критиковал speshuric в комментариях к соседней статье про 1С.


      1. CrushBy
        18.12.2019 13:08

        Там был другой контекст (drill-down и прочее, которое скорее отношение к BI имеет). Здесь же речь идет конкретно о формировании PDF. Вы просто так написали в статье, как будто в .Net или Java — это очень сложно. Но это не так.


        1. andy_minsk
          18.12.2019 15:31

          в Jasper после нормального 1с репортера что-то сделать — это мазохизм. Я не ярый пропагандист 1с, но в некоторых вещах он покрывает другие решения как бык овцу. BI, кстати. к ним не относится. Но генерация отчетов и печатных форм там почти идеальная.
          Что только не пробовали. Его, пожалуй только excel обгонит по сочетанию результат/простота, да и то только в неструктурированной отчетности.


          1. CrushBy
            18.12.2019 15:40

            Вы уточните, пожалуйста, все таки что и с чем Вы сравниваете. Печатные формы и отчеты — это две абсолютно разные вещи.

            Под печатными формами подразумевается то, что выводится на печать в формате, например, A4 (или любом другом размере страниц). Именно для этого и используется формат PDF.

            И при формировании PDF то, что 1С уделывает JasperReports — очень спорное утверждение. Учитывая то, что PDF — это по сути графический формат, а в 1С — табличный.

            Если речь идет об именно формировании отчетности (то есть вывода пользователю агрегированной информации в разных срезах), то логичнее сравнивать не с JasperReports, а например с Tableau или Imply. И там тоже сравнение явно не в пользу 1С.


            1. EvilBeaver Автор
              18.12.2019 15:50

              Ценник на Tableau еще упомянуть забыли )


              1. CrushBy
                18.12.2019 15:55

                Я для примера привел Tableau. Есть, например, Power BI. Там более гуманный ценник. И ничего, что 1С — тоже не бесплатный?


                1. EvilBeaver Автор
                  18.12.2019 16:00

                  Если сравнить с Табло или Пентахо — считай бесплатный )) А ведь они только агрегаторы-визуализаторы. Кто-то должен еще заплатить за создание UI для операционных работников


                  1. CrushBy
                    18.12.2019 16:34

                    Давайте не перескакивать с темы на тему. Изначально я указал неточность в статье, что в (.Net/Java) сложно реализовать печать в PDF. Потом почему-то перескочили на отчеты, а теперь уже операционные работники пошли.

                    В целом в OLTP систему вешать отчеты — это тоже палка о двух концах. Если большие объемы, то аналитику все равно лучше выводить в отдельную BI базу, вроде бесплатного Druid, а не реляционные базы.


                    1. ZEEGIN
                      18.12.2019 16:42

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


                      1. CrushBy
                        18.12.2019 16:48

                        Работнику склада не нужно знать все а только сколько заказов в работе и сколько товара в каких ячейках, утрированно.

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


                        1. ZEEGIN
                          18.12.2019 16:50
                          +1

                          И хорошо что нельзя, меньше дибильных интерфейсных решений.


            1. andy_minsk
              18.12.2019 16:28

              С точки зрения программиста 1с отчет и печатная форма — схожие понятия. Взять некие данные (запросом, чтением реквизитов, голым расчетом или просто из шаблона ...) и положить их в печатную форму. Во что потом форму печатать в бумагу, excel, pdf не суть важно. Важно то, что степень тюнинга — очень высокая, и можно сильно балансировать сложность отчета давая пользователю массу параметров настройки отчета.
              Сравнение с BI не прокатывает. Мы выгружаем пользовательские данные в PowerBI, Amazon QuickSight, немного в Tableau. Везде результат один — срезы и игра кубиками — супер, но нюансовые отчеты приходится даже тем у кого 1С нет в учете, делать на нем. Просто чтобы добиться подобного результата на вышеперечисленных системах — времени надо вагон. А 1С, да еще не из типовой а из подготовленного для BI хранилища — это задача для стажера в перерыве между парами


    1. Mes
      18.12.2019 13:34

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


      1. CrushBy
        18.12.2019 14:15

        Не путайте, пожалуйста. Речь шла именно о PDF (Printable Document Format). То есть именно форма, которая пойдет на принтер. Для отчетов во всем мире используются специализированные BI tool. К сожалению, 1С им заметно уступает в плане UX.


  1. SkyHunter
    18.12.2019 12:59

    Отличная статья, говорю как разработчик, сменивший стек с 1С на Python.


  1. opaopa
    18.12.2019 13:07

    1. EvilBeaver Автор
      18.12.2019 13:27
      +1

      Самое смешное в этой песне — это текущее место работы её автора )


      1. marmyshev
        18.12.2019 14:00

        Ну да, Pr-mex развивается! От хейтерства до принятия и любви… :)


  1. marmyshev
    18.12.2019 13:54
    +1

    Андрюх, спасибо за статью! Молодец, что выдержал направленное сравнение фреймворка (а не конкретных приложений или самой компании).


    В разных фрейворках есть плюсы и минусы.
    Я за то, чтобы развивать язык 1С (как ЯП) и фреймворк (ака само 1С: Предриятие).


    Зная разработку на других языках/фреймворках- могу сказать, в Java (например) делать бизнес приложение уровня «типовой от 1С» — это суцидно. Да, может кому-то прикольно, но для бизнеса и стратегического развития, имхо, суицидно.
    Я один раз, чуть не ввязался в такой проект на Python, хоть сам имею стаж 3-4 года на питоне, но Слава Богу, могу понять что это, с технологической стороной — утопичный проект (был и есть).


    1. EvilBeaver Автор
      18.12.2019 13:55
      +1

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


      1. marmyshev
        18.12.2019 14:05

        Ну бизнес ведь должен когда-то догадаться, в чём тут выгода и для кого?


    1. vvbob
      18.12.2019 14:09

      Т.е. SAP Hybris это утопичный проект?


      1. EvilBeaver Автор
        18.12.2019 14:15

        Ага. Та еще хрень. Лично участвовал в проекте пересадки крупного ритейлера с этой дряни на 1С, причем ритейлер очень сильно мечтал закопать этот Хайбрис и не вспоминать.


      1. marmyshev
        18.12.2019 14:25

        И сколько компаний могут позволить себе такую разработку и не умереть (ака «суицидно»)? С фреймворком от 1С такую разработку может себе позволить любой франч 10-20 программистов.
        Это я топлю за преимущества фреймворка 1С :)
        Далее, вопросы доработкам (открытости кода) и распространения… — в закрытом проекте на Java — тут много сложно-решаемых вопросов...


        1. vvbob
          18.12.2019 16:29

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

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


          1. EvilBeaver Автор
            18.12.2019 16:36
            +1

            О да, мне тоже приходилось видеть SAP Netweaver. Садись изучай и дорабатывай. переменные Z_YM084002, функции DLT_MTRANS_001_UBRM24, и IDE после которой Конфигуратор 1С будет даром бессмертных богов. Спасибо, не нужно.


            1. vvbob
              18.12.2019 17:07

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

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


              1. EvilBeaver Автор
                18.12.2019 17:13

                Я видел хайбрис мельком. По-моему там под капотом то же самое, что и в типовых 1С — бизнес-логика и обеспечивающие ее вспомогательные модули. Т.е. код что Хайбриса, что 1С:ERP доступен разработчику. А доступность кода сервера приложений Hybris — не уверен, что он доступен.


                1. vvbob
                  18.12.2019 17:31

                  Хотел написать что нифига подобного… потом призадумался, сам не слишком сильно в это погружался (видимо потому что почувствовал что меня опять в аналог 1С затягивает, хоть и с западным уклоном :)))), но процентов на 80 уверен что никакого сервера приложений там нет. Из проприетарщины возможно только какие-то библиотеки, но их штатный дизасемблер из JDK вполне нормально показывает.


  1. frkbvfnjh
    18.12.2019 13:59
    +1

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


    1. Neikist
      18.12.2019 14:05

      Простых бизнес приложений с небольшой нагрузкой. Попробуете запустить десятки тысяч пользователей или же замахнуться на очень крупный и нагруженный бизнес логикой проект (который еще и меняться будет со временем) — почуствуете всю боль динамической типизации, унылого рефакторинга, отсутсвия ФП и ООП, принятых часто в 1сных командах подхода писать без тестов, унылостью хранилища и прочими вещами что приносят боль.


      1. EvilBeaver Автор
        18.12.2019 14:18

        Ну тут вопрос в направлении боли. А еще можно прочувствовать боль от глючащих ORM, самописных ролевых моделях доступа с дырками, трах с корректной печатью документов и необходимостью делать руками ВьюМодели под каждый класс предметной области… Боль, она разная бывает :)


        1. Neikist
          18.12.2019 14:21

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


          1. EvilBeaver Автор
            18.12.2019 14:23

            Многие разработчики — да предпочтут эту боль, т.к. им нравится долго и бесконечно перестраивать абстракции и играть в творца. А бизнесу нравится чтобы было быстро и приносило деньги.


            1. Neikist
              18.12.2019 14:28

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


              1. EvilBeaver Автор
                18.12.2019 14:30

                Про юзабельность иде я написал в статье достаточно четко — она не на нуле, она в минусе. Тут я вроде как солидарен, не?


                1. Neikist
                  18.12.2019 14:36

                  Ну так мы тут про скорость разработки. А IDE на это очень заметно влияет. Как и статическая типизация языка которая на начальных этапах и на маленькой кодовой базе разработку замедляет а на более поздних этапах и на больших проектах ускоряет.


                  1. EvilBeaver Автор
                    18.12.2019 14:50

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


                    1. Neikist
                      18.12.2019 14:58

                      А, ну в такой формулировке соглашусь, да.


      1. Honomer
        18.12.2019 14:33

        Писать без тестов — каждый сам себе злобный буратино. Возможность писать «с тестами» присутствует. И не одна.


        1. Neikist
          18.12.2019 14:38

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


        1. frkbvfnjh
          18.12.2019 14:46

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


          1. speshuric
            19.12.2019 00:29
            +1

            Потому что механизмы убогие и начинаются не там. Нахера, извините, сценарное тестирование форм, когда нет модульных и интеграционных тестов? А их нет, потому что модульность не завезли, DI не завезли, мокать невозможно, в IDE поддержки нет.


            1. Honomer
              19.12.2019 08:26

              Извините, но вы даже близко не попали.
              Были бы тесты, была бы и поддержка в IDE, и моки, и поэтессы наверное.
              Но отсутствуют они совсем по другим причинам.


            1. stilic
              19.12.2019 18:59

              Потому что механизмы убогие и начинаются не там. Нахера, извините, сценарное тестирование форм, когда нет модульных и интеграционных тестов? А их нет, потому что модульность не завезли, DI не завезли, мокать невозможно, в IDE поддержки нет.


              Типичный разработчик не эти глобальные вещи меняет вовсе.

              То что вы написали — эти вещи только сама 1С да те кто полноценные конфигурации разрабатывают — тем и нужно. А там есть способы.


          1. Honomer
            19.12.2019 08:30

            Практически все разработчики типовых используют тестирование — ERP/УПП, БП, ЗУП. Они об этом неоднократно говорили.
            Вот франчи — да, там это скорее редкость. Но опять-таки это от культуры конкретной команды зависит.


            1. stilic
              19.12.2019 18:55

              Практически все разработчики типовых используют тестирование — ERP/УПП, БП, ЗУП. Они об этом неоднократно говорили.
              Вот франчи — да, там это скорее редкость. Но опять-таки это от культуры конкретной команды зависит.


              И от задач.
              Если это не какой-нибудь там Рарус, что полноценные конфигурации сам пишет — так задача у франча чаще «местного значения», весьма локальная, редко когда есть необходимость что-то полноценно тестировать.

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

              В этой схеме отдельное юнит-тестирование смысла не особо и полезно.


          1. stilic
            19.12.2019 18:50

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


            В известных мне веб-проектах — реализованные отдельные механизмы автоматизированного тестирования тоже редкость.

            В 1С тоже кто-то использует, кто-то нет.

            Ну и плюс специфика — этот функционал нужен еще вчера. А через три дня он будет уже изменен. А через полгода уже выключен.

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

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


            1. frkbvfnjh
              20.12.2019 07:04

              Подпишусь под каждым словом…


      1. frkbvfnjh
        18.12.2019 14:38

        На счет большой нагрузки — ни разу не спорю, но как указал автор, хозяевам 1С интересно все, что интересно бизнесу и большие нагрузки это важно, видимо поэтому в последних релизах появились механизмы позволяющие распределять таблицы одной базы по разным дискам или что то типа того. В свое время появились механизмы разделения итогов, управляемые блокировки и т.д. Что уж говорить, если в 1С 8.0 не было даже пакетных запросов. Сама платформа, как я понял, разрабатывается в таком ключе, что бы как можно быстрее дать готовое решение, а уже потом его оптимизировать — это наблюдается на протяжении всей истории платформ 1С8x. Отсюда собственно и скорость выхода новых релизов платформы с адским количество глюков, но зато быстро и что то новенькое, так сказать «рашн хард стайл программинг». В целом можно сказать, что 1С постоянно движется в направлении оптимизации и масштабируемости, пытается оседлать, так сказать, высокие нагрузки. И уже сейчас встречаются статьи где описывают успешно реализованные распределенные архитектуры на базе 1С которые выдерживают эти самые десятки тысяч пользователей. Да — ад, да — такое могут единицы, может и решения не тривиальные и не по учебнику, но уже есть зачатки и как то оно работает.


        1. Neikist
          18.12.2019 14:41

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


          1. frkbvfnjh
            18.12.2019 14:52

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


        1. pfihr
          19.12.2019 01:04

          я такие делал. и они из разряда "на 1с" быстро переходят в разряд "на sql", "на python" и т.п, а в 1с только формы ввода и остаются.


          1. stilic
            19.12.2019 19:03

            я такие делал. и они из разряда «на 1с» быстро переходят в разряд «на sql», «на python» и т.п, а в 1с только формы ввода и остаются.


            Видимо, вы сталкивались с крайне простыми бизнес-процессами, где дешево сделать на универсальных инструментах и это оправдано.

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

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


  1. longmaster
    18.12.2019 14:01

    При обсуждении темы про русский синтаксис почему-то никто никогда не вспоминает, или даже не задумывается, о другом аспекте. Дело вообще не в простоте для новичков. И совсем не в том, что синтаксис на родном языке, и так в чём-то легче.
    Это просто удобно. Это просто ОЧЕНЬ удобно!
    Автоматизируя бизнес-процессы в России, очень удобно именовать все сущности на русском языке. Не пытаться переводить их на английский, зачастую неправильно, не уродовать безумным транслитом. Практически любой большой проект автоматизации на других средствах вызывает порой гомерический хохот при виде наименований объектов и сущностей на латинице. Особенно с учетом того, что часто разработчики не очень хорошо знают английский.
    А теперь представьте написание кода, где все сущности именованы на русском, может даже переменные можно именовать на кириллице, но синтаксис самого языка — исключительно латиница! Да вы через неделю активной разработки раздолбаете Ctrl-Shift на клавиатуре, а потом словите нервный срыв!
    Я уж не знаю, сам ли Сергей Нуралиев в своё время придумал этот ход, но это оказалось отличной идеей для средств автоматизации учета именно в России. Ну и конечно же это совсем не значит, что как-то ограничивает продукты компании именно Россией, для всех остальных Андрей правильно заметил — всегда есть синонимы на латинице.


    1. Neikist
      18.12.2019 14:07

      Да никто уже 300 лет не вспоминает про русский синтаксис, всем давно уже все равно на двуязычность. Откуда у вас такие стереотипы?


    1. vvbob
      18.12.2019 14:13

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

      Либо у вас странное чувство юмора, либо вы видели исключительно какие-то поделки говнокодеров. Сколько разных проектов видел — именование сущностей стандартно делается на английском, этих сущностей не так много и даже не зная английского запомнить их не сложно. А если так уж охота «угореть по русскому» — та же Ява, как пример, давно поддерживает юникод и не запрещает писать все на русском (кроме операторов, само собой).


      1. EvilBeaver Автор
        18.12.2019 14:22

        даже не зная английского запомнить их не сложно

        А еще, не зная английского можно называть классы VypuskProduktsii, BillData, имея в виду BillDate и даже KladovshikAccessRights, имея в виду вообще хер знает что.


        Что, не попадались такие вещи от серьезных профессионалов своего дела, которые не марают руки об 1С?


        1. vvbob
          18.12.2019 16:37

          От серьезных нет, не встречалось. Обычно это стиль джунов, вчерашних студентов, и за такое именование в нормально поставленном процессе на ревью их постоянно бьют по рукам и заставляют переименовывать. Если вижу такое в коде — это один из основных признаков новичка. Сейчас даже не зная английского (что довольно странно для разработчика — не знать его на уровне хотя-бы чтения документации) не составляет никакой проблемы подобрать перевод с помощью того-же гуглопереводчика или словаря, хотя-бы. Да просто спросить, обычно разработчики не в вакууме пишут, спросить у соседа как лучше назвать «ВыпускПродукции» — это не «зашквар».


          1. akabrr
            18.12.2019 17:20

            С помощью гугла переводчика коллеги перевели название документа «Забор», имелось ввиду — забор груза, как fence.


            1. vvbob
              18.12.2019 17:26
              +1

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


          1. stilic
            18.12.2019 17:48

            Сейчас даже не зная английского

            Знание языка знанию языка рознь.

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

            Уже не говоря, что в разных регионан могут быть свои особенности названий.

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


            1. vvbob
              18.12.2019 18:01

              Ну так вы и по русски скорее всего не будете этих терминов знать. Пока в предметной области не разберетесь, русский язык в наименовании объектов вам не поможет. Что дезоксирибонуклеиновая кислота, что Deoxyribonucleic acid вам одинаково будет непонятно.


              1. stilic
                18.12.2019 18:22

                Ну так вы и по русски скорее всего не будете этих терминов знать

                Вы сможете передать носителю знаний прикладной области термин без ваших домыслов и искажений некорректного перевода с английского.

                Иначе получите детскую игру в «испорченный телефон».


          1. speshuric
            19.12.2019 00:36

            Привет вселенной розовых пони! В нашей вселенной во всех российских банках в Java-коде и в базах данных творится совершенно другое. Там идентификаторы в лучшем случае через гугл-транслейт написаны. Плюс ещё терминология бизнеса не совпадает с обратным переводом. И именно поэтому в банках трудятся тысячи аналитиков — если по-честному, то половина их работы разбараться в этой мешанине из идентификаторов.


            1. EvilBeaver Автор
              19.12.2019 15:23

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


            1. vvbob
              19.12.2019 15:45

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


              1. EvilBeaver Автор
                19.12.2019 17:07
                +1

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


              1. stilic
                19.12.2019 19:09

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


                Исчезнет ненужно для внутрироссийской разработки лишнее звено, которое превращает процесс в детскую игру «испорченный телефон» (когда выстраиваются в цепочку и на ухо по очереди передают друг другу фразу, что к концу цепочки преобразуется в нечто странное).

                Следовательно, качество результата (скорость его получения) улучшится, да.

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

                Другое дело, когда вы переводите его с английского с искажением смысла.

                Проблем нет только в общекомпьютерной терминологии, в универсальной терминологии, в простейших понятиях.

                А стоит погрузиться в предметную область — все становится очень и очень непросто.

                Даже профессиональный переводчик, если он не специализируется на этой области — и тот переведет некорректно.

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


      1. stilic
        18.12.2019 15:35
        +1

        Сколько разных проектов видел — именование сущностей стандартно делается на английском, этих сущностей не так много и даже не зная английского запомнить их не сложно.


        1) Ну это вы такие проекты видели. Я вот видел наименования сущностей на итальянском и французском — это жесть, работать невозможно, если ты языка не знаешь.

        2) А еще зачастую встречал, когда из-за слабого знания языка термины прикладной области или воспринимаются программистами с ошибками (что вообще страшно) или попросту разработка идет крайне медленно.

        Ваша ситуация когда все просто — когда речь идет об универсальных терминах. Стоит копнуть глубже, погрузившись в предметную область (если эта область не ИТ), то все — приехали, вокруг вас фактически иероглифы. И вроде бы разжеванное другим разработчиком длинное название метода/класса/переменной дает вам не больше понимания о программе, чем просто i1, i2, i3.


        1. vvbob
          18.12.2019 16:44

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


          1. stilic
            18.12.2019 16:49

            Если вы не разбираетесь в предметной области, то тут и знание языка не сильно поможет


            Программист + разбирающийся в предметной области + на не родном языке = золото в количестве веса тела этого программиста.

            В подавляющем большинстве все гораздо-гороздо проще.

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

            P.S.:
            Согласно вашей формулировке программист заведомо более квалифицирован чем любой другой специалист в предметной области, так как программист должен знать предметную область + программирование.

            А это не так.


            1. vvbob
              18.12.2019 16:55

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


              Э неет, не согласен. Так приятно, конечно думать, будучи программистом, но это не так. Программист должен разбираться в предметной области, что-бы говорить на одном языке со специалистами, так-же как и взаимодействующим с разработчиками специалистам полезно хоть немного быть в теме. Но уровень этого «разбираться» может быть разным. Даже среди узких специалистов нет одного уровня квалификации — всегда кто-то лучше, кто-то хуже разбирается, а того что просто разбирается в предмете, но не является специалистом, называть заведомо более квалифицированным — это не корректно.


              1. stilic
                18.12.2019 17:21

                Не понял, зачем вы ко мне процитировали это, где вы у меня это нашли:

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

                Это вообще не ко мне вопрос.

                Но вот на это отвечу:
                Программист должен разбираться в предметной области


                В идеале, — да.
                Фактически — такой программист автоматически становится золотым. Ибо он «специалист по предметной области» + «еще и программист».
                Именно поэтому в серьезных проектах, где цена подобных специалистов зашкаливала бы — и существую специальные методологии постановки задачи.
                Чтобы человек даже не разбирающийся в предметной области, мог бы задачу выполнить корректно.

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

                То, что «программист должен знать бухгалтерские проводки» — это ошибочное суждение. Бухгалтер должен говорить программисту какие проводки в каком случае. Программист должен только знать слово проводка.

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

                Но если данный термин будет на английском из-за какого-то дурацкого принципа не программировать с использованием русского языка — то мы получим просто ухудшение качества работы. Знаете такую детскую игру «испорченный телефон», когда по цепочке на ухо друг другу передают какой то смысл, и на другом конце цепочки смысл оказывается искаженным? Вот это оно самое.

                Ради чего? Ради того, чтобы показать кому-то как ты круто знаешь английский язык?


                1. vvbob
                  18.12.2019 17:52

                  По поводу цитаты — извините, копипаста вслепую иногда приводит к таким казусам :)

                  Там должно было быть

                  P.S.:
                  Согласно вашей формулировке программист заведомо более квалифицирован чем любой другой специалист в предметной области, так как программист должен знать предметную область + программирование.


                1. vvbob
                  18.12.2019 17:57

                  Я с вами в принципе согласен, по поводу квалификации, не должен программист в проводках разбираться лучше бухгалтера. Но вот когда я этим занимался — насмотрелся на… «девочек» бухгалтерш, которые в бухучете разбирались хуже меня (а я в нем тоже не был знатоком). Впрочем это загоняет дискуссию уже совсем в какие-то дебри.


                  1. mvladlin
                    19.12.2019 13:19

                    Согласен, я слышал от одного главного бухгалтера такое мнение: «бухгалтер не обязательно должен знать проводки, есть же программа, она должна правильно все сделать». Мои попытки возразить — не увенчались успехом.


                    1. vvbob
                      19.12.2019 13:24

                      Ага, и классика жанра — «Опять ваша дурацкая 1С все не правильно посчитала, а мне завтра отчет сдавать, ААААААААААААААААААААААА!!!!!!!!»
                      Потом выясняется что «специалист» просто «не умеет в бухучет», как сейчас принято говорить, и начинаешь терпеливо преподавать истерящей даме краткий курс бухучета (при том что сам в нем не то что-бы очень..) Жуть! Как вспомню, так вздрогну, слава богу теперь этим не занимаюсь.


                  1. stilic
                    19.12.2019 19:36

                    Но вот когда я этим занимался — насмотрелся на… «девочек» бухгалтерш, которые в бухучете разбирались хуже меня (а я в нем тоже не был знатоком).


                    Эти бухгалтерши по факту были операторами ввода данных.
                    Ничего удивительного. Бухгалтера эникеев тоже нередко называют программистами.


      1. apxi
        18.12.2019 16:40

        «Не так много» ??!!! Охренеть, откройте ERP, хотя нет, давайте попроще, откройте БП как самую простую и посмотрите все сущности.
        Много кто поддерживает юникод, только как правильно заметил longmaster через неделю вы раздолбаете Ctrl-Shift (хотя Alt-Shift удобней), а потом проклянете этот проект.


        1. Neikist
          18.12.2019 16:45

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


          1. apxi
            18.12.2019 16:47

            вот если будете на двух языках писать, то совсем отсохнет


            1. Neikist
              18.12.2019 16:49

              Вот я как раз 4 года и писал на 1с, причем что & что <> вводил именно переключая раскладку а не через alt+38 и подобное.


              1. apxi
                18.12.2019 17:38

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


                1. Neikist
                  18.12.2019 17:47

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


                  1. stilic
                    18.12.2019 17:49

                    Не уверен но вроде оно админских прав требовало.


                    Есть портативный менеджер раскладок клавиатуры. Даже установки не требует.



        1. vvbob
          18.12.2019 16:49

          Видел я и ERP и БД всевозможные, «букв» много, но подавляющее большинство понятий там составлено из относительно небольшого количество слов. Как в любом нормальном ЯП ключевых слов с десяток.


          1. apxi
            18.12.2019 17:41

            А если буквы посмотреть их вообще 33 штуки, но слов поболее будет.
            Как будет на английском «Книга учета доходов расходов» или " Данные о корректировке сведений о застрахованных лиц СЗВ КОРР"
            В любой случае писать на том языке на котором говорят пользователи работающие с ПО, намного проще.


            1. vvbob
              18.12.2019 17:45

              The book of income and expense
              Гуглоперевод. Вполне понятный на мой взгляд, не вижу никакой проблемы.


              1. apxi
                19.12.2019 08:16

                Через месяц забудете этот перевод и будете по каждому чиху лазить в гугл переводчик.


            1. Figurnov
              18.12.2019 18:28
              +1

              Перевести на английский словосочетание «Книга учета доходов и расходов» будет затруднительно. У англичан и американцев такую книгу, насколько мне известно, использовать для ведения учета не принято. Учет доходов и расходов обычно ведется отдельно, например в sales ledger и purchase ledger. Более того, набор книг и журналов, используемых для ведения финансового учета коммерческой организации, и формы этих книг и журналов устанавливает сам хозяйствующий субъект по своему усмотрению, а не правительство и не министерство финансов.


              1. apxi
                19.12.2019 08:15

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


                1. stilic
                  19.12.2019 19:44

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


                  И практически сразу спотыкаемся. Следите за руками:

                  Системный аналитик, ставящий задачу, оказывается знакомым с англоязычными терминами предметной области и использовал более правильное
                  «sales ledger, purchase ledger»

                  А программист, незнакомый с предметной областью, использовал просто кальку с английского, что дал ему Гуглепереводчик (ну или сам он знает английский без спец. терминов предметной области — наверняка и без Гуглепереводчика так же перевел бы и сам):
                  «The book of income and expense»

                  И это еще мы на самой поверхности. В конце концов, «The book of income and expense» с английского Гуглепереводчиком переводится и обратно нормально, я проверил только что.

                  А теперь берем другой распространенный термин:
                  «Вычет на ребенка с налога на доходы физических лиц»

                  Гуглеперевод:
                  «Deduction per child from personal income tax»

                  Обратный гуглеперевод:
                  «Удержание на ребенка с подоходного налога»

                  Повторим еще раз:
                  «Child Income Tax Withholding»

                  Обратно:
                  «Удержание подоходного налога с детей»

                  Налога с детей???


                  1. Honomer
                    20.12.2019 10:04

                    Качество гугл-переводчика — это та самая притча…
                    Полагаться на его перевод в чуть более или менее серьёзных вещах — это стрелять себе в ногу.
                    Впрочем, говоря на чистоту, тут никто не может похвастаться. Косячит и яндекс, и deepl, и все остальные. Просто перевод основанный на «статистической» модели, или как там Гугл говорил правильно, другим быть не может.


    1. marmyshev
      18.12.2019 14:29
      +1

      Почему-то, эти тупые забугорные программисты не плюются от того что пишут на своём родном языке, а не на «китайском» например)) А русского программиста это почему-то оскорбляет))


    1. stilic
      18.12.2019 15:08

      Дело вообще не в простоте для новичков. И совсем не в том, что синтаксис на родном языке, и так в чём-то легче.
      Это просто удобно. Это просто ОЧЕНЬ удобно!

      Из-за отсутствия на русской раскладке некоторых символов пунктуации, что есть только в латинской — есть и неудобства.

      Но использование названий объектов прикладной области на языке, что ты знаешь с детства, а не начал учить только в школе — да, это безусловно удобно.

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

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


  1. elisoffka
    18.12.2019 14:52
    -2

    Согласен:
    1) Компания 1С решает свои проблемы и проблемы клиентов за деньги.
    2) По оценке рынка специалистов и проблем предприятий с ним
    3) 1С это хорошо потому что быстрая отдача для клиента из коробки

    Теперь по существу:
    1) 1C это не фреймворк, это программа вроде Access, несмотря на сильно расширенный функционал и появление 2 звена в виде сервера предприятия.
    2) Не знаю как сейчас, но меня терзают сильные сомнения в знаке равенства между ЕЕ Java и 1С по крайней мере 5-10 лет назад
    3) 1С хорошо работает на ларьках и сети ларьков и масштабирует именно на торговых предприятиях. В остальных случаях где бизнес логика сильно отличается от торговли ,1С не работает.Но это не волнует компанию 1С они заботятся о самом крупном и простом секторе рынка — шавермочные и ларьки.
    4) Не знаю как сейчас, но несколько лет назад оптимизация SQL, которая позволяла не заботится о квалификации джуна была не сильно лучше запроса, написанного этим самым джуном и на базе в несколько десятков ГБ отчет можно было ждать вечность, но это не расстраивало бизнес которому надо здесь и сейчас и поэтому я лично наблюдал 4ПК подключенных к монитору через KVM с запущенными с утра отчетами, которые вечером можно было послать руководству по почте.
    5) В посте описанная простота входа сильно компенсируется тем что программист 1С это 90% технолог\специалист по бизнес логике\ПМ\консультант по работе с 1С

    Итого: если торговая компания или около того — хорошо
    если нет, то это сильно странный выбор
    страна большая и в глубинке фуллстек кодера не найти

    Все выше сказанное написано с учетом того что Bitrix это отдельный продукт.


    1. EvilBeaver Автор
      18.12.2019 14:53

      Я, конечно, заапрувил комментарий, но все что в нем написано, это настолько мимо кассы, что аж слов нет.


      1. elisoffka
        18.12.2019 15:04

        Это реальная компания, которая страдала от 1С, точнее от того что 1С не заточена под крупный бизнес. Мы же о реальном бизнесе на реальной земле и о том как 1С заботится о этом бизнесе. Помню как после обновления сервер предприятия перестал падать 2-3 раза в день, и в этом обновлении появились процессы(там был странный алгоритм смерти и рождения этих процессов) в этом сервере предприятия, но падать он не перестал, просто падал реже, а бизнес тот круглосуточный и в договорах за простои штрафы. Вы ведь заметили что я обсуждаю продукт из коробки, главную модель продажи 1С? Другая компания в этом же холдинге изначально использовала Oracle на самом нагруженном по данным направлении и не знала таких проблем.


        1. EvilBeaver Автор
          18.12.2019 15:21

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


          1. elisoffka
            18.12.2019 15:34

            Да да да. Я тут как то яндекс моней дей ходил и на мой вопрос -«а почему в платежке распечатанной нет информации о платеже и плательщике?» мне ответили что это баги. Вот и вы заняли странную позицию. Я же четко написал что после апдейта оно падать перестало само собой.Да и конфа там была почти полностью топовой т.к. от программистов было одно название. Да и к счастью российского бизнеса сервер 1с предприятия это не оракл с его десятками сертификаций и там. А отрицать главное конкурентное преимущество 1с такое как набрать студентов за доширак не стоит. Вы видимо давно джунов не искали по рынку.


        1. stilic
          18.12.2019 15:23

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


          Вряд ли тут проблема самой 1С.

          Мне кажется, что тут проблема в конкретных специалистах.

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

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

          Другая компания в этом же холдинге изначально использовала Oracle на самом нагруженном по данным направлении и не знала таких проблем.


          Узкоспециализированное решение (написанное грамотным разработиком конечно) завсегда будет иметь преимущество в этом пункте перед решением универсальным.

          Другое дело, что узкоспециализированное быстрое решение — еще и малофункциональное и не гибкое. И разработка/доработка его не дешёва и не быстра (кроме самый примитивных ситуаций).

          Поэтому нужно балансировать:

          Когда-то выгоднее использовать уже готовое универсальное,
          а когда выгоднее узкоспецилизированное созданное под конкретную задачу.


      1. elisoffka
        18.12.2019 15:08

        А если вы намекаете что 1С это не продукт, а платформа, то давайте попробуем внедрить ее в телекоме ну например попробуем заменить Zabbix или что нибудь еще. Для упрощения задачи агенты мониторинга предлагаю оставить любые левые.


        1. marmyshev
          18.12.2019 15:16
          +2

          Здесь намекает автор, что вы вообще не поняли статью.
          То, что вы высказываете свою боль — это понятно. Но не по теме данной статьи.

          Одно дело обсуждать Фреймворк, другое дело обсуждать «компанию» и третье дело обсуждать какой-то конкретный неназванный продукт (приложение, конфигурацию) написанную на этом фреймворке.


          1. elisoffka
            18.12.2019 15:28

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


        1. EvilBeaver Автор
          18.12.2019 15:22

          Статью не читали, да? Там четко написано где не надо делать на 1С


    1. stilic
      18.12.2019 15:13

      В остальных случаях где бизнес логика сильно отличается от торговли ,1С не работает


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

      Да и торговля — для многих видов деятельности вполне универсальный механизм.
      Лично адаптировал торговые конфигурации под различные производства, к примеру. Там львинная доля кода все так же переиспользуется.
      Самые серьезные доработки только для одного единственного документа «Выпуск продукции с расчетом издержек». Очевидно, что в торговой конфигурации такого нет.
      В ответ на вопрос: а зачем: тут решает доступность специалиста. Внедрять и поддерживать изначально специализированное решение, но с которым никто не знаком в ближайшем окружении — далеко не всегда выгоднее, чем просто допилить под себя то, что ты уже знаешь.

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


      1. elisoffka
        18.12.2019 15:21

        Есть масса вещей, которые не торговля и не производство. Представьте, допустим, РЖД и попробуйте угадать где кроме бухгалтерии используется 1С и сколько там всего что не укладывается в конфигурации 1с.


        1. EvilBeaver Автор
          18.12.2019 15:24

          Более того, я нигде не сказал, что надо делать все и на 1С. Я как раз сказал ровно обратное


          1. elisoffka
            18.12.2019 15:40

            Я не против вашей статьи в целом, просто заагрился на то что вы назвали 1С — фреймворк \среда разработки(«Считайте, что это Spring или ASP.NET, выполняемый некоторой средой выполнения (JVM или CLR соответственно).»).


            1. EvilBeaver Автор
              18.12.2019 15:52

              Разве эта аналогия неверна? В каком месте?


              1. elisoffka
                18.12.2019 16:08

                Верна, с точки зрения теории, но не сточки зрения практики и функциональности особенно в сравнении с Spring или ASP.NET.


                1. EvilBeaver Автор
                  18.12.2019 16:18

                  Ну оно как-бы все 3 фреймворка несколько разнятся по функциональности и целевому назначению слегка. Имелась в виду именно теория — пояснение архитектуры верхнего уровня.


            1. ZEEGIN
              18.12.2019 15:55

              Дело в том, что 1С и является фреймворком)


              1. elisoffka
                18.12.2019 16:07

                Да, но явно не дотягивает до Spring или ASP.NET с которыми 1С сравнили. А формы с VB и подключеним с к БД есть и в аксессе, на котором кстати почти все работало в начале 200х в одном из крупнейших ритейлеров.И работало кстати достаточно быстро.


                1. ZEEGIN
                  18.12.2019 16:32

                  Скорее спринг не дотягивает до 1С, сумасшедший поток абстракций, а в 1с создал объект и вот тебе и форма пользователя для десктопа и для веб клиента и структура в бд и rest api.


                  1. EvilBeaver Автор
                    18.12.2019 16:37

                    Это слишком просто для небожителя


        1. stilic
          18.12.2019 15:26
          +1

          Представьте, допустим, РЖД


          О. Да вы типичный пример привели. Серьезно. Типичный?
          Не стоит переживать за РЖД при их-то финансовых возможностях.

          Впрочем я на это ваше высказывание уже ответил заранее:
          habr.com/en/post/480658/#comment_21028022
          Но не спорю, что, разумеется, всегда можно найти сферу деятельности под которую 1С не годится.


          1. elisoffka
            18.12.2019 15:37

            Тогда возьмем итог статьи где сказано — «1С это фреймворк быстрой разработки приложений (RAD) для бизнеса и заточен под это.»
            РЖД бизнес? 1С Фреймворк?
            зачеркните лишнее.


            1. EvilBeaver Автор
              18.12.2019 15:55

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


              1. elisoffka
                18.12.2019 16:11

                Ок, разжую. Вот есть объекты в ООП, но суть не в этом, вот если основные объекты бизнес логики это не документ\отчет\печатная форма\продажа, то 1С не вариант.


                1. ZEEGIN
                  18.12.2019 16:33

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


                  1. elisoffka
                    18.12.2019 16:51
                    -1

                    Все кроме продаж\бухгалтерии, не?


                    1. EvilBeaver Автор
                      18.12.2019 16:57

                      Нравятся мне люди, аргументирующие словом "всё" на просьбу назвать что-то конкретное )


                      1. elisoffka
                        18.12.2019 17:12

                        Телеком, РЖД, все уже приведено.Но примеры не понравились, понимаю, больно, а как вы хотели?


                        1. stilic
                          18.12.2019 17:50

                          Телеком, РЖД, все уже приведено.Но примеры не понравились, понимаю, больно, а как вы хотели?


                          Почему задачи учета в бизнесе в телекоме и на железной дороге не решаемы 1С?

                          Снимать телеметрию с оборудования РЖД — рационально специализированным софтом, конечно.


                    1. ZEEGIN
                      18.12.2019 17:10

                      Откуда вы такое берете вообще?
                      Есть четкая методика того какие объекты 1С для каких задач надо использовать.
                      https://its.1c.ru/db/v8std#content:683:hdoc
                      Любые бизнес процессы компании и большинство механизмов автоматизации не связанные непосредственно с бизнес процессами ложатся на эти объекты, если не все. На 1С можно автоматизировать что угодно, от учета бензина на заправке с автоматическим считыванием датчиками состояния в цистернах до полной роботизированной автоматизации складского учета.
                      Вот, например, ребята мобильное приложение для отслеживание занятий фитнесом сделали https://play.google.com/store/apps/details?id=com.rarus.gyms
                      Кто-то делает планировщик занятий в университете.
                      Кто-то делает управление картотеками и библиотеками.
                      Производство. Строительство. Медецина. Сельское хозяйство. Культура. Оказание услуг. CRM. Управление зарплатой и кадрами. Управление проектами (вот, например, открытый проект https://github.com/BlizD/Tasks управления задачами с канбан доской).
                      Системы управления инфраструктурой и мониторингом серверов.
                      Да почти любые бизнес задачи можно решить.
                      Опять же, что не стоит решать на 1С отлично написано в статье.


                      1. elisoffka
                        18.12.2019 17:17

                        У меня была возможность пойти по пути темной стороны еще в те времена когда v8 на горизонте не предвиделось.Да сейчас понимаю что тогда над было становиться франшизером и стричь бабло, но не судьба, я тогда увлекся юниксом, сайтиками и много чем еще т.к. мне тогда сильно не понравились приколы с изменением задним числом и перепроведением(так вроде называлось) базы и косяки с остатками если это перепроведение падало на 3 дне и это мне досталось от франчайзи. Хотя речь не о франчайзи, а о странной бизнес логике типовой конфы исправления задним числом (торговля и склад) и последующих мучительно долгих перепроведениях.Т.е. если я правильно понял остатки меняются если документ создан\исправлен в определtнном интервале дат, если это было давно, то крути верти документами как хочешь, остатки те же- «как те такое Илон Маск?»

                        Это я все к тому что смотреть эти красивые картинки и буклеты желания нет.


                        1. EvilBeaver Автор
                          18.12.2019 17:19

                          Но авторитетное мнение по обсуждаемому вопросу вы, все же имеете, да? Замечательно!


                          1. elisoffka
                            18.12.2019 17:26

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


                        1. ZEEGIN
                          18.12.2019 17:29

                          Значит это все таки личная обида


                      1. elisoffka
                        18.12.2019 17:24
                        -1

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


                        1. EvilBeaver Автор
                          18.12.2019 17:29

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


                          1. elisoffka
                            18.12.2019 17:32

                            Ой, а не через подписку ли поставлялись для бухгалтерии последние апдейты в сильно меняющемся законодательстве. А ведь именно бухгалтерия тогда делала 90% продаж ИТС и более половины продаж 1С продуктов.Там же и последние печатные формы в соответствии с законом были и все остальное.


                            1. EvilBeaver Автор
                              18.12.2019 17:40

                              Иии? Большевицкие жидомасоны из 1С купили правительство и заставили его выпускать дурацкие законы, чтобы повысить продажи ИТС?


                              А потом, видимо, проделали то же самое с Microsoft и производителями антивирусов, да?


              1. PS_erg
                18.12.2019 16:52
                +1

                Как минимум в трех аэропортах используется система на базе 1С, которая выводит данные на табло в терминалах, озвучивает с помощью движка text-to-speech аудиооповещения, обменивается данными с сайтами, принимает и отправляет телеграммы авиакомпаниям и много чего еще…


                1. elisoffka
                  18.12.2019 17:30

                  У меня есть знакомый программист, его основная задача интегрировать обмен из разных сторонних приложений в 1С и обратно. И это страшное слово ОБРАБОТКА, которое призвано решать все проблемы обмена между приложениями с помощью ТЕКСТОВЫХ ФАЙЛОВ. Полагаю там то же нечто подобное практикуется.


                  1. ZEEGIN
                    18.12.2019 17:37

                    Темный у вас знакомый, сейчас можно использовать RabbitMQ.
                    Хотя в прочем 1С работает и с другими механизмами интеграций
                    https://v8.1c.ru/platforma/integraciya/


                    1. Neikist
                      18.12.2019 17:45

                      У нас с вами уже как то был в телеге спор на тему того что 1с принудительно заставляет партнеров кто новую коробку делает по 1с: совместно лепить обмен через КД, а КД это файлы. И даже несмотря на то что есть возможность якобы через веб сервисы работать — и там тоже файл. Потому что коробка. Потому что нужно чтобы было как все давно привыкли и более современные подходы — ни-ни. Причем из за специфики именно КД 2, хотя конфа только совсем недавно разрабатывалась. Что там сейчас кстати с кастомизацией enterprise data для КД 3, это разрешено при разработке коробок?


                      1. Ta_Da
                        18.12.2019 17:52

                        Простите, КД это «сериализация в XML по определенным правилам». Транспорт обмена в БСП, если я ничего не путаю, это не только файлы, а еще и веб-сервисы, например.

                        КД 3 не является «улучшенной версией» и заменой КД 2, в общем случае. Это по сути другой продукт, с другими задачами.


                        1. Neikist
                          18.12.2019 18:00

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


                          1. Ta_Da
                            18.12.2019 18:05

                            Ну дык… unix way «все это файл» и все такое.

                            Причем эти файлы расчитаны только на 1с

                            С учетом того, что в них кроме просто данных, может содержаться еще и логика обработки их в приемнике, ничего удивительного.
                            Это, согласитесь, не совсем претензия, что для обмена 1С-1С нужно использовать 1С. Если обмен 1С-«Что-то», то да, КД не лучший вариант, но по крайней мере знакомый неизвестному 1С-нику, который будет решение обслуживать/внедрять.


                            1. Neikist
                              18.12.2019 18:09

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

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


                              1. Ta_Da
                                18.12.2019 18:19

                                Для решения этой проблемы как раз КД 3 и делали.
                                НО! надо понимать, что вот все эти готовые инструменты (при всем их удобстве), это реверанс в сторону типовых конфигураций на поддержке и попытке снизить порог требований к поддержке.
                                Я сам не большой фанат КД или, допустим, БСП, но вполне понимаю плюсы обоих решений.


                                1. Neikist
                                  18.12.2019 18:44

                                  А вот КД 3 раздражает залоченным по сути форматом, насколько я помню ситуацию.


                                  1. Ta_Da
                                    18.12.2019 18:46

                                    Потому что он другую проблему решает — обмен опять же между/с типовыми, без необходимости переписывать правила в обеих базах, если одна из конфигураций изменилась.
                                    В КД 3 можно добавлять свои поля в существующие схемы. Опять же — решение для вполне конкретного круга задач.


                                    1. Neikist
                                      18.12.2019 18:47

                                      А если в формат не вписываешься — беда. Нормального способа сделать обмен и угодить 1с нет.


                                      1. Ta_Da
                                        18.12.2019 19:13

                                        Что значит «не вписываешься»? КД 3 это обмен между базами конкретными видами документов.
                                        Вашему решению с чем нужно было обмениваться и какими данными? Можно в общих чертах, без конкретики.

                                        Но в неком абстрактном случае (обмен с типовой, нестандартными данными и необходимость получения шильдика от 1С) — да, возможно и нет более «нормального» метода, чем использовать КД 2, со всеми его минусами.


                                        1. Neikist
                                          18.12.2019 19:24

                                          Данные об оборудовании, ремонтах, наработке оборудования, статистике отказов, выявленных дефектах, критичности этого дела, плюс еще что то в таком духе, уже больше года прошло, не помню уже ничего. Обе конфы наши 1С: ТОИР <-> 1С:RCM


                                          1. Ta_Da
                                            18.12.2019 20:34

                                            Как я понимаю, тут КД 3 не подходит в принципе.

                                            КД 2, с учетом того, что это обмен между вашими (как компании-разработчика) коробочными решениями, как раз-таки подходит отлично.
                                            В такой ситуации не совсем понятно возмущение о необходимости «разобраться в чужой бизнес-логике». Даже проблем при обновлении не будет — если правила «сломались», то вы сами и виноваты в изменении конфигурации.


                                            1. Neikist
                                              18.12.2019 20:38

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


                                              1. Ta_Da
                                                18.12.2019 20:48

                                                Нет, как раз 1С и заботится о разработчиках, которые будут внедрять систему, поэтому и требует чтобы вы использовали стандартный способ обмена 1С-1С — Конвертацию данных. Которую условный средний 1С-ник знать должен. А вот специфический экзотический обмен, который вы придумаете — не обязательно.

                                                Причем еще раз повторимся, для тех, кто будет это читать и не в курсе (я вот специально проверил сейчас), что такое «1С: Совместно» — это по сути набор требований от компании 1С к продуктам, которые кто-то хочет включить в общий прайс по всей партнерской сети 1С. При этом 1С еще и обязуется, что в случае если компания-разработчик вдруг исчезнет, взять решение на поддержку. Логично, что появляется требование к стандартам и используемым инструментам.
                                                Не хотите продавать решение через партнерскую сеть? Ок, можете не использовать КД 2.


                                                1. Neikist
                                                  18.12.2019 22:06

                                                  Ну, видимо у нас разные понятия о заботе о программистах)


                                                  1. Ta_Da
                                                    18.12.2019 22:59

                                                    Смотрите, какая получается ситуация.
                                                    Есть компания А — вендор платформы и владелец большой партнерской сети. Есть компания Б — на этой платформе делающая решение.
                                                    Компания Б хочет, чтобы компания А продавала ее решение через свою партнерску сеть + дала повесить на нее шильдик «Проверено вендером — Решение качественное» + взяла на себя риски поддержки этого решения, если вдруг компания Б исчезнет (понятно, что исчезать не планирует, но поддержка от вендора это еще один плюсик в глазах потенциального покупателя).

                                                    Компания А в ответ, предъявляет документ, которыей можно найти у нее на сайте, в которых описаны стандарты и критерии соответствия продукта шильдику «Проверено».
                                                    Пока у вас вопросов нет? С точки зрения бизнеса, без разницы причем, это делает 1C/Google/Apple/Microsoft или кто-то еще.

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


                                                    1. Neikist
                                                      18.12.2019 23:30

                                                      Вы сами прекрасно ответили, забота о бизнесе и заказчиках. То что разработчикам в 90% подобных случаев было бы удобнее с мессадж брокерами или рест апи работать, ибо позволило бы унифицировать и документировать интерфейсы, что часто упростило бы разработку и поддержку — вендору на удобство конечных разработчиков все равно.


                                                      1. Ta_Da
                                                        18.12.2019 23:38

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

                                                        И второе. Каким именно разработчикам, в 90% случаев было бы удобнее работать с мессадж брокерами, и протоколами, которые придумала ваша компания, если они все умеют (или должны уметь) работать с КД и на КД построены обмены в типовых (и многих не типовых решениях)? Вы опять путаете «разработчикам было бы интересно разобраться» и «разработчикам было бы удобнее/проще/быстрее».

                                                        Я сейчас не говорю о том, что КД лучшее решение, ни разу. Даже в решении «1С: Интеграция», которое вполне себе «1С: Совместимо», правила КД появились не сразу, насколько я знаю. Сначала там вообще использовались XSLT преобразования и это обозначалось как «плюс».


                                                        1. Neikist
                                                          19.12.2019 00:08

                                                          Это не проблемы моего прошлого франча что 1с загоняет партнеров палками в прошлый век? Как раз то что все работает на КД и конца и края этой порочной практике не видно — и показывает отсутствие заботы о разработчиках. Использовать такие решения как основные — это боль. Обязательно нужно знать обе конфигурации. Обязательно следить за версиями и доработками, для каждой пары разных конфигураций свои правила и прочее подобное.
                                                          Ну и никто не говорит про свои протоколы, нормальные документированные рест апи с json/xml например. Или MQ — тоже документировать и только в путь.
                                                          Даже если разработчику потребуется расширить интерфейсы обмена — поддерживать их будет все равно гораздо проще чем правила.


                                                          1. Ta_Da
                                                            19.12.2019 01:08

                                                            1с загоняет партнеров палками в прошлый век

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

                                                            Вы ведь понимаете, что если вы будете использовать нестандартный обмен, то его придется прикручивать во все типовые/отраслевые/другие «1С: Совместимо/Совместно» и придется заставлять партнеров изучать то, что вы придумали. Это не вариант от слова «совсем». Тем более «поддерживать будет гораздо проще, чем правила» — вам возможно будет проще.
                                                            Мне тоже было проще сделать свой обмен в ряде случаев (хотя как минимум в одном стоило воспользоваться форматом Enterprise, т.к. приемником была типовая БП3 на поддержке), но среднему 1С-нику это нафиг не нужно и ему это не проще. Да блин, даже среднему не-1Снику проще XML-ки гонять, а не MQ изучать.

                                                            Вот вы не лестно отзывались об Apple. Представьте ситуацию, вы делаете какой-нить модный фитнес-браслет, приходите с ним к Тиму Куку и говорите, «а давайте назовем его Apple SuperWatch, наклеим на него значок яблочка и продавать вы его будете в своих фирменных магазинах. но есть один нюанс — он работает только с телефонами Android». Вы понимаете, куда он вас пошлет с такой идеей?


                                                            1. Neikist
                                                              19.12.2019 01:23

                                                              Вы снова смотрите с т.з. бизнеса и с т.з. именно текущей ситуации. Да, это выгодно, но разработчикам менее удобно. Разработчикам было бы проще сделай 1с новую технологию. Да хотя бы более полноценный механизм расширения enterprise data позволяющий именно что каждой конфигурации декларировать поверх стандартного набора (либо набора чужой конфигурации) не просто новые поля, но новые данные. Да транспорт модифицировать для более удобной интеграции не 1сных систем — и то хлеб был бы, лучше чем то что сейчас.


                                                              1. Ta_Da
                                                                19.12.2019 01:38

                                                                Вы смешиваете два несвязанных вопроса:
                                                                — развитие платформы/решений и
                                                                — конкретную специфическую сертификацию решения.

                                                                1С как разработчик платформы добавляет поддержку JSON.
                                                                1С как разработчик решений выпускает «1С: Интеграцию» (кстати, работает не только через КД 2, и при этом имеет статус «1С: Совместно», так что дискуссия наша вообще странно выглядит — получается, что вы могли делать обмен как угодно, при условии наличия в конфигурации подсистемы из БСП) и «Конвертацию 3».
                                                                1С как поставщик решений, поддерживает существующий обмен с правилами КД2 и исходя из существующих и использующихся решений, требует (для сертификации по «1С: Совместно») использование КД2.


                                                                1. Neikist
                                                                  19.12.2019 01:51

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

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


                                                            1. stilic
                                                              19.12.2019 20:15

                                                              1с загоняет партнеров палками в прошлый век


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


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

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

                                                              Нет никакой проблемы и без КД


                                                              1. Ta_Da
                                                                19.12.2019 20:40

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


                                              1. elisoffka
                                                19.12.2019 09:14

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


                                                1. EvilBeaver Автор
                                                  19.12.2019 09:48

                                                  wrong


                                                1. stilic
                                                  19.12.2019 20:12

                                                  1C не заботится о крупном бизнесе и интеграция корпоративных приложений с эко-системой 1С их мало волнует.


                                                  Даже в среднем бизнесе интеграция — дело очень уникальное.

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

                                                  Это не так и сложно. Штатно платформа 1С поддерживает несколько разных технологий интеграции — выбирай подходящую и вперед.


                      1. Ta_Da
                        18.12.2019 17:59

                        Насчет «1С принудительно заставляет тех, кто делает коробку 1С: Совместимо». Ну… так вы же хотите шильду «1С: Совместимо»? Значит нужно использовать «стандартный» вариант обмена с другими конфигурациями.
                        Apple вон тоже требования к приложениям на свою ОС предъявляет, и ничего — все живы вроде. А они даже не дарят за это значок «Одобрено стандартами Стива Джобса» =)


                        1. Neikist
                          18.12.2019 18:01

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


            1. stilic
              18.12.2019 15:57

              Тогда возьмем итог статьи где сказано — «1С это фреймворк быстрой разработки приложений (RAD) для бизнеса и заточен под это.»
              РЖД бизнес? 1С Фреймворк?
              зачеркните лишнее.


              По поводу абсолютно любого инструмента можно найти примеры, где он не работает или работает плохо.

              Впрочем, полагаю автор процитированного вами имел ввиду — не для бизнеса, а для учёта в бизнесе.

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


        1. Ta_Da
          18.12.2019 15:27

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


        1. o4karek
          18.12.2019 15:28

          Есть много мест, где требуется учет. Но сваять на Платформе систему управления движением лично мне в голову не придет. Хотя, наверное, и это возможно.
          ЗЫ: Во времена 7.0 мне предлагали написать на этой платформе биллинг сотовой связи DAMPS. И директор конторы, где я тогда работал, очень сильно расстраивался после того, как на переговорах я открестился от этой идеи.


          1. stilic
            18.12.2019 15:38

            Во времена 7.0 мне предлагали написать на этой платформе биллинг сотовой связи DAMPS. И директор конторы, где я тогда работал, очень сильно расстраивался после того, как на переговорах я открестился от этой идеи.


            Возможно вы зря открестились.
            Если учесть при написании решения с нуля — платформа 1С предоставляет всего лишь довольно шустрый интерфейс доступа к СУБД (если не использовать автоматику 1С по работе с СУБД типа расчетов итогов регистров).

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

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

            А еще честнее было объяснить — что даже если написать на 1С и даже когда она работает, то ему не получится сэкономить как я выше написал.

            Так-то я видел биллинги написанные на чем угодно. На PHP и MyMSL, например. Включая ядро биллинга. Причем на том движке MySQL, что без полноценной поддержки транзакций. Строго говоря, может и не надо транзакций — зато быстро.

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


            1. o4karek
              18.12.2019 15:48

              эээ…
              начнем с простого — дата в 7.0 (которая в языке была доступна) не предполагала времени от слова совсем. В этой связи некоторые вещи было сделать нельзя by design (ну или изобретать собственный формат даты+времени). Возможности интеграции 7.0 — только COM, dbf и текстовые файлы. Интерфейс 7.0 назвать шустрым… немного нельзя. В интерфейсе 7.0 отсутствовало столько возможностей, что я их перечислять устану.
              И проблема была в том, что писать этот биллинг надо было мне. А написать это было нельзя. Я не считаю, что 1с-ник должен любой ценой запихать платформу в любую видимую дырку. Ведь потом с этим надо будет как-то жить.
              Любой инструмент имеет границы применимости. На условном БелАЗе сложно работать в такси в Москве. И на условной Камри не менее сложно возить породу в карьере.


              1. EvilBeaver Автор
                18.12.2019 15:57

                Это мой любимый пример — Феррари — полное дерьмо, щебня мало влезает, а бензина жрет много.


                1. o4karek
                  18.12.2019 15:58

                  Бензина она явно жрет меньше БелАЗа, но хуже то, что она в карьер просто не заедет.


                  1. EvilBeaver Автор
                    18.12.2019 16:01

                    Зачем в карьер? Мне на дачу щебенку возить по проселку. И навоз. Очень неудобная машина


              1. stilic
                18.12.2019 16:08

                начнем с простого — дата в 7.0 (которая в языке была доступна) не предполагала времени от слова совсем.

                Ну и в голых СУБД дата со временем появилась не сразу.
                Обходились как-то.
                Скажем использовать целое число в формате unix timestamp. Или даже строку.

                Возможности интеграции 7.0 — только COM, dbf и текстовые файлы.

                http с официальной внешней компонентой v7plus
                Да и перечисленного вами вполне хватило бы для очень многих задач. Было бы желание.

                Точнее, если вопрос стоял так:

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

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

                Конечно, можно сделать изящнее на более развитой по интерфейсу платформе. Но разве это обязательно?

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

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


                Если речь не идет о миллионах абонентов (а в описанном вами случае скорее речь о десятках тысяч в пике) то вполне можно.

                В те годы только предоплатная система была у операторов связи. И даже биллинги ведущих МТС/Билайна мало что умели в оперативном режиме делать.

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

                Я обратил внимание на вашу фразу:

                «Мне предложили написать биллинг на 1С и директор очень огорчился когда я отказался».

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

                Технически задача вполне себе реализуема.


                1. o4karek
                  18.12.2019 16:20

                  Технически задача вполне себе реализуема.

                  Попробуйте :) Именно на 7.0 (никаких 7.5 или, упаси Бог, 7.7).
                  Я не знаю (и тогда и сейчас), как адекватно (по производительности и устойчивости) реализовать эту задачу.
                  Если у вас получится — с удовольствием поучусь, как надо. Учиться никогда не поздно.
                  http с официальной внешней компонентой v7plus

                  На 7.0 не было такой компоненты. Там и внешних компонент-то не было :)
                  Базового функционала интерфейса 1С для очень многих вещей более чем достаточно.

                  Честное слово, вы, похоже, не представляете себе «базового функционала интерфейса» версии 7.0.
                  Например, оперативный сегмент написать на другом инструменте.

                  Вот именно это мне и предлагалось написать :)

                  Огорчился мой директор, а не директор оператора.


                  1. stilic
                    18.12.2019 16:44

                    Вот именно это мне и предлагалось написать :)
                    Огорчился мой директор, а не директор оператора.


                    Полагаю, что ваш директор огорчился, потому что ему посулили хороший куш.

                    Директор оператор тоже был доволен, потому что ему сказали что сделают неожиданно дешево.

                    Видите ли, эти директора — она далеки от технических вещей.

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

                    Когда такая ситуация мне встречается — я понимаю, что где-то рядом много денег. Начинаю разговаривать подробнее и в результате или выхожу на крупный проект (при этом совсем не обязательно, что на первоначальной технологии) или человек понимает, что это его фантазии.


                    1. o4karek
                      18.12.2019 16:57
                      +2

                      Я полагаю, что каждая проблема имеет свой инструмент для решения. И использовать для решения неподходящий инструмент — это показатель квалификации исполнителя. Другими словами — это непрофессионализм. И по результатам таких заходов появляется огромная масса тормозящих 1с-ов, которая неспособная справится с мизерной нагрузкой. Особенно после того, как ее немного поправили.
                      Мне и тогда (и после) платили деньги за то, что я решал проблемы, а не умножал их. У внедренца (хотя, скорее, у продажника, все-таки) должно быть хорошее качество: в нужный момент сказать: стоп! это выходит за рамки применимости инструмента. Мы или меняем инструмент или корректируем задачу.
                      Обсуждаемая статья тем и хороша, что черным по белому говорит: Платформа, как инструмент, имеет границы применимости. И важно понимать эти границы и вообще и в каждом конкретном случае.


                  1. stilic
                    18.12.2019 16:45

                    Если у вас получится — с удовольствием поучусь, как надо. Учиться никогда не поздно.


                    Движок DBF один из быстрейших в мире был в своё время.


            1. SwingoPingo
              18.12.2019 16:04

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


              1. EvilBeaver Автор
                18.12.2019 16:06

                Как понять не выживает? В каком месте?


                1. SwingoPingo
                  18.12.2019 16:23

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

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

                  В других применениях 1с на долгом промежутке не выживает. Я таких долгоживущий решений в отрыве от всей этой экосистемы не видел, хотя и сам по молодости писал.


                  1. EvilBeaver Автор
                    18.12.2019 16:27

                    Java — это язык программирования. Некорректно сравнивать язык программирования с фреймворком у которого жесткая зависимость от ORM-системы, на чем бы тот фреймворк не был написан.


                    И поверьте, 1С-как-язык-программирования прекрасно себе живет в отрыве и от базы данных и от объектов 1С.


                    1. SwingoPingo
                      18.12.2019 17:21

                      Мне кажется что вы согласны со мной в оценке что 1С это не «шустрый интерфейс для связи с СУБД» (во первых не шустрый, во вторых не только интерфейс, в третьих решений для связи с любыми субд на порядок или несколько меньше, чем для связи с БД в формате 1с). И ценность у 1С именно что в комплексе (быстро и сразу все).

                      //Про onescript не знал, но я не очень вижу реальную сферу его применения, право слово. Был бы к месту красивый пример, где onescript выступил бы в роли Д'Артаньяна.


                      1. EvilBeaver Автор
                        18.12.2019 17:35

                        да, я согласен насчет интерфейса к БД — я тоже не понял этого довода уважаемого комментатора.


                        Про 1скрипт — это был контраргумент на вашу фразу, мол Java "про нее можно сказать что это «всего лишь язык и машина для выполнения кода»".


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


                        Перечень вот тут Страничка, кстати, тоже написана на 1script


              1. Honomer
                18.12.2019 16:11

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


              1. stilic
                18.12.2019 16:12

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


                Речь конкретно об 1C v7.
                Формат её данных довольно прост.

                Файловая БД — это стандартный DBF. Что значат какие поля — нетрудно догадаться. Да и описания готовые есть.

                Вариант v7 под SQL — обладает той же структурой данных (в результате она плохо адаптирована под реляционные СУБД, так как рождена была для файловых).

                Существуют (ну или точнее существовали) продукты, которые напрямую извлекали данные из БД 1С.

                Это не сложно для программиста средней руки.


                1. Honomer
                  18.12.2019 16:13

                  Вы бы ещё про 6.0 вспомнили… Автор в своей статье говорит конкретно про платформу 1С: Предприятие 8. Зачем уходить от темы.


                  1. stilic
                    18.12.2019 16:16

                    Вы бы ещё про 6.0 вспомнили…

                    А при чем тут я?

                    Проследите ветку с начала — началось все с этого воспоминания времен v7.0, когда человеку предложили написать на ней биллинг, v8 тогда не было:
                    habr.com/en/post/480658/#comment_21028146

                    Написать биллинг на 1С v6 это нет.
                    А на v7 уже реально. Она была довольно шустрой, если знать как её готовить. Быстрее чем v8 (на огромных масштабах данных v8 быстрее, но биллингу совсем не обязательно все данные перебирать, достаточно ограничиться «горячими»).


    1. apxi
      18.12.2019 16:42

      Вы не в теме, вы не правы


  1. marmyshev
    18.12.2019 15:12

    Возможность типизации на уровне, например, TypeScript (как следствие более развитые средства анализа кода в IDE, рефакторинг, меньше обидных косяков)


    Вот тут близкая мне тема.
    Хочу немного (совсем чуть-чуть) не согласиться с тобой, ибо в новой IDE для 100% типизации кода есть все возможности.
    Другой глобальный вопрос — сделают ли во фреймворке режим для рантайма — чтобы тип нельзя было менять (жесткая типизация), но на этапе написания кода и компиляции — это уже сейчас есть возможность сделать.
    Тут — как раз «движение вперед» для языка 1С есть.


    1. EvilBeaver Автор
      18.12.2019 15:25

      для 100% типизации кода есть все возможности.

      Это поэтому она у меня на 16 гигах даже не стартует, да?


      1. marmyshev
        18.12.2019 15:28

        :) Наверное по другой причине)) я регулярно на 8Гб стартую ERP и работает…


        1. EvilBeaver Автор
          18.12.2019 15:47

          Сможешь выдать онлайн-мастер класс по запуску ЕДТ на моем ноуте? А то у нас как раз темы для стримов заканчиваются :)


        1. Honomer
          18.12.2019 15:55

          А сколько времени старт занимает, если не секрет?


          1. marmyshev
            18.12.2019 17:01

            А сколько времени старт занимает, если не секрет?

            Старт самой IDE занимает одинаково (примерно) хоть на ERP, хоть на любом микроскопическом проекте. 10-20 секунд у меня (тут все зависит от CPU и SSD).
            Дальше уже после старта есть фаза (условно) «Инициализации проекта», она сильнее зависит от объема проекта, т.к. проверяет актуальность данных на диске и с последнего запуска. Но если проект не менялся, пока IDE была выключена — то обычно 15-20 секунд.
            Так же далее идет открытие редакторов, которые были открыты в прошлой сессии — это еще время итд… а они за собой тянут немедленный старт внутренних сервисов… что тоже время.


            1. EvilBeaver Автор
              18.12.2019 17:18

              У меня на ноуте не стартует даже виртуальная машина Java в дефолтных настройках EDT. Грит "нимагу и всё". Я честно не пытался вникать, руки не дошли. Наверное там что-то надо подкрутить, но сам факт того что надо подкручивать после установки — меня напрягает


            1. Honomer
              20.12.2019 18:50

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


  1. SwingoPingo
    18.12.2019 15:27

    Всю ветку не осилил, но своих пару копеек вставлю:
    1 — идея о самопрограммирующем бухгалтере умерла не родившись, имхо и язык и объектную модель уже давно напрашивается привести в соответствие новой идее — программируют программисты.
    2 — хочется строгой типизации и весь доступный спектр sql инструментов желательно в какой нибудь крайней редакции.
    3 — фронт энд бэк разработка расходятся навсегда
    ну и 4 — отсутствие нормальной среды разработки лимитирует конечно


    1. o4karek
      18.12.2019 15:34

      1. Лозунг «Доступно и всерьез» (ИМХО) последний раз применялся в Бух 6.0. И там бухгалтер вполне мог самопрограммировать (и таких бухов было немало). А уже 7.5 такого лозунга и применения не предполагала.


      1. SwingoPingo
        18.12.2019 17:28

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


        1. o4karek
          18.12.2019 17:41
          +1

          За стабильность и обратную совместимость.
          Просто представьте, что в какой-то момент времени раз и новая версия получит другую реализацию СКД. Ну вот совсем другую. И внезапно те 100500 миллионов отчетов в разных информационных системах начнут возвращать другие цифры. Тут после существенных переработок генератора форм было столько криков и стонов, а тут отчеты…
          Мы радостно используем послезнание для анализа и критики решений, принятых 5-10-15-20 лет назад. Но только люди, принимавшие те решения а) не имели наших послезнаний и б) имели другой опыт и взгляды на разработку (не плохие взгляды, а другие).


          1. EvilBeaver Автор
            18.12.2019 17:43

            v9 будет?


  1. dhaenoor
    18.12.2019 15:42
    -1

    Поставил 1с на одной виртуалке, включил в постгресе, на другой виртуалке, log_min_duration = 0, ушел на выходные домой — 30 гигов диска на виртуалке с постгресом забито сообщениями о десятках тысяч запросов к базе, о каких-то временных таблицах, обращениями к одинэсовским системным таблицам. А ведь даже приложение на другой не было запущено, просто зарегистрирована и загружена база на 2 гига. Представлю как она гробит SSD, эта кривая дрянь. И это я ещё не смотрел в какой момент упала виртуалка от нехватки места на диске.

    Переопределение было и в 7.7 версии, к слову.


    1. marmyshev
      18.12.2019 15:58

      И ничего о «регламентных задания» в фреймворке 1С вы не слышали? :) Ну так можно про любой Фреймворк сказать: он делает какую-то непонятную Мне хрень — значит Фреймворк отстой.
      Наверное и о «блокировке регламентных заданий» в базе вы не слышали… :)
      Как бэ, напрашивается вопрос: зачем стараться пользоваться тем, что не хочешь нормально изучать? (я про Фреймворк 1С, а не про конкретное приложение).


    1. EvilBeaver Автор
      18.12.2019 16:03

      Странно, приложение интенсивно работающее с базой данных, интенсивно работает с базой данных… С чего бы это?


      1. dhaenoor
        18.12.2019 17:15

        1С как таковая была закрыта. Я могу понять регламентные работы вследствие действий пользователя. Но когда она двое суток тысячи запросов слала однотипных в БД — этого я понять не могу. Да ещё и в таких объёмах.
        Зачем всё это было надо? Отлавливали баг с разными результатами в отчетах при включенном и выключенном enable_indexscan. Как отлавливали — закрывалось окно 1С, постгрес останавливался, постгресовые логи вычищались, запускался постгрес, запускалась 1С, в 1С выполнялся отчет, 1С закрывался, стопорился постгрес — за 7-10 минут по полмиллиона строк в логах. Название конфигурации уже не помню, что-то там бюджетное. После этого всего я закрыл 1С на машине с виндой и ушел домой на выходные. Т.е. от клиента к базе запросов быть не могло.
        Баг в пг нашли и вылечили, относящихся к нему запросов из 1с было порядка 20 штук — создать временные таблицы, создать на основании временных таблиц другие временные таблицы, на их основании ещё, а уже после этого получить, из третьих по счёту таблиц, результат. Ну, понятное дело — система только запустилась, решила там что-то посмотреть. Но всё равно — попытайтесь мне объяснить — что значат 499980/5= ~99996 запросов за десять минут во время запуска. А я с балкона посмотрю…

        Я работал с 1С начиная с 6.0 версии, её мельком зацепил, но годик пообслуживал. На восьмой версии в 2005 году у меня батарейка села и я занялся SQL. А до того, параллельно с учёбой — писал на клиппере и FoxPro. Так что если я вижу более пятисот тысяч строк логов за десять минут, в приложении которое ничего не делает для пользователя, и считаю это ненормальным — это значит что это ненормально.


  1. zambas
    18.12.2019 16:44
    +1

    Никогда не был хейтером в адрес 1С, у нее есть своя ниша, есть свой рынок и отрицать это бессмысленно. НО!)) с появлением таких фреймворков как django ,flask, spring boot и прочие практически коробочные решения для того, что бы сделать здесь и сейчас что то уже работающее показывающее, но не бухгалтерию) интерес к ней пропал.


    1. EvilBeaver Автор
      18.12.2019 16:52

      Окей, давайте по второму кругу: как на перечисленных фреймворках сделать сквозной нумератор документов по набору ключей, недырявую модель распределения прав доступа и печать накладных в PDF?


      Очевидно, что можно сделать все перечисленные пункты, насколько быстро?


      Дело в том, что понятие "сделать здесь и сейчас что то уже работающее показывающее" слишком обобщенное. В статье приведен пример приложения для ларька с шаурмой — учет покупки, продажи, в разрезе покупных и продажных цен, учетом остатков по складам, разграничением доступа, веб-клиентом и отчетностью с возможностью drill-down и вывода в PDF. На 1С я сделаю за 2 часа. Кто меньше?


      1. zambas
        18.12.2019 18:35
        +1

        эм)) все это я делал)
        Подключаешь нужную тебе либу и работаешь), а в той же джанге ролевая модель из коробки-каркас конечно, но очень даже удобная.
        По поводу печати, берешь либо какая тебе нравится, а не ту какую тебе пихает вендор ))
        я например долго юзал aeroolib очень удобно)
        В общем это я могу сделать за 2-3 дня ))


        1. marmyshev
          19.12.2019 00:02

          Похоже вы в пролёте (вопрос был «кто меньше 2х часов?») а тут 2-3 дня… да ещё нужно знать конкретные либы что там и как подключается, юзается и реализуется…
          Это ещё не любого «питониста с улицы» возьми и он тебе сделает за 2-3 дня...


          1. zambas
            19.12.2019 11:50

            Odoo, ErpNext меньше 2х часов)
            Не сидите в коробке одного фреймворка, и не бычтесь, это вам не к лицу


            1. marmyshev
              19.12.2019 13:10

              Все-таки, вы не правы — Odoo, ErpNext — это не фреймворки, это конкретные бизнес-приложения. Я понимаю что там поднизом лежат какие-то фреймворки — вот с ними нужно сравнение, если вы в них специалист — прошу, поделитесь.

              Ну почитайте внимательно задачу: взять голый Фреймворк и сделать на нем конкретную бизнес-задачу.

              Не сидите в коробке одного фреймворка, и не бычтесь, это вам не к лицу

              Тут могу только предложить: «фреймворки в студию!» и давайте сравнительный анализ :)


              1. zambas
                19.12.2019 14:17

                Это с чего вы взяли, что Odoo и ERPnext это не фреймворки а Бизнес приложения)))))
                Вы можете установить Odoo без единого модуля и работать с ним как с фреймворком), Вы оперируете фактами как то извращенно, когда Вам удобно выдаете за фреймворк, а когда нет за Бизнес приложение)
                Установите себе Odoo и вы поймете, что это фреймворк, со встроеными уже готовыми решениями для Печати, GUI и тд, и при всем этом СВОБОДНАЯ от вендора и лепите на нее все что мир изобретает каждый день.

                Лично у меня был опыт создания приложения для учета рабочего времени компании, и мы взяли пустой фреймворк Odoo, и на его базе сделали свое приложение. Код открыт, делай что хочешь, а odoo дает только удобную orm, работа с печатью, api и GUI. и мы не зависили от того что там есть у него в коробе, лепили на него что хотели из мира python и не только.
                github.com/odoo/odoo — клоньте, удаляйте папку addons и у вас пустой фреймворк для созидания)

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


              1. zambas
                19.12.2019 14:52

                1. andy_minsk
                  19.12.2019 17:39

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


                  1. zambas
                    19.12.2019 18:50

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


      1. pfihr
        18.12.2019 23:22
        +1

        Проблема лишь в том, что Вы думаете, что все программисты мечтают программировать программы для ларьков с шаурмой. Это и есть основной просчет. Сейчас тренд — облачные решения и сервисы, работа с большими данными, микросервисы и т.п. В этих сферах 1с пролетает мимо и с большим свистом. Кстати, о микросервисах. Вы писали выше некоторые рассуждения на их счет. И тут ошибка, микросервисы нужны не ради микросервисности. Архитектура микросервисов позволяет взять и переписать любой сервис на НОВОЙ технологии, если она появилась. Это избавляет от ловушек легаси, в которой застряла 1с и скоро просто утонет после того, как появятся государственные облачные сервисы, решающие задачи с учетом и отчетностью.

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


      1. zambas
        19.12.2019 11:49

        Кстати) вспомнил фреймворки которые все это сделают за 2 часа
        Odoo, ErpNext, я думаю их куда больше, нее сидите в коробке одного фреймворка


  1. surVrus
    18.12.2019 17:17

    … — я не вижу на рынке достойного конкурента. За одну и ту же цену вы получаете фреймворк финансового приложения, кластеризуемый балансируемый сервер, с UI и веб-мордой, с мобильным приложением, с отчетностью, интеграцией и кучей еще чего.

    Apache OfBiz или его производные.
    Все Вами описанное более-менее есть. Все сделано на современных технологиях.
    Тоже фреймворк, тоже надо допиливать. Тоже куча плюсов и минусов.
    Но OfBiz сделан намного качественнее по каждому указанному Вами аспекту.
    Я смотрел и на 1C и на OFBiz с точки зрения именно как «бизнесмен», потом как «системный аналитик». Аспекты реализации и особенности работы — детально не анализировал. Но пока — меня вполне устраивает, все криво-косо, так или иначе — но работает. И простую бизнес-логику реализует быстро и без особых хлопот.


    1. EvilBeaver Автор
      18.12.2019 17:23

      Посмотрел демку OfBiz — по сценарию ввода данных для пользователя скорее напоминает SAP R3. Вот про "криво-косо но работает" пожалуй соглашусь, но как эта фраза коррелирует с "OfBiz сделан намного качественнее по каждому указанному Вами аспекту"?


      1. surVrus
        18.12.2019 19:50

        Посмотрел демку OfBiz

        Как «бизнесмен», которому не лень было ковыряться в софте, я работал и на 1С (от версии 4 до 8), и делал проекты на ACCPAC и смотрел иные системы. 1С мне нравилась, даже писали какие-то отчеты и разные добавки к ней.
        6 месяцев назад стал искать на чем можно сделать в стартапе «операционную систему бизнеса» (реализация модулей концепции GERAM). Чтобы она работала на этапах реализации проекта от «идеи» до «операционная деятельность».
        Использую OfBiz не долго, поэтому могу не все точно описать, не взыщите.
        Демка не передает чудес этого продукта. Выглядит все похоже, морда и front-end везде более-менее похожие. Сама логика работы — очень разная от 1С. Если коротко — то люди взяли продуманное решение, по сути книгу «The Data Model Resource Book. A Library of Universal Data Models for All Enterprises» Len Silverston и реализовали ее в виде фреймворка. И не только ее, но и видать много чего еще.
        Опишу только начало, про установку.
        Я 27 лет работал исключительно на инфраструктуре MS.
        Год назад перешел на Linux. Убунту. Так что опыта не особо.
        Прочитал как ставить Ofbiz. Типа «Download» OFBiz и "./gradlew ofbiz". И чё? типа все?
        Не поверилось, вроде сложная штуковина. Все заработало со второго раза. И то, только по моей глупости не с первого.
        Потом были муки с документацией на продукт. Пока не догадался скачать указанную выше книгу и прочитать. Понял, почему нет отдельной документации. Не особо нужна, все описано в этой книге.
        Функционал программы — огромный. Все, что мне нужно сейчас и будет нужно в ближайшие несколько лет — вроде все есть.
        Система идет в исходных кодах. Разработка, доработка — стандартными инструментами от Apache.
        СУБД — вроде бы тоже любая.
        Производительность при высокой нагрузке? А фиг его знает. Мне пока не надо, но вроде никаких особых ограничений нет.
        Модель событий? Открытая, все видно и доступно.
        API? Да вроде все инструменты там стандартные, все есть.
        Развертывание на Линукс? У меня заняло 20 минут, а я не особо спец.
        Контейнер? Да вроде изначально так и работает.
        Поддержка? Наверное какая-то есть. Пока не было нужды к ним обращаться.
        Настройка? Да не особо вижу разницу, объем работы примерно одинаковый с тяжелыми корпоративными пакетами. Да и в 1С не особо меньше.
        Цена? Да вроде небольшая, «полная стоимость владения» сопоставимая с 1С (но это пока только прикидки)
        Красивая «морда» для e-сommerce? Тоже вроде бы не особо сложно.
        Пока так.


  1. puyol_dev2
    18.12.2019 21:32
    -2

    1с это реально один из лучших решений сейчас для бизнеса. Для России точно самое лучшее. Касаемо языка тоже один из лучших языков для создания бизнес решений. 1с устарел? Наверно это скорее уже относится к java/c#, которые так же создавались как бизнес языки в середине 90х. И они уже слишком сложные на данный момент. Вокруг той же java уже существует с 10к разных упрощений. Ну и плюс 1с, как отметил автор — это универсализм специалиста. Он в состоянии как спроектировать решение, написав тз со слов клиента, так и реализовать его. А вот, если взять тех же java/c# разработчиков, здесь все намного сложнее и уж как повезет. Ибо сложность языков не дает в полной мере сосредоточиться на предметной области


  1. 3263927
    18.12.2019 22:32

    я для своего бизнеса написал собственную ERP систему на C#, не жалею


    1. puyol_dev2
      19.12.2019 19:48

      И сидишь подгоняешь отчетность и формы документов под постоянно меняющееся законодательство. Молодец )


      1. 3263927
        19.12.2019 19:50

        эту часть работы делает точка банк


  1. speshuric
    18.12.2019 23:41
    +2

    В прошлой статье я защищал 1С, а в этой, ну, пусть из латентного нонконформизма, но налью таки бочку дёгтя.
    1С сейчас в современном IT-ландшафте, как чемодан без ручки — нести тяжело, выбросить жалко. Для 2003-2004 года интеграция в IT-ландшафт была суперской, но, чёрт подери, ко мне того и гляди на собеседование придут люди рождённые в те годы. Что я под этим подразумеваю — ниже.
    Слааабые возможности интеграции. Что у нас есть в 1С для общения с другими приложениями? Файлы, COM-объекты, внешние компоненты, HTTP-запросы, SMTP/POP3, ODBC-подобные соединения с СУБД, плюс ещё некоторая достаточно экзотическая мелочёвка. Причём всё вышепереписленное с кучей оговорок:


    • Файлы по сути только текстовые. Работа с бинарными файлами — раньше была совсем не возможна, а сейчас низкоуровневый трешак, который я не смогу обосновать по стоимости разработки прикладных решений. Только если жизненно важно что-то простое разобрать. Отдать вендору должное — на файлах у него достаточно много неплохих стандартизованных отраслевых решений.
    • SMTP/POP3 — э, ну вы же всёрьёз не считаете, что это способ сделать API?
    • COM-объекты — доступны только под Windows (а уже и сервер умеет с linux жить, и клиенты не все это умеют), тупиковая ветвь эволюции. Ну камон, эта тема была в тренде 20(!) лет назад, закопайте уже таки стюардессу.
    • HTTP-запросы реализованы очень низкоуровнево. Ну то есть простые GET по HTTP ещё куда ни шло, но, например, какой-нибудь SPNEGO реализовать уже совсем не весело. HTTPS, кстати, долго был недоюзабельный. Вкупе с ещё одной проблемой 1С (отвратительной модульностью и сложностью переиспользования технического кода) это приводит к тому, что разработчики прикладных решений часто говорят "ну его нафиг, давайте файлами обмениваться".
    • ODBC-подобные соединения с СУБД — это только чтобы забирать данные из витрин. Серьёзный "контрактный" API на этом не строят.
    • Внешние компоненты (ВК). Теоретически "вы можете всё". Ахаха. Теоретически. Практически это некий самописный аналог IDispatch (привет, динозавры!!!) со своим ГПСЧ и практикантками. Их и было-то не много — в основном для интеграции с торговыми устройтсами, а году в 2005-2006 1С поменяла нутро этого формата (ушла от явного использования COM по сути и от интерактивных возможностей) и с тех пор их совсем почти не пишут. При написании надо либо дофига делать руками, либо делать кучу нетривиального тулинга, а для этого надо много времени. Готовых публичных и полезных ВК если и появляется, то точно не больше 2 штук в год. Теоретически можно даже из 1С работать с .NET (Elisy .Net Bridge), а практически он не развивается, например, .NET Core там нет. Ну и даже там всё не просто.

    Кому кажется этого достаточно, тот застрял в 2005 году. А я хочу: HTTP/2, GraphQL, gRPC, сериализацию в Protobuf, удобную интеграцию с kafka, RabbitMQ, ActiveMQ (и прочими ZeroMQ, nanomsg), хочу подключаться к MongoDB, Cassandra, Hadoop, хочу использовать комфортно распространённые API (ну, например, файлы в S3 хранить), хочу использовать SSO и аутентифицировать сервис 1С без хранения креденшелов. Это только то, что сходу вспомнилось. На самом деле этот список каждый день прирастает.


    Слабая интеграция в инфраструктуру современного IT. Да у 1С по сих пор даже работа с доменом AD и внешней аутентификацией всё ещё в детском состоянии! Максимум, что есть — указание, что Вася Пупкин может аутентифицироваться как PupkinVD@my.company. Нет корректной работы с группами, OU, блокированием/удалением, нет работы с корпоративным RBAC, нет альтернативных сервисов аутентификации (KeyCloack, например, или аутентификация в google том же). Интеграция с корпоративным мониторингом на ELC на уровне "принципиально возможна". То есть как бы её никто не запрещает делать, но там делать, прямо скажем, немало. Про успешную интеграцию в WAF и DLP просто не слышал. Интеграция с мессенджерами, телефонией и exchange — примитивна. Зато в 1С сканер ШК и фискальный регистратор почти всегда из коробки заводится, ну да.


    Слабые интерфейсные возможности. Пока сценарий работы кнопкутык, кнопкутык, полевбил, контрол-энтер, то всё прекрасно. Шаг вправо-влево и "не шмогла". Кто не согласен — вперёд покажите мне прототип интерактивного редактора markdown (хотя бы только с жирным и наклонным шрифтом) или интерактивную работу с картой (и нет, вам не поможет ГеографическаяСхема).


    О, кстати, про ГеографическаяСхема. Отдельно упомяну "кладбище невзлетевших фич". Это целая гора фич, которые или просто оказались не нужны или были хреново сделаны или вышли не так и не тогда, когда нужно было.
    Просто списком с минимальными комментариями:


    • ГеографическаяСхема — в этом виде оказалась никому не нужна. Вышла очень рано, не продумана инфраструктура. Сейчас проще пользоваться либо настоящими картами (яндекс, гугл), либо сторонними севисами/решениями
    • Статистический анализ данных — во многом опередил своё время, но сделан был "не для людей". Сейчас это делают либо в питон/юпитер, либо в табло/повербиай/клик. Очень обидно за державу. Они делали (хотели делать, точнее) кластерный анализ, пока остальные в том же классе всё ещё фильтровали эксель. Бигдата за несколько лет до хайпа.
    • Бизнес-процессы. Сделаны хуже, чем даже Elma, а это ещё надо постараться. Где-то как-то используются, обязательно присутствуют на экзамене 1С: Специалист (в жизни достаточно редко). Для сравнения посмотрите на эту же Elma или на Camunda или на любую другую BPM-систему.
    • Веб-сервисы (wsdl). Не успели появиться, как по факту списаны на свалку истории (заменены REST и MQ в нормальном, не 1С, мире)
    • Fast Infoset. Его место в нормальном мире занял ProtoBuf фактически.
    • Полнотектовый поиск не то чтобы совсем дохлый, но опять же — то как он сделан и подан не оставляет ему шансов быть в топе фич.
    • Сводная диаграмма — на фоне СКД и отчётов просто не взлетела.
    • Макеты текстовых документов. Крутая фича (нужна, если нужно отчёты в TXT формате делать). Но она никому почти не нужна.
    • Срез первых в регистре сведений. Ну просто оказался не нужен.
    • IBM DB2 RIP

    Ну а в разработке, как я уже отметил, всё плохо с модульностью решений и сложностью переиспользования технического кода. И по мне так БСП не пример того, как это "победили", а пример того, как это "проиграли".


    1. Neikist
      19.12.2019 00:14

      Во многом согласен, разве что по поводу интерфеса оговорочка — благодаря тому что вебкит наконец встроили в платформу — можно более менее на веб технологии расчитывать. Но в целом это выглядит… Мда, костылем. Да еще и на мобилках раньше были большие проблемы.


    1. bonv
      19.12.2019 03:26

      SMTP/POP3 — э, ну вы же всёрьёз не считаете, что это способ сделать API?

      А как по вашему отчетики в ФНС, ПФР отправляются (собственно, один из главных источников дохода фирмы 1С)?


      1. EvilBeaver Автор
        19.12.2019 14:52

        Это скорее к ФНС/ПФР вопрос, доколе!?


        1. bonv
          19.12.2019 15:32

          А что изменится если они перейдут на HTTP2/Protobuf или что-то другое?


          В 1С в своё время более-менее приличная поддержка http (запросы, ответы) появилась только из-за того что один из контролирующих органов принимал отчёты через сайт, в котором сессия в заголовках ответа приходила. До этого заголовки ответа штатными средствами нельзя было получить


          1. EvilBeaver Автор
            19.12.2019 17:08

            Кривокосая поддержка хттп в 1С по-принципу "кому это нужно" была до версии 8.2.18, и мы оба помним ту боль. Сейчас вроде бы они от этого вылечились


            1. bonv
              19.12.2019 17:24

              Мой комментарий как раз про 8.2.18


    1. bonv
      19.12.2019 03:38

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

      А можно пример где работа с бинарными файлами сделана на порядок лучше?

      HTTP-запросы реализованы очень низкоуровнево. Ну то есть простые GET по HTTP ещё куда ни шло, но, например, какой-нибудь SPNEGO реализовать уже совсем не весело

      А конкретней можно чего вам не хватает при работе c HTTP?


      1. speshuric
        19.12.2019 23:07

        А можно пример где работа с бинарными файлами сделана на порядок лучше?

        C, C++, C#, Java, Python, Rust, Go (и ещё несколько сотен языков)
        В 1С методы работы с чтением двоичных данных (которые появились в 8.3.9-8.3.10 в 2016 и 2017 годах — совершенно недавно по энтерпрайз меркам) предоставляют весьма низкоуровневые возможности: чтение примитивных числовых и строковых данных. Нет удобных инструментов чтения сразу в структуры данных. Да что там! Даже банально float прочитать — уже изголяться. Да что там float! Даже отдельных методов для знаковых/беззнаковых нет.
        А так как с модульностью и переиспользованием кода в 1С задница и юнит-тесты писать заколебёшься, то даже относительно простые потоки данных читать — боль-боль-боль.


        А конкретней можно чего вам не хватает при работе c HTTP?

        Я не говорю "не хватает". Я говорю "низкоуровневые". То есть сделать можно всё, как можно всё написать на ассемблере. Теоретически — да. Практически даже обращение к простому сервису с аутентификацией и последующий разбор результатов это какие-то невменяемые портянки кода по сравнению, например, с JS. В качестве примера попробуйте какой-нибудь список тикетов из Jira или GitLab по фильтру вытащить, только по-честному с правильной не-basic аутентификацией, без хранения пароля пользователя.
        Вроде и делается всё, но уж так это многословно.


        1. bonv
          19.12.2019 23:57
          +1

          В качестве примера попробуйте какой-нибудь список тикетов из Jira или GitLab по фильтру вытащить, только по-честному с правильной не-basic аутентификацией, без хранения пароля пользователя.
          Вроде и делается всё, но уж так это многословно.

          Сахара языку конечно не хватает, но в целом терпимо (см. КоннекторHTTP)
          Заголовки = Новый Соответствие;
          Заголовки.Вставить("PRIVATE-TOKEN", <your_access_token>);
          
          issues = КоннекторHTTP.GetJson(
          	"https://gitlab.example.com/api/v4/issues?labels=foo,bar&state=opened", 
          	Неопределено,
          	Новый Структура("Заголовки", Заголовки));
          


          1. speshuric
            20.12.2019 21:42

            Я вот не определился, читерство это или нет :) Но в одном определился: ваш КоннекторHTTP — крутейшая вещь. Спасибо за наводку, я, как архитектор уже начал обсуждение использование этой библиотеки у нас.
            Собственно, мне кажется, что это то, как должна была выглядеть работа с HTTP в платформе.
            И написана прям добротно-добротно:


            • Код структурирован, даже области используются — уважуха.
            • Методы небольшие, всё как надо. Декомпозиция на функции очень разумная.
            • Экспортные функции выделены в отдельный блоки и каждая экспортная функция со стандартным комментом
            • Код стандартно отформатирован, без грязноты практически, комменты по делу, нет широченных строк. Ну это же читается, как поэма!
            • Даже есть какой-никакой CI, статанализ и тесты.

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


            Что показалось спорным
            • Я сначала хотел умилиться использованию Знач, но потом понял, что то ли я не понимаю ваших принципов использования Знач, то ли они полуслучайные. Первый попавшийся пример РазбитьСтрокуПоСтроке(Знач Строка, Разделитель) — почему первый параметр с Знач, а второй без?
            • Тесты. Хардкод в тестах это лучше, чем хардкод в коде, но всё равно плохо. Если модуль собирается без доступа к Интернет, например, то тесты в текущем виде можно выкинуть. По-хорошему, параметры тестов нужно вынести отдельно. Вариантов тут масса, можно, например, вынести их в форму, можно макет, можно в какие-нибудь предопределённые данные. Лично я выносил в макет.
            • Тесты. Нет раздельного запуска тестов, но это лучше решать не локально для данной библиотеки, а делать фреймворк, а это задача сразу гораздо больше.
            • Тесты. Отчёт по тестам не для автоматизации. Но это тоже скорее вопрос к отсутствию фреймворка.
            • По коду тоже есть что сказать, но такие вещи проще и правильнее через PR делать.


    1. nirom
      19.12.2019 08:34

      Чемодан без ручки — очень точное сравнение. Весь такой красивый и качественный чемодан, но без ручки.


    1. CrushBy
      19.12.2019 10:10

      Одна из проблем 1С, что она не построена на базе технологии с виртуальными машинами (вроде .Net/Java). Да, при этом были бы дополнительные проблемы, но тогда подключение каких-то специфических редких вещей решалось бы просто добавлением зависимости в pom.xml (если Maven) и относительно небольшого кода по интеграции с самой платформой (так как все бы было в одной виртуальной машине).


    1. EvilBeaver Автор
      19.12.2019 14:59

      Многое точно, про интерфейсы например. но про интеграции… работа с бинарными файлами точно по интеграции прямо необходимо? Много ты знаешь популярных форматов обмена, основанных на бинарке? Протобуф еще далеко не мейнстрим. А json вроде как текстовый.


      В опенсорсе есть адаптер для AMQP (RabbitMQ) — модно и молодежно… С чем таким надо интегрироваться, что из 1С нельзя?


      По авторизации — тоже да. Однако, в последних версиях вроде как OpenID и OIDC прикрутили. Не пробовал, говорят работает (KeyKloack и прочее сюда)


      GraphQL и gRPC — да было бы неплохо, но в кровавом ентерпрайзе тоже пока не мейнстрим, скорее хипстерство.


      В целом, приятно видеть продолжение статьи, хоть и в виде комментария, все по делу.


  1. pfihr
    18.12.2019 23:49

    В статье не хватает рассмотрения еще некоторых особенностей. Однопоточный синхронный медленный интерпретатор. Нет возможности запуска асинхронных функций с получением результата не через базу (фоновые задания не предлагать!). Примитивная сборка мусора (алгоритм начала 90х). Нет разрешения циклических ссылочных зависимостей (сервер приложений легко течет по памяти, и нет средств поиска неисправности). Все эти факторы не позволяют реализовывать сложную бизнес-логику на встроенном языке (и поэтому есть такой распространенный паттерн запихивания бизнес логики в один запрос к базе). Но ее упорно напихивают в типовые решения.


    1. Neikist
      19.12.2019 00:16

      Вроде же средства поиска циклических зависимостей добавили? Оно теперь вроде как в ТЖ их отображает, да можно какой то опцией заставить платформу при их нахождении ронять все) Но да, механизмы сборки мусора заставляют плакать. Особенно учитывая квалификацию многих разрабов.


    1. speshuric
      19.12.2019 00:54
      +1

      Однопоточный синхронный медленный интерпретатор.

      Ну сравните с Python — там сам интерпретатор такой же "Однопоточный синхронный медленный". Асинхронность и быстрость снаружи интерпретатора.


      Примитивная сборка мусора

      И у Python тоже! :) тот же самый refcount (о, кстати, в Kotlin Native, если ничего за год не изменилось — тоже).


      1. Neikist
        19.12.2019 01:30

        python

        The standard implementation of Python, CPython, uses reference counting to detect inaccessible objects, and another mechanism to collect reference cycles, periodically executing a cycle detection algorithm which looks for inaccessible cycles and deletes the objects involved.

        Kotlin native
        Q: What is Kotlin/Native memory management model?

        A: Kotlin/Native provides an automated memory management scheme, similar to what Java or Swift provides. The current implementation includes an automated reference counter with a cycle collector to collect cyclical garbage.


        Из современных языков не считая крестов я только свифт знаю который опирается только на механизм подсчета ссылок и сильные/слабые ссылки для разрешения проблем. Во всех остальных давно так или иначе более умные gc. Да, у свифта по этой причине не будет пауз на сборку мусора, но насколько я знаю вполне существуют конкурентные сборщики мусора которые пусть дают свой оверхед, но не делают остановку мира. Плюс вроде как деление на поколения и частая работа сборщика тоже неплохо позволяет снизить проблемы с этим в случае если мир таки останавливаем.


        1. bolonov
          19.12.2019 09:10

          >Из современных языков не считая крестов я только свифт знаю который опирается только на механизм подсчета ссылок и сильные/слабые ссылки для разрешения проблем

          Rust тоже только rc использует.

          По моему опыту текущая ситуация с управлением памятью в 1С не является сколь-нибудь серьезной проблемой:
          1. Код, допускающий утечки, сейчас можно отладить с помощью инструментов платформы (https://its.1c.ru/db/metod8dev#content:5859:hdoc)
          2. Кластер серверов давно доступен в 64х битном варианте и чисто административными средствами — рестартом процессов по достижении заданного порога памяти — можно сделать незаметным отстутствие честного gc

          Короче, на мой вкус вполне нормальный компромисс


          1. Neikist
            19.12.2019 09:14

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


            1. bolonov
              19.12.2019 09:50

              > Перезапускать сервер тоже так себе идея, выгонять пользователей и все такое.

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


              1. Neikist
                19.12.2019 10:09

                Угу, а ничего что утекшая память в тех самых сеансах и висит в т.ч.?


                1. bolonov
                  19.12.2019 10:18

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

                  Автоматический рестарт процессов-вокеров кластером подчищает старые ошметки.


                  1. Neikist
                    19.12.2019 10:31

                    Вы ни разу не встречались с пользователями что в принципе не выключают комп и не закрывают приложения? Я вот сам такой.


                    1. bolonov
                      19.12.2019 10:43

                      Встречался, конечно. Такие «вечные» сеансы можно обыгрывать настройка параметров ИБ (https://v8.1c.ru/platforma/parametry-informacionnoy-bazy/).

                      Еще раз — рассказываю чисто по собственному опыту. Текущее положение дел по управлению памятью в кластере 1С не доставляет неудобств при наличии 64х битной версии и минимальных усилиях по администрированию кластера. Т.е. это (управление памятью) на мой взгляд вот точно не стоит рассматривать как ахиллесову пяту платформы.


                    1. VSOP_juDGe
                      20.12.2019 14:38

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


          1. pfihr
            19.12.2019 09:20

            Отличная ссылка (https://its.1c.ru/db/metod8dev#content:5859:hdoc)! Во всех следующих обсуждениях можно копипастить оттуда цитаты, чтобы все программисты видели, с каким добром им придется иметь дело :)


            1. EvilBeaver Автор
              19.12.2019 09:50

              А с каким добром? Управление памятью по счетчику ссылок. Что-то необычное там написано разве? То, что рантаймы со сборщиком мусора позволяют циклично ссылающимся объектам все-таки уничтожаться, не отменяет того, что код с циклично ссылающимися объектами — говнокод. И тут уже не язык виноват, что афтар так видит свой граф объектов.


              1. Neikist
                19.12.2019 10:12

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


              1. tsukanov-as
                19.12.2019 17:35

                > что код с циклично ссылающимися объектами — говнокод.
                Ну ты загнул конечно )
                Любая сетевая структура данных и у тебя проблемы.
                Навскидку пример: В AST рекурсивная функция будет ссылаться сама на себя. С подсчетом ссылок придется городить костыли чтоб память не текла.


                1. EvilBeaver Автор
                  19.12.2019 21:23

                  С подсчетом ссылок придется городить костыли чтоб память не текла.

                  Какие костыли? В деструкторе сделать delete[] children, а в деструкторах листьев — декремент счетчика ссылок на родителя.


                  1. Neikist
                    19.12.2019 21:48

                    Если это кресты как раз тут то память и потечет. Потому что если у детей есть свои дети — массив children мы то освободим, но сами потомки продолжат существовать, на них то их children ссылаются а сами они ссылаться на свои подчиненные элементы.
                    Вот тут как раз выход в слабых ссылках (например на родителя).


                  1. tsukanov-as
                    19.12.2019 21:51

                    Деструкторы во встроенном языке? =)
                    Ну да, мне кажется это костыли, которых не будет если есть GC. Он сам все удалит и удалит гарантированно корректно без моего участия (конечно тут тоже бывают исключения). У GC много минусов, но работа с циклическими ссылками — это имхо одна из важнейших фич, позволяющих работать с рекурсивными структурами данных прямолинейно без плясок с бубном. Думать об алгоритмах, а не как избежать утечки. А в 1С как только у тебя какой-то граф, так сразу головная боль. И это не фантазии, а проблемы с которыми мне уже доводилось сталкиваться. Побеждал реорганизацией структуры и компромиссами, а мог бы не ломать голову не тратить на это время вообще. Но опять же справедливости ради стоит сказать что подобные задачи на 1С почти не возникают и проблема не особо ощущается.


            1. bolonov
              19.12.2019 10:06

              Вот, тут более удобные средства поиска цикл. ссылок разобраны wonderland.v8.1c.ru/blog/razvitie-sredstv-diagnostiki


      1. bonv
        19.12.2019 03:51

        Ну сравните с Python — там сам интерпретатор такой же «Однопоточный синхронный медленный».

        Вы это про какой python? CPython многопоточный.

        Асинхронность и быстрость снаружи интерпретатора.

        Серьезно? Асинхронность снаружи? Что такое yield и как работает знаете?


  1. vvf1973
    19.12.2019 09:51

    Лучшие алгоритмисты — это выпускники матмеха/физмата. Лучшие руководители команд — это люди с хорошим классическим образованием и практикой, знающим монографию Дрюри не понаслышке. 1С — это прокладка между налогоплательщиками и МНС. Установи мораторий на изменение налогового и бухгалтерского законодательства лет на 10, и 1С канет в лету.
    1С — платформа интересная, много чего сделано на ее базе, но типовые продукты на ее базе в первую очередь рассчитаны на обслуживание интересов МНС, но никак не коммерческих предприятий.


    1. EvilBeaver Автор
      19.12.2019 09:53

      Вы где-то подзастряли во времени, начиная с того, что МНС больше не существует )
      1С сейчас активно живет за счет корпоративных приложений — документооборот, управление производством, фин.сектор. 1С лет 10, минимум, это не только налоги считать в бухгалтерии. Прилетайте в 2019


  1. mi76554
    19.12.2019 09:53

    >И еще — если к вам пришел наниматься 1С-ник, то 1С-ника можно смело ставить на должность лида аналитиков. Понимание задачи, предметной области, навыков декомпозиции у них развито великолепно.

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

    Ржу и плакаю =) 95% не знают протоколов от слова совсем, нет в голове понятия. Не понимают даже элементарный rest web api, понятие делового моделирования в стиле OOP для них дырка, управления версиями конфигураций-кода почти неведомо,… там длинный список

    Больше половины не знают что такое програмный автомат. Просто нет элементарных базовых знаний.

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

    «Ну у них сайт написан… на языке… не 1C», «Мне не нужно знать этот ваш SOAP» — из разговоров.


    1. EvilBeaver Автор
      19.12.2019 09:55

      Ну плохие вам коллеги попались, сочувствую. Есть такое в отрасли, это проблема низкого порога входа. Но есть и такие, кто делает CI, статический анализ, автотесты и интеграцию через Kafka, считая rest api слишком скучным и простым.


      1. mi76554
        19.12.2019 10:51
        -1

        >Ну плохие вам коллеги попались, сочувствую.

        И так _20_ лет, все плохие попадаются? =)
        И еще — на 100 одноэсников только 2 знали английский что бы что-то сказать и читать.
        Егожмать, английский — язык индустрии.

        98 % чуваков не могут понять что-то, что написано на базовом индустриальном языке.

        >Это проблема низкого порога входа.

        Вообще-то наличие огромного количества приставок к бухгалтерии и учету и десяткам «рогов и копыт» — тяжелая социальная проблема. Там, на этой проблеме, одноэсники и кормятся, на проблеме. Даже не думая сильно. То есть 95% на этом пороге входа и остаются.
        А че типа, мы и так нужные. Мы тут B2B из левого угла в правый и обратно автоматизируем.

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

        >Но есть и такие, кто делает CI, статический анализ, автотесты…

        Да, наверное есть. Двое. Прячутся.

        Давеча поймал такого 1с аналитика, глагольствовал об «enterprise resourse planning»
        Задал ему вопрос, найдите мне, сэр, хоть что-то из планирования кейсов-програм-проектов производства-процессов в будущем, а не фиксации пост-фактум, тут яркий монолог про желтый рай и сдулся.
        2019 год, если че.

        Другой упорол четыре терабайта блобов в SQL базу. Пока производство не встало.

        Раздутая «1c типа разработка» без альтернатив, иных понятий, иных компетенций, с дешевой до-индусской ставкой труда — это один из признаков социального заболевания.


        1. EvilBeaver Автор
          19.12.2019 13:05

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

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


          1. mi76554
            19.12.2019 13:37

            >я как бы в курсе чем там автоматизирован малый и средний бизнес.

            «приход-уход-склад» массово в sass, и несильно напрягает.
            пяток лидеров, поключиться дело 10-15 минут.

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

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


            1. EvilBeaver Автор
              19.12.2019 13:46

              Все-то вы про меня знаете, и за меня додумываете… А "великой", в вашем случае, надо писать с большой буквы :D


              1. mi76554
                20.12.2019 18:27

                >Все-то вы про меня знаете, и за меня додумываете

                Нет, конечно, далеко не все. Но бабахать по клавишам столько букв «исповеди одноэсника» уже само по себе профайл. Или анамнез. Смотря кто как посмотрит.


  1. tsukanov-as
    19.12.2019 09:55
    +1

    Годная статья. Спасибо


  1. Bambyrov
    19.12.2019 09:55

    Автор умолчал еще об одном недостатке: в 1С из «поздние версии» не совместимы с ранними, иначе говоря код, написанный в версии Version8_1 может уже не работать в Version8_3_10, его необходимо менять. Это все равно, что Excel документ 97 г. не откроется в Office 2010.
    На это прямо указывает Справка 1С: ОбъектМетаданныхКонфигурация, свойство
    РежимСовместимости (CompatibilityMode)


    1. EvilBeaver Автор
      19.12.2019 09:57

      "Несовместимы"? Или как раз наоборот, "совместимы" и даже есть флаг принудительного выключения фич, чтобы ваше легаси работало на новом рантайме? Автор не умолчал, но может недостаточно акцентировал, что новые рантаймы могут быть бажными и приносить проблемы. Да, такая неприятность с 1С есть, я думал что раскрыл это, но перечитав, понял, что недостаточно. А вот с совместимостью по коду — все хорошо.


      1. Bambyrov
        20.12.2019 18:18

        "-все хорошо"
        Не работал в 1С, но, извините, как оценивать цитату из той же Справки:
        «ПланСчетовМенеджер.<Имя плана счетов> (ChartOfAccountsManager.<Имя плана счетов>)
        Метод
        УстановитьОбновлениеПредопределенныхДанных (SetPredefinedDataUpdate)
        Описан:
        … Доступность:
        Сервер, толстый клиент, внешнее соединение.
        Вызов метода выполняет обращение к серверу.
        Примечание:
        В режиме совместимости конфигурации Версия8_3_4 доступность метода не зависит от использования в сеансе разделителей.
        В режиме совместимости конфигурации Версия8_3_3 необходимость обновлять определяется следующим образом:
        Обновление не будет производиться:
        если в метаданных или в данных установлено НеОбновлятьАвтоматически,
        если в метаданных или в данных установлено Авто, и текущий узел является периферийным.
        В противном случае предопределенные данные будут обновлены и/или созданы при первом обращении к данным.
        »


        1. Ta_Da
          20.12.2019 19:05

          При использовании конфигурации, которая написана на старой версии платформы, предусмотрен режим совместимости. Обратный вариант запуска (конфигурация новая, а платформа старая) не всегда возможен, да.
          Ну и в .Net так же и в java, что именно вас удивляет?

          Более того, если брать ваш пример с Excel, то, внезапно, не все возможности Excel 2010 поддерживаются форматом 97 года, о чем вам программа и сообщит, при попытке сохранения документа.

          P.S. пример вообще не в кассу. он не про «не будет работать», а про «в новой версии изменилось поведение».


        1. Fragster
          20.12.2019 19:16

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


    1. ZEEGIN
      19.12.2019 10:10

      Это не недостаток, это стандартная практика. Что-то обратно совместимо, что-то не совместимо.
      .Net 2.0 не полностью совместим с .Net 4.6, а с .Net Core и подавно.
      Код, написанный на Java 1.8 надо переписать чтоб запустить на Java 11.


      Режим совместимости как раз нужен для того чтобы запустить в новой версии старое поведение. Что бы на 8.3.16 система работала так де как 8.2.14 ей устанавливается режим совместимости. Хочешь использовать все новое: смени режим и адаптируй всю кодовую базу.


      Потому сравнение не верно. Он откроется и будет работать.


      1. Neikist
        19.12.2019 10:18

        А можно уточнить о переходе с 1.8 на 11? Что то о таком не слышал (специально правда и не интересовался, все таки на андроиде даже восьмая жава полноценно недоступна, иногда добавляют фичей из нее в дешугаринг d8 но до сих пор не все покрыто и не будет судя по всему).


        1. ZEEGIN
          19.12.2019 10:24

          Тебя интересуют проблемы самой явы или ада зависимостей по библиотекам каждая из которых по своему версионируется и которая может быть адаптирована или нет для новой явы?


          1. Neikist
            19.12.2019 10:31

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


    1. o4karek
      19.12.2019 10:17

      Давайте я вам стандартную фразу из ченджлога платформы приведу (с нее каждый список изменений начинается). Эта фраза описывает добавку нового режима совместимости.

      Возможность запуска конфигураций, разработанных в версии 8.3.15 и более младших, в версии 8.3.16, без внесения изменений в конфигурацию и без изменений структур данных. Это позволяет при переходе на версию 8.3.16 сначала выполнить переход без внесения изменений в конфигурацию, а потом, внести необходимые изменения и снять режим совместимости. Так же это позволяет иметь возможность после перехода на версию 8.3.16, при необходимости, использовать для работы с информационной базой и версию 8.3.15. Это можно делать, как до снятия режима совместимости, так и после (установив вновь режим совместимости).


  1. Sanyara
    19.12.2019 09:57

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


    1. Neikist
      19.12.2019 10:18

      Запрещают)) Нужно чтобы другие 1сники осилили))


  1. iliabvf
    19.12.2019 10:16
    -1

    О каком холиваре вообще идет речь? И так всем все понятно и все знают о недостатках 1С. Лично я всем начинающим и студентам настоятельно советую держаться как можно дальше 1С, если вам не безразлично ваше будущее как разработчика.


  1. andy_minsk
    19.12.2019 10:20
    +1

    Необходимость плотно поработать с продуктами западных компаний в бизнес-сфере и столкновение с реальными проблемами, очень сильно излечивают от пренебрежительного отношения к 1С. Может где-то и есть тот самый волшебный и технологичный софт, который пишется по чудесным спецификациям умных аналитиков, не менее умными программистами, использующими последние веяния технологий. Но сталкиваясь с реальностью далеко не маленьких, и с виду вполне технологичных контор, понимаешь, что все, что в этом мире приносит деньги, сильно завязано на legacy. а это формат csv, горы старого софта, который даже не подумают менять, файловый обмен, море excel, mainframe и туча людей, которые далеко не боги ни в аналитике ни в программировании. И в какую обертку микросервисов и веб-технологий его не заверни — внутри он тот же махровый монстр и никто его переписывать не будет. В мире финансов — так почти везде. Территория бывшего союза, кстати, гораздо более прогрессивна в этом плане. И далеко не в последнюю очередь из-за 1С.


    1. bolonov
      19.12.2019 11:58

      так и есть


  1. GeniyZ
    19.12.2019 10:29

    Я в разное время работал и с 1С и с SAP и с Галактикой.

    Сейчас я работаю с Парусом.

    И вообще не понимаю, как можно в трезвом уме и светлой памяти выбрать 1С вместо Паруса в крупной организации.

    Понятное дело, если организация мала, если совсем нет программистов, если всё устраивает «из коробки».

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

    С точки зрения IT, Парус в разы лучше и SAPа и Галактики и 1С.


    1. EvilBeaver Автор
      19.12.2019 13:10

      Аргументы? Я, понимаете какое дело, и видел парус и много слышал про него. Вот то, что я видел — никак не соответствует тому, что рекламируют те, кто про него рассказывает.


      Диалог каждый раз такой:


      — Парус на Оракле и поэтому он лучше SAP и 1С вместе взятых
      — А чем именно
      — Да всем!
      — Например?
      — Он для больших баз, которые только Оракл тянет
      — Что это за базы такие?
      — Больше терабайта!!!
      — Только Оракл такое тянет?
      — Да! и Парус!
      — Окей, с базой понятно, а сама система чем лучше?
      — Всем!
      — А конкретнее?
      — Всем! Лучше! Во всем!


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


      1. GeniyZ
        21.12.2019 14:40

        1. Для того, чтобы программировать под Парус не надо учить какой-то ещё язык. Знаний SQL и VB/JS/Perl/Python/Pascal более чем достаточно; а это значит, что для работы с Парусом проще найти специалиста, потому как для начала работы с ним вполне достаточно университетских знаний SQL;
        2. Самые критичные и важные и многие менее критичные и менее важные ограничения бизнес-логики заложены в "ядро" системы. А потому продать больше, чем произведено; исправить проводку в закрытом периоде и т.п. в разы сложнее, нежели в том-же 1С;
        3. Данные нормально хранятся в таблицах Oracle/PostgreSQL, а потому интегрировать самописные системы в разы проще с Парусом, потому-что не надо обмениваться всякими SOAP/WSDL/XML… это те-же таблицы в которые точно-также инсёртишь/апдейтишь/...
        4. Неимоверно качественно "изкоробки" работает учёт кадров и зарплаты, планирование производства; и он ещё крайне гибкий; Остальное тоже хорошо работает, но в остальном слишком много нюансов у каждого предприятия, а потому варианта "изкоробки" достаточно не бывает;
        5. Контроль прав на уровне базы данных (это про Парус 8, а не 10, который трёхзвенка); Т.е. нет какой-то прослойки для распределения прав;
        6. Если поднабраться опыта — то, опять таки, за счёт возможностей программирования "низкого уровня" — непосредственно в базе, — можно творить чудеса.
        7. Довольно мощный инструментарий "Табличных приложений" — мощная "интеграция" с электронными таблицами и MSProject;
        8. Довольно мощный инструментарий "Многомерных отчётов" — вполне себе OLAP, не самый мощный, не BI, но в большинстве случаев достаточно и этого;
        9. Довольно мощный инструментарий "Отчётов Drill-Down", чтоб в удобной форме отображать из каких первичных данных получились итоговые значения;
        10. Довольно мощный инструментарий "Регламентированных отчётов", — тут у меня нет слов, чтоб описать это как-то. Инструмент мощный, многогранный, удобный;
        11. Имеющиеся системы проще переводить именно на Парус, всё потому-же, что данные доступны просто в таблицах Oracle/PostgreSQL; Их проще наполнять имеющимися данными, синхронизировать и т.п.
        12. Парус — это не "чёрный ящик", как 1С. Если что-то где-то происходит, то всегда можно пройтись по коду, или тем-же дебагером, и понять что происходит. В 1С, зачастую, не понятно как там всё устроено. А на такую систему полагаться в критичных бизнес-процессах очень стрёмно.


        1. akryukov
          21.12.2019 17:43

          Ваш ответ тянет на статью. Может оформите отдельно?


    1. PS_erg
      19.12.2019 13:52

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


  1. D_E_S
    19.12.2019 10:35

    тот случай когда коментарии читать интереснее чем явную пропаганду 1С (где явные минусы плюсами сделали :-D )


    1. Neikist
      19.12.2019 10:38

      Да не, статья действительно довольно правдива более менее. Как сваливший с 1с говорю.


  1. akabrr
    19.12.2019 11:30

    На хабре же есть представители 1С (компании), может быть они как-то прояснят свое отношение к состоянию разработки в их фреймворке?


    1. EvilBeaver Автор
      19.12.2019 13:17

      Им нельзя, мамка не велит ) Я за них отдуваюсь… Состояние разработки описано в статье — с точки зрения IDE все пока что так себе. Есть новая IDE в статусе беты. Когда на нее пересядет вся отрасль — мой прогноз — очень нескоро, не раньше 5 лет в будущее.


      1. akabrr
        19.12.2019 14:23

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


    1. Arhitector1C
      19.12.2019 14:46

      Да, я представитель 1С. 1С — лучшая система в мире. Покупайте и программируйте только на 1С. Это быстро, качественно и недорого.


      1. EvilBeaver Автор
        19.12.2019 14:47

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


  1. devlev
    19.12.2019 12:14
    +1

    Прочитал от корки до корки. Автору огромный респект за статью!


    И все таки, мне кажется, open source захватит мир. Это не нормально, что идет отток программистов. Это не нормально что сама 1С — черный ящик. У меня лично складывается ощущение что 1С-ом правят какие то "волшебники".


    Мне кажется в идеальном мире должна быть какая то другая бизнес модель. Ну как например у того же nginx. А все эти закрытые ядра, уже пройденный этап — Internet Explorer например.


    Microsoft уже однажды профукал мобильных разработчиков
    Может ли с 1С произойти тоже самое?


  1. RomanSt
    19.12.2019 12:22
    +1

    Полностью осгласен с автором, хотя на 1С не пишу уже лет 8.

    Про недоспециалистов, которых легион, и которых шлют к вам учиться, вместо оказания полноценной поддержки. Так извините, пусть представитель ЯП/фреймворка/экосистемы в которой таких недоспециалистов нет, бросит в меня камень. Этот легион везде!!! И бороться надо с безграмотностью, а не с 1С.


  1. Almet
    19.12.2019 13:08

    «Используешь 1С — забудь про алгоритмы», помогите бабушке сдать отчетность в налоговую, а то что-то вся оборотка красная и непонятно откуда минусы. Статья хорошая, позновательная,
    НО программист 1С <> инженер-программист


    1. EvilBeaver Автор
      19.12.2019 13:19

      Лишь бы ляпнуть и пойти. Много ли в Java-разработке для предприятий тех алгоритмов, ась? А неучей там и подавно полно. Я насмотрелся, не проведешь.


      1. Almet
        19.12.2019 13:31

        Я не ляпнул, 1С-ом занимался с 2009-2018 г. сразу выбрал 8.0 а не 7.7, хоть и 7.7 имела доминирующее положение (даже сейчас есть конторы, которые сидят на 7.7, но только из-за того, что перенос данных и доработок стоит космос). Доминирующей работой специалиста 1С является поиск ошибки, приводящей к неверной отчетности, которую допустил пользователь при вводе данных (взять то же неоперативное проведение), а то что так делать нельзя — никому не интересно, т.к. руководитель послушает бухгалтера, чем программиста (особенно молодого). Так что 1С считаю хорошей учетной системой, НО, только в рамках того, что от нее требуется — учет прихода/расхода. То, что ПДФ создается одной строчкой в 1С — не считаю преимуществом, т.к. то же самое можно сделать и в ООП благодаря полиморфизму ;)


        1. EvilBeaver Автор
          19.12.2019 13:42

          То, что ПДФ создается одной строчкой в 1С — не считаю преимуществом, т.к. то же самое можно сделать и в ООП благодаря полиморфизму

          Именно полиморфизму? Точно не инкапсуляции?


          1. Almet
            19.12.2019 13:49

            А вы точно программист ООП или проверяете? Или вас смущает что может быть созданы объекты ReportPDF, ReportXLS и ReportTXT имеющие общего родителя с функцией вывода результата? К чему это больше подходит, к сокрытию или расширению функционала?


            1. EvilBeaver Автор
              19.12.2019 13:55

              del — предыдущий камент отредактирован.


            1. EvilBeaver Автор
              19.12.2019 14:08

              Меня смущает, что вы продолжаете ляпать про ООП и полиморфные объекты, а речь идет про конкретные реализации вывода в PDF на промышленных языках. Нет хорошей реализации вывода. А уж в какой класс "программист ООП" это потом вставит — совершенно несущественный вопрос.


              1. Almet
                19.12.2019 14:29

                А вот это как раз и существенный вопрос, т.к. программирование на 1С не особо заставляет думать над архитектурой (все уже придумали до нас). Вот это«куда вставить» потом боком и выходит, т.к. код разместил специалист в модуле формы и при обновлении все конечно же слетело :).
                1С делает все, чтобы снизить стоимость разработчика. Взять те же самые управляемые формы и СКД. Все можно настроить из Предприятия, НО, пользователи же не хотят учиться и разбираться как это работает, поэтому проще взять кодера 1С, он и принтер подключит, и кофеварку починит, и оборотку исправит, онжепрограммист. А то, что в клиент-серверном варианте 1С не работает бар-код, это нормально, «можно же файловую базу развернуть, у вас все-равно мало людей с базой работает». Это мне внедренец 1С посоветовал ))))
                Я ничего не имею против 1С, хорошая учетная система. Но называть сопровожденцев 1С — программистами, на мой взгляд не корректно, хотя бы в силу того, что в документации 1С нет описания типов данных и количества объема памяти, выделяемых для хранения. Хотя зачем это 1С…
                И к стати, по поводу PDF — habr.com/ru/post/112707, статья от 2011 года, когда в 1С и в помине PDF-а не было.


                1. EvilBeaver Автор
                  19.12.2019 14:46

                  Оооо да. Поверьте, я видел и даже руками пробовал все эти библиотеки и не спроста гневаюсь на ситуацию с PDF в .NET


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


                  1. Almet
                    19.12.2019 14:49

                    Какой вид сортировки используется в 1С?


                    1. EvilBeaver Автор
                      19.12.2019 15:01

                      В каком месте?


                      1. Almet
                        19.12.2019 15:03

                        В динамическом списке


                        1. nirom
                          20.12.2019 10:57

                          За сортировку отвечает СУБД, и не важно где вы программируете, в 1С, либо в каком-нибудь серьезном ООП проекте на Java или C++.
                          Вы что применяете знания ООП для сортировки или каждый раз пишите сортировку пузырьком на С++?


                          1. Almet
                            20.12.2019 13:55

                            Если вы работали с 1С, то знаете, что прямого доступа к СУБД не имеется, а только через «сервер приложений», а как оно там устроено — знают только разработчики.


                            1. nirom
                              20.12.2019 14:07

                              Это вариация типичной трехзвенная архитектура. Ни 1с-нику, ни любому другому прикладному программисту (Java, C++, Python и т.д.) не нужно беспокоиться о типе сортировке в динамическом списке (или его аналоге), об этом побеспокоится СУБД, и решит эту задачу куда лучше прикладного программиста.


          1. Neikist
            19.12.2019 13:56

            Ну в целом скорее полиморфизму кстати наверно)) Правда полиморифизм не только в ООП есть, просто ООП позволяет той самой инкапсуляцией типам поведение добавить.


      1. nirom
        20.12.2019 14:29

        Да. Человек занимается фундаментальными нерешенными проблемами вывода в pdf средствами ООП, а также сортировкой. Вы — автоматизацией бизнес-процессов. Чувствуете разницу?


  1. zurapa
    20.12.2019 09:53

    Не сказал бы я что Конфигуратор на столько плох, чтоб его ругать. Мне кажется, «плохому танцору всегда яйца мешают». Вот хранилище, контроль версий — это жесть какая-то в 1С. А конфигуратор пойдёт.

    Про феноменальность и крутость печатных форм улыбнуло. С виду это дейстительно крутым кажется. А когда в деталях заморачиваешься, разбираешься, там такое встречаешь?.. Плакать хочется. Некоторые очевидные вещи приходится на коленях делать. При том, что в форматировании текста, это очевидные потребности. В общем, если не лукавить, то хорошие документы текстовые одним шрифтом, одним стилем можно сделать, а если ваш заказчик, любит написать договор с жирненькими словечками, наклонными буковками выделять слова, то там вы красиво ничего стоящего не делаете. Будет мучительная боль. Вообще с табличными документами в 1С нельзя допускать работать педантов, которые любят, чтобы не было лишнего, отступы были правильны и прочая непечатная хрень помещаемая не к месту их возмущает. (намекая на себя). Если вы курсовые, дипломные работы оформляли не как все пробельчиками, межстрочный интервал энтерами, а делали всё, как положено по стилям, с настройкой отступов межстрочных интервалов в стиле, как это в Word реализовано, то тут вы будете плакать, рыдать, ненавидеть 1С, и мечтать о расправе с Нуралиевым.


    1. CrushBy
      20.12.2019 10:20

      Я собственно об этом выше и писал, что не стоит смешивать печатные формы и отчеты. Это разные механизмы, и у них разные задачи. Печатные формы, в любом случае, должны строиться в графическом формате (типа CrystalReports, FastReports, JasperReports и т.д.).


      1. Ta_Da
        20.12.2019 10:44

        Вот каким боком ваш ответ относится к комментарию, на который вы вроде как отвечаете?
        Где там про смешение отчетов и печатных форм (я уж не говорю, что вообще «смешение» это существует только в воображении команды ls fusion)?
        Более того, насчет «в графическом формате» — zurapa как раз и пишет, что «в графическом формате неудобно», в контексте сложных (читай «со сложным форматированием и кучей динамически изменяемых реквизитов») печатных форм.


    1. tsukanov-as
      20.12.2019 10:33

      Хранилище для конфигураций до миллиона строк работает прекрасно. Даже через интернет.
      Говорю как человек который именно в таком кейсе работает 2 года ежедневно.
      То что там нет веток, для кого-то минус, а для кого-то плюс.
      Для небольших команд ветки не особо нужны если не фанатеть по гиту.


    1. andy_minsk
      20.12.2019 10:55

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


    1. Ta_Da
      20.12.2019 11:33

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

      У меня наверное недостаточно опыта в таких задачах (менее требовательные заказчики?), но редко возникали проблемы с форматированием. В крайних случаях решалось с помощью шаблонов Word (для каких-нибудь договоров/счетов с хитрыми колонтитулами и факсимиле, когда не хотелось морочиться с копанием во встроенном табличном документе).

      Формально, вашу задачу можно попробовать решать с помощью объекта «HTML документ», но да, там тоже будет боль.
      Вообще, интересно было бы иметь возможность вставлять форматированный текст в конкретные ячейки табличного документа (или наоборот — вставлять табличный документ в форматированный текст). С другой стороны — в том же Excel такой возможности тоже нет (или есть?).


  1. Shrk66
    20.12.2019 12:38

    Большое спасибо за статью, удивительно здравый текст по такой холиварной теме. Очень редко профи дают себе труд высказаться, обычно обсуждают люди, слабо разбирающиеся в предмете) Единственный вопрос к слову «фреймворк». В моем понимании фреймворк- это что-то, написанное на языке. Джанго, Симфони, БСП- это фреймворки. А Платформа 1с все же платформа, как Питон, Джава и Си шарп, на мой взгляд. Фреймворк, включенный в платформу уже не очень фреймворк, на мой взгляд.


    1. Ta_Da
      20.12.2019 12:48

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

      Ну и есть такой любопытный момент, как «встроенные в платформу обработки» (просмотр списка активных пользователей, просмотр журнала регистрации), которые с одной стороны — недоступны для редактирования разработчиком (хотя можно подменять их вызов своими) и «зашиты» на уровне платформы, а с другой — являются обработками написанными на встроенном языке 1С (вообще, при переходе с 7 версии 1С на 8ую, меня дико радовало именно расширение возможностей встроенного языке, когда для многих объектов платформы, которые в предыдущих версиях были «черным ящиком», стали добавлять API).

      Кстати, некоторые вещи наоборот, сначала появлялись как библиотеки на встроенном языке, а в последствии были встроены на уровне платформы (для увеличения быстродействия — строковые функции, например, или необходимости работы на более низком уровне — версионирование объектов).