Comments 1784
Не моя тема, но все равно встряну. Знаете, что самое забавное. Я на хабре долгое время был с неполноценным аккаунтом (то есть read only). Но в принципе меня это не смущало, я оставлял комменты — разные критические и наоборот. И их всегда одобряли. Всегда кроме одного случая. Когда я в статье самого 1С спросил, а зачем они разделяли сервер и клиент (ну с пояснениями в стиле этой статьи). Его просто завернули. Видимо их такие мелкие проблемы не волнуют, ну или не барское это дело отвечать на такие вопросы.

У платформы 1С действительно есть недостатки, но есть и преимущества, которые перевешивают недостатки.
ИМХО 1С-ный ОРМ покрывает около 95-97% типичных учетных задач, автоматизацией которых занимаются "автоматизаторы"! финансового и управленческого учета.


С 1С ковыряюсь с 2002 года и мне очень редко было необходимо работать в обход 1С-ного ОРМ, непосредственно с SQL-сервером. Создать 3-4 вьюва исключительно для ускорения работы или заполнить прямыми запросами новый регистр.
А достаточно мощный механизм внешних компонент и работа с OLE/COM объектами из встроенного языка способны покрыть все остальные нетипичные задачи.
Ну а огромнейший каталог готовых решений — очень экономит время. Ну, вы и сами знаете. :)
ПС. полезно смотреть на продукт глазами стороннего от 1С человека, можно понять, что ты пропустил.
ПС2. Время — один из ценнейших ресурсов разработчика сейчас. И с его экономией 1С справляется на твердую четверку с плюсом.

Кстати, с тех пор как 1С отвергла идею внедрить в 1С конфигуратор наработки Орефкова по снегопату/openconf-у(1), я к 1С-у отношусь как к типичным барыгам, не более того.


(1) Это что-то наподобие визуал-асиста для MS VS студии.

Да понимаю тебя, сам не могу понять как сообщество терпит, видно вместо того чтобы сказать об этом — сообщесто прогресивных решило так — «а давайте мы сделаем работу 1с и назовём это опен соуросом», смешно получается.
Ох да, автор прекрасен. Забайтил на регу на хурбербере.
Такой некомпетентности в подобных вбросах я ещё не всетрчал.
Например про «Неэффективное получение данных объектов» или про «Отсутствие ограничений и событий для значений регистров» — это прекрасно, автор.
А ещё это: «В параметрах виртуальных таблиц можно использовать только константы».
Господи, я понимаю почему 1С заминает подобные темы, потому что за такое количество времени людей просто достало отвечать вот на подобные «гав».
Ну это правда смешно)
И если бы в других статьях хотелось бы ещё поспорить или указать на неточность в понимании ПРОБЛЕМЫ автором, то тут просто эпик. Это реферат, видимо) Просто уникальное НЕПОНИМАНИЕ матчасти вами же так глубоко ненавистной 1С)
Поднял настроение с утра, спасибо, знающий человек))
Очень конструктивный комментарий. Спасибо.

Если вы уж говорите о некомпетентности, так напишите что конкретно не так. А так на истерику больше похоже.
Знаете, автор, ваше творение просто не выдерживает критики. Я понимаю, что на вашем сайте ваше решение содержит одни + в зеленых квадратиках, на фоне других платформ, но просто из интереса, пообщались бы с 1С разработчиком, прежде чем вбрасывать ЭТО и сидеть тут и жать Ф5, в поисках одобрения людей, которые видя что либо плохое в сторону 1С сразу ляпнут лукас)
Вы наверное на мисте 6 частей (по 1000 сообщений) обсуждений пропустили. Конечно на мисте называть что-то обсуждениями — очень сильно ей льстить. Хотя определенный шарм в таких срачах все же есть (как с семечками или черешней, тяжело остановиться когда уже начал). Собственно много пунктов из обсуждений на мисте и пришло.
Странное ощущение — что именно то не выдерживает критики? Я опытный разработчик 1С и могу подтвердить что всё что тут перечисленно большая боль для меня — и самое больное что 1С совсем не собирается что то сделать полезное, всё что она может это изолироваться и поддерживать клуб любителей такой изоляции.
Я со всем согласен кроме части про блокировки и СКД.

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

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

В то же время совсем нулевые девочки из ЗУП которые даже компьютер сами выключить не могут, активно используют отчеты на СКД (конечно обернутые в более дружественный интерфейс).
На самом деле управляемые блокировки достаточно удобны и в друхе времени.

А что в них удобного? По сути нужно в голове все race condition держать, что очень сложная задача. Repeatable read с прозрачными материализациями и / или FOR UPDATE в ограничениях куда проще и удобнее.

А СКД — да, как такой «BI для бедных» может и имеет смысл. Но а) настройки в ним такие же примитивные как в BI — то есть группировка по полям, поля по прямым ссылкам (никаких регистров) и формулы, б) они нагружают оперативную базу, в) визуализация (например цветовая) там гораздо хуже чем в большинстве BI Tools.

Да и с точки зрения UX Еще->Изменить Вариант на порядок уступает тому же Imply.

Но это если мы говорим про пользовательские настройки. Как конструктор отчетов он не сильно лучше и не сильно хуже стандартных Crystal/Fast/Jasper и т.п. Собственно неудивительно что его аналога в мире никто и не делал, потому как непонятно зачем.
UFO landed and left these words here
UFO landed and left these words here
One to many это когда вы можете любую таблицу по полю замаппить в коллекцию любого объекта по полю. В 1с это можно сделать в очень частных случаях.

Про чтение, если вы обратитесь к объекту по ссылке (как это принято в orm) он считается целиком (с табличными частями). Я ссылку в статье давал.

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

Голый sql это все эти ВЫБРАТЬ ИЗ СОЕДИНЕНИЕ, которые по сути тот же самый SQL но на русском.

Возвращается к ORM — то есть считывают объекты и обращаются к ним по ссылкам, в циклах и т.п.

ЗЫ: с телефона не очень удобно отвечать, чуть позже отвечу подробнее.
One to many это когда вы можете любую таблицу по полю замаппить в коллекцию любого объекта по полю. В 1с это можно сделать в очень частных случаях.

Критерии отбора не подойдут?
UFO landed and left these words here
А можно прикладной неабстрактный пример такой потребности в терминах бизнес-логики, для понимания? Чтобы не обсуждать сферического коня в вакууме.


Вообще, если вы заметили это не в проблемах было, а именно в описании как это в 1С сделано. Я сам, если честно против классического ORM, но раз в 1С его решили поддерживать, то делали бы это нормально. А так ни рыба, ни мясо получилось.
Что мешает дёрнуть все нужные реквизиты в первом же запросе, не формируя по одному запросу для каждой ссылки? Обойдемся ровно одним запросом.

Потому как это уже не ORM по сути.
Это вкусовщина. А вот приведите хороший, годный ORM с более простым синтаксисом, чем этот? Работал я на SQLAlchemy — вот где ад и израиль, для не очень примитивных запросов приходилось перерывать их документацию чуть менее, чем полностью (и иногда в итоге скатываясь к конструкциям, которые поддерживаются только конкретным движком). А тут пиши себе на SQL-like языке, который платформа сама транслирует в нужный диалект. По мне так это удобно и колоссально снижает порог вхождения. Но если у вас есть примеры более удобных подходов — с удовольствием ознакомлюсь.

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

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

Ну… 1С вообще-то и не говорят что у них ORM (https://habr.com/ru/company/1c/blog/334050/)
Да это эпичная статья, наглядно показывающая, какая каша в голове у них творится, и собственно почему у них такое количество текущих и избыточных абстракций.

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

Желаю вам найти заинтересованных в вашей платформе клиентов и разработчиков.
UFO landed and left these words here
воспринимается намного менее прозрачно, чем

Ну вы тут немного лукавите, взяли разные по сложности запросы, переводы строк добавили, ну и т.п. Вы с HQL hibernate'ским лучше сравните.
А можно на уровне идеи как это должно работать? (или rbymnt ссылкой). Вот честно интересно. Сабжевый ORM'ный «более высокоуровневый язык на функциях» всё равно движку придется в конечном итоге превращать в конечные запросы MSSQL, Postgre и Ко, иначе как без этого дёрнуть данные из базы. Как процедурный язык с произвольным кодом превратить в эффективный SQL-запрос? (а не в соответствующую неэффективную лапшу на каком-нибудь T-SQL под капотом с курсорами и подзапросами в циклах).

Ну вот так например. Но вообще можете в блоге посмотреть статьи. Что касается эффективности запросов, то можете статью «Почему не SQL?» почитать, чтобы понимать какого класса оптимизации делаются в том же lsFusion.
У 1Сников то всё просто: отрезали все расширения разных диалектах, и почти один-в-один транслируют свой суррогатный язык запросов в запросы движков, местами добавляя постобработки в виде СКД. Далеко не супер гибко, зато достаточно эффективно (в рамках ограничений, налагаемых «кроссдвижковостью» конечно).

Ну в 1С как раз все по старинке императивно. Такой ПХП с парой высокоуровневых абстракций и визуальным программированием.
А можно прикладной неабстрактный пример такой потребности в терминах бизнес-логики, для понимания? Чтобы не обсуждать сферического коня в вакууме.

Могу привести реальный пример.

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

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

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

Это костыль, но по другому сделать не получается. Хранение каких-то сложных параметров в справочниках, чтобы ссылку на элемент справочника записать в регистр или табличную часть — вполне обычное явление.
UFO landed and left these words here
Ну да, можно и по другому. Ещё можно сделать регистр и хранить данные в нём. Кстати, несколько табличных частей не получится создать в регистрах. Но всё это не отменяет факта того, что тривиальная задача для СУБД выливается в «изобретательство».

Вышеописанное — не моё изобретение. «Деньги» — конфа, которая пишется «разработчиками 1с».

Я бы не отказался от возможности создавать «табличную часть» для любого реквизита. Ещё очень не хватает возможности создавать функции в записях структуры (хотя бы записывать ссылки на функции) — можно было бы накостылить аналог ООП.

Но вообще, вы просили пример, я его привёл. Нерешаемых задач нет — в крайнем случае можно всё хранить в xml в хранилище значения (кстати так поступают/ли с контактными данными в типовых конфигурациях, если мне не изменяет память). Но, имхо, ограничения платформы зачастую мешают, и часто спотыкаешься, если не пилишь стандартную систему количественного учёта чего-нибудь.
Про чтение, если вы обратитесь к объекту по ссылке (как это принято в orm) он считается целиком (с табличными частями). Я ссылку в статье давал.

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

its.1c.ru/db/metod8dev/content/2717/hdoc
И как кэширование меняет факт того, что он считается целиком с табличными частями? И главное вы же понимаете, что кэширование помогает только при повторном обращении в одном вызове к одним и тем же данным (что далеко не главная проблема).
Если большинство данных нужно будет использовать несколько раз за вызов, то логично получить все объект через ссылку и чтобы он закэшировался. Если нужно всего несколько реквизитов объектов (объекта), то можно воспользоваться запросом. Но обычно через ссылку данные получают только для изменения, для чтения пользуются запросом
Вы же понимаете насколько более неудобным и многословным код делает использование такого подхода с чтением через запросы? Да, в 1с по другому никак, но это не значит что это хорошо и удобно.
UFO landed and left these words here
Я ниже с ходу предложил костыльное решение https://habr.com/ru/company/lsfusion/blog/468415/#comment_20703549
А если хорошенько подумать можно и гораздо менее костыльное придумать используя анализ кода для оптимизаций. Просто то что я предложил — не должно быть сложно реализуемым в платформе, другие решения, более удобные и красивые, могут оказаться гораздо сложнее а то и нереализуемыми если оставить язык 1с.
Нет, не так. lsFusion все сама соберет в один запрос и одним запросом все считает. Но даже если не получится, кэширование в виде всяких shared buffers уже есть в самой СУБД. То есть по факту, если вы два раза считаете одни и те же данные ничего страшного. Если конечно вам при этом все равно надо считывать другие данные, и количество запросов будет минимальным.

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


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

А те кто начинают с этим спорить, не смогут вас понять все равно.
И, естественно, настоящие 1С-программисты не будут снисходить до уровня простого Java/SQL-разработчика, чтобы пояснить, какую именно матчасть учить, и в чем он ошибается. Ах да — у 1С же документация платная, и бесплатно никто ничего пояснять не будет. Это же не в стиле 1С экосистемы.

Вас обманули. "1С: Предприятие 8.3. Версия для обучения программированию" можно получить бесплатно по первой ссылке в гугле указав е-mail и какие-то регистрационные данные. В комплекте кроме документации еще и книжки какие-то были. Ну и бухгалтерия типовая вроде бы в качестве решения.

Это не та документация, увы. Тоже в свое время будучи 1сником разочаровался что с доступом к документации беда без ИТС.
UFO landed and left these words here
Эээ. У MS Dynamics как раз вроде как бесплатная документация. Я там много чего находил.

Microsoft в последнее время вообще радует своей открытостью во всем.
Потому что это практически единственный их шанс выжить. Иначе никому не нужна будет их документация и проще будет забыть про майкрософт, чем покупать документацию. Были бы они на коне как раньше, была бы такая же платная документация и прочее. А сейчас для них это вопрос жизни, потому и открыты.
Майкрософт еще не скоро умрет — это не вопрос жизни и смерти для них. И речь идет не только об открытости документации, а также об их недавнем повороте в сторону линукса и сообщества в целом.
Замечу: Желтые книжки про синтаксис — по сути «распечатанный» синтакс-помощник, который поставляется вместе с платформой.
Для «личного самообучения» есть Версия для обучения программированию, которую можно вообще скачать бесплатно.
UFO landed and left these words here

В смысле не та? Там руководство разработчика, руководство администратора, книжка про начало программирования в 1с. Что вы еще желаете там увидеть? У ИТС-техно объем документации в точности такой. Но за деньги. )

