Комментарии 532
Может быть, я зря нагнетаю, но в каком-нибудь настоящем ЯП вы видели, чтобы костыли, которые улучшают IDE, продавали за деньги?
C# и ReSharper:)
Я не разработчик. И не 1Сник. но о чём пишите понимаю неплохо. Админил долго 1с и взаимодействовал 1с разработчиками, иногда выступая аналитиком. Мне кажется 1С специалист часто (особенно если это типовая конфигурация, пусть и доработанная) это некий микс. Нечто среднее между специалистом поддержки конкретного приложения и традиционным программистом.
А проблемы о которых пишите Вы- они настоящие. только истоки надо искать в истории развития 1С. Как платформы для быстрой автоматизации типовых задач в малом и среднем бизнесе. Не для Энтерпрайза (о чём пишите Вы). От этого и многие фитче-баги родовые. в 7.7 ещё было вполне органично, а потом пошел этап перерождения системы в восьмиусого шиву который в какой то момент должен дать бой SAP.
И странности- например, меня как админа просит глав бух назначить права в переписанной ОПП. Профили не прописаны, она может сказать -что бы этот пункт меню работал и этот. Что бы разобраться какие роли дать мне приходилось открывать конфигуратор и смотреть там права.. Причём с первого раза не работало т к нужны ещё и права на связанные объекты. Или вот- обновление платформы. Разработчик 1С просит поставить -иначе релиз не обновить. 8.3 очередная. А конфигурация под 8.2 сделана и пользователи к его меню привыкли, а в новом формате многих пунктов, особенно "дописанных" нет. И я изгаляюсь в каком режиме и с какими параметрами заработает нормально (причём заработал только один из видов клиента- уже не помню тонкий или толстый).Ну или какой то косяк тех же бухов с занесением информации в систему, когда надо очищать регистр.
Сейчас работаю на крупном предприятии, где админы кластеров 1с отдельный отдел, по отделу у каждой конфигурации- вполне грамотно отмасштабировали и работает это всё с высокой нагрузкой и без тормозов. Но в среднем, в общем то Вы верно описали -ситуация, мягко говоря от идеала далеко.
"Разработчик 1С просит поставить -иначе релиз не обновить. 8.3 очередная. А конфигурация под 8.2 сделана и пользователи к его меню привыкли, а в новом формате многих пунктов, особенно "дописанных" нет."
- Страшные вещи описываете. Что это у вас за разработчик конфигурации такой, что затер собственные же пункты меню? Он за это вредительство небось денег взял? И когда за это платили, то ничего не смущало?
- Больше похоже на то, что у разработчика были обновления на систему, в которой сидела часть пользователей и которым нужен был именно 8.3, а другие продолжали работать в старой системе на 8.2 (странная терминология - и то и другое является управляемыми формами, переключение между которыми, грубо говоря, как применение стилей меняет только оформление, а вовсе не разделы и их наполнение командами).
- Только зачем вы подняли версию для всех, а потом героически пытались выкручиваться? Почему не оставили предыдущую версию? Для файловой в стартере можно указывать с какой именно версией платформы стартовать базу, а для серверной этого можно не делать, но нужно придумать уникальный диапазон портов, если зоопарк версий будет запускаться на едином хосте.
Да нормально всё с 1С, она дает возможность достойно зарабатывать с низким порогом вхождения. Да, много ограничений и ошибок, но и плюсов тоже много, бизнес сейчас не любит/может ждать, всё меняется очень динамично, 1С для этого хорошо подходит.
а я и не сказал, что 1С - кусок какашки. я несколько раз подчеркнул ее достоинства.
моя статья строится на сравнении идеальной 1С из статьи @EvilBeaverи того, что есть на самом деле.
Тут даже речь не в том, кусок какашки 1С или нет, просто вы сравниваете её не с теми продуктами. Вы противопоставляете её универсальным средствам разработки, чем 1С в общем-то и не является. 1С - это в первую очередь бизнес-приложение с инструментами разработки, и основное её назначение - дать бизнесу готовый функционал из коробки, который ещё можно кастомизировать. То, что на ней пытаются писать всё подряд, это, скажем так, сайд-эффект её распространённости и долговечности.
По моим наблюдениям, бизнесу (если это не IT компания) в общей массе, нужны не программисты, а консультанты. Типовая 1С:КА + пара расширений, и только успевай обновлять)
спасибо.
я просто устал от ограничений 1С, так то какая разница на чем кодить.
Для бизнеса важно решить задачу и быстро, если это делает 1С какая разница бизнесу? Специалистов по 1С в любой деревне, а какой нить SAP это медленно, дорого и к моменту запуска уже и цели у компании другие. Потому все и выбирают 1С, не просто так же сложилась такая тенденция.. А ограничения 1С больше возникают от желания сделать удобнее, красивее, быстрее, если разумно к этому подходить, то ограничения не являются такой уж и проблемой, ну при желании можно почти любой функционал через COM подтянуть или компоненты
1С хороша на своем поле боя - она очень хорошо подходит для RAD разработки CRUD-слоя над табличками с визуализацией из коробки. именно поэтому ее используют и в самописных конфигурациях.
моя статья не про это, а про сравнение идеальной 1С в оригинальной статье и тем, что есть на самом деле.
Сравнивать 1С с SAP это вообще не понимать, как устроена современна система SAP. Много можете назвать компаний, где внедрена такая система, Тогда зачем пишете?
1 С это никакая не ERP- cистема. В лучшем случае учетная бухгалтерия. Есть и функциональнее и производительнее.
А вот про SAP интересно послушать. Расскажите нам, как устроен современный SAP, чтобы мы могли сравнить?
Везде где я видел сап и работал на интеграции с сапом САП был слабым зеном, тормозом проекта и говном. Основной аргумент, который говорят саперы, когда не хотят ничего делать: "САП это не умеет". Почему-то, в их среде это считается приличным аргументом. Сейчас мне расскажут, что современный сап не такой, а я видел какой-то несовременный, может быть. Но то, что ABAP-based - шлак. Даже если на него наклеить шильдик S/4 и громко обещать, что "ну теперь, все не так, теперь все-по новому".
У нашей команды был стикерпак со внутренними мемами, так там одно из почётных мест занимала фраза "Так пришло из SAP"
А не кажется ли вам, что дело не в система, а во внедренцах с лучшими практиками. Вот только, скажи, почему у нас повально столько предприятий "имеет" SAP. Наверное остальные еще хуже. Как думаешь.
Я не за САР. Я за отечественную, достойную систему, а не халявную. Монополизация приводит к деградации.
Причем здесь SAP? Я не за САР.
Я за отечественную, качественную систему на отечественной платформе(безопасность), совместимую с аппаратным комплексом отечественного производителя. С единой базой для всех бизнес- процессов и операций организаций, предприятий. Для выполнения одной из важнейших функций автоматизации- оптиматизации. К сожалению, та компания,о которой статья, на мой взгляд, не соответствует этим критериям.
А вот как устроена ERP-система SAP можешь поинтересоваться индивидуально, самостоятельно, если интересно.
Да что вы, берите больше, это вообще никакая не система, это картинки просто, в которые можно мышкой тыкать :)))))
У меня складывается впечатление, что вы 1С не видели совсем. Я не топлю за неё, но по скорости/качеству решения бизнесзадач, гибкости и удобству на сегодня удобнее продукта я не знаю, может я отстал где-то?.... Вроде 30 лет уж в ИТ...
Полностью поддерживаю. Кажется, что программисты (от слова программировать, создавать качественный продукт) перевелись, а может их и не было.
На одном известном ресурсе по 1С, один такой же махатель шапкой из Фузины (кстати он в этой теме отметился) тоже говорил практически что и вы. Когда ему предложили наспор написать за неделю простейшую систему учета остатков товаров на Фузине vs 1С на УФ, то он сначала было взялся, а потом тупо слился. Хотите поучаствовать? Готовы на C# и WinForms написать за неделю простую учетную систему? Пусть даже оппонент с 1С будет не на УФ, а на ОФ. Даже беря во внимание только UI, на который вы в основном и расставили акценты, уверен что вы сольетесь уже на привязках элементов формы, даже до бизнес логики не дойдя.
"Готовы на C# и WinForms написать за неделю простую учетную систему? "
Из пластилина легко слепить детскую игрушку. Но самолет из пластилина сделать тяжело.
Никто не спорит что на 1С низкий порог и быстрая разработка ларьков. Но стране нужно не это, стране нужна автоматизация мега корпораций таких как газпром, почта россии, огромных заводов которые являются городами.
Многие 1С специалисты, и вы в том числе мыслите категориями ИП, когда нужно быстро и дешево. Я вот на ютубе смотрю канал одного человека, он там из Пеноплекса дом строит.
Тоже говорит смотрите как быстро получается, и дешево, и даже тепло.
Я за свою карьеру в 1С (18 лет разработки) построил не мало таких вот "домов" из пеноплекса, и пока ты его строишь всё супер, проблемы начинаются ближе к концу, когда нужно возводить перекрытия, крышу, сантехнику, вешать шкафы и полки и много чего другого...
Вы считаете, что построить большую и сложную систему на 1С в принципе невозможно?
Построить можно что угодно из чего угодно.
Проблема это все сопровождать, развивать, масштабировать. У меня есть опыт построения систем федерального уровня с базами в несколько терабайт, и огромными нагрузками, и работа с этими системами это в 90% случаев борьба с платформой, и СУБД. В общем все прелести монолита + отношение 1С к СУБД как набору DBF.
Мы покупаем промышленные СУБД за десятки миллионов что бы использовать их на уровне SELECT + максимально примитивный INSERT весь остальной функционал этих СУБД можно использовать только вопреки и с огромными костылями и сложностями.
Предполагаю, что это следствие универсальности 1С, т.е. возможности работы с несколькими СУБД.
У меня есть опыт построения систем федерального уровня с базами в несколько терабайт, и огромными нагрузками, и работа с этими системами это в 90% случаев борьба с платформой, и СУБД
но то, что системы такого масштаба существуют (и достаточно распространены в РФ), уже говорит в пользу 1с.
Я как то был на инфостарт и задавал вопрос Олегу Бартунову, можно ли где то ознакомиться с best practices по эксплуатции крупных монолитных баз от 1 Tb и выше.
На что получил ответ:
" best practices по эксплуатции крупных монолитных баз от 1 Tb заключается в том что бы не создавать крупные монолитные базы от 1 Tb"
И что примерно с 2002 года индустрия уходит от монолитов в сторону сервисов, так как объемы автоматизации а так же данных растут, и держать это все в одной базе бессмысленно, так как разные категории данных имеют разную критичность, разные объемы, разную нагрузку. Не просто так придумали разделение OLAP/OLTP.
Любая система на 1С это жесточайший монлит на всех уровнях от кода до субд.
Любая система на 1С это жесточайший монли
Не обязательно.
Я не зря написал "система", а не "база".
Система может состоять из нескольких баз.
Например РИБ с узлами содержащими разные виды данных.
Либо система состоящая из несколько несвязанных баз, между которыми происходит обмен информацией отдельными механизмами.
Вы действительно не понимаете разницу между РИБ и микросервисной/сервисной архитектурой?
Вот представьте что у вас в компании развернут сервис по работе с контрагентами, все части вашей системы (договора, документооборот и.т.п) при попытке подбора контрагента обращаются к нему, он хранит в своей собсвтенной базе списки контрагентов, отдает отрендеренную форму контрагента и.т.п.
Если у вас стало так много контрагентов что 1 серверне справляется вы разворачиваете еще один сервер и ставите между ними фасад который определяет на какой сервер отправить запрос (например по коду контрагента).
Т.е. вы вот когда в интернете переходите по ссылкам, вы же понимаете что за каждой ссылкой может стоят своя инфраструктура которая вообще в другой стране расположена, это для вас это цельное приложение.
Самый хороший пример того насколько ущербна 1С это библиотека "бесшовной" интеграции с документооборотом. Суть в том что вы можете процессы согласования отдавать в ДО, а результаты и ход процесса отслеживать в своей конфигурации... Вот только на 1С нельзя сделать ничего лучше чем просто продублировать все формы из ДО в эту библиотеку.
Как бы это работало в нормальном виде?
Просто iframe в который подтягиваются данные из системы согласования с офролемением через css. В 1С это могло бы выглядеть как открытие окна одного приложения в окне другого при том что пользователь не понимал бы что сейчас он видит данные из другной базы.
В 1С это могло бы выглядеть как открытие окна одного приложения в окне другого при том что пользователь не понимал бы что сейчас он видит данные из другной базы
Разве так сделать нельзя?
Только через COM и с кучей ограничений и условий. Плюс открытие окна одного приложения в другом это только самая вершина, тут хотя бы аналогию можно провести.
Не только.
Можно и запросами в другую базу организовать.
Ну вот запросами в "бесшовной интеграции" и реализовано, т.е. часть форм из ДО просто скопировано визуально.
А дальше через WEB сервис запрашивается струкутра данных и полученными данными заполняется копия формы.
В то же время если бы это были системы построенные на современных подходах к разработке, мы бы нативно открывали форму из другой системы в едином интерфейсе, т.е. при изменении на стороне ДО нам не приходилось бы дорабатывать копии форм и структуры данных в библиоткеке бесшовной интеграции, да и сама библиотека была бы не нужна.
Ваш пример с "системой" из нескольких конигураций приводит к тому что пользователь должен переключаться между разными интерфейсами если работает с несколькими решниями. Т.е. в нашем примере:
Работаем в ERP, согласовываем в ДО приводит к тому что нужно переходить в разные приложения. Ну или использовать очень ограниченные костыли в виде копий форм из ДО.
Системы гарантированной доставки сообщений, то, что вы называете RMQ, не решают все проблемы. Во-первых, они не гарантируют отсутствие проблем и сбоев. Во-вторых, они не могут этого сделать. Любая внешняя система доставки сообщений действует вне транзакции записи объекта. Т.е. вы никогда не можете быть уверены в том, что объект отправится при успешном завершении транзакции или наоборот. Кроме того, никто вам не гарантирует, что объект будет получен и вы об этом узнаете. Очереди даже хуже почты и мессенджеров в этом плане.
С другой стороны 1С предлагает небезупречный механизм, но с гарантированной доставкой сообщений. Га-ран-ти-ро-ва-нной. А это важно.
At least once - точно доставит, но возможно больше одного раза
At most once - может доставит, может нет, но точно не более одного раза
Exactly once - точно доставит, и точно не более одного раза.
Для exactly once требуется хранить в том или ином виде состояние на клиенте: offset/ключи корреляци и тп. Самый дорогой вариант. Более того, для поддержки exactly once, требуется поддержка и отправителя и получателя
Это вы ещё на LOR не заходили.
Чем больше читал статью - тем интересней становилось, что же будет в коментах.
Автор, я никоим образом не восхваляю 1с. Я с ней познакомился впервые в универе и лично мне сразу стало ясно, что связываться с ней не стоит. Хотя это годное решение для определенной ниши.
Но, многие проблемы, которые вы описали применительно к 1с, существуют и в мире «взрослого» программирования.
я шел по пунктам из оригинальной статьи @EvilBeaver и несколько раз подчеркнул, что 1С как JavaFX+Hibernate очень хороша для автоматизации заполняемых табличек.
Это, на мой взгляд, утонуло в общем настрое статьи, она больше воспринимается именно как "1с какашка". C#/Java/Go такая же какашка, просто там проблемы другие.
Дело в другом, что люди не прочитав изначальной статьи стали реагировать на ответную статью
Я прочитал оригинальную статью - мне показалось, что там фокус именно на бизнесовой составляющей работы программиста. Сесть изучить бизнес-процессы, подумать, надо ли делать и что и как надо сделать. Причем решение может лежать совсем не в плоскости информационного обеспечения. И с этой точки зрения (такой довольно высокоуровневой) - 1С с ее встроенными возможностями и недостатками отличная штука, потому что не позволяет утонуть в технических деталях.
Лет десять-двенадцать назад меня многие уговаривали идти в одинЭс. Мол, голова на месте, без куска хлеба не останешься. Но я всеми фибрами души ненавижу бухгалтерию. Поэтому, сразу пошел в Java и пр. Какое счастье.
Некоторое время я даже работал рядом с отделом одинЭсЭс'овцев - много общались, поэтому примерно понимаю, о чем говорит автор статьи.
я тоже устал от бухгалтерии :)
Но я всеми фибрами души ненавижу бухгалтерию
а причём тут бухгалтерия? львиная доля — оперативный учёт, можно (условно говоря) быть разработчиком на 1с и не знать что такое план счетов.
Автор каким-то образом даже подсчитал, что именно 80% из них не думают, когда программируют. Наверное, у него есть какая-то статистика, которую он вручную собирал.
Он видимо про копипаст кода из stackoverflow, но в упомянутых языках так не работает.
Ого, да тут целый дисс на меня и мое выступление в позапрошлом году! Придется ответ писать, что поделать...
Почитаю попозже, ибо многабукав, а я только-только проснулся. В любом случае, автору спасибо.за мнение (каким бы оно ни было) В спорах пождается истина.
В споре рождается всеобщее заблуждение, как писал классик.
даже любопытно будет почитать
я бы не сказал, что это прям дисс.
тем более где Вы видели дисс, где оппоненту респектуют за его разработку?
это скорее ответка по пунктам на Вашу оригинальную статью.
я даже заказывал редактуру и оценку литературной ценности, чтобы не вышло так, что я перехожу на личности.
пишите статью, почитаю, конечно, но спорить не очень хочется.
и да, мотивом для рождения ответки стал тезис что "настоящие программисты не думают, когда делают задачу".
В спорах пождается истина.
истина существует независимо от нашего восприятия и наших знаний о ней :)
А логично ли вообще требовать от 1С возможности создавать независимые приложения, парсить сайты, подключать нейронные сети и прочие вещи, о которых вы говорите?
Ведь 1С по сути просто раздутая CRM.
скорее все-таки domain-specific language - и из этого вытекает большинство вышеупомянутых плюсов и минусов
это раздутый ORM с визуализацией табличек, где классы ORM хорошо подходят под хранение периодических данных и всяких бухгалтерских расчетов.
так что это скорее DSL.
А какие проблемы у 1С с парсингом сайтов, которых нет у других систем? Ну может либы получше, XPath2+ с регулярками, но это просто вариант использования технологий (типа я напишу этот код в три строки, а я - в пять). https://infostart.ru/1c/articles/1031620/
как отрендерить javascript код и достать текущее DOM-дерево только встроенными средствами платформы?
Если решать вопрос отображения контента, дернутого из какого-то третьего места, то нужно хитро извернуться и только на клиенте, засунув какой-то джаваскрипт с страницу в поле хтмл-документа, огрести кучу приключений и остаться с неким похожим на правду результатом.
Но это в 1С никому не нужно. Цель парсинга - это получить эффективные данные, а не их отображение на странице. Эффективные данные ездят джисаном, иксэмелем, даже протобуфом (да, 1С с ним не умеет "сама"), потом уже джаваскриптами рендерятся. Но задача парсинга - это не абстрактный рендер, а та самая приехавшая информация (список адресов ломбардов и номеров их телефонов, например). И как они будут отрендерены - да всем пофиг, важно сделать из этого некий эксель и послать на почту юзеру, который уже будет их прозванивать (ну или роботу, которому внешний вид только мешает).
Задачи парсинга - это не отобразить у себя так, как где-то там. Если задача ставится именно так, то что-то тут не то.
ЗЫ: и с чего ответ про 1С и нативные методы? Какой-то бред. Ну и расскажи, где там "нативными методами" это все делается. Ага...
то есть в 1С нативными методами, никак. понял, спасибо.
Ни в одной известной мне корпоративной информационной системе (SAP, Axapta, Oracle ERP) я про такие нативные средства не слышал - вот чтобы пойти и распарсить DOM-дерево на каком-то произвольном сайте.
нативный метод - это когда в коде конфигурации написал на встроенном ЯП без внешних компонент.
На встроенном языке 1С можно написать что угодно, даже RTX-рендер. Вы просто не видели код либ на JS для всех этих штукалясин, которые называете "нативными" - они там ну очень большие. Ну и не совсем ясно, можно ли считать "нативным" скомпилированный в Web-asm какой-нить PgSQL, который также можно скомпилить в 1С-асм.
Просто 1С-неги часто не пишут свою либу на своем языке, которая бы представляла из себя интерпретатор JS для того, чтобы на кой-то хрен (совершенно непонятный) отрендерить какую-то область, чтобы выдрать оттуда какой-нить innerHTML. Но если говорить о возможностях, то 1С это вполне способна сделать хотя бы через поле HTML-документа, при том 99,9999% всех тех либ, которые Вы по какой-то причине считаете нативными, делают это через очень далеко, т.к. вряд ли имеют либы интерпретатора JS (ну если это не аналог "Выполнить" в той самой JS). Но если имеют - да флаг им в руки, ибо высосанный из пальца пример нафиг не нужен в реальной разработке, и делать парсинг через какие-то клики - это попытка запилить что-то, совершенно не понимая, зачем это нужно и как это делать правильно.
На встроенном языке 1С можно написать что угодно, даже RTX-рендер
я бы посмотрел на безумца, способного на это.
Вы просто не видели код либ на JS для всех этих штукалясин, которые называете "нативными" - они там ну очень большие.
я не претендую на бесконечную мудрость. я много еще чего не видел.
можно ли считать "нативным" скомпилированный в Web-asm какой-нить PgSQL, который также можно скомпилить в 1С-асм.
скорее всего нет, тут надо определиться, а что для Вас - нативный.
Просто 1С-неги часто не пишут свою либу на своем языке.
я думаю он просто дожил до окончания разработки.
интерпретатор JS для того, чтобы на кой-то хрен (совершенно непонятный) отрендерить какую-то область, чтобы выдрать оттуда какой-нить innerHTML.
да, а я 2 года занимался фигней. и одна большая фирма платила очень много денег другой фирме за распарсенные данные. более того знакомый старший Java разработчик из Сбера сказал, что задача вполне себе обычная и рабочая.
наверное он был неправ.
Но если имеют - да флаг им в руки, ибо высосанный из пальца пример нафиг не нужен в реальной разработке, и делать парсинг через какие-то клики - это попытка запилить что-то, совершенно не понимая, зачем это нужно и как это делать правильно.
естественно, JavaScript на сайтах не нужен, ведь они не защищаются от парсинга.
я бы посмотрел на безумца, способного на это.
https://infostart.ru/1c/articles/1096524/ - вот тут на "Перфоленте", языке, основанном на синтаксисе 1С. Есть и на самой 1С - погуглите.
да, а я 2 года занимался фигней. и одна большая фирма платила очень много денег другой фирме за распарсенные данные. более того знакомый старший Java разработчик из Сбера сказал, что задача вполне себе обычная и рабочая.наверное он был неправ.
https://habr.com/ru/post/656575/ - ну как бы, это. Надеюсь сумеете понять, почему статье влепили столько минусов. Думаю, что если бы Ваш друг со сбера что-то такое написал бы на хабре, то тоже бы огреб.
естественно, JavaScript на сайтах не нужен, ведь они не защищаются от парсинга
Сайты сами где-то эти данные берут. Вот я привел ссылку на статью по парсингу "защищенного от парсинга" сайта. Да, там клиентский рендеринг, который получает фактически данные в HTML с сервера в виде JSON-контейнера, и это, в общем-то, легко парсится. И есть целые конторы, которые только и занимаются, что парсят сайты. И реальная защита - это вообще генерация картинки, которую ты с джавой не спарсишь, а у всяких там OCR просто не хватит разрешения, чтобы прилично это распознать. Остальное - это игры сервера и клиента. Но сейчас многое вообще уходит на site-side-рендеринг, т.к. клиент не хочет ждать, в итоге он получает готовый фрейм, а не оболочку для одностраничника, динамически подгружающего данные.
В общем в части парсинга в 99% случаев не нужен этот вот клиентский кликер в виртуальном контейнере ДОМ-а, в остальном 1% случаев уже готовых решений овер дофига и изобретать велосипед нафиг не надо. И с 1С тут никаких проблем - она может дернуть локальный сервис, написанный на чем угодно, чтобы получить требуемое. И если проще написать это на питоне, то зачем это делать на 1С при разворачивании того же питона одной кнопкой на каком-нить аналоге хироку...
https://infostart.ru/1c/articles/1096524/ - вот тут на "Перфоленте", языке, основанном на синтаксисе 1С. Есть и на самой 1С - погуглите.
сдуру можно и металлические шарики разбить, последний комментарий - 2019, ну что ж актуальненько.
https://habr.com/ru/post/656575/ - ну как бы, это. Надеюсь сумеете понять, почему статье влепили столько минусов. Думаю, что если бы Ваш друг со сбера что-то такое написал бы на хабре, то тоже бы огреб.
это не парсер, это что-то вроде читалки XML
Сайты сами где-то эти данные берут. Вот я привел ссылку на статью по парсингу "защищенного от парсинга" сайта. Да, там клиентский рендеринг, который получает фактически данные в HTML с сервера в виде JSON-контейнера, и это, в общем-то, легко парсится. И есть целые конторы, которые только и занимаются, что парсят сайты. И реальная защита - это вообще генерация картинки, которую ты с джавой не спарсишь, а у всяких там OCR просто не хватит разрешения, чтобы прилично это распознать
это написано в книжке известной тетенький про современный скрапинг сайтов на Питоне, типа легче API выпросить, но не все сайты готовы делиться информацией.
капчу обходят через распознание звукового файлика, который можно выбрать для прослушивания.
OCR не справится с гуглокапчей второй версии.
В общем в части парсинга в 99% случаев не нужен этот вот клиентский кликер в виртуальном контейнере ДОМ-а, в остальном 1% случаев уже готовых решений овер дофига и изобретать велосипед нафиг не надо.
как я и сказал, средствами платформы без внешних компонент никак.
средствами платформы без внешних компонент никак
Даже RTX средствами платформы как, так что не о том речь. Вряд ли кто на чистом питоне будет писать ML, т.к. есть написанные на С/С++ либы типа pyTorch, Numpy, Pandas, e.t.c... И никому не придет в голову говорить, что на питоне вот нифига нельзя "без внешних компонент".
Ну ООП - это инкапсуляция, наследование и полиморфизм. В 1С нет только наследования, иекапсуляция - это директива Экспорт, полиморфизм - это отсутствие строгой типизации. С наследованием тоже можно что-то вымутить, хотя документы и прочие объекты и так наследуются от базового типа - считай, "прототипа".
По поводу медленности - да, он офигенно медленный. Пример - битовая матрица недействительных паспортов строится 50 сек на С, на 1С - уже 8 минут. На питоне и прочем не пробовал, но фиббоначи на 1С считается в 4 раза дольше, хотя функции рпьоты со строками не сильно медленнее, чем на PHP, хотя пыха сильно быстрее питона..
полиморфизм - это отсутствие строгой типизации
В случае ООП, полиморфизм это другое
Да, и что же это?
Параметрический полиморфизм является истинным, т.к. подразумевает исполнение одного и того же кода для всех допустимых типов аргументов, а ad-hoc-полиморфизм — мнимым, т.к. представляет собой обеспечение косметической однородности потенциально разного исполнимого кода для каждого конкретного типа аргумента
Пример: если в 1С добавить в массив сто разных документов, то для каждого из них вообще не парясь можно вызвать Записать(). А что Вы понимаете под словом "полиморфизм"?
Параметрический полиморфизм, цитату о котором вы приводите, это действительно выполнение функции с аргументами разного типа. Но это никак не связано с ООП, о котором вы пишете в комментарии о том что в 1с для ООП не хватает только наследования.
Следуя вашему определению полиморфизма как возможности выполнять один и тот же код для разных аргументов, то вот такой код:
template<class A>
A add(A a, A b) {
return a + b;
}является его примером? Он скомпилируется и выполнится для любого типа, который определяет оператор +. Но дело тут не в ООП.
Полиморфизм в ООП это про то что у вас при сохранении сигнатуры метода возможно его разное поведение. Это обычно достигается за счёт наследования, а именно того что наследник переопределяет методы родителя. И что, вероятно, важнее -- это то что класс-родитель может обращаться к этим методам и менять свое поведение.
И кстати, наследование почти всегда можно заменить композицией. Заменить нельзя как раз когда нам нужен полиморфизм.
Ну а что классически было полиморфизмом? Вот у вас есть базовый класс, вот у него есть виртуальный метод, вот у наследников этот виртуальный метод переопределен, вот у нас переменная базового класса, вот мы кладем в нее адрес производного класса, вызываем виртуальный метод и видим поведение производного класса, а не базового. Или что конкретно Вы понимаете под полиморфизмом? Для языков без строгой типизации это вообще бессмысленно, т.к. вызывая метод класса (записи документа с проведением) мы получаем именно проведение того объекта, для которого вызван этот метод. Никаких приведений типов...
На встроенном языке 1С можно написать что угодно
Увы, нельзя. Сам язык не так уж плох, там есть все необходимое. Но:
Он безумно медленный.
Нет ООП.
Если на второй пункт можно возразить "пишите в процедурном стиле", то первый поставит крест на любых начинаниях изобразить что-то посложнее. Кстати, тут, на хабре, был представитель 1С, и ему задавали вопрос об ускорении языка (может, даже я). Он ответил примерно так - "пока не планируем этим заниматься, так как быстродействие языка не является узким местом".
Ни медленность ни отсутствие ООП не являются причинами по которым на языке нельзя что-то написать. Это вопрос удобства/не удобства написания и выполнения, а не тьюринг-полноты.
задача может решаться очень долго, но если она в итоге была решена, то это значит что на языке её можно решить.
Сам язык не так плох. В нем, например, сильная типизация, в отличие, скажем, от PHP. Писать на нем вполне можно.
Выше речь шла о парсере - такие вещи писать вполне можно, и достаточно комфортно. По крайней мере, тут нет какого-то драматического разрыва от других языков подобного типа, скажем питона. Но применить это для серьезных задач будет, увы, нельзя.
Но применить это для серьезных задач будет, увы, нельзя.
Это другой вопрос. Вы говорите, что из-за того что там нет ООП и он медленный, на нём нельзя написать что-то. Теперь вы говорите, что написать можно, но применять написанное для серьезных задач будет нельзя. Как вы понимаете, это разные вещи.
Да, не точно выразился. Написать можно. Практической ценности это иметь не будет.
Вообще, у 1С такая идеология: "На встроенном языке пишем только прикладную логику. А все остальное, все, что обычно живет в библиотеках, мы встроим в платформу."
Хорошо ли это, плохо ли - можно спорить, но подход сейчас именно такой.
Уточню. Будет практическая ценность или нет зависит от многих факторов. И для чего-то сложного обычно ответ отрицательный.
Но бывает и по другому. Парсер JSON для конкретной задачи я на 1С писал. Давно, лет 10 назад, что бы подключить какой-то ресторанный POS. Проект успешно запустили. Но тут, во первых, требования к быстродействию низкие, а во вторых, парсер JSON пишется за несколько часов. Не универсальный, а что бы он понял данный конкретный обмен. А через год-другой 1С уже встроила этот функционал в платформу.
В 1с сильная типизация? Даже не смешно
Да, во встроенном языке 1С сильная типизация. Там почти нет неявных преобразований типов. И это хорошо.
Если не совсем понимаете, о чем речь, то информацию можно найти и на хабре: https://habr.com/ru/post/161205/
Ну да, пишем:
МойДокумент.Контрагент = Склад;
И всё работает несмотря на разные типы. Просто 1с приведет значение справочника склады к справочнику контрагентов и присвоит пустую ссылку.
С ссылками да, косяк. Ну давайте назовем "средней" типизацией )
Но она не слабая, это точно. Что такое слабая типизация можно понять, написав что-то на PHP. Там преобразовывается все что угодно во что угодно. Причем получившийся результат с непривычки сильно удивляет...
Один коллега ушел с 1С. После некоторого времени на PHP сказал, что изменил свое мнение относительно языка 1С, и это не самый худший язык))
Сейчас пишет на джаве.
Сейчас пишет на джаве.
ему в питон надо сходить, после джавы паника будет по началу
Джава ему понравилась :)
А я на джаву не смотрю. Мне нравится питон за офигительный комфорт и скорость разработки.
И так же нравятся языки, которые позволяют получать быстрый нативный процессорный код. Есть очень древний опыт на C++, но сейчас посматриваю в сторону раста, хотя еще не написал на нем ни строчки.
Нативным методом ни кто не может. Питон использует стороннюю библиотеку, ещё и написанную не на питоне. Так же и с другими языками. Я не знаю такого языка, где из коробки есть парсинг сайтов и тем более с выполнением js кода перед парсингом.
Зачем его рендерить? ВСкройте его апи и получайте даж структурированные данные.
ИМХО 1С - это среда разработки с ориентированием на работу с сущностями в разрезах периодов. Идеально для бухгалтерии, отчетности и т. п. То есть этот функционал уже готов и его не надо пилить отдельно. Ну и плюсом типовые конфы обновляются в соответствии с ветренным законодательством РФ. Всё остальное - жуткие минусы. От негибкости языка, до платности всего и вся. Шаг в сторону - только на костылях. Ну и сколько щас пустая конфа весит? Гигабайт?
Лет 10 назад, когда пустая конфа УТ весила около 600 метров, я решил поставить SAP, чтобы посмотреть, что это за зверь такой. Что конкретно ставил уже не помню, что-то типа CRM/HR, помню только, что ставилось около 9 часов и пустая "конфа" весила 32 Гб.
1С УТ на том же железа ставилась мин 4-6, весила пустая конфа около 600 метров. Ну так, для сравнения.
дело не в весе конфы, а в одних и тех же технологиях и 5 конфигурациях, в рамках которых живет среднестатистический 1С-программист.
Все же интересно было бы увидеть такой же разбор по SAP. Я участвовал в нескольких проектах (со стороны заказчика), там некоторые разработчики тоже очень похожие вещи рассказывали про архитектуру:
- много оберток
- разные модули писали в разное время разные команды, иногда даже названия одних и тех же сущностей в UI/UX не совпадают
- есть отдельная каста "писателей на ABAP" - специальном языке для SAP
1C занимает небольшую нишу постсоветского пространства, что накладывает ограничения на размер коммюнити. 1С долго развивался без крупных конкурентов, что допускает наличие неудобных вещей (а ты походи по рынку, поищи за такую же цену).
Ну да, без крупных конкурентов... Это вы пошутили. САП, Аксапта, Навик, Галактика, Парус.. имя им было легион.
Кажется, вы сами себе немного противоречите. Раз вы сами пишете, что 1С перераспределил рынок и выдавил из него остальных, значит он с ними конкурировал и смог подвинуть. Насчёт монопольного, кажется вы преувеличиваете. Маркет-шейр 1С всё это время не переваливал за 40% (максимум), если верить отчётам уважаемых фирм.
А что плохого в сегменитировании? Для "ларёчников" как было, так и осталось - 3000₽ за бухгалтерию. Вы считаете, что функционал для корпораций уровня "Газпрома" должен стоить копейку? а почему САП тогда такой дорогой?
Вы немножко неправильно поняли мою фразу: я имел в виду что 1С сначала выдавил конкурентов, а потом занялся перераспределением. Если мы ссылаемся на один и тот же источник отчетов, то лет 10 назад доля 1С доходила до 90% (максимум). Сейчас, да, цифра колеблется в районе 40%.
Я ничего не имею против сегментирования. Более того, я категорически против автоматизации учета "Сушевни на раёне" при помощи условного SAP HANA, а ПАО "НЛМК" (спасибо им за интереснейшие статьи!) – при помощи "Бухгалтерия Предприятия. Базовая версия". Главный аргумент 1Сников в борьбе с конкурентами был "Посмотрите сколько стоят лицензии и поддержка SAP ("Галактики") и сравните с нами". А вот после выдавливания конкурентов, ценник от 1С пошел вверх. Причем в разы. Повторюсь еще раз: на текущий момент стоимость лицензий и поддержки решений 1С для крупного бизнеса сейчас сравнялась с ценами на ту же "Галактику ERP". Только вот технологический базис (читай платформа) остался на прежнем уровне.
Наверное, вы имеете ввиду ограничение 99999 строк в табличной части объекта. А что плохого в этом ограничении? Вы когда-нибудь видели, скажем, товарную накладную, где бы потребовалось больше строк?
На количество данных в самих таблицах никаких ограничений нет.
Понимаю, тут принято ругать 1С. Но я все же за объективность.
А что плохого в этом ограничении?
На количество данных в самих таблицах никаких ограничений нет.
Кажется что Вы противоречите сами себе. Вообще-то "Количество данных" = "Количество строк". И да. Ограничение касается не только табличных частей объектов, таблиц значений, массивов и т.п., но и таблиц движений регистров, т.е. один документ не сможет сделать более 99999 записей в учетный регистр.
У упомянутых выше организаций количество основных средств может превысить сотню тысяч. Теперь представьте себе во что выливается регламентная операция расчета бухгалтерской и налоговой амортизации?
Или еще пример с "Инфостарта" как на одном заводе уперлись в это ограничение при расчете зарплаты. Разделение расчета по подразделениям не спасало ситуацию. На этом заводе работает 1500-2000 сотрудников. В "Мосгортрансе" – около 30000. И меня терзают смутные сомнения, что в "Мосгортрансе" оплата труда сводится только к "Оплата по окладу" и "Премия" (уверен что там у сотрудника не менее десятка начислений в месяц).
Вы когда-нибудь видели, скажем, товарную накладную, где бы потребовалось больше строк?
Накладную не видел. А вот прайс-лист на 120000 позиций – да. Впрочем такую накладную я могу представить: коносамент с сопроводительной ведомостью морского контейнеровоза.
Ну да, с накладной я погорячился. Ситуаций, когда возникает желание запихнуть в документ более 100К строк может быть много.
Но это ограничение, не потому что злобный 1С решил сделать пакость пользователям или чего-то не понимает. Оно происходит из устройств этих объектов.
Табличная часть документа грузится в память по малейшему чиху. Всегда, когда есть обращение к объекту.
Насчет движений - то же самое. Набор записей движения документа читается и записывается целиком через память.
То есть, проблема в том, что типовые объекты не подходят для таких ситуаций. И решения хорошего нет, приходятся извращаться. Может, со временем что-то придумают, сделают новые объекты для таких ситуаций. Может, нет. Но ограничение это точно не уберут. Могут лишь немного увеличить с ростом ресурсов компьютеров. Хотя я бы не стал.
С накладными (реализация товаров, услуг) с более чем 100 тыс. строк я имею дело. Ведь помимо купи-продай, есть производство, сфера услуг, а более глубокая детализация позволяет лучше анализировать. Другое дело, что клиенту не выдается "простыня" со всеми позициями. При печати данные группируются и остается в пределах 100-300 строк.
Ограничение в 99 999 строк удивило и я не понял, для чего это сделали. Проблему решил тем, что отказался от использования встроенной табличной части в некоторых документах в 1С. Данные хранятся в отдельной табличке (в терминах 1С это регистр сведений) Задача не тривиальная и не 2 часа работы. Однако решение позволило не только обойти это ограничение но и значительно повысило скорость открытия формы.
Теперь подробней:
Обычно такое поведение присуще ларечникам, которым IT не нужен, или когда автоматизация делается ради галочки, без реальной необходимости. Однако же в стране работают не только ларечники, а есть средний и крупный бизнес, который понимает ценность автоматизации процессов. Там я впервые столкнулся с кондовым отделом бухгалтерии, с тетеньками 50+, у которых программист всегда виноват и в апреле (время сдачи налоговой отчетности) всегда аврал. Соглашусь с Андреем, что дело не в 1С, а в людях, которые работают в типовых конфигурациях. Но почему-то именно в 1С таких заказчиков очень много. 1С – это CRUD для малого и среднего бизнеса, где обычно много табличек. И что бы мне ни говорили 1С-программисты, большая часть их задач лежит в этом заколдованном круге кусочков большой конфигурации. Это либо отчеты, призванные показать руководителю все в одном месте, либо обработки, призванные упростить какую-то хозяйственную операцию, либо отдельная подсистема, чтобы автоматизировать "уникальный бизнес-процесс", либо просто корректировка бизнес-процессов предприятия так, чтобы они ложились в типовую конфигурацию.
Так это и есть ниша 1С. Не у всех есть компаний ресурсы на айти отдел и собственный кастомный продукт. Да оно им и не надо. У них больше забот, связанных с основной деятельностью бизнеса. И очевидно, что в таких компаниях такие люди - не понимают в айти. У них не настроены айтишные процессы и вот это вот все. Зато понимают в логистике/продажах/ремонте/нужное подставить. Таким компаниям нужна стандартная конфигурация, одна-две доработки и несколько кастомных отчетов.
Еще утверждается, что если уйти из 1С в другой стек, ничего не поменяется, всегда будут авралы и не будет никакого удовольствия.
Это действительно так. Дело не в 1С. C#/Java/1C - это инструменты. Но те же самые "ларечиники" без понимания айти и процессов могут выбрать Java.
Что там с IDE?
Мне тоже приходится перезапускать IDE, порой ее глючит, она подвисает и жрет память даже больше чем Chrome.
По прошествии полутора лет могу перечислить, что же изменилось:
Мне показалось, что вас посадили в какую-то ограниченную песочницу. Я когда-то работал в системном интеграторе, с настроенными процессами. Было примерно так же. Сидишь ждешь описание от аналитика, кодишь, тестируешь, исправляешь, комитишь. Когда же я стал вести проекты - все поменялось. Мне и с заказчиком/клиентом надо пообщаться. И саппорт тикет разрулить на третьем уровне поддержки "почему у них там очередная цифра не так считается". И понимать "законы и предметную область", чтобы не натворить дел. Да и кэш приходится порой чистить, да и RESET нажимать. И соглашусь, что многое зависит от работодателя. Я сейчас работаю в небольшой компании, у нас тут нет полтыщи аналитиков/программистов/девопсов. Но знаете... как-то интересней... Свой проект, свое детище.
ORM в 1С – самый лучший. Один из разработчиков пришел к прямому чтению данных 1С из MS SQL. И это работало быстрее, чем платформенный ORM.
Слушайте, но причем тут 1С? Любая ORM работает медленней, чем нативные прямые запросы к БД. И многие программисты, с каким бы инструментом они не работали - приходят к нативным прямым запросам к БД для оптимизации производительности.
Мне понравился класс, приведенный Андреем на слайде. А для какого уровня в приложении этот класс?
Это сущность, отражает структуру таблицы в БД. Поэтому там BankId и Orders. Это для монолитов и маппинга ORM на БД. Да, возможно там не очень хорошо это спроектировано. В микросервисах ордера могут быть отдельно, клиенты отдельно. Но не суть. Технические претензии мне кажутся не обоснованными. Никто не обязывает отдавать заказы вместе с клиентом. Решается на уровне ORM (Fetch/Include) при построении запроса. А fetch = FetchType.LAZY - эта штука имеет неприятные побочные эффекты, начиная с N+1 и заканчивая ошибкой "транзакция/подключение к БД уже закрыто" на момент срабатывания Lazy, а так же проблемами при параллельной обработке/вычислениях.
По итогу - мне показалось у вас стадия гнева и отторжения 1С. В C#/Java/Go тоже много проблем. Видимо вы с ними просто еще не столкнулись.
Так это и есть ниша 1С. Не у всех есть компаний ресурсы на айти отдел и собственный кастомный продукт. Да оно им и не надо. У них больше забот, связанных с основной деятельностью бизнеса. И очевидно, что в таких компаниях такие люди - не понимают в айти. У них не настроены айтишные процессы и вот это вот все. Зато понимают в логистике/продажах/ремонте/нужное подставить. Таким компаниям нужна стандартная конфигурация, одна-две доработки и несколько кастомных отчетов.
согласен, поэтому и ушел туда, где есть потребность в автоматизации и понимание ее ценности.
Это действительно так. Дело не в 1С. C#/Java/1C - это инструменты. Но те же самые "ларечиники" без понимания айти и процессов могут выбрать Java.
да, но как я сказал ларечников в "большом IT" почему-то меньше.
и да, дело в работодателе, надо просто уметь выбирать.
Слушайте, но причем тут 1С? Любая ORM работает медленней, чем нативные прямые запросы к БД. И многие программисты, с каким бы инструментом они не работали - приходят к нативным прямым запросам к БД для оптимизации производительности.
при том, что в оригинальной статье утверждается, что ORM в 1С - лучшая.
моя статья построена на сравнении с оригинальной статьей @EvilBeaver
предлагаю Вам с ней ознакомиться.
Реляционные базы данных имеют свой язык запросов, декларативный, построенный на реляционной алгебре — SQL, они заточены под этот язык, язык заточен под структуру этих баз данных. Поэтому естественным образом, если мы используем ORM, который являет собой довольно убогий язык, не позволяющий реализовать всю мощь SQL, мы получаем просадки производительности.
Представьте, что мы используем C без интринсиков на современном микропроцессоре. Естественно, что мы не сможем и близко подступиться к возможностям этого ЦП. И придётся делать ассемблерные вставки.
Это сущность, отражает структуру таблицы в БД. Поэтому там BankId и Orders. Это для монолитов и маппинга ORM на БД. Да, возможно там не очень хорошо это спроектировано. В микросервисах ордера могут быть отдельно, клиенты отдельно. Но не суть. Технические претензии мне кажутся не обоснованными. Никто не обязывает отдавать заказы вместе с клиентом. Решается на уровне ORM (Fetch/Include) при построении запроса. А fetch = FetchType.LAZY - эта штука имеет неприятные побочные эффекты, начиная с N+1 и заканчивая ошибкой "транзакция/подключение к БД уже закрыто" на момент срабатывания Lazy, а так же проблемами при параллельной обработке/вычислениях.
согласен, не учел.
По итогу - мне показалось у вас стадия гнева и отторжения 1С. В C#/Java/Go тоже много проблем. Видимо вы с ними просто еще не столкнулись.
не разбираюсь в стадиях, ибо не психиатр.
я не говорил, что в других ЯП нет проблем, я просто подсветил некоторые недостатки платформы и типовых решений 1С.
У меня возникло ощущение, что вы сравниваете довольно обособленную нишу 1С со всей остальной экосистемой.
То есть, разрешая "настоящим программистам в настоящем мире" писать компиляторы на Haskell, низкоуровневый код на C, бизнес код на Java, расчётный на Fortran, а детский — на Scratch. Естественно, 1C с остальным миром конкурировать не может, и выглядит бледно.
Хотя если мы попробуем писать компиляторы на С, низкоуровневый low-latency код на Java, компиляторы на Scratch, а детей заставим учиться на FORTRAN 66, тоже ничего хорошего не выйдет.
Хотя если мы попробуем писать компиляторы на С
GCC вам передает привет.
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Я всего лишь отвечаю на тезисы оригинальной статьи, в которой как раз 1С сравнивается с другими ЯП общего назначения не в пользу последних. Вы видимо не читали оригинальную статью просто.
И еще немного из опыта. Была задача автоматизировать процессы в малом бизнесе - компания выращивала и продавала растения для ландшафтов (ну там в частном доме посадить цветочки, деревья, чтобы красиво было).
С одной стороны им нужен был стандартный бух и управленческий учет. С другой - сайт-лендинг пейдж и мобильное приложение-каталог-корзина. Ходишь по территории со своим смартфоном, сканишь QR коды на горшках и добавляешь к себе в корзину. На кассе оплачиваешь.
Так и какое решение? Писать с нуля аналог 1С? Чтобы вести склад, приход, выдачу, оплату с банковских карт, да? И сколько бы лет и денег на это ушло?
В итоге сайт, бэк-енд и мобилку написали на C# / Flutter. А вот для учета внедрили одну из стандартных 1С конфигураций. Плюс отдельно реализовали синхронизацию каталога товаров из 1С в бэк-енд для мобилки.
я не говорил, что 1С - какашка, я подчеркнул несколько раз ее достоинства.
ЯП выбирается исходя из поставленной задачи, все правильно.
Взять хотя бы реализацию регулярных выражений в платформе – в других ЯП
процессор регулярок представляет из себя отдельный класс, в котором
определены методы для обработки строк. Видимо, 1С-программисты не
достойны ничего, кроме трех куцых функций.
Я не в теме про 1С, но зачем нужен класс, если можно обойтись тремя функциями? Например, в POSIX regex их четыре, но вполне можно было прожить и без regerror(), и возвращать ошибку сразу. И ведь отлично все работает.
Я просто к тому, что это так себе аргумент.
Вся статья написана на сравнении 1С и "нормальных" языков программирования общего назначения. Это принципиальная ошибка. 1С - это довольно узко-специализированная среда со своей сферой применения. Как-то только начать жить в этой парадигме - лишние (но не все) претензии к 1С отваливаются.
все правильно, данная статья строится на тезисах из оригинальной статьи.
но 1С-программисты и их поле боля сравниваются с "взрослым IT", поэтому тут нестыковочка.
Вот именно. 1С - это не язык программирования общего назначения, 1С - это платформа для конфигурирования бизнес-приложений, приложений учета чего-либо. Ей и не надо уметь многое из того, что автор понаписал. С другой стороны, простейшую конфигурацию по учету остатков товаров можно накидать за пару дней, при этом там будет нормальный UI, возможность запускаться как локально так и в клиент-серверном варианте, а так же через браузер. Ни на каком другом ЯП ни с каким фреймворком такого результата достичь не получится: а) быстро, б) качественно и в) дешево. И эта конфигурация еще и будет супер поддерживаемая и расширяемая.
Типовые конфигурации — согласен. Переусложнены, с огромным уровнем абстракций(хотя какие многоуровневые абстракции в системе которая изначально задумана ориентированной на предметную область). В большинстве своем это «раздутая бухгалтерия» либо выросшие из неё решения с кучей всяких свистелок. Плата за универсальность, «хотели как лучше, вышло как всегда».
Платформа — очень удобная штука для своего перечня задач. Позволяет писать свои кастомные решения, при том довольно быстрые(говнокодинг не отменяется, им можно повесить все). Проблемы начинаются, когда на ней пытаются делать вещи, для которых она не предназначена. Типа как писать игры на Java. Писать можно, но разве что Just for fun.
Менеджмент и бизнес — не техническая деталь, му**ки могут попасться везде. Где то больше, где то меньше.
Автор, вы просто переросли себя как разработчика на платформе 1с. И как правильно заметили, что бы развиваться как специалист, необходимо знать и уметь в несколько технологий. Что бы было что сравнивать.
*p.s. Если слышите 1с ERP(поставить название любой конфигурации) — «лучшая в мире система» — значит этот человек пообщался с менеджером-продажником от франчайзи. Но такие-же фразы я слышал и от продажников других CRM.
Голос разума, который вряд-ли будет услышан
Большинство подобных статей можно разделить на три части. Боль от типовых конфигураций, боль от платформы и боль от менеджмента и бизнеса.
Типовые конфигурации — согласен. Переусложнены, с огромным уровнем абстракций(хотя какие многоуровневые абстракции в системе которая изначально задумана ориентированной на предметную область). В большинстве своем это «раздутая бухгалтерия» либо выросшие из неё решения с кучей всяких свистелок. Плата за универсальность, «хотели как лучше, вышло как всегда».
согласен
Платформа — очень удобная штука для своего перечня задач. Позволяет писать свои кастомные решения, при том довольно быстрые(говнокодинг не отменяется, им можно повесить все). Проблемы начинаются, когда на ней пытаются делать вещи, для которых она не предназначена. Типа как писать игры на Java. Писать можно, но разве что Just for fun.
Менеджмент и бизнес — не техническая деталь, му**ки могут попасться везде. Где то больше, где то меньше.
Автор, вы просто переросли себя как разработчика на платформе 1с. И как правильно заметили, что бы развиваться как специалист, необходимо знать и уметь в несколько технологий. Что бы было что сравнивать.
согласен полностью, я не говорил, что не в 1С не могут попасться люди с особенностями в руководстве.
Автор, вы просто переросли себя как разработчика на платформе 1с. И как правильно заметили, что бы развиваться как специалист, необходимо знать и уметь в несколько технологий. Что бы было что сравнивать.
да, и тут Вы правы.
1 С не ERP-cистема. Неужели у нас поголовно безграмотные спецы ИТ.
В смысле перерос? Надо было реализовать MCTS или генетический алгоритм, а 1С не дала? Дерево решений переобучилось, а он этого не заметил из-за особенностей платформы? Или он выбрал неверный алгоритм генерации случайных чисел, напортачил с GLC, seed не тот поставил и у него нейронка чудит?
Что конкретно пошло не так в этой высокой сфере? Может всем пора бежать в Rust?
Платформа — очень удобная штука для своего перечня задач. Позволяет писать свои кастомные решения, при том довольно быстрые(говнокодинг не отменяется, им можно повесить все). Проблемы начинаются, когда на ней пытаются делать вещи, для которых она не предназначена. Типа как писать игры на Java. Писать можно, но разве что Just for fun.
Фреймворк для своих задач отличный. Рантайм — ну тут уже такое. Язык — полный уг для решения любых задач, даже несмотря на все возможности фреймворка.
Менеджмент и бизнес — не техническая деталь, му**ки могут попасться везде. Где то больше, где то меньше.
В 1с их больше просто из за специфики. Малый и средний бизнес, айти отделы всяких там производственных предприятий… В общем очень такое себе. Продуктовых компаний очень мало, да и там часто не разработкой продукта занимаются, а внедрением его под заказчиков. Потому мой выбор — нативная андроид разработка.
Помню, как 1C-ники пинали товарища за статью с недостатками 1С, потому что у него не было опыта разработки на 1С, а он в общем-то джавист. И там действительно многое было упущено из-за этого. А эта статья хорошо ее дополняет, так как тут уже взгляд человека, наоборот, с большим опытом именно в 1С.
Что можно, а что нельзя на 1С
Читая эту главу, на ум пришла легендарная статья Спольски про протекающие абстракции.
В статье дан заголовок "Почему уходят из 1С". В принципе, дать короткий ответ у автора не получилось. Очень много текста, поданного сквозь призму личных переживаний, личных горестей от знакомства с платформой.
Я попытаюсь коротко ответить на вопрос статьи, для тех, кто за столь обширным текстом не смог уловить сути. Этот же ответ подходит и на другой вопрос "Почему не идут в 1С".
После декабря 2014 г., разработчики на других языках/платформах, стали для внешнего рынка по стоимости разработчиков из азий и индий. В связи с этим возникает вопрос - зачем студенту 1С сейчас идти разрабатывать на 1С, если можно пилить на забугорье на модном-молодежном за деньги, порой даже большие, чем на старте в 1С? Какова должна быть его мотивация? Ровно тот же самый тезис относится и к разработчику 1С со стажем - смысл пыхтеть и находиться в ситуациях, которых находился и автор, отбиваться от тёть Галь-бухгалтера с одной сторой, Иванычей со склада, с другой, еще успевать и в код, и в новые архитектуры, при это деньги за все эти муки предлагают такие, которые итак предлагают со старта Белые господа на других платформах/языках? Заливаем сверху все это соусом "а ведь с другим языком/платформой можно и тракторок завести", и получаем на выходе классическое неудовлетворение как от решения - войти в 1С, так и от решения - остаться в 1С. А 1сники то ребята не глупые, читают и Хабр в том числе. Один парень из Техасса рассказал свою историю успеха, другой из Германии, третий - из Австралии. Причем истории таки - вот я сидел тут по месту писал не на 1С, а потом - блин! Да я могу также писать но уже по другому рейту, в другой стране. Рас рас - и вот я уже там, вот моя статья, вот моя тележка, подписывайтесь! Повторюсь, 1сник - не дурачок, он все читает, читает, тёть Мани его каждый день прессуют-прессуют, у Иванычей какие-то сканеры не сканят, фуры стоят на погрузке/разгрузе, Ген/Фин/Хрен-дир присовывает ему, присовывает по жалобам от подчиненных. И так идут годы. Вы просто представьте мета-физичную чернь, которая разрастается в голове у бедолаги 1Сника? Какой-то парень сходил на курсы по фулл-стак разработке под мобилку или веб, и уже через год, сидит в Мюнхене, пьет баварское и передает пламенный привет нашему герою, который и в предметку, и в налоги, и хреноги, и в код, и в челночную дипломатию, и даже в админство (ну а кто принтер то подключит Алевтине Никалавне?) - а получает за это зарплату индсуса работающего по среднему рейту с условного фриланса? В какой-то момент, эта вся это неудовлетворенность прорывается, как гной, наружу и матерый/старый 1сник уходит в закат в условные Java/С#/PHP/о_0 - проходит некоторое время, и если у него всего получилось, то мы читаем статейку на хабре "Почему уходят из 1С".
Вот поэтому и уходят - уровень затрачиваемых усилий не соответствует уровню материального вознаграждения как минимум. Т.е. самое первое, с чего червяк в мозгах, начинает свою деятельность - да, почему блин, чел на мобилке-вебе-кровавом буржуйском интепрайзе, зарабатывает существенно больше, чем я? Потом, под этот базис, начинается подтяжка всей технической неудовлетворенностью уже самой платформой, конфигурацией и т.д., потом подтягивается и некая уже "фасадная" часть - у ребят на "другом" веселье, конференции, выступления и все такое, а у нас - эээммм, партнерская конференция раз в год, да подобное мероприятие от инфостарта, раз в год тоже? И вот все это парится там в голове, парится. И в конце концов, находит свой логический выход в виде "Да пошли вы все на ..ер - я сваливаю".
И кстати, пока я не видел тут историй о том от тех, кто свалил с 1С и потом раскаялся в этом. Обычно все получается.
Так что ребят, если все мною вышеописанное про вас и вы сейчас варитесь на какой стадии - не держите этот пар в себе. Возможно, и правда пора. Я думаю, что лучше пожалеть о сделанном, ведь вернутся никогда не поздно, чем годами жить в такой адской неудовлетворенности ни от денег, ни от своей работы, ни в принципе - ни от чего. Наша работа - это б0льшая часть нашей жизни, если вас условная "разработка на 1С" заколебала до такой степени, что вы уже и света белого не видите - попробуйте что-то другое. Не понравится - вернетесь.
В статье дан заголовок "Почему уходят из 1С". В принципе, дать короткий ответ у автора не получилось. Очень много текста, поданного сквозь призму личных переживаний, личных горестей от знакомства с платформой.
а разве в аннотации к статье я не написал, что это ответка на другую статью? и да, без личных переживаний сложно, если ты потратил столько лет жизни на что-то. это нормально.
Я попытаюсь коротко ответить на вопрос статьи, для тех, кто за столь обширным текстом не смог уловить сути. Этот же ответ подходит и на другой вопрос "Почему не идут в 1С".
коротко и без эмоций не очень получилось. но я согласен с Вами.
Какой-то парень сходил на курсы по фулл-стак разработке под мобилку или веб, и уже через год, сидит в Мюнхене, пьет баварское и передает пламенный привет нашему герою
я могу и ошибаться, но 1 года недостаточно для full-stack
Обычно все получается.
не всегда, пару месяцев назад собеседовал 1Сницу на позицию middle backend developer.
у нее нет знаний большого IT, пришлось отказать.
Приветствую, подскажите, пожалуйста, в чем у неё явно были провалы? Какое у неё образование было? Профильное? Сам изучаю дорожную карту, чтобы переметнуться из 1С в Golang, Вузовские академические знание остались (закончил магистратуру по прикладной информатике) сейчас смотрю с чего начать, что изучить перед непосредственном изучение языка.
Заранее спасибо.
Для работы с 1С знания только его языка недостаточно (только если чисто кодировщиком по готовымТЗ).
Нужно ещё понимать и предметную область - т.е. бух. учёт, управленческий учёт, торговые / производственные операции, в целом понимать бизнес процессы организаций.
Образование профильное, но давно полученное.
Провалы по работе с Linux, не знала про Kubernetes, микросервисную архитектуру, заминалась на простых вопросах, а ля разнице между TCP и UDP, разнице между HTTP 1.1 и HTTP 2.0.
Про профилировщик Golang плохо ответила.
Какие-то знания теоретические все же есть, но как только давали задание на практику - плавала, даже в примитивах Golang.
SQL запрос оптимизировала плохо, несмотря на мои подсказки.
На джуна Golang не прошла, хотя на своей основной работе - старший разработчик 1С. Да и брать джуна в 35 лет - такое себе.
я конечно на собес как сеньор ходил, и реакция интервьюверов на то что я знаю ответы на озвученные вами вопросы вызывала крайне бурную одобрительную реакцию в плане 'ого, вы это знаете. это ооочень хорошо!!' и по факту многие миддлы, практически все, не знают sql, про tcp я вообще молчу, тут дай бог сеньор знает
может я в таких конторах работал, но я работал и в известных компаниях в т.ч. забугорных (не faang конечно, но всеже)
Да и брать джуна в 35 лет — такое себе.
ну вот, ейджизм, ну как так? со мной работал коллега, он в 38 лет ушел из военки в ИТ с нуля на питон, сейчас один из лучших программеров миддлов с которыми я сталкивался
Ходил как-то на собес, меня там спросили про нормальные формы, я ответил, что их вроде как шесть. Поправили. Потом спросили, а что они значат. Я в общем и целом рассказал, тоже немного поправили. А потом я спросил о том, много вообще народу рассказало про нормальные формы хоть что-то. Сказали, что я первый. Вот как-то так...
И ждать от миддла программиста что он будет знать основы tcp/ip, сети и хитросплетения протоколов, а уж темболее сисадминские знания линукса (ща работаю в конторе где половина прогов на винде сидят, питонисты) — это только лишь плюс, а не обязательные требования
я вот разве что знания sql записал в обязаловку (хотя практика показывает, народ его нифига не знает, и если человек в состоянии написать селект с двумя разными джойнами — это уже зачет)
а миддл — это тот кто прям откровенный бред не пишет в коде, типа селектнуть две выборки в базе через .all() в orm, а потом средствами языка сравнивать значения… ну типа 'а че такова, я так учился'
я и не от каждого сеньора готов таких знаний ждать кстати (несмотря на то что это все знаю) просто потому что такие люди тоже редкость
Человек открыл себе, что программирование - это не только правка форм и настройка принтера, от всей души поздравляю! То, что я всегда требовал от 1С программистов и повально не находил – уметь оценивать сложность алгоритмов и знание запросов СУБД. Без этого код на 1С часто поражал мое воображение, а народ считал, что и так сойдет.
Разрабатывать продукт – это конечно интереснее, чем его обслуживать или допиливать на внедрении. И это будет на любом языке программирования, на любом фреймворке (кстати, кто-то еще веб-системы и бек-енд без фреймворков разрабатывает?)
Мне что интересно, в свое время все учили сначала ассемблер, потом С, потом С++ (я лично так осваивал программирование). И никогда не стоял предел числа изучаемых языков программирования. Сейчас народ гордо хвастается, что знает 2 языка программирования. А если потребуется освоить еще 2 языка? Еще 5? 1С осваивается за неделю, Питон за пару недель. Да, на джаву наверное меньше месяца закладывать не надо. Всё хорошо для своего применения, и если человек не готов за несколько недель освоить новый язык, который подходит лучше для прикладной задачи, это что, называется специалист по программированию? Ну вместо 1С будет Java, тот же станок только ручки хромированные. И что до пенсии ничем другим не заниматься? Какие то скучноватые перспективы. Кругозора много не бывает, и знать 1С как средство БЫСТРОЙ разработки бизнес приложений, мне кажется, очень полезно.
Никто не вернется к работе на первой линии, а это та линия, где общаются с тётями и дядями по поводу копейки в балансе.
Вы представьте программиста, который общается с пользователями и пишет на С++ или даже C#, вот у кого жизнь летит под откос.
Просто не надо молотком забивать шурупы, а отвёрткой забивать гвозди.
1C код я видел только на картинке, и если верить той картинке, программа пишется на кириллице (или я не прав?). Отсюда вопрос, а это вообще реально использовать для разработки 1С скриптов что-нибудь из популярных ИДЕ/редакторов типа VS Code, emacs, Sublime? Это же с ума сойдёшь на каждый хоткей раскладку переключать
И да, то что там кириллица, это минимальная проблема, очень быстро привыкаешь.
прямо причем в том-же файле.
написать всю функцию на английском.
и вызвать ее.
единственно что названия полей в справочниках и документах все равно будут на русском.
Можно писать на английском
По правде можно писать и на латинице.
Есть отдельные конфы на ней.
Кириллица традиционно используется, потому что 99% документации на ней.
А где это у нас хоткеи зависят от раскладки? Можно списочек этих криворуких мудаков?
Если очень хочется, то использовать кастомный редактор кода возможно, но нужны качественные танцы с бубном. Из-за этого 99,9% 1С-ников используют только конфигуратор. Хотя у VScode, например, есть нужные плагины для языка 1С.
Да, можно выгрузить все в XML файлы и редактировать их в VSCode. Формы правда руками придется править, хотя может быть плагин придумали уже. Результат работы загружать в конфигуратор уже. Вот если бы изначально вендор сделал хранение конфигурации в виде списка XML файлов, а в файл или табличку в базе собирал при некой компиляции, то конечно были бы трудности с преобразованием в один некий исполняемый аналог jar файла, но не было бы этих приседаний с загрузкой XML в конфигуратор. Да и git прикрутить было бы легче.
то конечно были бы трудности с преобразованием в один некий исполняемый аналог jar
но не было бы этих приседаний с загрузкой XML в конфигуратор
Вы не видите, что это одно и то же? просто конфигуратор позволяет править код прямо внутри типа jar а. Ну или точнее как там бандл для jscript называется? так как внутри все таки исходники.
А EDT работает уже так, как вы хотите. Все в распакованном виде и только при попытке запустить вызывается тот же конфигуратор, который собирает из кучи файлов аналог jar.
Ну так давайте свое организуем. Возьмем, например linq2db как ORM и blazor как UI и построим свой фреймворк аналог 1С
А вы будете свой аналог 1С в таком же темпе обновлять вслед за бешенным темпом изменения нормативки, налоговой и прочее-прочеее. И всё это за копейки.
Да всё уже есть
https://lsfusion.org/ru/
На хабре у них есть свой хабра-корп раздел
Я 10 лет работал 1Сником. И все 10 лет испытывал постоянный стресс, жаловался на работу и страдал. Работал и во франчайзи и на "заводе". Везде всё одинаково.
По сути, 80% всех 1Сников - это сопровожденцы/внедренцы типовых конфигураций. Ничего своего или нового не пишут. Поэтому успех ждёт тех, кто знает какой-либо учёт, т.е. предметную область, и в той конфигурации, с которой он работает.
Я страдал, потому что любил код, а не разбираться в том, куда пропала копейка или почему себестоимость легла не на тот счёт. Более того, даже если ты хочешь сделать что-то хорошее - тебе это просто не дадут сделать. Во франче главное - часы. Тяп-ляп и в продакшен. Ну не будет клиент платить за какие-то автотесты или оптимизацию/рефакторинг. На "заводе" чуть свободнее, но всё равно не разгуляешься. Свою подсистему или новую небольшую конфигурацию скорее всего не дадут написать, потому что потребности такой нет. Максимум - интеграция с каким-то документооборотом, или мессенждерами.
И что самое плохое - ты и чтец и жнец, и на дуде игрец. Человек-оркестр. Сам собираешь аналитику, сам общаешься с заказчиком, сам кодишь, сам тестируешь, сам сдаёшь работу.
Но вот уже почти год как я перешёл из 1С в Java разработку. И это небо и земля! Есть нормальное версионирование - git. Есть проектные команды с чётким разграничением ролей, т.е. я 90% времени посвящаю коду и 10% на всякие митинги внутри команды. Мне не нужно знать учёт! Вообще не парит, какие там законы понапридумывали и как это вендор реализовал у себя. 100500 бесплатных курсов, ресурсов и форумов, где можно найти ответ на любой свой вопрос (заодно и английский прокачаешь). Если есть какая-то библиотека, то есть и документация по ней. А не как с СКД в 1С, где попробуй ещё найти информацию о том, как сделать нестандартный отчёт с использованием макетов. Есть тесты!
Полная свобода! Только код. Вся сложность сводиться к умению грамотно спроектировать классы и структуру БД. Говнокод никто не отменял как и всякое легаси, но с этим на порядок приятнее разбираться, чем с такими же проблемами в 1С - просто потому, что инструментов для этого больше и они удобнее.
Полностью согласен с Вами.
То что вы не нашли нормального франча, где программисты 1С занимаются написанием кода, а не общением с заказчиком - это Ваши проблемы. Git для 1с сейчас есть. А основы учета должен знать любой, кто работает в сфере его автоматизации, но разумеется не вникая в то на каком счете что учитывается.
А те, кто разбирается ещё и в учёте, зарабатывают больше.
То что вы не нашли нормального франча, где программисты 1С занимаются написанием кода, а не общением с заказчиком - это Ваши проблемы.
Это довольно токсичное выражение. Это же не вопрос того, что найти легко, это просто я поленился. Предложений крайне мало. Чтобы было разделение на роли, должна быть команда. Чтобы была команда, должен быть хотя бы средненький проект. У мелкой франчи это будет 1-3 клиента с таким типом работ. У крупной больше, но всё равно далеко не все 100% работ будут такими. Всё равно все эти франчи содержат ещё армию клиентов с простенькими задачами от 4 до 40-80 часов, на которые целую команду выделять не будут. Так что в какую бы франчу вы ни попали, вам очень повезёт, если вы будете работать именно в проектной команде внутри на интересных проектах. А даже если и будете, всё равно будут привлекать на разовые работы "универсалом".
Git для 1с сейчас есть.
Если вы про EDT, то я с ней пытался работать на реальном проекте 3 года назад. И это была боль, потому что она ещё сырая. Не говоря уже про то, что только управляемые формы поддерживаются. УПП или УТ10.3 - про git сразу забываем. И отдельная боль - обновлять доработанные конфигурации. Клиенты такому "особенно" рады, когда за обновление допиленной УПП или ERP им приходиться платить чуть ли не каждые 3 месяца за 20-40, иногда даже 80 часов работы программиста.
А основы учета должен знать любой, кто работает в сфере его автоматизации, но разумеется не вникая в то на каком счете что учитывается.
Именно этим я сейчас и доволен. Мне нет необходимости знать больше, чем основы основ. В 1С ты обязан знать хорошо, если хочешь выполнять более сложные или интересные задачи, чтобы повысить ЗП. На одних тех.скилах не уедешь. Я так и написал. Умеешь кодить и знаешь учёт - сразу +грейд к должности. Если не знаешь учёт, то стать сеньором очень сложно, т.к. сеньор в 1С должен уметь внедрять самостоятельно какой-либо вид учёта. В других сферах, это гораздо гибче. Есть просто лид команды, который больше уже менеджер, если не хочешь, можешь смотреть в сторону техлида, архитектора. И вот всё равно тут нет такой завязки на бизнес-логику. Всё это не плохо и не хорошо в общем. Мой комментарий о моих предпочтениях. Я себя сейчас чувствую гораздо увереннее. И да, 10 лет в 1С мне при этом крайне мало пригодилось, нерелевантный опыт со всем этим знанием учёта. Крайне жаль потраченного времени.
Чтобы было разделение на роли, должна быть команда
1 аналитик и 1 разработчик это уже команда. Со времен 1С:УПП разработчикам в бизнес-логике делать нечего, также как и аналитикам в разработке :)
Всё равно все эти франчи содержат ещё армию клиентов с простенькими задачами от 4 до 40-80 часов, на которые целую команду выделять не будут
Ну есть проектные работы, есть работы по сопровождению, но в любом случае с клиентом будет общаться аналитик, а код писать разработчик
Так что в какую бы франчу вы ни попали, вам очень повезёт, если вы будете работать именно в проектной команде внутри на интересных проектах
Да, с "улицы" человека вряд ли привлекут на ведущую роль в ключевом проекте, но что мешает проявить себя на вспомогательных работах? Тогда вполне возможно на следующем проекте роль будет уже ведущая?
А даже если и будете, всё равно будут привлекать на разовые работы "универсалом"
Универсалом это и на ДО, и на ЗУП, и на ERP, и на бюджет? Если разработчиков в подразделении мало, то скорее всего так и будет. Плюс работы в больших компаниях или подразделениях, что у разработчиков появляется специализация.
Если вы про EDT, то я с ней пытался работать на реальном проекте 3 года назад. И это была боль, потому что она ещё сырая. Не говоря уже про то, что только управляемые формы поддерживаются
За 3 года многое изменилось в лучшую сторону. Пока еще сырая, но работать можно. Чем больше по размеру конфигурация, тем больше времени требуется на решение проблем и тем мощнее нужна рабочая станция. Решение поддерживать только управляемые формы связано все-таки с тем, что обычные (вместе с интерфейсами) были реализованы плохо. Их нельзя выгрузить/загрузить в XML из-за того, что они содержат бинарные данные, а рефакторить все это только для поддержки EDT было избыточным.
И отдельная боль - обновлять доработанные конфигурации. Клиенты такому "особенно" рады, когда за обновление допиленной УПП или ERP им приходиться платить чуть ли не каждые 3 месяца за 20-40, иногда даже 80 часов работы программиста.
Вы думаете в других системах не так? Посмотрите как обновляют Axapta или SAP. Там нет трехстороннего сравнения/объединения и часть изменений вручную переносят, а бывает заново модули внедряют. Чтобы обновление не было болью, нужно вести доработку с учетом будущих обновлений. Нужны строгие регламенты и контроль за их соблюдением. УПП в этом плане гораздо хуже, т.к. на обычные формы нельзя программно добавлять элементы, а это закрывает возможность для технологий кастомизации.
В 1С ты обязан знать хорошо, если хочешь выполнять более сложные или интересные задачи, чтобы повысить ЗП. На одних тех.скилах не уедешь
Какие нужны знания об учете? Что такое двойная запись. Чем отличаются списания по FIFO, LIFO, средняя. БУ=НУ+ПР+ВР. Чем при расчете зарплаты период действия отличается от периода регистрации. Вот когда у конечного клиента работаешь, там действительно много ненужных знаний появляется
сеньор в 1С должен уметь внедрять самостоятельно какой-либо вид учёта
Ну да, а еще сам акты подписать и за деньгами сгонять :)))
И да, 10 лет в 1С мне при этом крайне мало пригодилось, нерелевантный опыт со всем этим знанием учёта
Ну если вы из ERP в геймдев ушли, то опыт действительно нерелевантный. Но если вы много лет внедряли ERP, перейти в ту же Axapta будет гораздо проще. Там все то же самое, только проще для понимания и сложнее для доработки.
т.к. на обычные формы нельзя программно добавлять элементы
Можно.
Решение поддерживать только управляемые формы связано все-таки с тем, что обычные (вместе с интерфейсами) были реализованы плохо. Их нельзя выгрузить/загрузить в XML из-за того, что они содержат бинарные данные
Это не является препятствием, бинарные данные всё равно как-то же расшифровываются, значит, можно сделать для них понятное представление.
Скорее, просто решили, что не будут их поддерживать.
Чтобы обновление не было болью, нужно вести доработку с учетом будущих обновлений.А как предугадать, какой именно сорт мочи стукнет в голову «ребятам с селезневки»? ну, типа как с резервами в переходе с *.4 на *.5?
Методики такой разработки, в общем-то, известны.
Вот, например, достаточно подробно описано
https://infostart.ru/1c/articles/647048/
а остальное — баянистый баян. Кстати, комменты для добавления/замены/удаления были реализованы черт знает когда в опенконфе, сделаны в турбоконфе (и наверняка в снегопате, его не ковырял), а селезневцы «ниасилили». зато котиков сделали
Поддержку коллег - работа с обычными формами проще "управляемых", которые в народе называют "неуправляемыми" из-за их избыточных ограничений по сравнению с ОФ. Программное добавление на ОФ намного очевиднее и проще чем в УФ. Я еще когда только начинал работать с 1С во времена 8.0 и УПП 1.0, то развлекался тем, что с пустой заготовки делал форму со множеством закладок, всеми видами элементов управления и обработчиками их изменения. Обработчики нужно создавать заранее, но это проблема и в УФ, так как 1С не умеет в рефлексию.
Десериализацию обычных форм в XML не сделали только потому, что "ленивые жопы" и захотели подрезать свой бэклог. ОФ - это все те же группы с элементами и их свойствами. Некоторые из свойств действительно бинарные (те же картинки), но с каких пор XML перестал хранить бинарные данные (base64)?
О каких ограничениях идет речь? То что нельзя разместить ActiveX объекты? Так это уже не актуально. Кому интересно возиться с координатами, размерами и привязками? Я вообще считаю, что это наследие 1С:Предприятие 7 не должно было попасть в 1С:Предприятие 8.
Попробуйте выгрузить конфигурацию с обычными формами в файлы, затем изменить что-то на форме, затем вернуть обратно и вы увидите что файл стал другим. Скорее всего там хранятся служебные объекты, которые сериализуются вместе с формой. То есть чтобы сделать выгрузку/загрузку обычных форм нужно рефакторить эту функциональность.
>То что нельзя разместить ActiveX объекты?
Да и хрен с ними. Кому надо выведут на поле ХТМЛ-документа.
>Кому интересно возиться с координатами, размерами и привязками?
Мне интересно, а так же всем, кто хочет получить красивую экранную форму. Мы много лет долбали компанию 1С на партнерском форуме и закидывали их скриншотами форм, которые на 8.0/8.1 выглядят по логике/удобству/красоте просто идеально, и которые превращаются в убожество при попытке перевода на управляемую форму - сплошное пустое пространство с минимумом полезной информации. В конце-концов они сдались и дали нам "компактный режим". Но хотелось бы все же для групп форм возможностей по визуальному структурированию, которые есть у div/span на веб-страничках.
Раньше много чего на формах можно было сделать с помощью наложения друг на друга элементов управления, свертки групп в любую сторону, скрытых командных панелей, которые можно было делать источниками для контекстных меню и так далее - ограничения только фантазиями. Это было слишком много возможностей уровня редакторов интерфейсов Visual C++ и Delphy - просто не потянули. Было принято решение максимально упростить интерфейс для облегчения верстки для веб-клиента. Хотя это не особо им помогло - даже тут в комментариях многие жалуются на наличие багов в веб-версии.
>Попробуйте выгрузить конфигурацию с обычными формами в файлы...
Что-то вы странное написали. Сделайте то же самое с управляемой формой и получите аналогичный результат. Иногда даже ничего на форме менять не нужно - платформа за вас сама все изменит.
Кстати, я на днях столкнулся с падением платформы 8.3.22 (текущая актуальная и потому рекомендованная) при попытке открытия управляемой формы. С ошибкой, говорящей что-то про дженкинс, было ничего не понятно кроме путей сборки проекта в компании 1С. Но я заподозрил, что проблема могла быть в реквизитах формы. В XML файле просто поменял их местами и загрузил назад в конфигуратор. Все, магия свершилась! Критическая ошибка ушла (а раздражение осталось).
Поддерживаю по всем пунктам!
Идеальные формы на 8.0/8.1? Это там где на одной форме десятки элементов и при скрытии ненужных будут зиять огромные пустые места? А уж сколько проблем возникало, при необходимости добавить новый элемент между двумя существующими. А сейчас это можно программно сделать за 5 минут не усложнив при этом дальнейшую поддержку.
Компактный режим появился как вариант интерфейса "Такси". Что касается расширения возможности размещения элементов на форме - никто не обещал, что будут все возможности HTML. Сейчас вся индустрия идет по упрощению форм, собственно поэтому интерфейс Такси и был выпущен.
Наложение элементов и скрытые командные панели это вообще зло. У веб-версии есть действительно особенности, кроме того она более остро реагирует на неправильное написание подписчиков, в которых делают недопустимые контекстные серверные вызовы.
Управляемые формы выгружаются и загружаются без каких либо проблем. Если у вас есть сценарий воспроизведения, что это не так, нужно писать в службу поддержки. Считать только что выпущенную версию как рекомендованную я бы точно не стал. Разве что для небольших внутренних проектов. Опять же, если зафиксировали ошибку писать нужно в службу поддержки.
1) Нет, пустые пространства - это про управляемую форму, а на обычной все именно так как вы сверстаете. Если не правильно настроить привязки, то можно сделать такого же монстра как и на УФ. Программное добавление элементарное, но нужно дополнительно потратить минуту на смещение координат для существующих элементов, но в отличии от УФ, где у вас они просто уедут вниз, тут вы можете управлять "уезжанием" и сжать 6 элементов до той же высоты, которые занимали 5 элементов.
2) То-то и оно - от разработки классических десктопных GUI ушли, а до веба не дошли.
3) Это ваше субъективное мнение. Если вы в себе не уверены, то просто не используйте подобные возможности. Но это не повод для запрета для остальных.
4) Вы передергиваете, ведь обычные формы тоже "выгружаются и загружаются без каких либо проблем" - точнее проблемы ОФ и УФ являются идентичными (но я не извращенец, чтобы таким заниматься при невозможности выгрузить обычную форму в текстовый формат для версионирования в гите). Я много лет общаюсь с поддержкой 1С и знаю, что последняя версия именно рекомендованная. Если у вас не последняя версия, то любую вашу ошибку просто не зарегистрируют, так как "вероятно она уже исправлена в актуальной версии". А вот "версию для ознакомления" я ставлю очень редко и только для точечных тестов нового функционала.
Вот простая задача. При открытии формы необходимо скрыть один из элементов. Как вы это будете делать? Пересчитывать координаты всех элементов которые находятся ниже? Заголовок с полем тоже не связать, приходилось им управлять независимо. Не удивительно, что как только появилась платформа 8.2, мы все новые формы в УПП делали управляемыми, чтобы поскорее избавиться от этого кошмара.
У вас есть пример веб-интерфейса, который удобнее десктопного при работе с данными?
Да видел я все это убожество, когда командную панель или элемент на форме не найти
По вашему ошибка только что выпущенной версии платформы (вероятнее всего там новая версия формата), которую безусловно исправят, идентична многолетней проблеме не имеющей решения? Есть много проектов, где разработчики используют Git без EDT, что-то я не помню чтобы жаловались на подобные проблемы. Служба поддержки просит проверить на последней версии, чтобы упростить себе жизнь, критичные ошибки исправляются и в предыдущих версиях. Например 14.10.2022 вышла сборка 8.3.17.2733, причем первая сборка версии 8.3.17 вышла 23.04.2022. Новые версии есть смысл ставить либо для новых проектов, либо когда нужна новая функциональность.
Последовательность шагов решения: а) добавляем на форму новую панель с отключенными закладками и границы привязок по границам панели; б) помещаем элементы, которые должны скрываться на эту панель; в) элементы ниже (или справа, или слева - зависит от верстки) привязываем к границам соседних элементов, а не к границам формы г) на триггер смены видимости элементов вешаем свертку группы наверх (или налево, или направо - зависит от верстки) - это всем известный прием, которым все пользовались со времен 8.0 (пример - форма подбора номенклатуры в УПП 1.0).
В том то и дело! Поэтом безоговорочное отключение десктопных возможностей было явно поспешным. Хорошо, что разрешили делать смешанные ОФ/УФ интерфейсы
"Да видел я все это убожество, когда командную панель или элемент на форме не найти" на управляемой форме! В отличии от УФ на ОФ хорошо работает поиск по элементам на форме. И если ты видишь элемент на форме, то можешь с ним работать без всякой экстрасенсорики - откуда тут эта команда? на форме этой команды нет, среди общих тоже нет... а, нашел - она у совершенно левого объекта метаданных, но как параметр задана ссылка на текущий (а еще лучше задан определяемый тип, чтобы поиск использования не дал быстры результат).
Ошибки - это ошибки. Зачем торговаться? На хабре есть рассказ Петра Грибанова о выпуске платформ - сначала внутри разрабатывают, потом несколько циклов альфа теста и закрытые бетта-тесты, и лишь когда уверены в функционале, то выпускают... нет не в релиз, а в открытый бетта-тест, после которого примерно через месяц закидывают в релизы. Внутри себя 1С использует всегла самую актуальную версию, а внутри фреша даже идут с опережением!
Да, именно так, ради простой задачи делать кучу действий. Вот и спрашивается - зачем все это? Бывало форма при масштабировании криво работала и приходилось проверять все эти привязки. Про программную модификацию формы для упрощения обновления даже не задумывались тогда.
И каких же десктомных возможностей недостает управляемой форме, что по-вашему делает ее эффективное использование невозможной?
Ну да, часть команд принадлежит форме, другие принадлежат объектам метаданных, третьи вообще добавляются программно. Всегда можно сделать поиск ссылок на объект, чтобы их найти
Ну да, евангелисты компании 1С считают что у всех пользователей установлена последняя версия платформы. Но реальность абсолютно другая, причем это касается не только продуктов компании 1С.
Разговор куда-то не туда пошел. Я не утверждаю, что на ОФ приятно работать! Многие вещи делать нужно через Ж! Да я сам еще во времена 8.0 и 8.1 писал предложения сделать возможности декларативной верстки как у HTML (как потом сделали в УФ, но не совсем).
Но я утверждаю, что хоть временами и трудно, но на ОФ можно сделать все что хочешь по визуальному оформлению! В отличии от УФ, где некоторые вещи (привязки, сокрытие по функциональным опциям или правам доступа) делают намного проще, но некоторые вещи невозможно сделать в принципе (из-за чего очень многие группы разработок выводят на форму поле HTML-документа, в котором делают все визуальные красивости).
Не сижу плотно в разработке на УФ, иначе бы накидал множество примеров, но на ум приходят следующие:
1) На УФ в отличии от ОФ нельзя управлять видимостью команд! Т.е.в ОФ вы можете для документа спокойно скрыть кнопки записи или проведения (при чем как на командной панели, так и в меню "все действия"), а в УФ вам разрешают только отключить автозаполнение и генерировать все кнопки вручную - после чего у вас будет право их скрывать методом удаления (не только системные команды, но и настроенные для формы в конфигураторе).
2) В УФ управление видимостью нельзя делать единообразно. Для некоторых элементов нужно в свойствах прописать функциональную опцию и не забыть ее установить при открытии формы. Для колонок в табличных частях видимость для разных строк можно скрывать только с помощью условного оформления (если добавить табличной части реквизит формы и устанавливать его программно при выводе строк, то можно правило условного оформления сделать фиксированным сразу в конфигураторе, но я видел, что многие формируют условное оформление программно по событию изменения таблицы). Для элементов формы, которые не являются колонками таблиц, внезапно видимость из условного оформления не работает и их нужно скрывать с помощью кода Элемент.Видимость=Ложь. А вот в ОФ Видимость=Ложь скроет любой элемент (включая конкретную колонку только для конкретной строки таблицы) и не нужно держать в голове зоопарк различных приемов для различных элементов.
В целом УФ мог бы быть крутым инструментом для построения интерфейсов, но из-за "недоделали тут, недокрутили там" по функциональности вышло хуже чем ОФ.
Согласно методологии БСП, все команды добавляются кодом, что на самом деле правильно. Для контекстного меню команды тоже можно добавлять программно.
Видимость, как и некоторые другие свойства, нужно воспринимать как расширение условного офориления для таблиц формы. При изменении видимости элементов формы почти всегда происходит серверный вызов для перестроения формы, поэтому можно понять, почему разработчики отказались от управления видимостью с помощью условного оформления для всех элементов формы. Но есть примеры подсистем, когда правилами задаются взаимосвязи видимости и затем эта логика выполняется через общие подписчики.
Спасибо, что вспомнили про библиотеку БСП. Набор хаков для обхода ограничений платформы. Комманда разработки действительно хорошие программисты и очень в муках стараются, чтобы другие разработчики на УФ мучались чуть меньше...
Точно и тут спасибо за напоминание - серверные вызовы при изменении отображения на клиенте. Как у меня много крови выпило еще во времена 8.2 (тогда визуальные возможности были еще хуже чем на последних версиях Такси). Пишу форму документа с несколькими табличными частями для логистической конфигурации (заказы с торговыми точками, флот машин и версии возможных маршрутов) и внезапно при использовании гигантские тормоза и все тупит. Оказывает, что если у элемента формы изменить Заголовок/Title, то это вызывает контекстный вызов (рука-лицо). Плюс еще несколько неочевидных и чисто клиентских действий тоже зачем-то сервер дергают...
эээ.... батенька... на практике постоянно сталкивался с тем, чего нельзя сделать в УФ, писал сперва на сайт куда-то, но потом понял, что бесполезно. А в 1С писать еще бесполезнее.
взять тот же управляемый интерфейс - там нельзя программно нарисовать и главное - скрыть пункты меню. вах
И все 10 лет испытывал постоянный стресс
Это нетолько к 1С относиться. В Геймдеве тоже самое, как и в др ит сферах.
По сути, 80% всех 1Сников — это сопровожденцы/внедренцы типовых конфигураций. Ничего своего или нового не пишут.
Во многих ит компаниях похожая ситуация. Винтик в системе.
Тяп-ляп и в продакшен.
Ну так это для всего ит сейчас так. Время деньги.
И что самое плохое — ты и чтец и жнец, и на дуде игрец. Человек-оркестр. Сам собираешь аналитику, сам общаешься с заказчиком, сам кодишь, сам тестируешь, сам сдаёшь работу.
?? Ну так и Java/С++/Php прогер — (в подавляющем ) сам общается с заказчиком, сам кодит, сам тестит.
Но вот уже почти год как я перешёл из 1С в Java разработку. И это небо и земля!
Так часто бывает. Когда из одной сферы переходишь в другую. Получаешь дофаминовый шторм. Пройдут годы, и у вас вновь будет апатия.
Ну так и Java/С++/Php прогер — (в подавляющем ) сам общается с заказчиком, сам кодит, сам тестит.
Это разве что в низкопробных галерах и в госучреждениях. В приличных местах с заказчиками общаются менеджеры и аналитики, а тестируют тестировщики (QA).
Пройдут годы, и у вас вновь будет апатия.
А может и не будет.
тестируют тестировщики (QA).
А что Java прогер тестировать вообще ничего не должен?
Программисты настолько не любят тестировать, что придумали автотесты именно для того, чтобы не делать это самим :) А так, если серьезно, разработчики обычно тестируют только базово во время отладки: прогнал на разных вариантах ветвлений, убедился что в основных случаях оно работает, а дальше передал таску QA-тиме, которые уже будут тестировать новый функционал по-полной со всеми пограничными кейсами, ну и заодно могут проверить что после изменений ничего не сломалось в старом существующем.
Бизнес свои деньги считать умеет, время программиста обычно стоит ощутимо дороже, чем время ручного тестировщика, поэтому и есть смысл освободить программиста от рутины и дать ему заниматься именно программированием, а не тестированием. Да и результат будет лучше, когда тестирует не тот, кто разрабатывал.
Да и результат будет лучше, когда тестирует не тот, кто разрабатывал.
Ибо если Вася уверен, что 2 + 2 = 5, то он и в тесте также напишет! :-)
Ради справедливости, юниты должны писать программисты. У QA просто квалификации не хватит. А если хватит, то он не долго останется QA и сам свалит в прогеры.
Я когда попробовал писать на Java, то мне понравилось TDD - сначала описывал тест на JUnit, а потом делал реализацию, что бы все стало зеленым.
Парное программирование - это тоже круто!.
Не, юниты — тот кто пишет задачу. Сценарии — кто-то еще.
И да, юниты это пыль, которая выкидывается при рефакторинге.
Так часто бывает. Когда из одной сферы переходишь в другую. Получаешь дофаминовый шторм. Пройдут годы, и у вас вновь будет апатия.
4.5 года был в 1с (далеко не в самом худшем франче по устройству процессов и уровню решаемых задач), сейчас 4 года как перешел на андроид. Это было лучшее решение в моей жизни, до сих пор вспоминаю 1с с содроганием.
Вот кстати да. Ровно тоже самое что написано выше мне говорили 8 лет назад, когда я уходил в "серьезное" программирование из болота под названием АСУТП. 8 лет прошло, а дофаминовый шторм до сих пор не прошел и никакой апатии не наблюдается, все устраивает. Так что решение однозначно было правильным.
А эти фразы про "так часто бывает, пройдут годы..." напоминают анекдот, про тот как люди пытаются выбраться из котла в аду, а свои же их затаскивают обратно. С релокацией в другую страну та же история, кстати.
Это нетолько к 1С относиться. В Геймдеве тоже самое, как и в др ит сферах.
Стресс везде. И в общем, тут многое зависит от работодателя, и как он относится к сотрудникам. Но мой стресс вызван был моей болью, что я вынужден заниматься тем, что мне не нравится. Чем выше по карьере лезешь в 1С, тем сильнее смещается акцент в сторону бизнес-аналитики. Джуниору достаточно 90% уметь в код и 10% в учёт. Сеньору уже 40% код, 60% учёт. В 1С буквально заставляют знать всё больше и больше информации про учёт и вникать в бизнес-аналитику для того, чтобы оставаться конкурентоспособным. И в оригинальной статье это приводится почему-то как неоспоримое преимущество.
Вот кстати в точку. В той статье-презентации, которой оппонирует автор этой публикации, лейтмотивом проходит мысль типа "1С-программисты - большие умницы, потому что на пол-ставки подрабатывают бизнес-аналитиками".
О том, что очень многие программисты эту бизнес-аналитику в гробу видали, и хотели бы заниматься ею как можно меньше (благо в приличных местах есть разделение обязанностей и это можно делегировать специальным людям), тот чувак, судя по всему, вообще не догадывается, иначе бы он точно не упоминал как преимущество работы с 1С.
Точно так же веселят его рассуждения про "бизнесу не нужен ваш код, алгоритмы, автотесты и архитектуры, бизнесу нужно решение его задач". И почему-то забывает, что все-таки, пусть и не всегда, но нередеко, бизнесу нужно не просто "решение задач", но и чтобы эти задачи были решены качественно - чтобы всё не тормозило как черт знает что, чтобы не падало и не ломалось от неосторожного щелчка и фаз луны, чтобы в будущем изменить условия задачи или решить заодно еще одну можно было за разумное время, а не перепахивать всё вверх дном с матами и регрессиями. И если вы решаете задачи с помощтю кода, то для этого и нужны те самые оптимальные алгоритмы, тесты и продуманная архитектура. Для бизнеса-ларька пойдет и "херак-херак в продакшн", а для серьезного бизнеса с долгосрочным горизонтом планирования - уже нет.
И почему-то забывает, что все-таки, пусть и не всегда, но нередеко, бизнесу нужно не просто «решение задач», но и чтобы эти задачи были решены качественно — чтобы всё не тормозило как черт знает что, чтобы не падало и не ломалось от неосторожного щелчка и фаз луны, чтобы в будущем изменить условия задачи или решить заодно еще одну можно было за разумное время, а не перепахивать всё вверх дном с матами и регрессиями.
наговнокодить можно на любом языке программирования, в любой системе, в любой стране… Да, в 1с это, возможно, легче сделать. Плюс низкий порог вхождения помогает.
Так с этим никто и не спорит. Некоторым заказчикам и говнокод пойдет, кому главное чтобы быстро и дешево, а дальше хоть потоп и трава не расти (другое дело, что потом на этом сам исполнитель обжечься очень сильно может, когда ему свое же говно придется потом много лет поддерживать). Но суть в том, что там человек почти прямым текстом продвигает идею, что те, кто заморачиваются и стараются не делать говнокод - по определению не очень умные :)
Лейтмотивом там проходит более высокий уровень абстракции. Это как в пайтон ты датасайнтист, а в С++ червь компьютерный, из той же оперы.
И если вы решаете задачи с помощтю кода, то для этого и нужны те самые оптимальные алгоритмы, тесты и продуманная архитектура. Для бизнеса-ларька пойдет и "херак-херак в продакшн", а для серьезного бизнеса с долгосрочным горизонтом планирования - уже нет.
Для последнего это скорее "херак-херак, херак-херак, херак-херак, херак-херак (стук колес) и в продакшн".
Главное на третьем хераке сделать рефакторинг когда все сценарии уже собраны.
Просто другая планета.
Таки 1с - это эталонное ненужно.
Платный закрытый вендорлок, причем сделаный чудаками на букву 'м', подмявший местечковый рынок(ты еще и ограничен в ареале обитания), которого почему то не замечают наши монопольщики.
Ещё добавил бы такую аналогию- довольно популярны сейчас специализированные высокоуровневые инструменты. Своя ЯП есть в power bi, в Exel есть vba, в компоненте экзель power qwerty тоже свой язык программирования. И люди пишут. Видимо потому что какие то задачи эффективней (быстрей). где то ниже порог вхождения. Хотя можно те же данные отображать через джаспер/кристал/ещё какой нибудь репорт и вытягивать стандартными sql запросами
Хотя и возможностей там куда меньше чем в каком ни будь древнем Delphi (где хочешь- с сокетами работаешь, хочешь- вставки пишешь на ассемблере хочешь -без каких то лицензий хоть миллион потоков создаешь; и кстати можно ещё и ПО продавать, например неограниченное лицензий на регион, что в решениях 1С невозможно). Ну а на каких нибудь плюсах и десятки компиляторов и куча фреймворков на выбор - и от вендоров -mfc,vcl,..net и кросплатформенные (qt) и работать может от микроконтлроллеров и часов то меймфреймов и можно забабацать хоть ОС.
С позиции программиста удобней универсальный ЯП. тот же пайтон -хоть бэкенд, хоть аналитику данных, хоть скрипты для администрирования, а если заморочится то и приложение c GUI, можно даже для сотового. Но для специалиста который решает конкретные задачи и бэкграунда в разработке не имеет- может быть куда удобней специфичный инструмент
А 1С я восхищаюсь не как пользователь: ребята создали целую индустрию с кучей разработчиков решений, франчайзи, обучением специалистов. Экосистема цела приличного уровня- таких кейсов в РФ очень мало. и вытеснял он скорей не грамотные ентрпрайз решение, а решения которые были хуже -я как то, н-ное кол-во лет назад) был на собеседовании в фирме которая с 1с конкурировала- наблюдал бухов которые приходили на обучения со своими системщиками, разрабатывалась система на foxpro, но причём центральный эфис поскольку исходники не передавал, а кастомизировать под клиентов надо- они декомпилировали (точней деинтерпритировали) решение и допиливали его. Как они накатывали новый резил с адаптацией своих изменений уже не знаю
Ещё добавил бы такую аналогию- довольно популярны сейчас специализированные высокоуровневые инструменты. Своя ЯП есть в power bi, в Exel есть vba, в компоненте экзель power qwerty тоже свой язык программирования. И люди пишут. Видимо потому что какие то задачи эффективней (быстрей). где то ниже порог вхождения. Хотя можно те же данные отображать через джаспер/кристал/ещё какой нибудь репорт и вытягивать стандартными sql запросами
low-code давно в моде, сколько себя помню.
С позиции программиста удобней универсальный ЯП. тот же пайтон -хоть бэкенд, хоть аналитику данных, хоть скрипты для администрирования, а если заморочится то и приложение c GUI, можно даже для сотового. Но для специалиста который решает конкретные задачи и бэкграунда в разработке не имеет- может быть куда удобней специфичный инструмент
чем универсальнее, тем сложнее. тем больше надо следить за совместимостью.
это собственно и случилось с 1С - тонкий клиент, толстый клиент, веб-клиент, мобильное приложение, мобильный клиент и везде один ЯП.
А 1С я восхищаюсь не как пользователь: ребята создали целую индустрию с кучей разработчиков решений, франчайзи, обучением специалистов. Экосистема цела приличного уровня- таких кейсов в РФ очень мало. и вытеснял он скорей не грамотные ентрпрайз решение, а решения которые были хуже -я как то, н-ное кол-во лет назад) был на собеседовании в фирме которая с 1с конкурировала- наблюдал бухов которые приходили на обучения со своими системщиками, разрабатывалась система на foxpro, но причём центральный эфис поскольку исходники не передавал, а кастомизировать под клиентов надо- они декомпилировали (точней деинтерпритировали) решение и допиливали его. Как они накатывали новый резил с адаптацией своих изменений уже не знаю
да, уютная золотая клетка от местной корпорации добра :)
Начинал карьеру как раз с некоего отношения к 1С. Конфигурации пилил другой человек, а сам занимался всякой около фигнёй. Но что то покодить успел чтобы запомнилось на долго. В итоге пути с той конторой удачно и оперативно разошлись.
А в кризисном 2008 чуть не вляпался по полной. До сих пор лежит набор адепта. Какая то коробочка с книгой и чем то ещё. Надо не забыть выкинуть. Нормальную работу как то сложно было найти, вот и возникло помутнение. Но, обошлось :)
Сейчас сам себе сеньор и условия весьма шоколадные. Из большой конторы по заказной разработке ушёл в мелкую, но с перспективами. Пилю свою ИС и в планах развитие ИТ в принципе. Никаких обвесов вроде РП и аналитики. Сейчас так быстрее. Опыт в 15+ лет позволяет быть человеком-оркестром :)
Да, в 1С есть автоматизированное тестирование, Vanessa и другие инструменты. Но почему даже вендор не использует их? Почему тестирование остается уделом небольшой части энтузиастов?
Это вы с чего решили, что в 1С нет автоматизированного тестирования? 1С очень неохотно афиширует свою внутреннюю кухню. Я уверен, что оно есть, но не дает 100% результат.
Ленивые и жадные.
Оба тезиса спорные. Как вы написали "100500 противоречащих друг другу законов, которые успел напечатать бешеный принтер" должны найти отражение в программе, например 1С:Бухгалтерия Базовая, которая продается за 3300 и даёт доступ к обновлениям без ИТС. И эти изменения должны быть реализованы в срок.
Это вы с чего решили, что в 1С нет автоматизированного тестирования?
с того, что документ "Перемещение товаров" не был проведен ни разу на этом автоматизированном тестировании и таким образом был выпущен в тираж.
Почему уходят из 1С?