Comments 1789
Хороший вброс, годный.
Не моя тема, но все равно встряну. Знаете, что самое забавное. Я на хабре долгое время был с неполноценным аккаунтом (то есть 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С)
Поднял настроение с утра, спасибо, знающий человек))
Очень конструктивный комментарий. Спасибо.
Если вы уж говорите о некомпетентности, так напишите что конкретно не так. А так на истерику больше похоже.
Если вы уж говорите о некомпетентности, так напишите что конкретно не так. А так на истерику больше похоже.
Знаете, автор, ваше творение просто не выдерживает критики. Я понимаю, что на вашем сайте ваше решение содержит одни + в зеленых квадратиках, на фоне других платформ, но просто из интереса, пообщались бы с 1С разработчиком, прежде чем вбрасывать ЭТО и сидеть тут и жать Ф5, в поисках одобрения людей, которые видя что либо плохое в сторону 1С сразу ляпнут лукас)
Вы наверное на мисте 6 частей (по 1000 сообщений) обсуждений пропустили. Конечно на мисте называть что-то обсуждениями — очень сильно ей льстить. Хотя определенный шарм в таких срачах все же есть (как с семечками или черешней, тяжело остановиться когда уже начал). Собственно много пунктов из обсуждений на мисте и пришло.
Странное ощущение — что именно то не выдерживает критики? Я опытный разработчик 1С и могу подтвердить что всё что тут перечисленно большая боль для меня — и самое больное что 1С совсем не собирается что то сделать полезное, всё что она может это изолироваться и поддерживать клуб любителей такой изоляции.
Я со всем согласен кроме части про блокировки и СКД.
На самом деле управляемые блокировки достаточно удобны и в друхе времени.
СКД тоже не имеет аналогов. Возможно позиционирование у него и правда не до конца выверено, но продвинутым пользователям очень нравится.
У меня есть опыт работы с BI (особенно с MS BI) и могу сказать что пользователи вообще не могут работать с BI системами, они слишком сложны для них.
Если я им дашборды создам то да, они могут, где то могут поля перетянуть, но на этом все.
В то же время совсем нулевые девочки из ЗУП которые даже компьютер сами выключить не могут, активно используют отчеты на СКД (конечно обернутые в более дружественный интерфейс).
На самом деле управляемые блокировки достаточно удобны и в друхе времени.
СКД тоже не имеет аналогов. Возможно позиционирование у него и правда не до конца выверено, но продвинутым пользователям очень нравится.
У меня есть опыт работы с BI (особенно с MS BI) и могу сказать что пользователи вообще не могут работать с BI системами, они слишком сложны для них.
Если я им дашборды создам то да, они могут, где то могут поля перетянуть, но на этом все.
В то же время совсем нулевые девочки из ЗУП которые даже компьютер сами выключить не могут, активно используют отчеты на СКД (конечно обернутые в более дружественный интерфейс).
На самом деле управляемые блокировки достаточно удобны и в друхе времени.
А что в них удобного? По сути нужно в голове все race condition держать, что очень сложная задача. Repeatable read с прозрачными материализациями и / или FOR UPDATE в ограничениях куда проще и удобнее.
А СКД — да, как такой «BI для бедных» может и имеет смысл. Но а) настройки в ним такие же примитивные как в BI — то есть группировка по полям, поля по прямым ссылкам (никаких регистров) и формулы, б) они нагружают оперативную базу, в) визуализация (например цветовая) там гораздо хуже чем в большинстве BI Tools.
Да и с точки зрения UX Еще->Изменить Вариант на порядок уступает тому же Imply.
Но это если мы говорим про пользовательские настройки. Как конструктор отчетов он не сильно лучше и не сильно хуже стандартных Crystal/Fast/Jasper и т.п. Собственно неудивительно что его аналога в мире никто и не делал, потому как непонятно зачем.
Приведите пример где конкретно нужно «учить матчасть».
One to many это когда вы можете любую таблицу по полю замаппить в коллекцию любого объекта по полю. В 1с это можно сделать в очень частных случаях.
Про чтение, если вы обратитесь к объекту по ссылке (как это принято в orm) он считается целиком (с табличными частями). Я ссылку в статье давал.
Убогость заключается в том что нет инструментов борьбы с проблемой N+1.
Голый sql это все эти ВЫБРАТЬ ИЗ СОЕДИНЕНИЕ, которые по сути тот же самый SQL но на русском.
Возвращается к ORM — то есть считывают объекты и обращаются к ним по ссылкам, в циклах и т.п.
ЗЫ: с телефона не очень удобно отвечать, чуть позже отвечу подробнее.
Про чтение, если вы обратитесь к объекту по ссылке (как это принято в orm) он считается целиком (с табличными частями). Я ссылку в статье давал.
Убогость заключается в том что нет инструментов борьбы с проблемой N+1.
Голый sql это все эти ВЫБРАТЬ ИЗ СОЕДИНЕНИЕ, которые по сути тот же самый SQL но на русском.
Возвращается к ORM — то есть считывают объекты и обращаются к ним по ссылкам, в циклах и т.п.
ЗЫ: с телефона не очень удобно отвечать, чуть позже отвечу подробнее.
One to many это когда вы можете любую таблицу по полю замаппить в коллекцию любого объекта по полю. В 1с это можно сделать в очень частных случаях.
Критерии отбора не подойдут?
А можно прикладной неабстрактный пример такой потребности в терминах бизнес-логики, для понимания? Чтобы не обсуждать сферического коня в вакууме.
Вообще, если вы заметили это не в проблемах было, а именно в описании как это в 1С сделано. Я сам, если честно против классического ORM, но раз в 1С его решили поддерживать, то делали бы это нормально. А так ни рыба, ни мясо получилось.
Что мешает дёрнуть все нужные реквизиты в первом же запросе, не формируя по одному запросу для каждой ссылки? Обойдемся ровно одним запросом.
Потому как это уже не ORM по сути.
Это вкусовщина. А вот приведите хороший, годный ORM с более простым синтаксисом, чем этот? Работал я на SQLAlchemy — вот где ад и израиль, для не очень примитивных запросов приходилось перерывать их документацию чуть менее, чем полностью (и иногда в итоге скатываясь к конструкциям, которые поддерживаются только конкретным движком). А тут пиши себе на SQL-like языке, который платформа сама транслирует в нужный диалект. По мне так это удобно и колоссально снижает порог вхождения. Но если у вас есть примеры более удобных подходов — с удовольствием ознакомлюсь.
Не понимаю, чем свой диалект снижает порог вхождения. Скорее наоборот.
Про более удобные подходы позабавило. Тут нас одна половина обвиняет в ангажированности, а вторые искренне удивляются, что мы предлагаем взамен. Более удобный подход — оставить объекты и сделать более декларативный и высокоуровневый язык чем SQL без инкапсуляции (не на таблицах а на функциях). И с кучей других возможностей.
Я сам, если честно против классического ORM, но раз в 1С его решили поддерживать, то делали бы это нормально. А так ни рыба, ни мясо получилось
Ну… 1С вообще-то и не говорят что у них ORM (https://habr.com/ru/company/1c/blog/334050/)
воспринимается намного менее прозрачно, чем
Ну вы тут немного лукавите, взяли разные по сложности запросы, переводы строк добавили, ну и т.п. Вы с HQL hibernate'ским лучше сравните.
А можно на уровне идеи как это должно работать? (или rbymnt ссылкой). Вот честно интересно. Сабжевый ORM'ный «более высокоуровневый язык на функциях» всё равно движку придется в конечном итоге превращать в конечные запросы MSSQL, Postgre и Ко, иначе как без этого дёрнуть данные из базы. Как процедурный язык с произвольным кодом превратить в эффективный SQL-запрос? (а не в соответствующую неэффективную лапшу на каком-нибудь T-SQL под капотом с курсорами и подзапросами в циклах).
Ну вот так например. Но вообще можете в блоге посмотреть статьи. Что касается эффективности запросов, то можете статью «Почему не SQL?» почитать, чтобы понимать какого класса оптимизации делаются в том же lsFusion.
У 1Сников то всё просто: отрезали все расширения разных диалектах, и почти один-в-один транслируют свой суррогатный язык запросов в запросы движков, местами добавляя постобработки в виде СКД. Далеко не супер гибко, зато достаточно эффективно (в рамках ограничений, налагаемых «кроссдвижковостью» конечно).
Ну в 1С как раз все по старинке императивно. Такой ПХП с парой высокоуровневых абстракций и визуальным программированием.
А можно прикладной неабстрактный пример такой потребности в терминах бизнес-логики, для понимания? Чтобы не обсуждать сферического коня в вакууме.
Могу привести реальный пример.
Конфигурация «Деньги» — очень маленькая и простая конфигурация для домашней бухгалтерии. Есть документ Расход, куда построчно можно вводить данные чека, например. Данные вводятся в табличную часть. Конфа позволяет для каждой строки табличной части задать произвольное количество аналитик. То есть, в строке табличной части может быть просто «статья расхода, сумма, количество», а может быть «статья расхода, сумма, количество, проект, финансовая цель, важность,…, на что хватит фантазии». То есть в строке табличной части произвольное количество столбцов.
Как это реализовано. В строке хранится ссылка на справочник «Пакеты аналитик статей». В справочнике нет реквизитов, только табличная часть с ссылками на аналитику и их значениями. При сохранении документа Расход система ищет в этом справочнике элемент с таким же набором аналитик и значений как в табличной части, и если не находит, создаёт новый элемент справочника.
Оно работает, но реализацию вряд ли можно назвать красивой. Вместо того, чтобы сделать «табличную часть строки табличной части», пришлось создавать избыточный объект-справочник, который в интерфейс не выводится и содержит кучу ненужного для такой задачи функционала. Плюс хранится как отдельный объект и программисту нужно отдельно продумывать создание, поиск и удаление, разворачивание данных в столбцы и сворачивание обратно.
Это костыль, но по другому сделать не получается. Хранение каких-то сложных параметров в справочниках, чтобы ссылку на элемент справочника записать в регистр или табличную часть — вполне обычное явление.
Ну да, можно и по другому. Ещё можно сделать регистр и хранить данные в нём. Кстати, несколько табличных частей не получится создать в регистрах. Но всё это не отменяет факта того, что тривиальная задача для СУБД выливается в «изобретательство».
Вышеописанное — не моё изобретение. «Деньги» — конфа, которая пишется «разработчиками 1с».
Я бы не отказался от возможности создавать «табличную часть» для любого реквизита. Ещё очень не хватает возможности создавать функции в записях структуры (хотя бы записывать ссылки на функции) — можно было бы накостылить аналог ООП.
Но вообще, вы просили пример, я его привёл. Нерешаемых задач нет — в крайнем случае можно всё хранить в xml в хранилище значения (кстати так поступают/ли с контактными данными в типовых конфигурациях, если мне не изменяет память). Но, имхо, ограничения платформы зачастую мешают, и часто спотыкаешься, если не пилишь стандартную систему количественного учёта чего-нибудь.
Вышеописанное — не моё изобретение. «Деньги» — конфа, которая пишется «разработчиками 1с».
Я бы не отказался от возможности создавать «табличную часть» для любого реквизита. Ещё очень не хватает возможности создавать функции в записях структуры (хотя бы записывать ссылки на функции) — можно было бы накостылить аналог ООП.
Но вообще, вы просили пример, я его привёл. Нерешаемых задач нет — в крайнем случае можно всё хранить в xml в хранилище значения (кстати так поступают/ли с контактными данными в типовых конфигурациях, если мне не изменяет память). Но, имхо, ограничения платформы зачастую мешают, и часто спотыкаешься, если не пилишь стандартную систему количественного учёта чего-нибудь.
Про чтение, если вы обратитесь к объекту по ссылке (как это принято в orm) он считается целиком (с табличными частями). Я ссылку в статье давал.
Предвзято лукавите. А как на счёт этого
Однако запрос будет выполнять считывание из базы данных при каждом вызове. Соответственно, при многократном обращении к одним и тем же данным будет выполняться многократное считывание. Этого можно избежать, обращаясь к свойствам ссылки. В этом случае используется кэширование объектов и в определенном интервале времени при повторном обращении к данным объекта не будет выполняться повторное считывание
its.1c.ru/db/metod8dev/content/2717/hdoc
И как кэширование меняет факт того, что он считается целиком с табличными частями? И главное вы же понимаете, что кэширование помогает только при повторном обращении в одном вызове к одним и тем же данным (что далеко не главная проблема).
Если большинство данных нужно будет использовать несколько раз за вызов, то логично получить все объект через ссылку и чтобы он закэшировался. Если нужно всего несколько реквизитов объектов (объекта), то можно воспользоваться запросом. Но обычно через ссылку данные получают только для изменения, для чтения пользуются запросом
Вы же понимаете насколько более неудобным и многословным код делает использование такого подхода с чтением через запросы? Да, в 1с по другому никак, но это не значит что это хорошо и удобно.
Я ниже с ходу предложил костыльное решение https://habr.com/ru/company/lsfusion/blog/468415/#comment_20703549
А если хорошенько подумать можно и гораздо менее костыльное придумать используя анализ кода для оптимизаций. Просто то что я предложил — не должно быть сложно реализуемым в платформе, другие решения, более удобные и красивые, могут оказаться гораздо сложнее а то и нереализуемыми если оставить язык 1с.
А если хорошенько подумать можно и гораздо менее костыльное придумать используя анализ кода для оптимизаций. Просто то что я предложил — не должно быть сложно реализуемым в платформе, другие решения, более удобные и красивые, могут оказаться гораздо сложнее а то и нереализуемыми если оставить язык 1с.
Нет, не так. lsFusion все сама соберет в один запрос и одним запросом все считает. Но даже если не получится, кэширование в виде всяких shared buffers уже есть в самой СУБД. То есть по факту, если вы два раза считаете одни и те же данные ничего страшного. Если конечно вам при этом все равно надо считывать другие данные, и количество запросов будет минимальным.
И вообще, работа с данными на сервере приложений, это в принципе зло и убийство производительности (он для этого не предназначен).
И вообще, работа с данными на сервере приложений, это в принципе зло и убийство производительности (он для этого не предназначен).
чуть позже отвечу подробнее
На мой взгляд не нужно отвечать.
Суть в том что у тех кто способен понять о чем вы пишите вопросов не возникает, может быть есть в каких то моментах иной взгляд, но в целом (особенно в части про СУБД) так все и есть.
А те кто начинают с этим спорить, не смогут вас понять все равно.
И, естественно, настоящие 1С-программисты не будут снисходить до уровня простого Java/SQL-разработчика, чтобы пояснить, какую именно матчасть учить, и в чем он ошибается. Ах да — у 1С же документация платная, и бесплатно никто ничего пояснять не будет. Это же не в стиле 1С экосистемы.
Вас обманули. "1С: Предприятие 8.3. Версия для обучения программированию" можно получить бесплатно по первой ссылке в гугле указав е-mail и какие-то регистрационные данные. В комплекте кроме документации еще и книжки какие-то были. Ну и бухгалтерия типовая вроде бы в качестве решения.
Это не та документация, увы. Тоже в свое время будучи 1сником разочаровался что с доступом к документации беда без ИТС.
Эээ. У MS Dynamics как раз вроде как бесплатная документация. Я там много чего находил.
Microsoft в последнее время вообще радует своей открытостью во всем.
Microsoft в последнее время вообще радует своей открытостью во всем.
Замечу: Желтые книжки про синтаксис — по сути «распечатанный» синтакс-помощник, который поставляется вместе с платформой.
Для «личного самообучения» есть Версия для обучения программированию, которую можно вообще скачать бесплатно.
Для «личного самообучения» есть Версия для обучения программированию, которую можно вообще скачать бесплатно.
В смысле не та? Там руководство разработчика, руководство администратора, книжка про начало программирования в 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С по форумам и чатам. Для этого есть документация! Можно бесплатно и официально скачать учебную платформу, общую документацию, популярные конфигурации и книги Радченка с Хрусталевой — online.1c.ru/catalog/free/18610119
Интересно, а Бухгалтерия и УПП есть на lsFusion? я бы сравнил
Знания автора об 1с поверхностные. И устарели.
А так, у меня два вопроса к авторам, просьба ответить честно:
1. Для кого написана эта статья?
2. Для чего написана эта статья?
1. Для кого написана эта статья?
2. Для чего написана эта статья?
Для того же для чего пишут все статьи на хабре. Рассказать про проблемы технологий (в данном случае конкретной технологии) и способы их решения. Как для 1С разработчиков, так и для других разработчиков бизнес-приложений и вообще бэкендов (чтобы они знали «как там у них», да и проблемы у них во многом могут быть схожие).
И, совершенно случайно, в корпоративном блоге компании, не имеющей никакого отношения к критикуемой технологии? Спасибо за честный ответ.
А Вы видели как Ауди с БМВ троллили друг друга в рекламе? Было достаточно забавно и никакого особо негатива. Сторонним наблюдателям было интересно.
Ну как бы весовые категории в данном случае несколько, скажем так, различные. Я как раз и пытался узнать, для кого они эту рекламу написали, но не судьба, видимо.
Например, когда у кого-то, кто конкурирует с 1С, будут спрашивать, а чем плох 1С, то ему смогут давать ссылку на эту статью.
Если только конкурируют платформы для разработки, а не готовые решения. Я, правда, слабо представляю подобную конкуренцию между 1С и lsfusion, ниши практически не пересекающиеся.
Тут речь не только про lsFusion идет. Если у меня написано на .Net, а у кого-то на 1С, то можно говорить, что там хуже, так как строится на слабой платформе (по крайней мере, с точки зрения маркетинга). Все же понимают, что дом построенный на плохом фундаменте будет хуже, чем тот, который построен на хорошем.
Сравнивать будут решения по функциональности и качеству решения проблем бизнеса, в первую очередь, стоимости доработки и сопровождения во вторую.
Если же брать разработку с нуля — lsfusion надо тогда сравнивать с .Net, CUBA, odoo. 1С больше про готовые решения, а не про платформу.
Если же брать разработку с нуля — lsfusion надо тогда сравнивать с .Net, CUBA, odoo. 1С больше про готовые решения, а не про платформу.
Вы не поверите, на 1С много отраслевых и самописок с нуля пишут. О чем собственно и сказано в статье.
Так отраслёвки пишут обычно франчи 1С, часто как нашлёпки на типовые от 1С, на чём же ещё их писать франчам? С нуля от независимых разработчиков знаю только про WMS системы, и отдельные редкие случаи, вроде Деловых линий.
А я очень много знаю. Более того в Беларуси основной игрок на рынке бухгалтерии (!) свою конфигурацию с нуля писал. Ну или на рынке FMCG розницы (где Астор например тоже с нуля свою конфу делает).
И вообще у чуть более крупных клиентов самописок на 1С более чем достаточно.
И вообще у чуть более крупных клиентов самописок на 1С более чем достаточно.
Не знаю как у вас там, в Беларуси, а в России самописки на 1С у крупняка обычно получаются в результате многолетней доработки изначально типовой 1С, которая происходила параллельно с ростом бизнеса. Чтобы так осмысленно взять, и в крупной компании абсолютно с нуля писать своё на 1С — это очень большая редкость. Астор, опять же, тоже скорее всего из франчей/отдела 1С-ников вышел, так что ниразу не показатель.
Вы видимо в обсуждении на мисте не учавствовали. Вы же понимаете, что к примеру УТ или ERP для FMCG розницы (да и не FMCG) не подходит никак (там половины нужных модулей нет). И допилить УТ до нужного состояния это все равно что из танка самолет сделать. Особенно с учетом убогости возможностей рефакторинга в платформе. И Астор с нуля писал, не понимаю почему не показатель.
Писал Астор с нуля на 1С потому, что уже имел штат специалистов по 1С, а не потому, что осознанно выбрал эту платформу. То, что типовые от 1С — далеко не идеал, спорить не буду, это мне вполне очевидно.
Астор — образовывался как 1с-ный франч :)
Помню ту конфу для розничной торговли (Модный магазин), их первая попытка перейти на 8-ю платформу. Долго они пытались нам её внедрить, всё время хотели, чтобы мы переделали свои бизнес-процессы под их алгоритмы. В результате год потерянного времени и куча денег в никуда. Потом перешли на самописку на основе типовой Розницы.
Нравится <> Идеал. То, что могло быть намного хуже — согласен. Но могло быть и намного лучше :)
Как платформа 1С проигрывает всем на рынке. Даже SAP. Причем практически по всем пунктам. Но раз ей нет равных в мире, посмотрим как ей удастся выйти на англоязычный рынок без существующих разработчиков, и поддержки перемудреного местного законодательства. Шляпу готовы съесть, если в течении 5 лет они даже 0.01% мирового рынка не займут?
Как платформа 1С проигрывает всем на рынке. Даже SAP. Причем практически по всем пунктам.
Рынок считает иначе и голосует рублем сами знаете за кого — в 1С несут денежки и сторонним программистам, занимющимся 1С.
SAP, кстати, тоже та еще шляпа со своими проблемами. Напрасно вы ее как пример лучшего решения приводите.
Рынок не считает иначе. Просто 1С оказался в нужное время в нужном месте. А в таком случае можно даже с очень плохой платформой захватить большую долю рынка. Вот если им удастся занять хоть какую то значимую долю на мировом рынке с нуля (пусть и с их теперешними ресурсами) тогда да, можно будет говорить, что «в целом ей просто нет равных в мире». А пока это просто мелкий локальный игрок.
а нам и в России хорошо…
а тут 1С уделывает всех…
а по поводу мирового рынка, на родине SAP не так давно дойчебанк С ГОРДОСТЬЮ ХВАСТАЛСЯ о том что у них появился андроидпэй… эпл пей пока нет но вот андроидпэй появился…
так что заливать про мировой рынок не надо…
а тут 1С уделывает всех…
а по поводу мирового рынка, на родине SAP не так давно дойчебанк С ГОРДОСТЬЮ ХВАСТАЛСЯ о том что у них появился андроидпэй… эпл пей пока нет но вот андроидпэй появился…
так что заливать про мировой рынок не надо…
Вы так говорите, как будто функционирование androidpay и applepay это заслуга 1С.
я так говорю в пример того что «мировой опыт» зачастую где то там далеко отстает от российского… как например в сфере распространения бесконтактных платежей…
вроде — родина SAP — а телефоном расплатиться в метро или где-нибудь там в палатке покупая мороженку — нельзя… технологии то не позволяют…
вроде — родина SAP — а телефоном расплатиться в метро или где-нибудь там в палатке покупая мороженку — нельзя… технологии то не позволяют…
я так говорю в пример того что «мировой опыт» зачастую где то там далеко отстает от российского…
Особенно в разработке ПО, да.
мой пример был приведен в качестве того что безапелляционно и закрыв глаза повторять что «мировой опыт всегда на шаг впереди российского» — по крайней мере не верно…
а по поводу разработки отраслевого ПО — ну вот пример 1С… есть аналогичные системы с подобным сбалансированным функционалом, стоимостью, порогом вхождения, поддержкой нац/законодательств на западе?
а по поводу разработки отраслевого ПО — ну вот пример 1С… есть аналогичные системы с подобным сбалансированным функционалом, стоимостью, порогом вхождения, поддержкой нац/законодательств на западе?
безапелляционно и закрыв глаза повторять что «мировой опыт всегда на шаг впереди российского»
А кто это говорил?
есть аналогичные системы с подобным сбалансированным функционалом, стоимостью, порогом вхождения, поддержкой нац/законодательств на западе?
На западе есть системы автоматизации учета на предприятиях, которые удовлетворяют тамошних заказчиков. С поддержкой национальных законодательств, конечно же. Не могу сравнить их функциональность и порог вхождения с 1С, конечно же, но кого это волнует, если их функциональность достаточна для заказчика, а стоимость разработки достаточно низка, чтобы заказчик мог себе это позволить?
И как минимум в США как минимум для SMB на этом рынке весьма жесткая драка.
А кто это говорил?
таков контекст беседы…
Не могу сравнить их функциональность и порог вхождения с 1С, конечно же, но кого это волнует
однако то что 1С ну просто никак не может быть более продвинутым и качественным продуктом чем некие западные решения вы не сомневаетесь…
таков контекст беседы…
Это вы его себе таким придумали. Если хочется сражаться с пугалом — сколько угодно, но без меня.
однако то что 1С ну просто никак не может быть более продвинутым и качественным продуктом чем некие западные решения вы не сомневаетесь…
Скорее наоборот: я пока не вижу оснований считать, что 1С — это более продвинутый и качественный продукт, чем (нужное вписать).
У них это по другой причине сложилось. Там где прежде не было вообще никаких технологий, новые технологии ложатся как масло на хлеб. А там где работают старые технологии, новые часто конфликтуют и поэтому их внедрение затормаживается и требует серьёзного пинка чтобы пропихнуть. В конце концов, другие страны можно использовать как полигон для масштабной натурной обкатки технологий и выявление её слабых мест.
Он никак не считает. Он ест, что дают.
И 1С не лучше всего остального, просто остальное, что существовало на рынке, не сильно лучше, того что предлагал / предлагает 1С. Поэтому не смогло его подвинуть, равно как и наоборот.
И 1С не лучше всего остального, просто остальное, что существовало на рынке, не сильно лучше, того что предлагал / предлагает 1С. Поэтому не смогло его подвинуть, равно как и наоборот.
Он никак не считает. Он ест, что дают.
И почему же тогда приходится напрягаться, что-то выдумывать? А чё попало рынок почему-то не хавает.
… это все равно что из танка самолет сделать
Ох, как всё это знакомо.
1. Если знаете много и пишут с нуля значит есть смысл.
2. Если разговор про конфигурацию от Хьюменсистем. То это не пример нормальной/качественной разработки, а пример «впаривания» продукта. В которой ресурсов на защиту потрачено больше чем на бизнес функционал.
У меня сложилось впечатление что автор многие вещи пересказывает «со слов»
2. Если разговор про конфигурацию от Хьюменсистем. То это не пример нормальной/качественной разработки, а пример «впаривания» продукта. В которой ресурсов на защиту потрачено больше чем на бизнес функционал.
У меня сложилось впечатление что автор многие вещи пересказывает «со слов»
Но в конце автор и задается вопросом почему платформу 1с выбирают для разработки новых решений, вместо выбора более удобных вещей. У меня честно говоря только одно предположение — бренд и сеть франчайзи которая допилит в любой деревне за копейки новую колонку в отчет.
Так кто выбирает то, приведите примеры?
Например компания в которой я работал пишут «Итилиум», «1С: ТОИР», «1С:RCM». Но то ладно, то уже черт знает сколько лет франч (хотя для мобильных приложений их никто не заставлял 1с выбирать, наверно, отношения с вендором не очень хорошо знаю).
А так, сколько на инфостарте статей про новые «нетленки»? Иногда даже от частных лиц. Внутренние проекты иногда начинают на 1с, хотя даже не планируют во вне выпускать, но тут наверно по наличию ресурсов выбирают, какие программисты есть под рукой, те и пишут.
А так, сколько на инфостарте статей про новые «нетленки»? Иногда даже от частных лиц. Внутренние проекты иногда начинают на 1с, хотя даже не планируют во вне выпускать, но тут наверно по наличию ресурсов выбирают, какие программисты есть под рукой, те и пишут.
Ну вы же понимаете, что код как в статье допиливать — это мягко говоря не каждому под силу. Тем более в деревне. Мне стремно в него лезть, боясь что где-то что-то упадет, а уж франчу…
Собственно на том же рынке FMCG розницы в Астор даже компании со своим штатом 1С программистов боятся лезть (не то что франчи).
Собственно на том же рынке FMCG розницы в Астор даже компании со своим штатом 1С программистов боятся лезть (не то что франчи).
Ну вы же понимаете, что код как в статье допиливать — это мягко говоря не каждому под силу. Тем более в деревне. Мне стремно в него лезть, боясь что где-то что-то упадет, а уж франчу…
Именно по этому качеству ваша система сливает 1С вчистую.
Уж что-что, а программисты по 1С как раз сыщатся влегкую.
Но не те, кто станет разбераться в вашей системе.
Собственно на том же рынке FMCG розницы в Астор даже компании со своим штатом 1С программистов боятся лезть (не то что франчи).
Да ладно, боятся.
Может, просто потому что нужно работать на том рынке, что ты хорошо знаешь и который тебе и приносит хорошее бабло?
Это как Боинг стал бы автомобили строить. Тоже интересный рынок. Но не его. Они на самолетах специализируются.
Ну вы еще бы в машинных кодах писали вместо того чтобы взять java, .net, python и подобное.
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сник за пару дней осилит.
А вот писать на питоне в стиле 1с, но с добавлением типов в аргументы — мне кажется любой 1сник за пару дней осилит.
делает код круче
Да нет такого понятия в коммерческой разработке. Есть лишь критерии для оценки эффективности. ООП, особенно если добавить элементы ФП — позволяет писать код более эффективно, с меньшим количеством ошибок. Да, на 1с быстрее наваять поделие из за довольно широкой стандартной библиотеки — но развивать и поддерживать его — та еще боль. Это вам кажется что все дураки и выбирают инструменты рабочие по их крутости, да, такое тоже бывает когда выбирают чисто из личных предпочтений, но это исключение из правил. Инструменты выбирают исходя из их эффективности для решения задач.
З.Ы. А если отходить от коммерческой разработки — я бы тыкал c/c++, rust, haskell — но в коммерческую разработку я даже не думаю их тащить, потому что с коммерческой точки зрения на тех задачах которые я решаю они не эффективны. Эффективны языки вроде js (ух как я его ненавижу), dart (эффективность пониженная из за малой распространенности разработчиков и потому трудной заменяемости одного разработчика другим), c#, java, kotlin, python, даже php современный насколько слышал сейчас сделали более по человечески и подходящим для разработки крупных проектов.
Их код поддерживать проще на словах, а на деле на их платформе невозможно вообще ничего создать такого, что будет интересно бизнесу. Абсолютно ничего.
А вы насколько хорошо знаете lsFusion чтобы делать такие выводы? По своему опыту скажу что мы например ведем постоянную доработку (по 25 задач в день) / поддержку порядка 40 различных клиентов со 30к пользователей в сумме силами 7-8 разработчиков lsFusion. А я знаю компании у которых больше 1с разработчиков на одну компанию из этих 40. Ну и про одного 1с разработчика работает только в очень простых случаях.
Я же им официально писал с просьбой предоставить простейший модуль, на что получил
Честно говоря не в курсе что и кому вы писали. Но предоставить это что значит? Разработать? Ну вы же понимаете что это процесс требующий хотя бы контурное описание что надо разработать? Вы это предоставили? Если нет то причем тут платформа.
Там не работающее решение было, а уровня демки на сайте lsFusion. Фузиновцы как я понял сейчас делают клон одного из самых популярных решений на мировом рынке. На 1с его не один год делать, даже в текущей постановке.
В любом случае спорить с вами дело неблагодарное, у вас редкая каша в голове, вы путаете платформу и решения на ней. По вашей логики qualcomm и intel вообще пустышки и не должны существовать так как ничего конечным потребителям предложить не могут. И эту разницу судя по реакции на ваши комментарии тут понимают все кроме вас. Поэтому дальше отвечать вам это переливать из пустого в порожнее. Так что я тоже пас. Может у lair ещё терпения хватит с вами общаться.
Смысл приводить примеры личного опыта как оправдание?
Так это ж ровно то, что вы делаете.
Скажем так — 1 одинэсник запросто сопровождает все виды учёта предприятия, на котором учёт ну очень сложный
Любого предприятия, или одного конкретного предприятия?
Их код поддерживать проще на словах, а на деле на их платформе невозможно вообще ничего создать такого, что будет интересно бизнесу.
Вы про конкретного "убийцу 1С", или про все конкурирующие платформы?
Про всех убивцев 1С.
А, эти мне не интересны. Я даже не уверен, что я сходу назову больше одной претендующей на это системы.
Т.е. вы уверенно знаете, что плохо и не правильно
В определенных контекстах, да. Именно поэтому и уточняю каждый раз, о чем идет речь.
но при этом не знаете как правильно
Да нет, почему же. Я часто знаю, как лучше. Опять-таки в области своей специализации.
Тема то про очередного убивца 1С.
Нет, "тема" про то, чем 1С плох. Это не одно и то же.
Впрочем, последнее время она уже давно про то, как вы пытаетесь доказать, что 1С лучше всех (по крайней мере, так ваша позиция воспринимается).
— а почему никогда никому неудалось поймать Джо?
— потому что его никто никогда не ловил
— потому что его никто никогда не ловил
А в командах какого размера вы работали и над какими задачами? Я вот одно время почти пару лет в разработке коробочных продуктов с нуля на 1с учавствовал, пусть даже команда небольшая была, 10 программистов 1с всего в максимуме. Ну еще аналитики, но они с кодом не работали. А потом еще 2 с копейками года эти коробочные продукты в командах на предприятиях внедряли. В т.ч. например одним из заказчиков был Магнит. И что такое поддержка, развитие, проектирование и рефакторинг проектов из сотен тысяч строк кода на 1с (думаю к миллиону ближе, точно не считали) — я представляю. Вы же, по моим ощущениям, скорее не роль программиста играете в рабочих процессах, а роль интегратора. И вам не важны те сложности с которыми сталкиваются разработчики продуктов.
Поймите, на 1С из готовых кубиков собираешь нужное тебе приложение
Я что-то пропустил? Все готовые решения это огромные медленные монолиты. А с нуля разрабатывать на ТАКОЙ платформе (со всеми вышеобозначенными проблемами) это самоубийство.
1С, это платформа, готовые решения, которые максимально подходят для большинства
Для большинства в какой выборке?
В Красноярске (это такой городок в России) из всех предприятий, где я был (а это штук 20), всегда либо стоит 1С, либо переходят на неё
Я правильно понимаю, что выборка, на основании которой вы говорите, что 1С подходит для "большинства" — это 20 предприятий в Красноярске?
Я даже не вижу смысла с этим спорить, вполне возможно, что решения 1С действительно подходят для большинства из этих 20 предприятий.
не приводя НИ ОДНОГО аргумента в свою пользу.
У меня нет мнения о том, какая платформа лучше всего подходит для предприятий в Красноярске, откуда у меня какие-то аргументы по этому поводу?
Интересно было бы послушать про весь цивилизованный мир
О, так это легко.
Открываем, значит, 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 шт
«Программист 1С» — 850 шт
«Java developer» — 2500 шт
Так в том-то и дело, что 1С, это не платформа, на которой разрабатывают решения с нуля.
Опровергаю своим примером. Или вы думаете конфигурации 1с из воздуха берутся?
Сравнение сложных IT-систем (в частности, ERP) очень больная тема. Все описанные в статье проблемы имеют прямое отношение к стоимости доработки и сопровождения. Или Вы считаете, что все современные подходы к разработке направлены не на это, а просто на то, чтобы потешить эго разработчиков?
Имеют, конечно, в общем. Но если есть готовое решение для производства от 1С, и нет такого от lsfusion, например, — не имеют, в частности :))
Это статья не про lsFusion, а про 1С. Возможно будет еще и про то, как это сделано в lsFusion. И выше я писал, что если речь идет о производстве на 1С и другой технологии, то эта статья помогает понять, как минимум, что плохо в фундаменте той, что на 1С.
Так ведь нет ничего другого в РФ за такие деньги, вот в чём проблема. Я и пытаюсь объяснить, что не конкурируете вы с 1С никак на уровне платформы.
Как минимум, lsFusion — это альтернатива для разработки так называемых «нетиповых» решений. О чем, например, указано в статье.
Ну да, альтернатива. Только не для 1С. Вы сильно преувеличиваете значение нетиповой разработки с нуля на платформе 1С в настоящее время.
Вся суть статьи в том, что у платформы 1С много проблем. Давайте не будем скатываться в обсуждение рынка бизнес-приложений и типовых конфигураций. То, что в США на COBOL'е работает куча крупных компаний, автоматически не делает COBOL классной платформой для разработки приложений.
Да, у 1С много проблем. Но почему это так волнует lsfusion?
Даю подсказку. Открываем список статей в блоге компании lsfusion. Смотрим количество плюсов и комментариев в статьях с критикой 1С и SQL, сравниваем с количеством авторов публикаций в блоге. Потом смотрим количество комментариев и плюсов в статьях без критики 1С и SQL (последние штуки 3-4), тоже сравниваем с числом авторов статей в блоге. Делаем выводы.
«Возможности ничего не стоят, без проблем которые они решают.» © будем считать мой.
«Совпадение, не думаю».
Давайте так, это Хабр. Если с каким то пунктом вы не согласны, отлично, дайте развернутый комментарий, покажите что автор не прав (вы же понимаете что многие на Хабр ради комментариев заходят). И тогда все поймут что это просто «маркетинговый бред», «автор просто не разбирается» и все в таком духе.
Давайте так, это Хабр. Если с каким то пунктом вы не согласны, отлично, дайте развернутый комментарий, покажите что автор не прав (вы же понимаете что многие на Хабр ради комментариев заходят). И тогда все поймут что это просто «маркетинговый бред», «автор просто не разбирается» и все в таком духе.
В статье рассказывается система со стороны кодера и совсем никаким боком не затрагивается область бизнес-приложений. В том-то и проблема, что это трындец какие разные вещи. С одной стороны бизнесмену всё равно какой крутой или кривой код, ему то всё видится только в виде бизнес-объектов, тогда как с другой стороны, идёт измерение крутости кода
Все правильно пишите.
И если бы речь шла о сугубо технической вещи, которую рядовой пользователь не видит, с чем непосредственно не взаимодействует — выбор бы делали технические специалисты, ориентируясь на чисто технический аспект.
Но здесь это не так.
Авторы ссылаются на опыт глубоко подкапотачный вещей типа PostgreSQL vs Oracle.
Но там действуют другие правила.
В статье рассказывается система со стороны кодера и совсем никаким боком не затрагивается область бизнес-приложений.
Издеваетесь? Как раз основной посыл статьи, что вместо того, чтобы фокусироваться на бизнес-задачах разработчику 1С приходится заниматься всякой ерундой, вроде ручных блокировок, директив компиляции, callback'ов, ЗначениеВРеквизитФормы, связыванием списков и реквизитов и т.п.
в 1С больше инструментарий, а вы это преподносите как минус…
Да — в вашем мире и в вашей области автоматизации эти инструменты избыточны и ненужны… но ваше решение с 1С практически нигде не пересекается, по этому по сути вы еще не очень доросли до этих инструментов.
Ну не нужна вам асинхронность и управление серверными вызовами — да… вы просто не сталкивались с такими бизнес-задачами… а 1С сталкивался в полный рост…
это не делает 1С хуже — это делает 1С универсальнее и сложнее.
а с точки зрения разработчика — ну давайте реализовывать функционал фильтрации результатов поиска при вводе по строке по вхождению в наименование товарной позиции… у кого будет проще решение?
monosnap.com/file/ORhXPM24Lg4tmcFPob8Qs92cTY12XJ
сколько вы времени потратите и вообще сможете эту бизнес-задачу реализовать?
Да — в вашем мире и в вашей области автоматизации эти инструменты избыточны и ненужны… но ваше решение с 1С практически нигде не пересекается, по этому по сути вы еще не очень доросли до этих инструментов.
Ну не нужна вам асинхронность и управление серверными вызовами — да… вы просто не сталкивались с такими бизнес-задачами… а 1С сталкивался в полный рост…
это не делает 1С хуже — это делает 1С универсальнее и сложнее.
а с точки зрения разработчика — ну давайте реализовывать функционал фильтрации результатов поиска при вводе по строке по вхождению в наименование товарной позиции… у кого будет проще решение?
monosnap.com/file/ORhXPM24Lg4tmcFPob8Qs92cTY12XJ
сколько вы времени потратите и вообще сможете эту бизнес-задачу реализовать?
Как раз основной посыл статьи, что вместо того, чтобы фокусироваться на бизнес-задачах разработчику 1С приходится заниматься всякой ерундой, вроде ручных блокировок, директив компиляции, callback'ов, ЗначениеВРеквизитФормы, связыванием списков и реквизитов и т.п.
Совсем не так много этой работы как вам кажется.
Скажем, мне ручные блокировки понадобились прошлый раз, дай вспомню, года два назад. Да и директивы компилятора — пожалуй что уже как с полгода не писал.
И, у 1С все это было автоматом — 2/3 того, что вы перечислили — это сравнительно поздние нововведения. Раньше и без них было — да прям как у вас.
Однако, оказлось, что чем более разноплановых задач ставят перед 1С — тем более разнообразные инструменты полезнее.
Ваше восприятие таковым кажется, потому как вы не имеете достаточно опыта с той системой, что критикуете.
Это нормальное восприятие любой новой системы. Ваша система — тоже не исключением будет, ежели кто соберется на нее перейти — людей ждет такой же батхерт при входе в новую для себя технологию, что и у вас возник с 1С.
Раньше и без них было — да прям как у вас.
Нет не как у нас. Раньше все (а точнее большинство) на клиенте было и автоматически блокировалось кучу лишних данных. Что не масштабируемо. А в lsFusion все масштабируемо — все на сервере приложений, прозрачные материализации и update conflict'ы из коробки и т.п.
Однако, оказлось, что чем более разноплановых задач ставят перед 1С — тем более разнообразные инструменты полезнее.
Нет, у них возникли проблемы с масштабируемостью, а не разноплановые задачи.
Нет, у них возникли проблемы с масштабируемостью, а не разноплановые задачи.
Зачем делать функционал, пока в нем не возникло потребности?
Это одно и то же:
- Ранее использовалось с небольшими базами данных и для них и создавалось. К чему там лишние сложности для разработчиков, когда автоматика платформы справлялась.
- Возникала задача использовать с большими базами данных — она же проблема масштабирования.
Вы о чем вообще спорите?
О том, что есть 2 способа блокировок на выбор прикладного программиста (автоматический и ручной) и это плохо?
О том, что получилось два механизма. Один простой, но не работающий. Второй сложный но работающий. Почему не сделать один простой и работающий (то есть чтобы «автоматика платформы справлялась»).
Один простой, но не работающий
Кто вам сказал-то что он неработающий? Те, кто не умеют их готовить? Гы.
Не испытываю проблем с автоматическими блокировками, кроме весьма редких случаев — ручные понадобились в прошлый раз даже не в этом году, а намного дольше я их не использовал почему то.
Кто вам сказал-то что он неработающий? Те, кто не умеют их готовить? Гы.
Речь шла не только про блокировки, а и про ОФ, про ОткрытьФормуМодально и т.п. Но даже касательно автоматических / ручных блокировок. Вы в курсе что в 1С автоматические блокировки ВСЮ таблицу в PostgreSQL блокируют, а в MS SQL на сложной логике и большом количестве пользователей у вас эскалации через раз будут, после чего база тоже в клинч начнет входить.
del
Ах тыж, на святое покусился
А у вас есть свои интеграторы/внедренцы?
Ну просто демо-продукт на сайте он совсем… Ущербный…
Что-то более похожее на реальную жизнь увидеть бы.
Ну просто демо-продукт на сайте он совсем… Ущербный…
Что-то более похожее на реальную жизнь увидеть бы.
Вы про эту демку? (но там только часть функционала, можете кликнуть на модули посмотреть, что именно там сделано)
Это рыба, на которой впрочем работает большое количество предприятий >= 4к сотрудников, причем все модули от производства, до автозаказов (кроме бухгалтерии, HR и фронта).
Это рыба, на которой впрочем работает большое количество предприятий >= 4к сотрудников, причем все модули от производства, до автозаказов (кроме бухгалтерии, HR и фронта).
логика объектов напоминает обычный ORM, правда, со своими особенностями:
Никаких one-to-many, many-to-many отображений нет, их функцию выполняют так называемые табличные части — коллекции внутренних объектов, фактически агрегированных в основной объект.
Подчиненный справочник с владельцем и есть классическое one-to-many
Ну это все равно не совсем классический one-to-many, потому как, как я понимаю, работает между двумя одинаковыми типами (справочник-справочник), скажем справочник с регистром или документом вы так не свяжете. Но да про них, я что-то забыл, точнее про подчиненные справочники у меня был отдельный пункт, но потом исчез, а в другие не дописал. Сейчас попробую немного изменить статью.
Почему один объект справочника, на который ссылаются 1000000 записей регистра остатков и 1000000 записей документа, который породил эти записи регистра, это не one-to-many?
Потому, что это many-to-one :))
Вы из справочника через точку можете написать что-то вроде: Товар.ДокументыПрихода[10].Дата?
А где так можно писать, и какой документ нужно считать 10-м?
Ну почти во всех ORM. Например в Java указываете OneToMany и @JoinColumn для List и у вас будет коллекция с документами. В данном случае будет рандомный документ, хотя вроде можно порядок указывать в таком маппинге. Но 10 это я для примера написал. Пусть будет «FOR Товар.ДокументыПрихода».
Ну маппинг у 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С должен и в вебе и в SQL и в ORM разбираться и в запросы руками предикаты проталкивать. И потом у относительно небольших компаний штат 1С программистов — 15 человек. А у нас есть отдел из 10 человек, который дорабатывает нон-стоп и поддерживает 40 клиентов (в основном крупных), в которых в сумме 60к человек работает.
И в том же УТ, там 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 достаточно непростых задач в день закрывается).
Я просто не до конца понимаю, что именно быстрее там так сильно получалось. Особенно с учетом, когда запросы надо вот так писать.
Если тому же lsFusion разработчику сказать так писать, он на тебя как на идиота посмотрит. Типа делать мне больше нечего.
То есть с точки зрения декларативности современный 1С от той же Java не сильно отличается, о чем я собственно и писал в статье.
Я просто не до конца понимаю, что именно быстрее там так сильно получалось. Особенно с учетом, когда запросы надо вот так писать.
Запрос
ВЫБРАТЬ
РасходнаяНакладнаяСостав.Номенклатура,
УчетНоменклатурыОстатки.КоличествоОстаток
ИЗ
Документ.РасходнаяНакладная.Состав КАК РасходнаяНакладнаяСостав
ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетНоменклатуры.Остатки(,
Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)) КАК УчетНоменклатурыОстатки
ПО УчетНоменклатурыОстатки.Номенклатура = РасходнаяНакладнаяСостав.Номенклатура
ГДЕ
РасходнаяНакладнаяСостав.Ссылка = &Документ И
(УчетНоменклатурыОстатки.КоличествоОстаток < РасходнаяНакладнаяСостав.Количество ИЛИ
УчетНоменклатурыОстатки.КоличествоОстаток ЕСТЬ 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С не вытягивает по производительности и эргономике (также как и в банках) Но это временно.
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. это всё в мерках Московских зарплат миддл-сеньорского уровня обоих сфер
за ту зарплату сколько платят при работе с 1С — слишком много геморроя причем не борьбы с платформой, а просто много задач и обязанностей вообще, которые подразумеваются под программистом 1С.
тоесть, я сейчас гораздо меньше всего делаю на питоне и эти вещи проще (занесло меня в эту сферу после явы), а получаю гораздо больше чем когда я работал с 1С
И это дело не в квалификации, со мной работал сеньор 1Сник (которого переманили из интегратора) имеющий огромный опыт в ERP, УПП и кучу одинесовских «специалистов»… и он получал меньше меня сейчас.
Это при том что мой коммерческий опыт программинга в 'обычных языках' у меня всего 5 лет. (я до этого был админом, а одинесил с 2005 года)
p.s. это всё в мерках Московских зарплат миддл-сеньорского уровня обоих сфер
Так может потому что
нигде толком не применим кроме 1с? Тогда как например C# разработчик спокойно переквалифицируется на Java или C++ при необходимости и ему не нужно будет в подробностях изучать кучу готовых «конфигураций» чисто прикладных. Да и знание прикладной области гораздо менее важно чем для 1сника. А для 1С сперва стоят знания конфигураций и предметной области, а только потом знания собственно приемов и практик программирования, работы ОС, сетей и прочего.
огромный опыт в ERP, УПП и кучу одинесовских «специалистов»
нигде толком не применим кроме 1с? Тогда как например C# разработчик спокойно переквалифицируется на Java или C++ при необходимости и ему не нужно будет в подробностях изучать кучу готовых «конфигураций» чисто прикладных. Да и знание прикладной области гораздо менее важно чем для 1сника. А для 1С сперва стоят знания конфигураций и предметной области, а только потом знания собственно приемов и практик программирования, работы ОС, сетей и прочего.
я не спорю. в итоге я и переквалифицировался на java/python
Какие задачи на питоне решаете что гемора меньше? А то может тоже из 1С свалить ) Питон и JS я знаю и смотрю по сторонам с прищуром ))
так это же хорошо, когда можешь решить реальную задачу бизнеса, понимая его проблемы и методику, а не тупо кодить по готовому ТЗ, в котором за тебя подумали как делать и ты не можешь шагнуть в сторону
А за тарелку супа или за масло с икрой — щас выбора много где от 150-180 предлагают на руки.
Просто если хочется за границу укатить, тогда 1С мешает
А за тарелку супа или за масло с икрой — щас выбора много где от 150-180 предлагают на руки.
Просто если хочется за границу укатить, тогда 1С мешает
Специализация это вещь. Невозможно хорошо разбираться и в программировании и в бизнесе как предметной области. Что то будет отставать. Кому то нравится ковыряться в законодательстве, бух учете и прочей скукоте — пожалуйста. Но это не мое (хотя даже когда я работал в 1с франче этим не программисты а аналитики занимались). Мне же интереснее развиваться как программисту.
Поэтому в 1С специально сделали примитивный язык, чтоб для решения задач не требовались годы опыта в Java или C# и можно было аналитику программировать (хотя сейчас уже вряд ли на 8.3, это в 7.7 простота была)
С ростом сложности проектов в 1С сейчас тоже больше специализации, внедрения одним человеком остались в прошлом или только в маленьких городах на обновлении/допиливании бухгалтерии и УТ.
Сейчас например только на внедрении одного модуля из «Управления Холдингом» может быть команда из человек 5-10 и задачи нифига не скучные ) И хайлоад и многопоточность и веб-сервисы и RabbitMQ встречается
С ростом сложности проектов в 1С сейчас тоже больше специализации, внедрения одним человеком остались в прошлом или только в маленьких городах на обновлении/допиливании бухгалтерии и УТ.
Сейчас например только на внедрении одного модуля из «Управления Холдингом» может быть команда из человек 5-10 и задачи нифига не скучные ) И хайлоад и многопоточность и веб-сервисы и RabbitMQ встречается
А язык по прежнему в одном месте. И почти хайлоадом занимался на 1с, и на веб/http сервисах собаку съел, и с шиной сообщений работал (правда какой то древней от ibm). Язык перестал соответствовать решаемым задачам. Вы верно подметили что даже на среднего размера проектах (от 1кк до 5кк) программист уже не играет в одно рыло и аналитика и программиста и админа. Тем не менее ему по прежнему приходится страдать.
Поэтому в 1С специально сделали примитивный язык, чтоб для решения задач не требовались годы опыта в Java или C#
Вы как-то преувеличивайте значение знания конкретного языка программирования.
Какие годы? Сам язык учится легко и просто.
Сложно учатся концепии, принципы, паттерны и алгоритмы. Библиотеки? Ну какое-то время уходит. Но небольшое, все равно их никто целиком не помнит, все справочниками пользуются.
Доводилось принимать программистов на работу (разговаривал с ними на техническом собеседовании). Неоднорактно убеждатся: можно брать и с чужим стеком, если толковый. Если специалист толковый, то он впоследствие довольно быстро осваивает новый для себя стек. И полноценно эффективно начинает работать через 1-2 месяцаа.
Так наоборот. Вместо того чтобы решать бизнес-задачи, разработчику приходится думать над директивами компиляции, оптимизацией запросов, где и когда проверять ограничения, связывать списки с реквизитами, строить механизмы инкрементальных обновлений и т.д и т.п. Даже C# разработчику не все из этих вещей надо делать.
Запросы прям любые фигачить можно, неужто? Надо конечно же делать те же проверки и заполнения. Только на более низком уровне — реализуя разные громоздкие ООП-паттерны и зависимости между таблицами, классами, ORM знать надо. То что парой кликов в 1С делается надо самому придумать и заложить в архитектуре.
В 1С ты оперируешь сразу бизнес-данными, списки сразу готовые получаешь, директивы компиляции — это вообще не затратно, автоматически ставятся в 95% случаев, механизм обновления платформа уже имеет.
В итоге миниимально работающий продукт (MVP) под бизнес-задачу можно выкатить на 1С через неделю, накидав мышкой, а потом развивать и оптимизировать хоть под холдинг.
А на Java/C# что? Они дают максимум какой-то фреймворк и ООП-паттерны для разработки с нуля, это даже не скелет, а указания «Как правильно рисовать скелет и куда прилеплять мясо».
Сеньор по Java просто умеет технически правильно лепить скелеты и навешивать на него спущенные ему аналитиком требования.
Сеньор по 1С умеет по хотелкам клиента построить целое приложение, правильное как на техническом уровне, так и на уровне бизнес-логики (настройки, отчеты, гибкие формы)
В 1С ты оперируешь сразу бизнес-данными, списки сразу готовые получаешь, директивы компиляции — это вообще не затратно, автоматически ставятся в 95% случаев, механизм обновления платформа уже имеет.
В итоге миниимально работающий продукт (MVP) под бизнес-задачу можно выкатить на 1С через неделю, накидав мышкой, а потом развивать и оптимизировать хоть под холдинг.
А на Java/C# что? Они дают максимум какой-то фреймворк и ООП-паттерны для разработки с нуля, это даже не скелет, а указания «Как правильно рисовать скелет и куда прилеплять мясо».
Сеньор по Java просто умеет технически правильно лепить скелеты и навешивать на него спущенные ему аналитиком требования.
Сеньор по 1С умеет по хотелкам клиента построить целое приложение, правильное как на техническом уровне, так и на уровне бизнес-логики (настройки, отчеты, гибкие формы)
Сеньор по Java просто умеет технически правильно лепить скелеты и навешивать на него спущенные ему аналитиком требования.
Просто, ага.
Ну с точки зрения бизнеса он узкий специалист который «всего лишь» хорошо знает «движок» системы. Но без аналитика и консультанта он ничего не может реализовать.
А 1Сник выслушает бизнес-задачу заказчика на его языке и уже понимает какие объекты будут затронуты для решения, как оптимизировать на будущее, предложит варианты как удобно интегрировать решение со смежными подсистемами например и т.д.
Это как хороший водитель-механик по ремонту BMW, который переберет машину шефа и помощник руководителя, который его понимает с полуслова и решает/делегирует любые вопросы, в том числе и с машиной
А 1Сник выслушает бизнес-задачу заказчика на его языке и уже понимает какие объекты будут затронуты для решения, как оптимизировать на будущее, предложит варианты как удобно интегрировать решение со смежными подсистемами например и т.д.
Это как хороший водитель-механик по ремонту BMW, который переберет машину шефа и помощник руководителя, который его понимает с полуслова и решает/делегирует любые вопросы, в том числе и с машиной
А 1Сник выслушает бизнес-задачу заказчика на его языке и уже понимает какие объекты будут затронуты для решения, как оптимизировать на будущее, предложит варианты как удобно интегрировать решение со смежными подсистемами например и т.д.
… то есть 1С-ник — это одновременно хороший бизнес-аналитик и хороший специалист по интеграции? И, наверное, еще и хороший специалист по тестированию?
Конечно, особенно если он на предприятии в штате и не стажер-кодер. CI и автоматическое тестирование по BDD уже вовсю пришло в 1С.
Если в интеграторе, то там обычно проекты большие и есть выделение методологов или функциональных архитекторов, которые пишут ТЗ и ФТ, но не до уровня классов и таблиц, а в терминах предметной области.
Технический архитектор может рулить на уровне концепций и подсистем, но обычный разработчик все равно понимает свой участок методологически
Если в интеграторе, то там обычно проекты большие и есть выделение методологов или функциональных архитекторов, которые пишут ТЗ и ФТ, но не до уровня классов и таблиц, а в терминах предметной области.
Технический архитектор может рулить на уровне концепций и подсистем, но обычный разработчик все равно понимает свой участок методологически
Конечно, особенно если он на предприятии в штате и не стажер-кодер.
Тут немедленно возникает два вопроса.
Как так получается, что 1С-ник умудряется совмещать в себе как минимум три квалификации, которые обычно принадлежат разным людям?
Почему вы думаете, что разработчики на других платформах не могут так же?
Получается, потому что 1С более высокоуровневая система, программист оперирует сразу объектами бизнеса, а не абстрактными ООП-концепциями, интерфейсами, синглтонами, отражением СУБД через ORM и пр.
Т.е. когда ты пообщался с заказчиком и накидал на бумажке нужные сущности и реквизиты, структуру отчетиков набросал — ты уже подготовил драфт бизнес-системы, который можно за день перенести в конфигуратор и прописать второстепенные детали. И вся дальнейшая разработка это интерфейсные рюшечки, отчеты, интеграции.
Надо добавить новый документ с 50 реквизитами — 20 минут и он в интерфейсе со всеми экранными формами, сиди прописывай чистую бизнес-логику, думай над UI/UX, а не над созданием классов, генераторов/конструкторов, get/set, дата-адаптетов, фабрик и т.д.
Интересно посмотреть бы на человека, который и с бизнесом общается и в javaЕЕ шарит и крутой фронт может написать на реакте например.
На западе такое не приветствуется точно, там рулит узкая специализация, нанимают по человеку на 1 функцию и пишут годами системы за миллионы евро.
А в итоге получается что команда из 10 джавистов делает за год меньше чем 3 одинесника и европейцы выпадают в шок когда показываешь им 1С.
Т.е. когда ты пообщался с заказчиком и накидал на бумажке нужные сущности и реквизиты, структуру отчетиков набросал — ты уже подготовил драфт бизнес-системы, который можно за день перенести в конфигуратор и прописать второстепенные детали. И вся дальнейшая разработка это интерфейсные рюшечки, отчеты, интеграции.
Надо добавить новый документ с 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, куда без них?
Внеконтекстные вызовы тоже нужная вещь.
Увы на Java почему то не придумали подобный фреймворк чтоб и UI и ORM и бизнес-модели было удобно реализовывать. Почему то все отдельно и надо уметь либо что то одно, либо скрещивать все это со спрингом
Еще раз смысл статьи в том, что добавляя все эти тонкости, они убирают автоматические возможности. И крупные проекты состоят из множества мелких, где все равно больше нужна быстрота и простота разработки, а не тонкие настройки.
Нет, без них можно было обойтись. И в тех же САП и Axapta таких абстракций гораздо меньше. А в lsFusion вообще нет (то есть например пиши условие в ГДЕ или где хочешь, оптимизатор сам разберется).
Условия и Менеджер это обычный SQL, куда без них? Внеконтекстные вызовы тоже нужная вещь.
Нет, без них можно было обойтись. И в тех же САП и Axapta таких абстракций гораздо меньше. А в lsFusion вообще нет (то есть например пиши условие в ГДЕ или где хочешь, оптимизатор сам разберется).
Полагаться на автоматические возможности это дилетантский подход. Зачем тогда делают зеркалки за 200к для проф. фотографов, снимали бы на телефон и всё.
1С потому и внедрила все эти тонкости, потому что на больших проектах ничего на автомате не внедришь.
Если у вас система не дает рулить вр.таблицами и выполнением на клиенте/сервере, мне вас жаль, у вас продукт уровня 1С 7.7 времен 1995 года.
Там можно было прикрутить dll прямого доступа к sql и работало намного быстрее чем 1С 8, большие магазины легко автоматизировались, но «почему-то» 7.7 безнадежно устарела, на одной скорости далеко не уедешь в современном мире.
Ссылаться на САП и Аксапту глупо, первая внедряется для галочки годами и за миллиарды за счет откатов, выглядит как говно и требует серверов от 10000 евро, вторая имеет долю рынка на уровне плинтуса. Они подходят для запада где разработаны, где стабильность и порядок в законах, другой менталитет и зарплаты.
1С родилась в РФ и лучше всего подходит для наших реалий, попытки это оспорить, имея на руках сомнительный софт для автоматизации в самой примитивной сфере (торговля) — выставление себя на посмешище
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) древность данных обычно обратно пропорциональна вероятности их использования, а на поддержание промежуточных итогов нужны дополнительные ресурсы (в частности место на диске), практическая польза от такой оптимизации весьма сомнительна (если, конечно, оперативную базу одновременно активно не используют как аналитическую, но об этом позже).
ну… про 1Снка который в одном лице сразу и качественный методист и знает типовую и кодит как бог — было более менее справедливо много лет назад… когда типовые были простыми и их было немного…
по современным продуктам если глобально подходить к методикам — все же чаще появляются отдельные специалисты-консультанты… равно как и все больше и больше кодеров появляется которые владеют методиками разработки на 1С но в бизнес-процессы не лезут… оно им не интересно и не нужно…
по современным продуктам если глобально подходить к методикам — все же чаще появляются отдельные специалисты-консультанты… равно как и все больше и больше кодеров появляется которые владеют методиками разработки на 1С но в бизнес-процессы не лезут… оно им не интересно и не нужно…
вы рассуждаете на уровне «чтобы ходить человеку приходится думать какую ногу сначала ставить — левую или правую»
да не задумывается разработчик… он просто знает как надо и делает как надо… а там где спорные моменты может этими директивами сделать более оптимально — например не отправлять лишний контекстный запрос на сервер тогда когда он там не нужен…
да не задумывается разработчик… он просто знает как надо и делает как надо… а там где спорные моменты может этими директивами сделать более оптимально — например не отправлять лишний контекстный запрос на сервер тогда когда он там не нужен…
Просто если хочется за границу укатить, тогда 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С они совсем другие чем в низкоуровневых платформах где все с нуля пишется на голом ООП. И надо учиться заново, пару лет погружаться в такой подход
Язык программирования давно роли не играет, нужны знания фреймворков, их подводных камней, 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% именно так все и обстоит. А ведь это франч входящий в относительно небольшое число «центров разработки».
З.Ы. Не без исключений конечно, но на 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#, например, или из крестов — у меня было бы намного больше релевантного опыта, я бы гораздо раньше начал изучать технологии разные и программирование, вместо всяких учетов и бухгалтерии и этих пробелов было бы гораздо меньше. Аналогично меньше было бы потрачено бесценного времени.
Ну и меня как бы тоже как и автора взяли после 1с писать на java/kotlin, автор нигде не говорит что ему это далось сложно, но так же нигде и не говорит что это ему далось просто.
Да и то что получаю я как мидл в своем регионе по новой специализации, как и то что я смогу устроиться мидлом куда то еще вообще ничего не значит. Это тупо девальвация лычек. Мидлами уже считают всех кто хоть как то может самостоятельно решать задачи.
Я вижу какие у меня гигантские пробелы в знаниях. Я вижу как мне далеко до топовых разработчиков. То что куча народа с теми же пробелами живет и работает — не делает такую ситуацию нормальной.
К чему я это? Если бы я переходил из C#, например, или из крестов — у меня было бы намного больше релевантного опыта, я бы гораздо раньше начал изучать технологии разные и программирование, вместо всяких учетов и бухгалтерии и этих пробелов было бы гораздо меньше. Аналогично меньше было бы потрачено бесценного времени.
Если бы я переходил из C#, например, или из крестов — у меня было бы намного больше релевантного опыта, я бы гораздо раньше начал изучать технологии разные и программирование, вместо всяких учетов и бухгалтерии и этих пробелов было бы гораздо меньше. Аналогично меньше было бы потрачено бесценного времени.
Еще раз не согласен: «релевантные» технологии и не сложны и не критичны. Их мало кто знает, не будьте с собой столько строги.
А понимание потребностей конечных клиентов (а 1С-ец куда как ближе к конечному клиенту) — этого вы из книжек не узнаете. Тот опыт тоже полезен.
Для конечных задач клиентов есть бизнес аналитики и дизайнеры. Не говоря уж о случаях когда конечные клиенты другие программисты. Ну и нет, не так уж и просты.
Впрочем немного поправлюсь, я ситуацию оцениваю с точки зрения регионов в основном. Что там в столицах — знаю только по слухам. Может там для каждого 1сника как нефиг делать стек сменить не теряя грейда и опыта.
UPD. Я конечно в оплате при переходе не потерял, но это тупо из за везения произошло, у компании особых вариантов не было, да и бюджеты заметно больше чем у 1сных франчей.
Впрочем немного поправлюсь, я ситуацию оцениваю с точки зрения регионов в основном. Что там в столицах — знаю только по слухам. Может там для каждого 1сника как нефиг делать стек сменить не теряя грейда и опыта.
UPD. Я конечно в оплате при переходе не потерял, но это тупо из за везения произошло, у компании особых вариантов не было, да и бюджеты заметно больше чем у 1сных франчей.
А понимание потребностей конечных клиентов (а 1С-ец куда как ближе к конечному клиенту) — этого вы из книжек не узнаете. Тот опыт тоже полезен.
… пока вы не выясните, что, внезапно, у выделенного аналитика это понимание лучше, чем у вас, и вы ему мешаете.
А понимание потребностей конечных клиентов (а 1С-ец куда как ближе к конечному клиенту) — этого вы из книжек не узнаете. Тот опыт тоже полезен.
… пока вы не выясните, что, внезапно, у выделенного аналитика это понимание лучше, чем у вас, и вы ему мешаете.
Если у вас не было опыта непосредственной работы с клиентами — то да.
Язык программирования давно роли не играет, нужны знания фреймворков, их подводных камней, ORM, библиотек тестирования, паттернов проектирования и реализации.
Кому нужны?
Джуну? Да, потому что ему больше и показать себя нечем.
Мне доводилось принимать решения после технического собеседования, которые вам покажутся странными:
И брал умных ребят на совсем другой стек, совсем другой язык. И знаете — ни разу не прогадал, новый стек осваивали действительно быстро, как я это и предполагал.
Это пишется в 10 кликов мышью и "есть null" можно мышой перетянуть или руками набрать. Минут пять работы, если структуру базы данных знаешь. Видео записать? )
И я бы еще вместо вложенного запроса породил временную таблицу с именем типа ТоварыДокумента, чтобы лет через 5 проще править было — запрос стал бы еще больше.
Расскажите как быстро пишется запрос по трем таблицам в вашей системе. И как выглядит. Я вот не зная откуда вы это скопировали догадываюсь, что этот запрос выбирает строки расходной накладной, для которых не хватает остатков.
Я скопировал из методических рекомендаций самой 1С.
Как это делается в lsFusion — тут. Вообще никаких запросов писать не надо.
Как это делается в 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 новых типов документов наследование и полиморфизм используются. То есть новые типы документов наследуют просто ReceiptDetail, и если надо перегружают реализацию / реализуют quantity. Больше ничего не меняется. Все декларативно и само автоматически работает.
При появлении еще 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 множественное наследование есть.
Два склада в одном документе? Как это отобразится в таблицу?
> Никто не пишет вручную запросы
Я пишу.
> через СКД можно создавать очень мозголомные конструкции
По моему глубокому убеждению, если вам требуется для решения учетных задач создавать «мозголомные конструкции», у вас что-то не так спроектировано, или инструмент имеет серьезные проблемы.
Я пишу.
> через СКД можно создавать очень мозголомные конструкции
По моему глубокому убеждению, если вам требуется для решения учетных задач создавать «мозголомные конструкции», у вас что-то не так спроектировано, или инструмент имеет серьезные проблемы.
Я пишу.
я же не сказал что «все», конечно есть исключения
если вам требуется для решения учетных задач создавать «мозголомные конструкции», у вас что-то не так спроектировано, или инструмент имеет серьезные проблемы.
иногда чтобы выцепить десяток цифр раз в месяц, проще сделать пятиэтажный запрос, чем городить десяток регистров и индексов ради сокращения этого запроса до одного селекта.
Сейчас работаю с человеком с такой точкой зрения, такие решения часто имеют под собой контекст в виде неограниченного бюджета на сроки разработки и на оборудование… никак не могу такое поддержать (эффективный менеджер у меня в голове плачет)
А зачем вручную писать запросы? Я понимаю, что в разговорах это звучит офигительно и прям «Тру», но смысл писать запрос руками, если есть удобный конструктор, ускоряющий и упрощающий жизнь? на написание маленького запроса с 2-3 Временными таблицами руками можно пол жизни убить + искать ошибку в опечатке «Субкотно»…
ИМХО это какой-то особый сорт мазохизма, все же…
Вы может еще Ctrl+C/Ctrl+V не пользуетесь?
ИМХО это какой-то особый сорт мазохизма, все же…
Вы может еще Ctrl+C/Ctrl+V не пользуетесь?
И я пишу. Но не всегда прямо только руками, иногда сделаю заготовку конструктором и правлю руками, а иногда и наоборот. Как быстрее. Зачем писать руками:
1. Конструктор не позволяет писать комментарии, и убивает уже написанные — одного этого достаточно, что бы не пользоваться им редактирования уже написанных запросов.
2. Для меня текст запроса гораздо более нагляден, чем бесконечное число закладок в закладочке в конструкторе. Так проще изучать запрос, и сразу вносить комментарии. Еще было бы проще с нормальной синтаксической подсветкой по запросу :(
3. Скажу тайну — в других средах разработки нет конструктора, а есть подсказка по именам таблиц. Поэтому там не может быть ошибки в «Субконто...». И, оказывается, что написать запрос с клавиатуры часто проще и быстрее, чем щелкать мышкой по закладкам и прокручивать списки с именами таблиц и полей. Так что еще вопрос, где особый сорт мазохизма…
4. Конструктор может не все.
1. Конструктор не позволяет писать комментарии, и убивает уже написанные — одного этого достаточно, что бы не пользоваться им редактирования уже написанных запросов.
2. Для меня текст запроса гораздо более нагляден, чем бесконечное число закладок в закладочке в конструкторе. Так проще изучать запрос, и сразу вносить комментарии. Еще было бы проще с нормальной синтаксической подсветкой по запросу :(
3. Скажу тайну — в других средах разработки нет конструктора, а есть подсказка по именам таблиц. Поэтому там не может быть ошибки в «Субконто...». И, оказывается, что написать запрос с клавиатуры часто проще и быстрее, чем щелкать мышкой по закладкам и прокручивать списки с именами таблиц и полей. Так что еще вопрос, где особый сорт мазохизма…
4. Конструктор может не все.
Я не против, пишите, но все ваши 4 пункта просто придирки:
1) Ну не позволяет, это вообще не проблема, для начала — необходимо писать понятные запросы, к которым максимум можно оставить комментарий до текста запроса — комментарии в тексте запроса 1С имхо — моветон.
2) Это вкусовщина и привычка, есть подозрение, что вы не особо владеете конструктором, либо очень сильно привыкли к ручному текстингу.
3) Спасибо за тайну, но речь идет про 1С, в других средах пускай хоть «кофа с чаем» будет, ну и написать запрос в 1С часто проще и быстрее сделать в конструкторе, если это не запрос выбора из одной таблицы + форматирование запроса будет корректным и читаемым и на него вы не потратите кучу времени.
4) Конструктор может не всё — никто не может всё, а конструктор — облегчает жизнь разработчика.
Поймите, я не против, чтоб вы или кто-то другой писал запросы без конструктора, это ваше дело и ваша жизнь, но нельзя отвергать прогресс. Конструктор не совершенен, но он облегчает разработку и экономит время программиста 1С, как и другие фишки типа Ctrl+Space, F12, Alt+Shift+F. Это все просто экономит жизнь и нервы.
А уж если брать другие языки, так в Java — можно программировать и в обычном блокноте, и есть такие люди, но тот же Notepad++ удобнее и практичнее…
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 я и сам терпеть не могу. А под полным отображением инфы об одной таблице я собственно и понимаю отображение на экране одновременно информации о составе выбираемых полей, источниках таблицы, группировках, условиях и отборах и прочему. Чтобы это в конструкторе увидеть — приходится как зайцу по вкладкам прыгать. При этом часто желательно видеть как данные по текущей таблице, так и данные по прошлой.
>комментарии в тексте запроса 1С имхо — моветон
??? Комментировать код — моветон ???!!!
??? Комментировать код — моветон ???!!!
Комментарии В ТЕКСТЕ ЗАПРОСА, типа такого:
Это моветон.
Либо до, либо после текста запроса необходимо ставить комментарий, патамушта если запрос будет большой или разработчик слепой, то твой коммент не увидят, а при правке запроса консолью твой коммент канет в лету
Запрос = Новый Запрос(
"|ВЫБРАТЬ
|* //Комментарий о моей офигенской дописке
|ИЗ
|Справочник.ВариантыОтчетов КАК ВариантыОтчетов");
Это моветон.
Либо до, либо после текста запроса необходимо ставить комментарий, патамушта если запрос будет большой или разработчик слепой, то твой коммент не увидят, а при правке запроса консолью твой коммент канет в лету
Код SQL ничем принципиально не отличается от обычно программного кода, и точно так же, там есть необходимость писать комментарии. 1С приучила пользоваться конструктором, и не писать комментарии в запросах, потому что это не позволяет конструктор. Но это не значит, что это правильно. Это, на самом деле, проблема.
Посмотрите код ERP. Там уже есть комментарии в запросах, некоторые из них мне с экономили часы разборок с кодом. Вот, копирую пример из типовой ERP:
|ВЫБРАТЬ // Оплата поставщикам через подотчетное лицо (Дт 60.01 :: Кт 71)
Посмотрите код ERP. Там уже есть комментарии в запросах, некоторые из них мне с экономили часы разборок с кодом. Вот, копирую пример из типовой ERP:
|ВЫБРАТЬ // Оплата поставщикам через подотчетное лицо (Дт 60.01 :: Кт 71)
Вообще, я не говорю — что конструктор плохо. Или что писать руками — плохо. Надо уметь все и применять то, что эффективнее. Руками писать — это однозначно гибче. Но конструктором бывает быстрее. Но не всегда.
Простой пример. В запросе есть выборка во временную таблицу. Потом она обрабатывается еще в десятке запросов. Вдруг выясняется, что данные надо в этой выборке взять из другой таблицы, с другими названиями полей. Остальное не меняется. Если в конструкторе начать менять выборку в эту таблицу, конструктор безнадежно портит всю обработку, что следует далее.
В тексте это делается элементарно — просто исправляешь название таблицы и имена полей.
Причем здесь прогресс — не понимаю. Есть язык запросов (диалект SQL). Что бы на нем писать, надо его знать и понимать. Знать и понимать — это значит уметь читать его текст, и уметь писать на нем. Это главное. Все остальное — это всего лишь вспомогательные инструменты.
Простой пример. В запросе есть выборка во временную таблицу. Потом она обрабатывается еще в десятке запросов. Вдруг выясняется, что данные надо в этой выборке взять из другой таблицы, с другими названиями полей. Остальное не меняется. Если в конструкторе начать менять выборку в эту таблицу, конструктор безнадежно портит всю обработку, что следует далее.
В тексте это делается элементарно — просто исправляешь название таблицы и имена полей.
Причем здесь прогресс — не понимаю. Есть язык запросов (диалект SQL). Что бы на нем писать, надо его знать и понимать. Знать и понимать — это значит уметь читать его текст, и уметь писать на нем. Это главное. Все остальное — это всего лишь вспомогательные инструменты.
Я не нахожу этот конструктор удобным. Куча вкладок, кнопок, галочек, часто с невразумительными, интуитивно непонятными подписями. Как там у Радченко, главного 1с-писателя в одном из описаний создания отчета: у вас получился не тот результат, это потому что на пред-предыдущем шаге вы забыли на вкладке… поставить третью сверху галочку на дополнительной панели… — что-то вроде этого.
И мелкий шрифт, который нельзя (!!!) изменить.
Нет, спасибо. Конфигуратором (даже не скд) я обычно пользуюсь в последний момент, когда надо уже написанный и отлаженный фрагмент кода скопипастить в модуль и сохранить. А до того предпочитаю пользоваться текстовым редактором, отлаживаюсь через веб-сервис с помощью своей утилиты. Конфигуратор по мне — слишком тормозной и неудобный инструмент.
И мелкий шрифт, который нельзя (!!!) изменить.
Нет, спасибо. Конфигуратором (даже не скд) я обычно пользуюсь в последний момент, когда надо уже написанный и отлаженный фрагмент кода скопипастить в модуль и сохранить. А до того предпочитаю пользоваться текстовым редактором, отлаживаюсь через веб-сервис с помощью своей утилиты. Конфигуратор по мне — слишком тормозной и неудобный инструмент.
98% разработчиков используют СКД
Результатом работы которого является тот же запрос в виде строки, и который запросто накроется в рантайме если переименовать реквизит/справочник ибо проверку корректности всех запросов после изменения структуры конфигурации в 1с возложили на разработчика.
Да и иногда запросы формируются динамически, от условий каких то, через конкатенацию строк.
UPD. Я под конец моей работы с 1с (на 3-4 год) конструктором запросов конечно пользовался, но внутри него открывал текстовое редактирование, ибо так удобнее. И да, при чем тут СКД, когда мы про запросы в коде говорим, а не в отчетах?
на 1С можно наваять сложную систему учета, и она будет работать, за то время пока для обычных 'фреймворков и sql' будут только писать ТЗ и набирать народ с вилкой 180-250
В 8.3? Я собственно статью и написал, что наваять на ней систему, которая будет нормально работать на >10к записей, не сильно проще чем на том же .Net. А если с lsFusion сравнить, где ни одной из верхних 21 проблем нет (а это еще далеко не все проблемы), то это разница будет как между лошадью и автомобилем. Причем lsFusion под LGPL лицензией, то есть открытыми исходниками, бесплатно и т.п.
Не любят в наше время честно вести бизнес. Вместо того, чтоб делать свой продукт качественным и конкурентоспособным (оно может так и есть на самом деле), начинают черный маркетинг на крупных ресурсах.
Сравнение лошади и автомобиля в комментарии выглядит как популистическая байка.
1С — известные крупняки, у которых огромный выбор решений, бекграунда, комьюнити, специалистов, франчей и тд. У них хотя бы разъемы подходят к местному бизнесу
IsFusion — платформа, которая только пытается выйти на рынок, предлагая подобный 1С функционал.
Я бы хотел почитать аналогичную этой статью о 21 минусе IsFusion.
Сравнение лошади и автомобиля в комментарии выглядит как популистическая байка.
1С — известные крупняки, у которых огромный выбор решений, бекграунда, комьюнити, специалистов, франчей и тд. У них хотя бы разъемы подходят к местному бизнесу
IsFusion — платформа, которая только пытается выйти на рынок, предлагая подобный 1С функционал.
Я бы хотел почитать аналогичную этой статью о 21 минусе IsFusion.
Я бы хотел почитать аналогичную этой статью о 21 минусе IsFusion.
Так разберитесь в lsFusion и напишите. Мы даже ее заплюсуем, насколько сможем. Мы никогда не были против открытого обсуждения любых проблем.
1С — известные крупняки, у которых огромный выбор решений, бекграунда, комьюнити, специалистов, франчей и тд. У них хотя бы разъемы подходят к местному бизнесу
Когда Форд сделал автомобиль, тоже было много стойл, сена, конюхов, известные крупняки и т.п. И по вашему он проблемы лошадей не должен был упоминать?
А вообще я уже писал:
«Возможности ничего не стоят, без проблем которые они решают.»
Когда Форд сделал автомобиль, тоже было много стойл, сена, конюхов, известные крупняки и т.п. И по вашему он проблемы лошадей не должен был упоминать?
Дык Форд то выиграл по итогу как мы знаем.
А вы еще нет.
И не факт что выиграете.
Как не выиграли еще 5 подобных же перспективных «убийц 1С» в этом веке.
Вам пишут, что у 1С есть неоспаримые преимущества помимо технологического совершенства (хотя и в этом плане 1С на весьма хорошем уровне).
А вы в ответ — «зато мы более технически совершенны» (что кстати не очевидно из ваших статей).
Однако, так как продукт 1С не шняга, незначительным техническим преимуществом (если оно есть вообще) не сместить 1С с рынка.
Об этом ваш оппонент вам и пишет.
Почему не 1С?