Ну человека в начале этой ветки послали матчасть учить, т.е. правильные 1сные практики (вроде тех что на спеце по платформе проверяются), работу с БСП и какими то стандартными решениями и прочее. Ну и кстати, если заказывать коробку — это не бесплатно (там все эти руководства и Радченко). Если заказывать в электронном виде — там этого нет (не было когда я это делал по крайней мере).
А почему у меня вот по этой ссылке дает только демо-доступ на 7 дней?

Назовите мне еще хоть одну вменяемую технологию, где документация за деньги (причем еще и по подписке)?

Вы все-таки скачайте версию для обучения. Вам дадут пожизненный доступ на сайт ИТС для обновления и к документации для разработчиков.


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

Разве уже дают? У меня этого доступа нет, хотя версию для обучения даже коробку покупал, только к обновлениям платформы и совсем базовой документации. Может что покупал 5 лет назад а не сейчас…
Вы все-таки скачайте версию для обучения. Вам дадут пожизненный доступ на сайт ИТС для обновления и к документации для разработчиков.

Я скачал. Мне не дали. Что я сделал не так?

Я не знаю. Мне когда-то дали. Документацию-то в поставку положили?

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

You're welcome:
https://toster.ru/tag/1с/questions — 1310 вопросов, 59% решено
https://toster.ru/tag/1с-предприятие/questions — 503 вопроса, 57% решено.
Но это для тех, кто случайно сталкивается с 1С. Более глубокие вопросы бесплатно прорабатываются на инфостарте.
В том, что у 1C есть большое коммьюнити и Q&A ресурсы, никто не сомневается. (1310 вопросов — это, правда, как-то мелковато для того количества программистов и того времени, которое существует платформа). На ru.stackoverflow, например, есть еще 3-4 сотни вопросов. Вот только это ни разу не документация. По Q&A вряд ли получится что-то с нуля изучить.
DAleby претензия же была к тому, что никто не помогает? Помогают!

Согласен, что глупо изучать работу с платформой 1С по форумам и чатам. Для этого есть документация! Можно бесплатно и официально скачать учебную платформу, общую документацию, популярные конфигурации и книги Радченка с Хрусталевой — online.1c.ru/catalog/free/18610119
Я когда-нибудь устану такие комменты одобрять. Но потом же будут говорить цензура.

Слушаю и ваши комментарии. Что, где, по какому пункту не так?
А так, у меня два вопроса к авторам, просьба ответить честно:
1. Для кого написана эта статья?
2. Для чего написана эта статья?
Для того же для чего пишут все статьи на хабре. Рассказать про проблемы технологий (в данном случае конкретной технологии) и способы их решения. Как для 1С разработчиков, так и для других разработчиков бизнес-приложений и вообще бэкендов (чтобы они знали «как там у них», да и проблемы у них во многом могут быть схожие).
И, совершенно случайно, в корпоративном блоге компании, не имеющей никакого отношения к критикуемой технологии? Спасибо за честный ответ.
А Вы видели как Ауди с БМВ троллили друг друга в рекламе? Было достаточно забавно и никакого особо негатива. Сторонним наблюдателям было интересно.
Ну как бы весовые категории в данном случае несколько, скажем так, различные. Я как раз и пытался узнать, для кого они эту рекламу написали, но не судьба, видимо.
Например, когда у кого-то, кто конкурирует с 1С, будут спрашивать, а чем плох 1С, то ему смогут давать ссылку на эту статью.
Если только конкурируют платформы для разработки, а не готовые решения. Я, правда, слабо представляю подобную конкуренцию между 1С и lsfusion, ниши практически не пересекающиеся.
Тут речь не только про lsFusion идет. Если у меня написано на .Net, а у кого-то на 1С, то можно говорить, что там хуже, так как строится на слабой платформе (по крайней мере, с точки зрения маркетинга). Все же понимают, что дом построенный на плохом фундаменте будет хуже, чем тот, который построен на хорошем.
Сравнивать будут решения по функциональности и качеству решения проблем бизнеса, в первую очередь, стоимости доработки и сопровождения во вторую.
Если же брать разработку с нуля — lsfusion надо тогда сравнивать с .Net, CUBA, odoo. 1С больше про готовые решения, а не про платформу.
Вы не поверите, на 1С много отраслевых и самописок с нуля пишут. О чем собственно и сказано в статье.
Так отраслёвки пишут обычно франчи 1С, часто как нашлёпки на типовые от 1С, на чём же ещё их писать франчам? С нуля от независимых разработчиков знаю только про WMS системы, и отдельные редкие случаи, вроде Деловых линий.
А я очень много знаю. Более того в Беларуси основной игрок на рынке бухгалтерии (!) свою конфигурацию с нуля писал. Ну или на рынке FMCG розницы (где Астор например тоже с нуля свою конфу делает).

И вообще у чуть более крупных клиентов самописок на 1С более чем достаточно.
Не знаю как у вас там, в Беларуси, а в России самописки на 1С у крупняка обычно получаются в результате многолетней доработки изначально типовой 1С, которая происходила параллельно с ростом бизнеса. Чтобы так осмысленно взять, и в крупной компании абсолютно с нуля писать своё на 1С — это очень большая редкость. Астор, опять же, тоже скорее всего из франчей/отдела 1С-ников вышел, так что ниразу не показатель.
Вы видимо в обсуждении на мисте не учавствовали. Вы же понимаете, что к примеру УТ или ERP для FMCG розницы (да и не FMCG) не подходит никак (там половины нужных модулей нет). И допилить УТ до нужного состояния это все равно что из танка самолет сделать. Особенно с учетом убогости возможностей рефакторинга в платформе. И Астор с нуля писал, не понимаю почему не показатель.
Писал Астор с нуля на 1С потому, что уже имел штат специалистов по 1С, а не потому, что осознанно выбрал эту платформу. То, что типовые от 1С — далеко не идеал, спорить не буду, это мне вполне очевидно.
Помню ту конфу для розничной торговли (Модный магазин), их первая попытка перейти на 8-ю платформу. Долго они пытались нам её внедрить, всё время хотели, чтобы мы переделали свои бизнес-процессы под их алгоритмы. В результате год потерянного времени и куча денег в никуда. Потом перешли на самописку на основе типовой Розницы.
UFO landed and left these words here
Нравится <> Идеал. То, что могло быть намного хуже — согласен. Но могло быть и намного лучше :)
UFO landed and left these words here
Как платформа 1С проигрывает всем на рынке. Даже SAP. Причем практически по всем пунктам. Но раз ей нет равных в мире, посмотрим как ей удастся выйти на англоязычный рынок без существующих разработчиков, и поддержки перемудреного местного законодательства. Шляпу готовы съесть, если в течении 5 лет они даже 0.01% мирового рынка не займут?
Как платформа 1С проигрывает всем на рынке. Даже SAP. Причем практически по всем пунктам.


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

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

а по поводу мирового рынка, на родине SAP не так давно дойчебанк С ГОРДОСТЬЮ ХВАСТАЛСЯ о том что у них появился андроидпэй… эпл пей пока нет но вот андроидпэй появился…

так что заливать про мировой рынок не надо…

Вы так говорите, как будто функционирование androidpay и applepay это заслуга 1С.

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

вроде — родина SAP — а телефоном расплатиться в метро или где-нибудь там в палатке покупая мороженку — нельзя… технологии то не позволяют…
я так говорю в пример того что «мировой опыт» зачастую где то там далеко отстает от российского…

Особенно в разработке ПО, да.

мой пример был приведен в качестве того что безапелляционно и закрыв глаза повторять что «мировой опыт всегда на шаг впереди российского» — по крайней мере не верно…

а по поводу разработки отраслевого ПО — ну вот пример 1С… есть аналогичные системы с подобным сбалансированным функционалом, стоимостью, порогом вхождения, поддержкой нац/законодательств на западе?
безапелляционно и закрыв глаза повторять что «мировой опыт всегда на шаг впереди российского»

А кто это говорил?


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

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


И как минимум в США как минимум для SMB на этом рынке весьма жесткая драка.

А кто это говорил?


таков контекст беседы…

Не могу сравнить их функциональность и порог вхождения с 1С, конечно же, но кого это волнует


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

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


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

Скорее наоборот: я пока не вижу оснований считать, что 1С — это более продвинутый и качественный продукт, чем (нужное вписать).

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


а я и не вам отвечал…

Скорее наоборот: я пока не вижу оснований считать, что 1С — это более продвинутый и качественный продукт, чем (нужное вписать).


не видите — не считайте.
не видите — не считайте

Тогда в чем смысл вопроса "есть аналогичные системы [...] на западе?"

У них это по другой причине сложилось. Там где прежде не было вообще никаких технологий, новые технологии ложатся как масло на хлеб. А там где работают старые технологии, новые часто конфликтуют и поэтому их внедрение затормаживается и требует серьёзного пинка чтобы пропихнуть. В конце концов, другие страны можно использовать как полигон для масштабной натурной обкатки технологий и выявление её слабых мест.
UFO landed and left these words here
Он никак не считает. Он ест, что дают.

И 1С не лучше всего остального, просто остальное, что существовало на рынке, не сильно лучше, того что предлагал / предлагает 1С. Поэтому не смогло его подвинуть, равно как и наоборот.
Он никак не считает. Он ест, что дают.

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

Рынок всегда ест то, что первое успело заскочить на рынок с MVP и/или попав в массовую нишу (бухгалтерию например). А дальше на этом рынке его в состоянии подвинуть, только что-то фундаментально лучше (чем альтернативы 1С не являются, явно как и 1С не лучше своих текущих альтернатив).
ну как бы 1С не первая заскочила на рынок… она выдавила с него многих и многих… и продолжает выдавливать…
UFO landed and left these words here
UFO landed and left these words here
… это все равно что из танка самолет сделать

Ох, как всё это знакомо.
1. Если знаете много и пишут с нуля значит есть смысл.
2. Если разговор про конфигурацию от Хьюменсистем. То это не пример нормальной/качественной разработки, а пример «впаривания» продукта. В которой ресурсов на защиту потрачено больше чем на бизнес функционал.
У меня сложилось впечатление что автор многие вещи пересказывает «со слов»
Но в конце автор и задается вопросом почему платформу 1с выбирают для разработки новых решений, вместо выбора более удобных вещей. У меня честно говоря только одно предположение — бренд и сеть франчайзи которая допилит в любой деревне за копейки новую колонку в отчет.
Например компания в которой я работал пишут «Итилиум», «1С: ТОИР», «1С:RCM». Но то ладно, то уже черт знает сколько лет франч (хотя для мобильных приложений их никто не заставлял 1с выбирать, наверно, отношения с вендором не очень хорошо знаю).
А так, сколько на инфостарте статей про новые «нетленки»? Иногда даже от частных лиц. Внутренние проекты иногда начинают на 1с, хотя даже не планируют во вне выпускать, но тут наверно по наличию ресурсов выбирают, какие программисты есть под рукой, те и пишут.
Ну вы же понимаете, что код как в статье допиливать — это мягко говоря не каждому под силу. Тем более в деревне. Мне стремно в него лезть, боясь что где-то что-то упадет, а уж франчу…

Собственно на том же рынке FMCG розницы в Астор даже компании со своим штатом 1С программистов боятся лезть (не то что франчи).
Ну вы же понимаете, что код как в статье допиливать — это мягко говоря не каждому под силу. Тем более в деревне. Мне стремно в него лезть, боясь что где-то что-то упадет, а уж франчу…

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

Собственно на том же рынке FMCG розницы в Астор даже компании со своим штатом 1С программистов боятся лезть (не то что франчи).


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

Это как Боинг стал бы автомобили строить. Тоже интересный рынок. Но не его. Они на самолетах специализируются.

UFO landed and left these words here
Ну вы еще бы в машинных кодах писали вместо того чтобы взять java, .net, python и подобное.
UFO landed and left these words here
C# лучше потому что язык статически типизированный с ООП и нотками функциональщины. А не потому что кто то более выскоуровневый кто то менее. Да и что это за параметр «крутость»? Важно удобство, скорость решения задач, сложность поддержки и развития и прочее.
C# лучше потому что язык статически типизированный с ООП и нотками функциональщины.


Лучше вообще?
Или, все же, лучше для задач, в которых используется 1С?

Понимаете в чем дело:

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

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

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

Понимаете, в чем дело:

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

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


Это одно и то же.

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

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


Да, все правильно.

Видимо, и плюсы динамической типизации вам известны тоже?

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

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

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


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


«Значительная часть в платформе» != «Все подряд в платформе».

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

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

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

А только потому, что 1С легко под себя подправить на месте — потому бизнес ставит себе 1С и уверен, что если что понадобится он легко и просто под себя подгонит. Этим занимаются программиста «на местах». Вот для этой основой массы программистов и не нужно усложнять работу.
Еще раз, не ради БСП, а ради того что мы строим над своими данными и логикой а так же бсп. Ну и какой нибудь пайтон не сильно сложнее 1с (если в дебри не лезть).
Ну и какой нибудь пайтон не сильно сложнее 1с (если в дебри не лезть).


Об этом и речь.
Сложнее всего осваиваются новичками базовые абстрации языков программирования.

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

Поэтому изучение другого языка для сложившегося программиста даже рядом не похоже на эту проблему для начинающего.
Вот не сказал бы. Можно ли назвать начинающими программистами людей которые по 5-7 лет на 1с пишут? А для них даже java или пайтон освоить гораздо сложнее чем программисту на C# например. Знаю немало примеров. Просто другие концепции часто применяются в современных промышленных языках которые к 1с неприменимы из за отсутствия ООП того же.
А вот писать на питоне в стиле 1с, но с добавлением типов в аргументы — мне кажется любой 1сник за пару дней осилит.
UFO landed and left these words here
делает код круче

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

З.Ы. А если отходить от коммерческой разработки — я бы тыкал c/c++, rust, haskell — но в коммерческую разработку я даже не думаю их тащить, потому что с коммерческой точки зрения на тех задачах которые я решаю они не эффективны. Эффективны языки вроде js (ух как я его ненавижу), dart (эффективность пониженная из за малой распространенности разработчиков и потому трудной заменяемости одного разработчика другим), c#, java, kotlin, python, даже php современный насколько слышал сейчас сделали более по человечески и подходящим для разработки крупных проектов.
UFO landed and left these words here
Их код поддерживать проще на словах, а на деле на их платформе невозможно вообще ничего создать такого, что будет интересно бизнесу. Абсолютно ничего.

А вы насколько хорошо знаете lsFusion чтобы делать такие выводы? По своему опыту скажу что мы например ведем постоянную доработку (по 25 задач в день) / поддержку порядка 40 различных клиентов со 30к пользователей в сумме силами 7-8 разработчиков lsFusion. А я знаю компании у которых больше 1с разработчиков на одну компанию из этих 40. Ну и про одного 1с разработчика работает только в очень простых случаях.


Я же им официально писал с просьбой предоставить простейший модуль, на что получил

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

UFO landed and left these words here

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


В любом случае спорить с вами дело неблагодарное, у вас редкая каша в голове, вы путаете платформу и решения на ней. По вашей логики qualcomm и intel вообще пустышки и не должны существовать так как ничего конечным потребителям предложить не могут. И эту разницу судя по реакции на ваши комментарии тут понимают все кроме вас. Поэтому дальше отвечать вам это переливать из пустого в порожнее. Так что я тоже пас. Может у lair ещё терпения хватит с вами общаться.

Смысл приводить примеры личного опыта как оправдание?

Так это ж ровно то, что вы делаете.

UFO landed and left these words here
Скажем так — 1 одинэсник запросто сопровождает все виды учёта предприятия, на котором учёт ну очень сложный

Любого предприятия, или одного конкретного предприятия?


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

Вы про конкретного "убийцу 1С", или про все конкурирующие платформы?

UFO landed and left these words here
Про всех убивцев 1С.

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

UFO landed and left these words here
Т.е. вы уверенно знаете, что плохо и не правильно

В определенных контекстах, да. Именно поэтому и уточняю каждый раз, о чем идет речь.


но при этом не знаете как правильно

Да нет, почему же. Я часто знаю, как лучше. Опять-таки в области своей специализации.


Тема то про очередного убивца 1С.

Нет, "тема" про то, чем 1С плох. Это не одно и то же.


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

— а почему никогда никому неудалось поймать Джо?
— потому что его никто никогда не ловил
А в командах какого размера вы работали и над какими задачами? Я вот одно время почти пару лет в разработке коробочных продуктов с нуля на 1с учавствовал, пусть даже команда небольшая была, 10 программистов 1с всего в максимуме. Ну еще аналитики, но они с кодом не работали. А потом еще 2 с копейками года эти коробочные продукты в командах на предприятиях внедряли. В т.ч. например одним из заказчиков был Магнит. И что такое поддержка, развитие, проектирование и рефакторинг проектов из сотен тысяч строк кода на 1с (думаю к миллиону ближе, точно не считали) — я представляю. Вы же, по моим ощущениям, скорее не роль программиста играете в рабочих процессах, а роль интегратора. И вам не важны те сложности с которыми сталкиваются разработчики продуктов.
UFO landed and left these words here
Поймите, на 1С из готовых кубиков собираешь нужное тебе приложение


Я что-то пропустил? Все готовые решения это огромные медленные монолиты. А с нуля разрабатывать на ТАКОЙ платформе (со всеми вышеобозначенными проблемами) это самоубийство.
UFO landed and left these words here
1С, это платформа, готовые решения, которые максимально подходят для большинства

Для большинства в какой выборке?

UFO landed and left these words here
В Красноярске (это такой городок в России) из всех предприятий, где я был (а это штук 20), всегда либо стоит 1С, либо переходят на неё

Я правильно понимаю, что выборка, на основании которой вы говорите, что 1С подходит для "большинства" — это 20 предприятий в Красноярске?


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

UFO landed and left these words here
не приводя НИ ОДНОГО аргумента в свою пользу.

У меня нет мнения о том, какая платформа лучше всего подходит для предприятий в Красноярске, откуда у меня какие-то аргументы по этому поводу?


Интересно было бы послушать про весь цивилизованный мир

О, так это легко.


Открываем, значит, StackOverflow jobs и пытаемся там найти хотя бы одну вакансию по 1С.


Ну или если вам технический сайт не интересен, то откроем Gartner, ERP-рынок, и попробуем найти 1С в списке "Top 5 ERP Software Worldwide".


Я достаточно регулярно слышу про SMB ERP-рынок в Америке и западной Европе, и 1С там не упоминается. NetSuite — да. Sage — да. QuickBooks. Dynamics. Иногда — SAP. 1С — никогда.


PS


Почему же так?

… например, потому что далеко не каждому предприятию нужен разработчик по платформе, на которой у него написано ПО.

а по мск ХХ мне выкидывает:
«Программист 1С» — 850 шт
«Java developer» — 2500 шт
Как вы будете решать задачу? Нужен некий портал/личный кабинет с пятью справочниками, и двумя документами. Есть нюанс. Будет 10к пользователей в течении одного часа с утра, и столько же вечером. Сколько такое решение будет стоить на 1С? Замечу 1С уже используется и вот к ней такой функционал надо добавить.
UFO landed and left these words here
Вы проигнорировали вопрос про стоимость. Сколько лицензий 1С надо купить. И какое железо для этого нужно. Да все 10к будут вбивать 1-2 документа. В течении этого часа. Могу сразу сказать такое решение на 1с + golang + postgres + vuejs выйдет не дороже 200к. И потребует не самого мощного сервера. А сколько будет такое решение стоить на 1С и сколько серверов под это надо? У меня есть пример где до сих пор сидят на 1с 77 только потому, что 8.х это монстр с неуемным аппетитом до ресурсов. И работать надо быстро. А не медитировать над проведением документов.
Так в том-то и дело, что 1С, это не платформа, на которой разрабатывают решения с нуля.

Опровергаю своим примером. Или вы думаете конфигурации 1с из воздуха берутся?
UFO landed and left these words here
Дайте готовое типовое решение на базе 1С под мобильную платформу с аппаратным сканером, которое по broadcastReceiver будет принимать ШК. Ну или попробуйте для чудесной мобильной 1С разработать внешнюю компоненту и желательно в одной IDE. Ну или получите 1к внешних событий за секунду(каждое по 300 байт), чтоб платформа не легла.

Asterisk в режиме полного дебага без фильтров на 500 абонентов. Компонента шлёт все как внешнее событие. Машина core i5 4670, 16 гб ram, 1Gb сеть, win10 PRO. Проводилось ради теста. 3 секунды 1с падает.

Но в целом, если поступает хотелка от предприятия, то сначала ищется что-то готовое и допиливается

А это готовое откуда берется? Вот как раз есть люди что это «готовое» пишут и поддерживают. Типовые и отраслевые конфигурации всякие там, и прочее.
Сравнение сложных IT-систем (в частности, ERP) очень больная тема. Все описанные в статье проблемы имеют прямое отношение к стоимости доработки и сопровождения. Или Вы считаете, что все современные подходы к разработке направлены не на это, а просто на то, чтобы потешить эго разработчиков?
Имеют, конечно, в общем. Но если есть готовое решение для производства от 1С, и нет такого от lsfusion, например, — не имеют, в частности :))
Это статья не про lsFusion, а про 1С. Возможно будет еще и про то, как это сделано в lsFusion. И выше я писал, что если речь идет о производстве на 1С и другой технологии, то эта статья помогает понять, как минимум, что плохо в фундаменте той, что на 1С.
Так ведь нет ничего другого в РФ за такие деньги, вот в чём проблема. Я и пытаюсь объяснить, что не конкурируете вы с 1С никак на уровне платформы.
Как минимум, lsFusion — это альтернатива для разработки так называемых «нетиповых» решений. О чем, например, указано в статье.
Ну да, альтернатива. Только не для 1С. Вы сильно преувеличиваете значение нетиповой разработки с нуля на платформе 1С в настоящее время.
Вся суть статьи в том, что у платформы 1С много проблем. Давайте не будем скатываться в обсуждение рынка бизнес-приложений и типовых конфигураций. То, что в США на COBOL'е работает куча крупных компаний, автоматически не делает COBOL классной платформой для разработки приложений.
Даю подсказку. Открываем список статей в блоге компании lsfusion. Смотрим количество плюсов и комментариев в статьях с критикой 1С и SQL, сравниваем с количеством авторов публикаций в блоге. Потом смотрим количество комментариев и плюсов в статьях без критики 1С и SQL (последние штуки 3-4), тоже сравниваем с числом авторов статей в блоге. Делаем выводы.
«Возможности ничего не стоят, без проблем которые они решают.» © будем считать мой.
«Совпадение, не думаю».

Давайте так, это Хабр. Если с каким то пунктом вы не согласны, отлично, дайте развернутый комментарий, покажите что автор не прав (вы же понимаете что многие на Хабр ради комментариев заходят). И тогда все поймут что это просто «маркетинговый бред», «автор просто не разбирается» и все в таком духе.
Нет, я получил честные ответы ответы на все свои вопросы, дальнейшая дискуссия смысла не имеет.
UFO landed and left these words here
В статье рассказывается система со стороны кодера и совсем никаким боком не затрагивается область бизнес-приложений. В том-то и проблема, что это трындец какие разные вещи. С одной стороны бизнесмену всё равно какой крутой или кривой код, ему то всё видится только в виде бизнес-объектов, тогда как с другой стороны, идёт измерение крутости кода


Все правильно пишите.

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

Но здесь это не так.

Авторы ссылаются на опыт глубоко подкапотачный вещей типа PostgreSQL vs Oracle.
Но там действуют другие правила.
В статье рассказывается система со стороны кодера и совсем никаким боком не затрагивается область бизнес-приложений.

Издеваетесь? Как раз основной посыл статьи, что вместо того, чтобы фокусироваться на бизнес-задачах разработчику 1С приходится заниматься всякой ерундой, вроде ручных блокировок, директив компиляции, callback'ов, ЗначениеВРеквизитФормы, связыванием списков и реквизитов и т.п.
в 1С больше инструментарий, а вы это преподносите как минус…
Да — в вашем мире и в вашей области автоматизации эти инструменты избыточны и ненужны… но ваше решение с 1С практически нигде не пересекается, по этому по сути вы еще не очень доросли до этих инструментов.

Ну не нужна вам асинхронность и управление серверными вызовами — да… вы просто не сталкивались с такими бизнес-задачами… а 1С сталкивался в полный рост…

это не делает 1С хуже — это делает 1С универсальнее и сложнее.

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

monosnap.com/file/ORhXPM24Lg4tmcFPob8Qs92cTY12XJ

сколько вы времени потратите и вообще сможете эту бизнес-задачу реализовать?
UFO landed and left these words here
Как раз основной посыл статьи, что вместо того, чтобы фокусироваться на бизнес-задачах разработчику 1С приходится заниматься всякой ерундой, вроде ручных блокировок, директив компиляции, callback'ов, ЗначениеВРеквизитФормы, связыванием списков и реквизитов и т.п.

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

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

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

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

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

Нет не как у нас. Раньше все (а точнее большинство) на клиенте было и автоматически блокировалось кучу лишних данных. Что не масштабируемо. А в lsFusion все масштабируемо — все на сервере приложений, прозрачные материализации и update conflict'ы из коробки и т.п.
Однако, оказлось, что чем более разноплановых задач ставят перед 1С — тем более разнообразные инструменты полезнее.

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


Зачем делать функционал, пока в нем не возникло потребности?

Это одно и то же:

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


Вы о чем вообще спорите?
О том, что есть 2 способа блокировок на выбор прикладного программиста (автоматический и ручной) и это плохо?

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

Кто вам сказал-то что он неработающий? Те, кто не умеют их готовить? Гы.

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

Кто вам сказал-то что он неработающий? Те, кто не умеют их готовить? Гы.

Речь шла не только про блокировки, а и про ОФ, про ОткрытьФормуМодально и т.п. Но даже касательно автоматических / ручных блокировок. Вы в курсе что в 1С автоматические блокировки ВСЮ таблицу в PostgreSQL блокируют, а в MS SQL на сложной логике и большом количестве пользователей у вас эскалации через раз будут, после чего база тоже в клинч начнет входить.
UFO landed and left these words here
А у вас есть свои интеграторы/внедренцы?
Ну просто демо-продукт на сайте он совсем… Ущербный…
Что-то более похожее на реальную жизнь увидеть бы.
Вы про эту демку? (но там только часть функционала, можете кликнуть на модули посмотреть, что именно там сделано)

Это рыба, на которой впрочем работает большое количество предприятий >= 4к сотрудников, причем все модули от производства, до автозаказов (кроме бухгалтерии, HR и фронта).
логика объектов напоминает обычный ORM, правда, со своими особенностями:

Никаких one-to-many, many-to-many отображений нет, их функцию выполняют так называемые табличные части — коллекции внутренних объектов, фактически агрегированных в основной объект.

Подчиненный справочник с владельцем и есть классическое one-to-many
Ну это все равно не совсем классический one-to-many, потому как, как я понимаю, работает между двумя одинаковыми типами (справочник-справочник), скажем справочник с регистром или документом вы так не свяжете. Но да про них, я что-то забыл, точнее про подчиненные справочники у меня был отдельный пункт, но потом исчез, а в другие не дописал. Сейчас попробую немного изменить статью.

Почему один объект справочника, на который ссылаются 1000000 записей регистра остатков и 1000000 записей документа, который породил эти записи регистра, это не one-to-many?

Вы из справочника через точку можете написать что-то вроде: Товар.ДокументыПрихода[10].Дата?
Ну почти во всех ORM. Например в Java указываете OneToMany и @JoinColumn для List и у вас будет коллекция с документами. В данном случае будет рандомный документ, хотя вроде можно порядок указывать в таком маппинге. Но 10 это я для примера написал. Пусть будет «FOR Товар.ДокументыПрихода».
Так цикл по выборке и в 1С можно и список выведет без проблем. Если конечно товар это реквизит документа прихода (а не его табличной части), что я только один раз в реальной конфе видел

Ну маппинг у 1с не такой богатый, как у хибернейта. Смогу написать Товар.ДокументыПрихода[10].Документ.Дата

Запросы по старинке пишутся в строках (смотри примеры выше). Это создает как минимум две проблемы


Никто не пишет вручную запросы, 98% разработчиков используют СКД (которую вы не поняли и решили что оно не нужно) в том числе в качестве редактора запросов.
Вы таки не забывайте что даже среди обычных разработчиков довольно немного народа знают SQL больше чем select/insert/update/join а через СКД можно создавать очень мозголомные конструкции в текстовом представлении которых даже имея большой опыт в 1С без бутылки водки не разобраться (и то потом в дурку увезут)

Учитывая это вы просто переносите свой опыт из других систем на 1С в стиле «ой тут не как в pl/sql всё плохо»… ага… будет у нас программист 1С, программист pl/sql ещё dba и веб программер… а потом мы вспомним что пишем конфигу для заводика со штатом 100 человек.

на 1С можно наваять сложную систему учета, и она будет работать, за то время пока для обычных 'фреймворков и sql' будут только писать ТЗ и набирать народ с вилкой 180-250

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

И в том же УТ, там 95% запросов это и есть примитивные select join (причем с промежуточными результатами во времянках). И я написал почему. Хотите вот сейчас пять случайных мест открою и вставлю сюда запросы. Ну или вы тоже самое сделаете.

Учитывая это вы просто переносите свой опыт из других систем на 1С в стиле «ой тут не как в pl/sql всё плохо»… ага… будет у нас программист 1С, программист pl/sql ещё dba и веб программер… а потом мы вспомним что пишем конфигу для заводика со штатом 100 человек.

Так в этом наоборот и проблема. Что 1С должен и в вебе и в SQL и в ORM разбираться и в запросы руками предикаты проталкивать. И потом у относительно небольших компаний штат 1С программистов — 15 человек. А у нас есть отдел из 10 человек, который дорабатывает нон-стоп и поддерживает 40 клиентов (в основном крупных), в которых в сумме 60к человек работает.
И потом у относительно небольших компаний штат 1С программистов — 15 человек

проклятие 1С в том что основные их клиенты это малый-средний бизнес, и им не надо штат в 15 человек

Я работал в одной средней конторе (500чел штат, офисы по всей стране) где 1С была ядром всего фин.блока и частью бекофиса основной (финансовой, это фин-контора) ИТ системы… у нас было два человека 1С-ника… и был отдел который поддерживал эту ИТ систему… как раз 15 человек java-программеров которые по 2-3 недели пилили задачи которые мы в 1С рисовали за 1-2 дня… и в итоге часть некритичного функционала начали сгружать в 1С из-за того что это быстрее, дешевле и эффективнее получалось
500 человек штат и целых 2 1С программиста? У нас я говорил выше есть ИТ отдел на 10 человек, который дорабатывает custom made решения для 40 клиентов с 60к человек штатом в сумме (у многих по 3-5 достаточно непростых задач в день закрывается).

Я просто не до конца понимаю, что именно быстрее там так сильно получалось. Особенно с учетом, когда запросы надо вот так писать.
Запрос
ВЫБРАТЬ
    РасходнаяНакладнаяСостав.Номенклатура,
    УчетНоменклатурыОстатки.КоличествоОстаток
ИЗ
    Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетНоменклатуры.Остатки(,
                             Номенклатура В (
                                   ВЫБРАТЬ Номенклатура
                                   ИЗ Документ.РасходнаяНакладная.Состав
                                   ГДЕ Ссылка = &Документ)) КАК УчетНоменклатурыОстатки
        ПО УчетНоменклатурыОстатки.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура
ГДЕ
    РасходнаяНакладнаяСостав.Ссылка = &Документ И
    (УчетНоменклатурыОстатки.КоличествоОстаток < РасходнаяНакладнаяСостав.Количество ИЛИ
        УчетНоменклатурыОстатки.КоличествоОстаток ЕСТЬ NULL)


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

То есть с точки зрения декларативности современный 1С от той же Java не сильно отличается, о чем я собственно и писал в статье.
Ну, современная Java все же получше чем 6-7. А уж если задействовать другие JVM языки вроде котлина, груви, кложи, скалы и прочих — можно вообще чудеса декларативности показывать.
Угу, сравнили — ваш отдел не поддерживает бухгалтерию, зарплату и производство, и при этом все клиенты из одной отрасли.
Из вот этого списка:

Human Resource.
Inventory.
Sales & Marketing.
Purchase.
Finance & Accounting.
Customer Relationship Management(CRM)
Engineering/ Production.
Supply Chain Management (SCM)

Поддерживается все кроме Accounting (у многих Finance мы тоже закрываем) и HR. Хотя да производство там простое (общепитовское). Есть клиенты из разных отраслей, в том числе даже BPM (некоторые очень публичные, которых по этой причине пока не можем называть). Хотя да, не спорю, есть перекос в FMCG розницу, где 1С не вытягивает по производительности и эргономике (также как и в банках) Но это временно.
есть ИТ отдел на 10 человек, который дорабатывает custom made решения для 40 клиентов

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

в моем примере этим занимается внутренний отдел разработки без привлечения оутсорса (вообще я не люблю оутсорс, который высасывает килотонны денег со слабым выхлопом и многомесячными препирательствами в согласовании ТЗ...)… а до этого нам 1С внедрял интегратор со штатом в десяток 1Сников, да… меня тогда взяли чтобы 'понять чё вообще происходит, каждый месяц по 3 ляма платится, результатов почти нет' — в итоге все свелось к 2м человекам в штате и повышением результативности разработки в сотни раз.

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

Вы думаете что на нашем рынке 1С нет? Но мы за счет эффективности все равно существенно дешевле чем свои ИТ-отделы и другие решения на 1С. И там далеко не простые типовые вещи (почитайте хотя бы задачи какие там решаются, а в FMCG рознице с ассортиментом в 100к взаимозаменяемых товаров требования к эргономике и производительности огромные)
а до этого нам 1С внедрял интегратор со штатом в десяток 1Сников, да… меня тогда взяли чтобы 'понять чё вообще происходит, каждый месяц по 3 ляма платится, результатов почти нет' — в итоге все свелось к 2м человекам в штате и повышением результативности разработки в сотни раз.

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

Затраты на франча были в разы больше
Также контора полуайтишная, и ИТ отдел в целом это самая большая статья затрат в принципе. и 'два человека в штате на 1С' — это цветочки по сравнению 15 java-программеров, четверо плюсовиков и два отдела эксплуатации с обычными админами… одинесники по сравнению с основным отделом разработки это бедные родственники… (я в итоге и сбежал оттуда к явистам… геморроя на 50% меньше, а зарплата на 100% больше, отпад)
==
и вообще, эта контора дочка огромной международной корпорации с забугорными акционерами, не испорченная 'российскими финдирами'
геморроя на 50% меньше

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

тоесть, я сейчас гораздо меньше всего делаю на питоне и эти вещи проще (занесло меня в эту сферу после явы), а получаю гораздо больше чем когда я работал с 1С
И это дело не в квалификации, со мной работал сеньор 1Сник (которого переманили из интегратора) имеющий огромный опыт в ERP, УПП и кучу одинесовских «специалистов»… и он получал меньше меня сейчас.
Это при том что мой коммерческий опыт программинга в 'обычных языках' у меня всего 5 лет. (я до этого был админом, а одинесил с 2005 года)
p.s. это всё в мерках Московских зарплат миддл-сеньорского уровня обоих сфер
Так может потому что
огромный опыт в ERP, УПП и кучу одинесовских «специалистов»

нигде толком не применим кроме 1с? Тогда как например C# разработчик спокойно переквалифицируется на Java или C++ при необходимости и ему не нужно будет в подробностях изучать кучу готовых «конфигураций» чисто прикладных. Да и знание прикладной области гораздо менее важно чем для 1сника. А для 1С сперва стоят знания конфигураций и предметной области, а только потом знания собственно приемов и практик программирования, работы ОС, сетей и прочего.
Какие задачи на питоне решаете что гемора меньше? А то может тоже из 1С свалить ) Питон и JS я знаю и смотрю по сторонам с прищуром ))
UFO landed and left these words here
так это же хорошо, когда можешь решить реальную задачу бизнеса, понимая его проблемы и методику, а не тупо кодить по готовому ТЗ, в котором за тебя подумали как делать и ты не можешь шагнуть в сторону
А за тарелку супа или за масло с икрой — щас выбора много где от 150-180 предлагают на руки.
Просто если хочется за границу укатить, тогда 1С мешает
Специализация это вещь. Невозможно хорошо разбираться и в программировании и в бизнесе как предметной области. Что то будет отставать. Кому то нравится ковыряться в законодательстве, бух учете и прочей скукоте — пожалуйста. Но это не мое (хотя даже когда я работал в 1с франче этим не программисты а аналитики занимались). Мне же интереснее развиваться как программисту.
UFO landed and left these words here
Поэтому в 1С специально сделали примитивный язык, чтоб для решения задач не требовались годы опыта в Java или C# и можно было аналитику программировать (хотя сейчас уже вряд ли на 8.3, это в 7.7 простота была)
С ростом сложности проектов в 1С сейчас тоже больше специализации, внедрения одним человеком остались в прошлом или только в маленьких городах на обновлении/допиливании бухгалтерии и УТ.
Сейчас например только на внедрении одного модуля из «Управления Холдингом» может быть команда из человек 5-10 и задачи нифига не скучные ) И хайлоад и многопоточность и веб-сервисы и RabbitMQ встречается
А язык по прежнему в одном месте. И почти хайлоадом занимался на 1с, и на веб/http сервисах собаку съел, и с шиной сообщений работал (правда какой то древней от ibm). Язык перестал соответствовать решаемым задачам. Вы верно подметили что даже на среднего размера проектах (от 1кк до 5кк) программист уже не играет в одно рыло и аналитика и программиста и админа. Тем не менее ему по прежнему приходится страдать.
Поэтому в 1С специально сделали примитивный язык, чтоб для решения задач не требовались годы опыта в Java или C#


Вы как-то преувеличивайте значение знания конкретного языка программирования.

Какие годы? Сам язык учится легко и просто.

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

Доводилось принимать программистов на работу (разговаривал с ними на техническом собеседовании). Неоднорактно убеждатся: можно брать и с чужим стеком, если толковый. Если специалист толковый, то он впоследствие довольно быстро осваивает новый для себя стек. И полноценно эффективно начинает работать через 1-2 месяцаа.
UFO landed and left these words here
Так наоборот. Вместо того чтобы решать бизнес-задачи, разработчику приходится думать над директивами компиляции, оптимизацией запросов, где и когда проверять ограничения, связывать списки с реквизитами, строить механизмы инкрементальных обновлений и т.д и т.п. Даже C# разработчику не все из этих вещей надо делать.
Запросы прям любые фигачить можно, неужто? Надо конечно же делать те же проверки и заполнения. Только на более низком уровне — реализуя разные громоздкие ООП-паттерны и зависимости между таблицами, классами, ORM знать надо. То что парой кликов в 1С делается надо самому придумать и заложить в архитектуре.
В 1С ты оперируешь сразу бизнес-данными, списки сразу готовые получаешь, директивы компиляции — это вообще не затратно, автоматически ставятся в 95% случаев, механизм обновления платформа уже имеет.
В итоге миниимально работающий продукт (MVP) под бизнес-задачу можно выкатить на 1С через неделю, накидав мышкой, а потом развивать и оптимизировать хоть под холдинг.
А на Java/C# что? Они дают максимум какой-то фреймворк и ООП-паттерны для разработки с нуля, это даже не скелет, а указания «Как правильно рисовать скелет и куда прилеплять мясо».
Сеньор по Java просто умеет технически правильно лепить скелеты и навешивать на него спущенные ему аналитиком требования.
Сеньор по 1С умеет по хотелкам клиента построить целое приложение, правильное как на техническом уровне, так и на уровне бизнес-логики (настройки, отчеты, гибкие формы)
Сеньор по Java просто умеет технически правильно лепить скелеты и навешивать на него спущенные ему аналитиком требования.

Просто, ага.

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

… то есть 1С-ник — это одновременно хороший бизнес-аналитик и хороший специалист по интеграции? И, наверное, еще и хороший специалист по тестированию?

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

Тут немедленно возникает два вопроса.


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


  2. Почему вы думаете, что разработчики на других платформах не могут так же?


Получается, потому что 1С более высокоуровневая система, программист оперирует сразу объектами бизнеса, а не абстрактными ООП-концепциями, интерфейсами, синглтонами, отражением СУБД через ORM и пр.
Т.е. когда ты пообщался с заказчиком и накидал на бумажке нужные сущности и реквизиты, структуру отчетиков набросал — ты уже подготовил драфт бизнес-системы, который можно за день перенести в конфигуратор и прописать второстепенные детали. И вся дальнейшая разработка это интерфейсные рюшечки, отчеты, интеграции.
Надо добавить новый документ с 50 реквизитами — 20 минут и он в интерфейсе со всеми экранными формами, сиди прописывай чистую бизнес-логику, думай над UI/UX, а не над созданием классов, генераторов/конструкторов, get/set, дата-адаптетов, фабрик и т.д.
Интересно посмотреть бы на человека, который и с бизнесом общается и в javaЕЕ шарит и крутой фронт может написать на реакте например.
На западе такое не приветствуется точно, там рулит узкая специализация, нанимают по человеку на 1 функцию и пишут годами системы за миллионы евро.
А в итоге получается что команда из 10 джавистов делает за год меньше чем 3 одинесника и европейцы выпадают в шок когда показываешь им 1С.
Получается, потому что 1С более высокоуровневая система, программист оперирует сразу объектами бизнеса, а не абстрактными ООП-концепциями, интерфейсами, синглтонами, отражением СУБД через ORM и пр.

Тут, понимаете ли, есть (как минимум) две загвоздки.


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


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

А во-вторых, я не зря написал "хороший специалист по интеграции". Понимаете, интеграция — это такое дело, где объектами бизнеса оперировать можно очень недолго. А потом начинается… pull-модель, push-модель, REST, SOAP, вебсокеты, комет, OAuth, OAuth 2, OIDC, OIDC identity provider, пропьетарная авторизация просто потому что мы так можем, очереди сообщений, вебхуки, подписание — и все, погребен.


Надо добавить новый документ с 50 реквизитами — 20 минут и он в интерфейсе со всеми экранными формами, сиди прописывай чистую бизнес-логику, думай над UI/UX, а не над созданием классов, генераторов/конструкторов, get/set, дата-адаптетов, фабрик и т.д.

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


А в итоге получается что команда из 10 джавистов делает за год меньше чем 3 одинесника

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

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

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


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

SOAP? :) По крайней мере именно с ним наблюдал такую ситуацию.

Хотя ради справедливости в последнее время стало больше попыток внедрения нормальных подходов к разработке (а не фигак-фигак и в продакшн), а соответственно появляется и разделение ролей.

Ну а где разделение ролей, там и аргументация выше теряет всякий смысл.


SOAP?

Он. Насколько я помню, на тот момент для работы с SOAP в 1С приходилось чуть ли не руками разбирать и собирать XML, со всеми вытекающими.

Ну а где разделение ролей, там и аргументация выше теряет всякий смысл.

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


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

Если это была 8-ка, то нет, там оно всё легко и просто — платформа сама всё делает. Только вот стандарт они прочитали как-то по-своему, в итоге 1С <=> 1С работает отлично, а вот попытка работы с чем-то другим — это поход по граблям. Может быть и разбирали/собирали чтобы превратить XML в что-то понятное парсеру платформы.

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

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


Если это была 8-ка

Честное слово, не помню. Давно было.

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

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


Кстати, ещё видел такой вариант — задачи аналитика пытаются переложить на заказчика. Заканчивается это, правда, обычно плохо — заказчик просто ищет другого 1Сника. Хотя бывают и исключения.

Почему же не будет? Аналитика-то отдельного нет, а задачу выполнить надо.

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

Потому что квалификации не хватит

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

Был случай кстати когда приходилось тоже руками xml собирать для внешней системы, 1с не поддерживает soap заголовки.
У меня на прошлой работе даже на небольших проектах, до 1млн стоимостью обязательно был аналитик (часто им на совсем уж крошечных проектах дело и заканчивалось). Про более крупные и не говорю, там обычно команда из аналитиков и программистов. Вот с тестировщиками беда была, да, их только на коробки выделяли, поскольку критические баги в релизе какие то там рейтинги франча в списках 1с снижали.
объектами бизнеса

&НаСервереБезКонтекста, РеквизитФормыВЗначение, ОбработкаОповещения, условия в ВиртуальнойТаблице, МенеджерВременныхТаблиц, ВременноеХранилище вот прям бизнес-объекты.

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

Или вы про Справочник, Документ? Прямо мега абстракции, аж пару предопределенных полей и нумератор. Или вы про регистр — представление SQL в самом примитивном случае?
ну я не отрицаю и даже приветствую что 8.3 усложняется и возможностей все больше, тонкостей оптимизации. Потому и проекты на 1С делаются все крупнее — холдинги, госкорпорации, распределенные сетевые организации.
Главное что все эти технические объекты вписаны в структуру бизнес-объектов и можно лепить как быстро на коленке мышкой, так и супероптимально профессионально под тысячи одновременных пользователей.
Условия и Менеджер это обычный SQL, куда без них?
Внеконтекстные вызовы тоже нужная вещь.
Увы на Java почему то не придумали подобный фреймворк чтоб и UI и ORM и бизнес-модели было удобно реализовывать. Почему то все отдельно и надо уметь либо что то одно, либо скрещивать все это со спрингом
Еще раз смысл статьи в том, что добавляя все эти тонкости, они убирают автоматические возможности. И крупные проекты состоят из множества мелких, где все равно больше нужна быстрота и простота разработки, а не тонкие настройки.
Условия и Менеджер это обычный SQL, куда без них? Внеконтекстные вызовы тоже нужная вещь.

Нет, без них можно было обойтись. И в тех же САП и Axapta таких абстракций гораздо меньше. А в lsFusion вообще нет (то есть например пиши условие в ГДЕ или где хочешь, оптимизатор сам разберется).
Полагаться на автоматические возможности это дилетантский подход. Зачем тогда делают зеркалки за 200к для проф. фотографов, снимали бы на телефон и всё.
1С потому и внедрила все эти тонкости, потому что на больших проектах ничего на автомате не внедришь.
Если у вас система не дает рулить вр.таблицами и выполнением на клиенте/сервере, мне вас жаль, у вас продукт уровня 1С 7.7 времен 1995 года.
Там можно было прикрутить dll прямого доступа к sql и работало намного быстрее чем 1С 8, большие магазины легко автоматизировались, но «почему-то» 7.7 безнадежно устарела, на одной скорости далеко не уедешь в современном мире.
Ссылаться на САП и Аксапту глупо, первая внедряется для галочки годами и за миллиарды за счет откатов, выглядит как говно и требует серверов от 10000 евро, вторая имеет долю рынка на уровне плинтуса. Они подходят для запада где разработаны, где стабильность и порядок в законах, другой менталитет и зарплаты.
1С родилась в РФ и лучше всего подходит для наших реалий, попытки это оспорить, имея на руках сомнительный софт для автоматизации в самой примитивной сфере (торговля) — выставление себя на посмешище
Полагаться на автоматические возможности это дилетантский подход.

… а все ваши "набросал в конструкторе" — это не автоматические возможности?


Зачем тогда делают зеркалки за 200к для проф. фотографов

… с автофокусом, например. На него полагаться — тоже дилетантский подход? Да и автомат экспозиции тоже, в общем-то, вполне используется профессионалами.

… а все ваши «набросал в конструкторе» — это не автоматические возможности?
ну видите, 1С не убирает базовые автоматические возможности, не противоречьте себе же.
с автофокусом, например. На него полагаться — тоже дилетантский подход?
А про ручной фокус в курсе? Иногда автофокус только мешает, так же и с ручными блокировками и ручным клиент-серверным управлением: надо в 5% случаев, но как раз когда это влияет на оптимизацию и требуется для масштабируемости.
Зачем в Hibernate можно на чистом SQL делать запросы? Подумайте над этим.
ну видите, 1С не убирает базовые автоматические возможности, не противоречьте себе же.

А я себе и не противоречу. Я вроде нигде не говорил, что 1С что-то убирает.


А про ручной фокус в курсе?

В курсе и никогда не пользуюсь.


надо в 5% случаев, но как раз когда это влияет на оптимизацию и требуется для масштабируемости.

А в остальных 95% вы полагаетесь на ту самую автоматику, которую вы называете дилетантским подходом.

1С потому и внедрила все эти тонкости, потому что на больших проектах ничего на автомате не внедришь.

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

Много у вас было на 1С 7.7 баз с 1к одновременных пользователей, террабайтных баз и вот таким функционалом?
1С родилась в РФ и лучше всего подходит для наших реалий, попытки это оспорить, имея на руках сомнительный софт для автоматизации в самой примитивной сфере (торговля) — выставление себя на посмешище

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


Объемы данных при наличие индексов значения не имеют — это забота СУБД. Там что 50 гигабайт, что пара терабайт уже неважно. Большая часть данных с этого терабайта — «холодные» данные, к которым редко обращаются.

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

и вот таким функционалом?

90% того, что вы указали — есть в типовой.
Остальное допиливается под конкретного заказчика.

с 1к одновременных пользователей

Это единственный довод по сути.
90% того, что вы указали — есть в типовой.
Остальное допиливается под конкретного заказчика.

Вы же понимаете, что даже если это так (то есть 90% есть, хотя это не так). То 10% на таких сложных проектах (с учетом описанных в статье проблем) — это почти бесконечность. И никакого смысла это делать у заказчика нет, лучше взять специализированное решение.
То 10% на таких сложных проектах (с учетом описанных в статье проблем) — это почти бесконечность. И никакого смысла это делать у заказчика нет, лучше взять специализированное решение.


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

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


Вы про автоматический предварительный подсчет итогов по периодам — говорите «голый SQL»?

Или вы про Справочник, Документ? Прямо мега абстракции, аж пару предопределенных полей и нумератор.


Вы «забыли» про привязанные к данным формы
Про автоматическую очистку регистров при отмене проведения.
И др. мелочи, но реально экономящие время.

Вы про автоматический предварительный подсчет итогов по периодам — говорите «голый SQL»?

Про это тоже было в статье. В OLAP это преподсчет из коробки и ГОРАЗДО эффективнее, а в OLTP особо и не нужен.
Вы «забыли» про привязанные к данным формы

Привязка к данным формы есть практически везде. Без этих крышесносящих классах в скобочках и РеквизитыФормыВЗначение. Более того в том же lsFusion этого разделения вообще нет, и форма сразу данные базы (ну или временные данные) отображает.
Про автоматическую очистку регистров при отмене проведения.

Вы же в курсе, что в типовых так не делают? И знаете почему?
В OLAP это преподсчет из коробки и ГОРАЗДО эффективнее, а в OLTP особо и не нужен.


В OLAP можно в корне по другому подходить.
Но OLTP каждый раз нагружать сервер расчетами, когда вам понадобятся остатки???

Серьезно?

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

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

Но OLTP каждый раз нагружать сервер расчетами, когда вам понадобятся остатки???

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


Что там с производительносью и акуальностью (ведь нельзя продать то, чего нет, актуальность должна быть сиюминутной) при постоянно появляющихся новых данных в OLTP?
В случае:
CREATE MATERIALIZED VIEW balance
SELECT SUM(x) FROM ledger GROUP BY a,b,c;
?
Все хорошо. Есть грабли, что только в конце транзакции обновляется, но это детали (в 1С по факту в таком же стиле используется)
ну… про 1Снка который в одном лице сразу и качественный методист и знает типовую и кодит как бог — было более менее справедливо много лет назад… когда типовые были простыми и их было немного…

по современным продуктам если глобально подходить к методикам — все же чаще появляются отдельные специалисты-консультанты… равно как и все больше и больше кодеров появляется которые владеют методиками разработки на 1С но в бизнес-процессы не лезут… оно им не интересно и не нужно…
вы рассуждаете на уровне «чтобы ходить человеку приходится думать какую ногу сначала ставить — левую или правую»

да не задумывается разработчик… он просто знает как надо и делает как надо… а там где спорные моменты может этими директивами сделать более оптимально — например не отправлять лишний контекстный запрос на сервер тогда когда он там не нужен…
UFO landed and left these words here
Просто если хочется за границу укатить, тогда 1С мешает


1) Ваше высказывание в контексте рекламируемой lsFusion — выглядит странно. Хотя, если за границу — это в Белоруссию, то, конечно.

2) Почему мешает-то? Программисткие навыки куда денутся? Автор этих строк легко и свободно начал использовать Go после многих лет с 1С. Если вы хотите уехать за границу, то вам больше мешает незнание языка человеческого.

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


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

Я конечно ваш бекграунд не знаю

30 лет и 15 языков программирования.
Уверяю вас — трудно выучить только первый.
Непросто — второй.
Дальше уже элементарно. Ведь распространенные языки программирования — они же все похожи друг на друга. Ну это если не брать Хаскель какой нибудь, однако это экзотика.

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


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

Ерунда вся эта классификация. Объективно можно сравнивать только в пределах одного предприятия.

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

Плюс названия должностей часто используют чтобы манипулировать:

  • Назовем должность солиднее. Поддержим ЧСВ. Но денег не добавим.
  • Или напротив — у нас жесткая тарифная сетка. Поэтому если тебя назвать senior, то платит придется больше. Не вариант. Сиди миддлом до скончания века.


Все это не добавляет объективности всем этим названиям.
30 лет и 15 языков программирования.
Уверяю вас — трудно выучить только первый.
Непросто — второй.

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

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


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

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


Ну дык Хаскель я и не считаю.
А 98% распространенных языков — это потомки Алгола-68 или его ближайших родственников.
причем тут программистские навыки, в вакансиях видели когда нибудь требования типа «3 года коммерческой разработки на Java»?
Язык программирования давно роли не играет, нужны знания фреймворков, их подводных камней, ORM, библиотек тестирования, паттернов проектирования и реализации.
В 1С они совсем другие чем в низкоуровневых платформах где все с нуля пишется на голом ООП. И надо учиться заново, пару лет погружаться в такой подход
причем тут программистские навыки, в вакансиях видели когда нибудь требования типа «3 года коммерческой разработки на Java»?

Эээ… да, а что?

3 года коммерческой разработки на %LangName%

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

Это мечты работодателей там описаны.
Они вообще хотели бы чтобы за копейки и супер-специалист. Реальность немного инача. Она отрезвляет и работодателей.

Это только приходя из 1с нужно кучу всего с нуля изучать.


Да и из веба в смартфонные приложения или из веба в 1С или… — да при любой смене направления.

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

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

Еще раз о своем опыте:

Программируя много лет 1С — довольно свободно (за 1-2 дня) перешел на новый язык Go. Где-то за пару недель мои познания в нем уже сравнились с типовыми джунскими, что имеет 1 летний джун на Go. Ну а за пару месяцев — ко мне уже не подкопаешься в знаниях нового стека, где на уровне 4-х летнего миддла. При том, что всё это время я уже мог активно программировать на новом стеке (все оценки времени даны с высоты сегодняшнего 7 летнего опыта на Go и 30 летнего опыта в программировании вообще, 18 из них 1С).

Сложность перехода преувеличена.
Да и из веба в смартфонные приложения

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


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

А то, что писать ее придется не на 1С, а на PHP/Go/Python — уже не важно.

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


Еще раз:

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

Где-то при 7 лет опыта (это крепкий миддл) — вам вообще никакие концепции не страшны, кроме Хаскеля.

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


Вы преувеличивайте непохожесть парадигм в большинстве распространенных языков программирования.
Я знаю бывших коллег, они очень хорошие, сложившиеся 1сники, проекты выполняют с бюджетами в миллионы и десятки миллионов, но никто из них не читал ни Роберта Мартина, ни Макконела, ни Фаулера, ни банду четырех, ни (подставьте любого другого автора не из мира 1с) никто не интересуется практиками написания хорошего кода (распространение их шло за счет нескольких энтузиастов). Почти никто не слышал об О нотации. Даже протокол http для многих темный лес. О тестах даже думают единицы, не пишет практически никто. Методологиями разработки тоже особо не интересуются. Вообще кругозор за пределами 1с как по технологиям так и по практикам нулевой, все вбухано в знание платформы и прикладных конфигураций, больше ни на что у них времени не остается.

З.Ы. Не без исключений конечно, но на 90% именно так все и обстоит. А ведь это франч входящий в относительно небольшое число «центров разработки».
но никто из них не читал ни Роберта Мартина, ни Макконела, ни Фаулера, ни банду четырех, ни (подставьте любого другого автора не из мира 1с) никто не интересуется практиками написания хорошего кода (распространение их шло за счет нескольких энтузиастов). Почти никто не слышал об О нотации. Даже протокол http для многих темный лес.


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

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

Ох что то сомневаюсь я в ваших словах. Если не брать мелкие студии где день за днем одно и то же делают — картина я думаю все же другая.
Ох что то сомневаюсь я в ваших словах. Если не брать мелкие студии где день за днем одно и то же делают — картина я думаю все же другая.


Люди — всегда люди.
Единицы — круты, да.

Но основная масса… Не идеализируйте их.

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

Но это не значит, что наш мир не может существовать и с плохими специалистами — мир же существует уже много лет.

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

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

Если что я как раз сейчас в процессе смены специализации, после 4 лет 1с. И 1с был первым серьезным языком для меня, как и для коллег с моей прошлой работы. По меркам 1сников я был весьма посредственным спецом, пусть и с широким кругозором в остальном ИТ. По меркам разработки на java/котлин (под андроид, но не суть важно) я тяну максимум на junior+ несмотря на уже почти год работы с этим стеком. Причем по большому счету потому что приходится ломать себя и встраивать в свою работу те принципы которые в 1с не применяются либо по историческим причинам, либо по причине технической невозможности. IoC, DI контейнеры, clean architecture, solid, паттерны — я до сих пор в этих и подобных темах плаваю как топор. Тесты вон до сих пор писать еще не начал, нужно будет Бека перечитать еще разок…
Если что я как раз сейчас в процессе смены специализации, после 4 лет 1с. И 1с был первым серьезным языком для меня, как и для коллег с моей прошлой работы. По меркам 1сников я был весьма посредственным спецом, пусть и с широким кругозором в остальном ИТ. По меркам разработки на java/котлин (под андроид, но не суть важно) я тяну максимум на junior+ несмотря на уже почти год работы с этим стеком. Причем по большому счету потому что приходится ломать себя и встраивать в свою работу те принципы которые в 1с не применяются либо по историческим причинам, либо по причине технической невозможности. IoC, DI контейнеры, clean architecture, solid, паттерны — я до сих пор в этих и подобных темах плаваю как топор. Тесты вон до сих пор писать еще не начал, нужно будет Бека перечитать еще разок…


Люди — разные.
Вот тот же путь из 1С в Java:

Мой опыт работы в Фирме 1С

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

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

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

К чему я это? Если бы я переходил из C#, например, или из крестов — у меня было бы намного больше релевантного опыта, я бы гораздо раньше начал изучать технологии разные и программирование, вместо всяких учетов и бухгалтерии и этих пробелов было бы гораздо меньше. Аналогично меньше было бы потрачено бесценного времени.
Если бы я переходил из C#, например, или из крестов — у меня было бы намного больше релевантного опыта, я бы гораздо раньше начал изучать технологии разные и программирование, вместо всяких учетов и бухгалтерии и этих пробелов было бы гораздо меньше. Аналогично меньше было бы потрачено бесценного времени.


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

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

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

А понимание потребностей конечных клиентов (а 1С-ец куда как ближе к конечному клиенту) — этого вы из книжек не узнаете. Тот опыт тоже полезен.


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


Если у вас не было опыта непосредственной работы с клиентами — то да.
Язык программирования давно роли не играет, нужны знания фреймворков, их подводных камней, ORM, библиотек тестирования, паттернов проектирования и реализации.


Кому нужны?
Джуну? Да, потому что ему больше и показать себя нечем.

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

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

Это пишется в 10 кликов мышью и "есть null" можно мышой перетянуть или руками набрать. Минут пять работы, если структуру базы данных знаешь. Видео записать? )


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


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

Я скопировал из методических рекомендаций самой 1С.

Как это делается в lsFusion — тут. Вообще никаких запросов писать не надо.

Суммируем все строки приходной накладной и вычитаем все строки расходной накладной? Я все правильно понимаю? При появлении еще 5 новых типов документов начинаем суммировать строки в них и вычитать/складывать? Или за GROUP SUM что-то более интересное, чем select sum()?


receivedQuantity 'Суммарный приход' = GROUP SUM quantity(ReceiptDetail d) BY item(d), stock(receipt(d));
shippedQuantity 'Суммарный расход' = GROUP SUM quantity(ShipmentDetail d) BY item(d), stock(shipment(d));
currentBalance 'Текущий остаток' (Item i, Stock s) = receivedQuantity (i, s) (-) shippedQuantity (i, s);


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


Если Не ОбщийМодульПроверка.ПроверитьПоложительностьКоличества(ЭтотОбъект) Тогда 
   Отказ = Истина;
КонецЕсли;
Только в lsFusion это весь код. А вот ПроверитьПоложительностьКоличества покажете? Ну и заодно куда вы приведенный вами код будете помещать. Вообще было бы очень интересно посмотреть аналог примера из моей ссылки на 1С (но только весь код, а не додумайте сами)
При появлении еще 5 новых типов документов начинаем суммировать строки в них и вычитать/складывать?

Обычно при появлении 5 новых типов документов наследование и полиморфизм используются. То есть новые типы документов наследуют просто ReceiptDetail, и если надо перегружают реализацию / реализуют quantity. Больше ничего не меняется. Все декларативно и само автоматически работает.

Помещать в процедуру ПередЗаписью в модуле набора записей регистра.


Вы же не показываете код парсера вашего языка. Может быть чтобы превратить GROUP SUM в SELECT у вас миллион строчек ушло? Я с таким же успехом могу написать внешнюю компоненту и поместить метод ПроверитьПоложительностьКоличества туда.


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

Помещать в процедуру ПередЗаписью в модуле набора записей регистра.


Я не 1С программист и у меня нету 1С головного мозга. Мне все эти ваши «ПередЗаписью в модуле набора регистра» ни о чем не говорят.

Вы же не показываете код парсера вашего языка. Может быть чтобы превратить GROUP SUM в SELECT у вас миллион строчек ушло? Я с таким же успехом могу написать внешнюю компоненту и поместить метод ПроверитьПоложительностьКоличества туда.


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

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

Делается интерфейс SkuLedger, и инвентаризация делает агрегированные объекты от классов, которые от него наследуются.

Не уходите от темы. Есть конкретная задача — давайте весь код, как ее реализовать. А то 1Совцы любят просто потрепаться, что вот я это сделаю супер быстро, а когда доходит до дела — сливаются.
Процедура ПриЗаписи(Отказ, Замещение)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   ОстаткиТоваровОстатки.Товар КАК Товар,
        |   ОстаткиТоваровОстатки.КоличествоОстаток КАК КоличествоОстаток
        |ИЗ
        |   РегистрНакопления.ОстаткиТоваров.Остатки(
        |           ,
        |           Товар В (&Товары)
        |               И Склад В (&Склады)) КАК ОстаткиТоваровОстатки
        |ГДЕ
        |   ОстаткиТоваровОстатки.КоличествоОстаток < 0";

    Запрос.УстановитьПараметр("Склады", ЭтотОбъект.ВыгрузитьКолонку("Склад"));
    Запрос.УстановитьПараметр("Товары", ЭтотОбъект.ВыгрузитьКолонку("Товар"));

    Если Не Запрос.Выполнить().Пустой() Тогда
        Отказ = Истина;
    КонецЕсли;
КонецПроцедуры

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

Помещать в процедуру ПередЗаписью в модуле набора записей регистра.

Ну так они так и делают, и что из этого получается (3 запроса на огромное количество строк) я написал в статье.
Может быть чтобы превратить GROUP SUM в SELECT у вас миллион строчек ушло?

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

От обоих. В lsFusion множественное наследование есть.
Ну так они так и делают, и что из этого получается (3 запроса на огромное количество строк) я написал в статье.

https://habr.com/ru/company/lsfusion/blog/468415/?reply_to=20700475#comment_20700763 один запрос по регистру остатков вместо двух по всем строкам расходных и приходных. 20 строк, из которых половина текст запроса сгенерированный конструктором, супротив 5 строк скрытых запросов сгенерированных ORM.


Вы сравниваете удобный пример, с системой которая вынуждена реализовывать плохо структурированные требования налогового кодекса. Когда вы сможете сделать расчет НДФЛ, с учетом ликвидаторов, летчиков, владельцев одного, двух и более детей, материальной помощи студенту до 4000 рублей, тогда можно будет оценивать сложность и поддерживаемость.


От обоих. В lsFusion множественное наследование есть.

Два склада в одном документе? Как это отобразится в таблицу?

Так нажмите на строке запроса правой кнопкой мыши и выберите пункт «Открыть в конструкторе» (что-то похожее по смыслу, давно с 1С не работаю, точно не помню).

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

> через СКД можно создавать очень мозголомные конструкции
По моему глубокому убеждению, если вам требуется для решения учетных задач создавать «мозголомные конструкции», у вас что-то не так спроектировано, или инструмент имеет серьезные проблемы.
Я пишу.

я же не сказал что «все», конечно есть исключения

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


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

Сейчас работаю с человеком с такой точкой зрения, такие решения часто имеют под собой контекст в виде неограниченного бюджета на сроки разработки и на оборудование… никак не могу такое поддержать (эффективный менеджер у меня в голове плачет)
А зачем для запросов, которые я приводил в статье СКД? Вот реально, там же один JOIN максимум.
А зачем вручную писать запросы? Я понимаю, что в разговорах это звучит офигительно и прям «Тру», но смысл писать запрос руками, если есть удобный конструктор, ускоряющий и упрощающий жизнь? на написание маленького запроса с 2-3 Временными таблицами руками можно пол жизни убить + искать ошибку в опечатке «Субкотно»…
ИМХО это какой-то особый сорт мазохизма, все же…

Вы может еще Ctrl+C/Ctrl+V не пользуетесь?
И я пишу. Но не всегда прямо только руками, иногда сделаю заготовку конструктором и правлю руками, а иногда и наоборот. Как быстрее. Зачем писать руками:
1. Конструктор не позволяет писать комментарии, и убивает уже написанные — одного этого достаточно, что бы не пользоваться им редактирования уже написанных запросов.
2. Для меня текст запроса гораздо более нагляден, чем бесконечное число закладок в закладочке в конструкторе. Так проще изучать запрос, и сразу вносить комментарии. Еще было бы проще с нормальной синтаксической подсветкой по запросу :(
3. Скажу тайну — в других средах разработки нет конструктора, а есть подсказка по именам таблиц. Поэтому там не может быть ошибки в «Субконто...». И, оказывается, что написать запрос с клавиатуры часто проще и быстрее, чем щелкать мышкой по закладкам и прокручивать списки с именами таблиц и полей. Так что еще вопрос, где особый сорт мазохизма…
4. Конструктор может не все.
Я не против, пишите, но все ваши 4 пункта просто придирки:
1) Ну не позволяет, это вообще не проблема, для начала — необходимо писать понятные запросы, к которым максимум можно оставить комментарий до текста запроса — комментарии в тексте запроса 1С имхо — моветон.
2) Это вкусовщина и привычка, есть подозрение, что вы не особо владеете конструктором, либо очень сильно привыкли к ручному текстингу.
3) Спасибо за тайну, но речь идет про 1С, в других средах пускай хоть «кофа с чаем» будет, ну и написать запрос в 1С часто проще и быстрее сделать в конструкторе, если это не запрос выбора из одной таблицы + форматирование запроса будет корректным и читаемым и на него вы не потратите кучу времени.
4) Конструктор может не всё — никто не может всё, а конструктор — облегчает жизнь разработчика.

Поймите, я не против, чтоб вы или кто-то другой писал запросы без конструктора, это ваше дело и ваша жизнь, но нельзя отвергать прогресс. Конструктор не совершенен, но он облегчает разработку и экономит время программиста 1С, как и другие фишки типа Ctrl+Space, F12, Alt+Shift+F. Это все просто экономит жизнь и нервы.
А уж если брать другие языки, так в Java — можно программировать и в обычном блокноте, и есть такие люди, но тот же Notepad++ удобнее и практичнее…
Конструктор помогает как раз только с простыми запросами. Как только нужно что то поправить в сложном запросе где нужно на экране видеть сразу все данные по нескольким таблицам — конструктор ничем помочь не может, он даже по одной таблице не может всю инфу отобразить.
Как только нужно что то поправить в сложном запросе где нужно на экране видеть сразу все данные по нескольким таблицам


В сложном запросе, без конструктора, у вас все данные не влезут на экран.
Вы устанете руками дописывать и разбирать запрос с 10-15 временными таблицами, кучей соединений, вычислений, переименований, куда вам надо добавить выборку из не типовых регистров и обособленной выборкой данных (при крупной выборке это больше 500 строк запроса, клесиком листать устанешь).

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


Как это не может? Что вы под этим понимаете?

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

Индивидуально все, я вообще работаю на темно-синем фоне редактирования кода, коллеги кривятся, а мне красота)
Меня в общем то и это не сильно устраивало (отсутствие автокомплита и компайл тайм проверок), потому ни с 8.2 ни с 8.3 больше не работаю.
UFO landed and left these words here
Ну, я обычно конструктором редактировал простые запросы до 5 пакетов, запросы на десятки пакетов мне уже удобней было править руками. Именно править правда. Набрасывать скелет все же конструктором удобнее было из за отсутствия автокомплита.
>комментарии в тексте запроса 1С имхо — моветон
??? Комментировать код — моветон ???!!!
Комментарии В ТЕКСТЕ ЗАПРОСА, типа такого:
Запрос = Новый Запрос(
"|ВЫБРАТЬ
|* //Комментарий о моей офигенской дописке
|ИЗ
|Справочник.ВариантыОтчетов КАК ВариантыОтчетов");

Это моветон.
Либо до, либо после текста запроса необходимо ставить комментарий, патамушта если запрос будет большой или разработчик слепой, то твой коммент не увидят, а при правке запроса консолью твой коммент канет в лету
Код SQL ничем принципиально не отличается от обычно программного кода, и точно так же, там есть необходимость писать комментарии. 1С приучила пользоваться конструктором, и не писать комментарии в запросах, потому что это не позволяет конструктор. Но это не значит, что это правильно. Это, на самом деле, проблема.
Посмотрите код ERP. Там уже есть комментарии в запросах, некоторые из них мне с экономили часы разборок с кодом. Вот, копирую пример из типовой ERP:
|ВЫБРАТЬ // Оплата поставщикам через подотчетное лицо (Дт 60.01 :: Кт 71)
Вообще, я не говорю — что конструктор плохо. Или что писать руками — плохо. Надо уметь все и применять то, что эффективнее. Руками писать — это однозначно гибче. Но конструктором бывает быстрее. Но не всегда.
Простой пример. В запросе есть выборка во временную таблицу. Потом она обрабатывается еще в десятке запросов. Вдруг выясняется, что данные надо в этой выборке взять из другой таблицы, с другими названиями полей. Остальное не меняется. Если в конструкторе начать менять выборку в эту таблицу, конструктор безнадежно портит всю обработку, что следует далее.
В тексте это делается элементарно — просто исправляешь название таблицы и имена полей.

Причем здесь прогресс — не понимаю. Есть язык запросов (диалект SQL). Что бы на нем писать, надо его знать и понимать. Знать и понимать — это значит уметь читать его текст, и уметь писать на нем. Это главное. Все остальное — это всего лишь вспомогательные инструменты.
Конструктор безнадёжно устарел, это факт. Но уж в EDT то всё-всё будет :))
Я не нахожу этот конструктор удобным. Куча вкладок, кнопок, галочек, часто с невразумительными, интуитивно непонятными подписями. Как там у Радченко, главного 1с-писателя в одном из описаний создания отчета: у вас получился не тот результат, это потому что на пред-предыдущем шаге вы забыли на вкладке… поставить третью сверху галочку на дополнительной панели… — что-то вроде этого.
И мелкий шрифт, который нельзя (!!!) изменить.
Нет, спасибо. Конфигуратором (даже не скд) я обычно пользуюсь в последний момент, когда надо уже написанный и отлаженный фрагмент кода скопипастить в модуль и сохранить. А до того предпочитаю пользоваться текстовым редактором, отлаживаюсь через веб-сервис с помощью своей утилиты. Конфигуратор по мне — слишком тормозной и неудобный инструмент.
Расскажите это органам требующим квартальную декларацию по алкоголю.
UFO landed and left these words here
98% разработчиков используют СКД

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

UPD. Я под конец моей работы с 1с (на 3-4 год) конструктором запросов конечно пользовался, но внутри него открывал текстовое редактирование, ибо так удобнее. И да, при чем тут СКД, когда мы про запросы в коде говорим, а не в отчетах?
на 1С можно наваять сложную систему учета, и она будет работать, за то время пока для обычных 'фреймворков и sql' будут только писать ТЗ и набирать народ с вилкой 180-250

В 8.3? Я собственно статью и написал, что наваять на ней систему, которая будет нормально работать на >10к записей, не сильно проще чем на том же .Net. А если с lsFusion сравнить, где ни одной из верхних 21 проблем нет (а это еще далеко не все проблемы), то это разница будет как между лошадью и автомобилем. Причем lsFusion под LGPL лицензией, то есть открытыми исходниками, бесплатно и т.п.
Не любят в наше время честно вести бизнес. Вместо того, чтоб делать свой продукт качественным и конкурентоспособным (оно может так и есть на самом деле), начинают черный маркетинг на крупных ресурсах.
Сравнение лошади и автомобиля в комментарии выглядит как популистическая байка.
1С — известные крупняки, у которых огромный выбор решений, бекграунда, комьюнити, специалистов, франчей и тд. У них хотя бы разъемы подходят к местному бизнесу
IsFusion — платформа, которая только пытается выйти на рынок, предлагая подобный 1С функционал.

Я бы хотел почитать аналогичную этой статью о 21 минусе IsFusion.
Я бы хотел почитать аналогичную этой статью о 21 минусе IsFusion.

Так разберитесь в lsFusion и напишите. Мы даже ее заплюсуем, насколько сможем. Мы никогда не были против открытого обсуждения любых проблем.
UFO landed and left these words here
Вот надоели уже люди с такими комментами. Ну так ответьте по пунктам, если считаете, что автор где-то не разобрался.
UFO landed and left these words here
1С — известные крупняки, у которых огромный выбор решений, бекграунда, комьюнити, специалистов, франчей и тд. У них хотя бы разъемы подходят к местному бизнесу

Когда Форд сделал автомобиль, тоже было много стойл, сена, конюхов, известные крупняки и т.п. И по вашему он проблемы лошадей не должен был упоминать?
А вообще я уже писал:
«Возможности ничего не стоят, без проблем которые они решают.»
Когда Форд сделал автомобиль, тоже было много стойл, сена, конюхов, известные крупняки и т.п. И по вашему он проблемы лошадей не должен был упоминать?


Дык Форд то выиграл по итогу как мы знаем.
А вы еще нет.
И не факт что выиграете.
Как не выиграли еще 5 подобных же перспективных «убийц 1С» в этом веке.

Вам пишут, что у 1С есть неоспаримые преимущества помимо технологического совершенства (хотя и в этом плане 1С на весьма хорошем уровне).

А вы в ответ — «зато мы более технически совершенны» (что кстати не очевидно из ваших статей).

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

Об этом ваш оппонент вам и пишет.
Как не выиграли еще 5 подобных же перспективных «убийц 1С» в этом веке.

Таких убийц еще не было.
хотя и в этом плане 1С на весьма хорошем уровне

И статья это очень хорошо показывает.
незначительным техническим преимуществом

Ничего себе незначительным. Тут все проблемы максимально фундаментальны.
Как не выиграли еще 5 подобных же перспективных «убийц 1С» в этом веке.

Таких убийц еще не было.


То есть вы не изучили опыт предшественников?

Вы же говорите о ком-то конкретном? Можете озвучить их («убийц»)? Мне действительно интересно.
CUBA Platform :)) Но они вовремя поняли, что пиариться на 1С — не очень хорошая идея.
Это очередной классический ORM с огромным порогом вхождения (ничем не отличающийся от остальных 100). Все равно, что трактор с автомобилем сравнивать.
Уважаемый, вы не поняли мой ответ. Я не сравнивал ваши с Кубой технические достоинства, а сравнивал желание попиарится за счёт более известного конкурента.
UFO landed and left these words here
Причем lsFusion под LGPL лицензией, то есть открытыми исходниками, бесплатно и т.п.


Это имеет значение только для небольшой части потенциальных клиентов вашей системы.
Вы не забывайте, что ваш продукт вовсе не OpenOffce для дома — а это продукт для бизнеса.

Стоимость платформы 1С — это копейки.
По сравнению со стоимостью работ по ее обслуживанию и доработе.

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

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

Если вы посмотрите на то, как это происходит в мире — как продукты автоматизации бизнеса все больше платные. Бесплатных мало.

Доминируют только те бесплатные — что базовые кирпичики типа nginx, OpenOffice. Как что сложное и очень ответственное — а система автоматизации это сердце бизнеса — так бизнес уже не ведется на халяву и предпочитает платить разработчикам.

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

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


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


Одно другому не противоречит:

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

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

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

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

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

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


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

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

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

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

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


Вы это серьезно?
У меня теща к своему частному дому просто пристроила 2 комнаты. Ей это обошлось в 50 000 рублей (ну и плюс внутрення отделка за отдельные деньги потом).

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

Визуальное программирование не ускоряет программирование. Текстом писать гораздо быстрее, в статье на эту тему все расписано по пунктам. Производительность повышается путем повышения уровня абстрагирования, с чем в 1С — беда.
У меня теща к своему частному дому просто пристроила 2 комнаты. Ей это обошлось в 50 000 рублей (ну и плюс внутрення отделка за отдельные деньги потом).

А если теще комната маленькой покажется и она захочет расширить ее на 10 см, а на кухне окна в пол и высокие потолки сделать, расскажете потом как в 50к уложились.
Вы серьезно считаете, что снести весь дом целиком и построить его из панелей — было бы дешевле?

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

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

2. Интеграторы. Почти все: лень, наплевательское отношение, некомпетентность. Простой пример: разослал запрос на 50 лицензий + сервер, разброс сумм был впечатляющим, в половине случаев лицензия на сервер отсутствовала. Далее 9 из 10 начали рассказывать о том что нужно обязательно winserv, обязательно mssql, о сложностях поддержки итд. Если спросить про linux то 9,8 из 10 начинает жалобно завывать. Это вообще единственная сфера, где я размахиваю перед людьми существенными деньгами а они в ответ хамят и бросают трубки.
1. Да, с тем же вебом они явно что-то намудрили. Я не понимаю как при таком простом DOM у них demo-ma.1c.ru так тормозит. Вообще эта тема просто не влезла в статью. Куда логичнее кстати было бы сделать просто вход для custom frontend'а, скажем генерить тот же код на реакт, и чтобы при необходимости разработчик мог его изменять. Типа как тут. Но 1с походу принципиально ни с кем не интегрируются.

2. Ну это следствие определенной консолидации рынка с одной стороны и низкой IT-грамотности с другой стороны.