Как стать автором
Обновить

Комментарии 233

Ухх, хорошо-то как!
Напомнили трагическое произведение, которое меня сильно впечатлило в детстве.
Все умерли
Жили-были пузырь, соломинка и лапоть. Пошли они в лес дрова рубить. Дошли до реки и не знают, как перейти через реку. Лапоть говорит пузырю:

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

Соломинка перетянулась с берега на берег. Лапоть пошел по соломинке, она и переломилась.

Лапоть упал в воду и утонул. А пузырь хохотал, хохотал, да и лопнул.

Я тоже вспомнил эту сказку, но сразу вспомнил еще и древнюю песню Лаэртского про трёх нелепых персонажей (один из которых — муравей). Даже не знаю, какая аналогия из этих двух лучше отражает состояние индустрии.

Я так понимаю, что муравей — клиент. Тот, что резвый из ближайших кустов — программист 1С. Остальные — консы, разрабы и аналитики.
Тот, что резвый из ближайших кустов — программист 1С.

Я Оруэлл с вашей аналогии.
А вот это вот угрожающе нависающее над муравьём — дедлайн по внедрению маркировки и сдаче годовых отчётов.
А вот это вот угрожающе нависающее
Мне казалось, что оно как раз характеризует результат работы конса и разраба, а программист «спасает» клиента. В песне описывается частный (счастливый) случай, когда нашелся программист. В остальных случаях клиент оказывается весь в…

Да, статья в стиле "чукча-стайл" что вижу то и пою. Развлекательная.
Для пикабу пойдет, но для хабра — это понижение планки/качества контента.

Собственно, а что-то в этом всем автора удивляет? В конце концов, мир 1С — это мир замкнутый, там хорошему разработчику особо некуда расти профессионально. Так или иначе, а те, кому расти интересно, будут охотно разбегаться в другие области, менее ограниченные технологически. Я это лично в мелком масштабе наблюдал. Понятно, что если новых на замену целенаправленно не выращивать — то общий уровень будет падать. Все вполне предсказуемо.
Все модные технологии также можно прикрутить к 1С: докеры, эластики, кликхаусы, боты, автоматизированное тестирование…
Расти есть куда и можно это делать бесконечно, пока развивается всё остальное ИТ. Было бы желание.
НЛО прилетело и опубликовало эту надпись здесь
А куда растут другие программисты? Изучают новый оператор? Или библиотеку, который написали как раз для подключения ко всему вышеперечисленному?
Что есть развитие программиста в вашем понимании? Может мат алгоритмы должен прокачивать? Или в asm спускаться?
НЛО прилетело и опубликовало эту надпись здесь
И весь этот список применим к 1С. За исключением, может, изучения новых фреймворков, хотя и тут 1С выпустила EDT на базе эклипса.
и какой же фреймворк можно подключить в EDT к 1С? А так же какие паттерны можно применить в 1С где нет интерфейсов и наследования? Как можно в 1С перейти с монолитной бухни на микросервисную?
В EDT сейчас есть интеграция с фреймворком БСП. Если вам не нравится проприетарная БСП, есть открытый аналог, причем на английском диалекте 1С (все как любят тру программисты).

Пилить микросервисную архитектуру на 1С никто не мешает- у 1С есть и формат для шины данных, и коннекторы к AMPQ (платформенные и сторонние).

Ну а для пытливых умом, есть OneScript.Web.
В EDT сейчас есть интеграция с фреймворком БСП

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

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

Любопытно, в чем именно вы видите «костыль на костыле»?
БСП не фреймворк, а просто библиотека.

Так то и Spring просто библиотека. И БСП совсем необязательно полностью включать в свой проект.

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

В смысле отсутствует? В базовой подсистеме до сих пор живы и работают методы еще с самого первого релиза.

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

Если что, что интеграция это обоюдоострая вещь. И бодрячкового хардкода я навидался вовсю. Начиная от ручного парсинга xml-к (с соответствующими требованиями вплоть до количества пробелов в отступах), и REST-интерфейсов которые всегда возвращающих 200, COM-объектов которые работают только на Windows 2000, самопальных RPC разной степени вменяемости. Про интеграции с системами на Excel я даже говорить не буду. И все это добро сделано «с применением лучших паттернов проектирования и самых современных фреймворков», да.
и REST-интерфейсов которые всегда возвращающих 200
А что с этим не так? Особенно в 1С. Которая сама по себе может вывалить и 403, 404 и 500. Не заходя в сервис.
Да почти все ОК. Только не надо возвращать 200, если на твоей стороне все упало, и сервис валяется в коме. Зато эндпойнт оптимистично отвечает «200» с пустым телом на любой запрос — все хорошо, прекрасная маркиза.

А с 1С не так?
404 — не найден ресурс,
403 — у учетки нет прав
500 — вам вернули исключение, см. тело ответа

Или вы обычно пишите сервисы в которых этих ошибок возникнуть не может по определению?
Не помню точно, какую то из 400х можно словить при зависших сеансах. При этом в конфу 1с даже не заходит. 500 — отдаёт если в коде есть ошибка и вызывается исключение. 401 отдаётся тоже до захода в конфу. Я обычно на любой запрос отличный от того что я ожидаю отдаю 400. А вот при ошибках в работе с данными, проведение документов, запись справочников, отдаю 200 с пояснение что и как. Оно не всегда просто ошибка. По логике ответа.
UPD. 403 — тоже не отдаю, отдаю это в 200.
В итоге 1С использует коды ответов по стандарту, вы нет. Но говнокодят все равно 1С-ники.
Была отличная статья на хабре по поводу rest и ответов в кодах http. Так там подобные кейсы очень хорошо разобраны. И не следование стандартам этих самых кодов, это мой выбор, потому как я встал на эти грабли с «правильными» кодами http.
Пилить микросервисную архитектуру на 1С никто не мешает

Это уже совсем сову на глобус. Мешает почти всё. Я прям аж завис от того с чего начать.


  1. Невозможность (ну или очень высокая сложность) интеграции с классическими инструментами MSA. Ввод-вывод в stdio — его нет, получение переменных окружения — нет (тут мы сразу прощаемся с Vault), поднятие неСУБД компонент как подов, сложность интеграции с kafka, низкая производительность HTTP, аутентификация/авторизация между микросервисами не такая лёгкая.
  2. "Неотчуждаемость" многих компонентов платформы. Вся 1С построена фактически вокруг пользовательских сеансов, начиная от лицензирования. Попробуйте сделать 3 конфигурации, так чтобы 2 из них были "микросервисами", а одна "фронтом" — у вас "фронт" либо начнёт бизнес-логику "МС" затягивать, либо вы упоретесь в интеграции.
  3. Модульность решений на уровне кода на встроенном языке почти никакая.
  4. Оверхед по производительности относительно монолита есть и в Java/.Net, что уж там, но в 1С это будет просто блокер проекта.
  5. РСУБД-центричность. Микросервис нередко вообще не требует РСУБД (файлы, кешики, простые key-value, плюс 1-5 табличек в постгре). Это быстро станет техническим ограничением.

Формально нельзя сказать, что совсем невозможно сделать MSA на 1C, но, право, найти более неподходящий инструмент непросто.

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

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

sdout — для консольных приложений есть OneScript. 1C как консольное приложение работать не может.

Поддерживается аутентификация: basic, NTLM (kerberos), OAuth, российская ЕСИА.

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

3. Глобальная проблема модульности — один глобальный неймспейс. Спрятать что либо можно только на уровне соглашений. В остальном Отделять одни сущности от других вполне можно.

4. Смотря что вам нужно. 1С оптимизирована на исполнение определенных задач. В этом классе задач Java и .NET съедят весь бюджет еще на уровне проектирования.

5. Если вам не нужна БД, то использование 1С излишне. Тут или тот же OneScript — если оставаться в рамках языка. Или все же решение на другом языке.

Я не говорю, что 1С плохая платформа для учётной системы. Наоборот — весьма удачная. Но для микросервисов не подходит. Заметьте, я даже не утверждаю, что MSA всегда нужна.
Я лишь не согласен с тезисом, что 1С подходит для MSA. В рамках MSA есть несколько центральных идей, которые очень сложно реализовать в монолитном ландшафте 1С (в качестве ориентира я предлагаю использовать уже классическую книгу "The Tao of Microservices" — она небольшая относительно, прочитайте, если есть возможность, немного устарела, но в качестве фундамента обсуждения подойдёт).


  • Если "инстанс это конкретная БД", то, например, вы напрочь прощаетесь с 95% инструментов и приёмов масштабирования.
  • "stdout — для консольных приложений есть OneScript" — т.е. информационную базу в качестве пода нам уже будет неудобно использовать.
  • "Поддерживается аутентификация: basic, NTLM (kerberos), OAuth, российская ЕСИА." — поднимите информационную базу 1С в поде, которая будет поднимать секреты из vault и чтобы это было хоть сколько-то не костыльно. Сравните с кодом .NET/Java/Node(JS/TS).
  • "Как делать интеграции без учета бизнес-логики сервиса?" — о, это и есть самое сложное в MSA :) отчасти помогают стандартные инфраструктурные решения, но в целом MSA — это как раз на деление на независимые (слабозависимые) домены.
Если посмотреть с чего вообще началось общение в этой ветке, то увидим, что я отреагировал на то, что человек сказал, что одинэсник не может развиваться как программист, т.к. он находится в каком-то своем вакууме.
Если разработчик на php разовьется, написанием своего микросервиса на GO, то что мешает одинэснику написать точно такой же микросервис на GO и дергать его по мере необходимости из 1С. Таких примеров тоже хватает.
Часто использую Go как прослойку между 1С и фронтом. Мешает 1С в голове. В ней все не так. И взрослые ЯП нужно учить с самого начала. 1С не давно пришла, к более менее стандартным терминам.
и какой же фреймворк можно подключить в EDT к 1С?

На текущий момент их два: конфигуратор и EDT edt.1c.ru
Но про них я написал выше, что по сути выбора нет.
А так же какие паттерны можно применить в 1С где нет интерфейсов и наследования?

В 1С «почти» нет наследования. Да, какие-то из паттернов не применимы в принципе, но это не значит, что в 1С нельзя применять паттерны проектирования. Они не только про ООП.
Как можно в 1С перейти с монолитной бухни на микросервисную?

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

Это среды разработки, а не фреймворки.
В 1С «почти» нет наследования. Да, какие-то из паттернов не применимы в принципе, но это не значит, что в 1С нельзя применять паттерны проектирования. Они не только про ООП.

Приведите пример использования паттерна в 1С.
А что именно мешает? Например, вынести расчет себестоимости в отдельную «базу» или сервис и дергать его по мере надобности?

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

Не трудно — это 1С.
Приведите пример использования паттерна в 1С

любой поведенческий? Что-то на уровне платформы (те же подписки/«наблюдатель» и версионирование/«снимок»), что-то реализуется на уровне кода.

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

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

Фасад, Декоратор, Адаптер… проще наверное сказать какие не применимы. Или вы под паттернами проектирования что-то другое понимаете?
Но почему-то никто так не делает. Даже фирма 1С почему-то не выпускает отдельный сервис для расчета себестоимости. А все потому, что очень много зависимостей для расчета которые необходимо собирать.

Всё, что можно вынести в отдельный сервис — выносится. Ес-но расчет себестоимости никто выносить отдельно не будет, потому что там требуется огромное количество начальных данных. Это как если бы пересчет индекса для БД вынесли б в отдельный сервис.
В типовых используется как минимум сервис получения данных о контрагентах, адресе, ЭДО и т.п.
А на местах уже пишут под конкретные цели и потребности. Если вы их не видели, то это не значит, что микросервисов не существует.
1С прекрасно работает и с REST и с SOAP и со всякими кроликами. Также и сама может выступать в роли микросервиса (конечно с GO не сравнить, но возможность есть)
Не трудно — это 1С.

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

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

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

По поводу «для учета». Ну да, для учета. И SQL создавалась «для учета». И что?
Я не топлю за использование 1С везде где можно и нельзя. 1С имеет свои преимущества и недостатки. Микросервисы на базе 1С, ИМХО, очень уже нишевое решение.

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

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

Что, например, можете сказать по поводу паттерна DTO?

хм, 1С-ный Enterprise Data DTO в чистом виде.
А что именно мешает? Например, вынести расчет себестоимости в отдельную «базу» или сервис и дергать его по мере надобности?

Мешает то, что задолбаетесь отковыривать логику и данные, нужные для расчёта себестоимости в отдельную БД. Микросервисы — это про "low coupling high cohesion".

Мешает то, что задолбаетесь отковыривать логику и данные, нужные для расчёта себестоимости в отдельную БД

Но это ограничение не 1С как платформы, а предметной области, разве нет?

И да, и нет.
Да: учётные системы c ACID, с взаимосвязанными объектами/разрезами учёта, с большой и нагруженной СУБД действительно отвратительный кандидат на "микросервисность". Говоря откровенно, на рынке в мире нет ни одного примера реализации учетной системы уровня предприятия на микросервисах. Хотя и есть системы/платформы в которых модульность на порядок лучше, чем в 1С.
Нет: в рамках платформы 1С сложно отковырять почти любой блок.

Нет: в рамках платформы 1С сложно отковырять почти любой блок.

Уточню — «в рамках методических рекомендаций и типовых решений». Платформа-то никак не ограничивает, ИМХО.
Интересно, а есть примеры расчета себестоимости в виде микросервиса?
Это рост в ширь
А если вглубь? И не в рамках хардкорного хайлоада?
«Вообще, 1С как по мне — это днище, вот есть джуны джавы, пхп или еще чего-то, они находятся внизу иерархии, а «сеньеры» 1С — еще ниже всего этого…»

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

Вот как раз в учетном плане в западных конторах такое древнее/монструозное ПО, что то что оно до сих пор работает реально заслуга их стабильности и неприхотливости налоговых органов.

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

Выше я жаловался на кейс с ручным разбором XML-ек на той стороне — как раз была ИХ древняя учетная прога, и их разраб сказал, что ему проще захардкодить формат, чем реализовать нормальную поддержку XML.
Вот тут бред несете как раз ВЫ. Весь учет экономической деятельности на подавляющем большинстве предприятий в РФ реализован на 1С. Ничего на мировых технологиях и близко не видно с таким соотношением цена+скорость внедрения+возможности. Куча отраслевых решений (типа сельхозучета, сотня решений наверно), ERP системы на заводах и CPM в холдингах, расчет зарплаты. Никто в здравом уме не будет внедрять это все на питончике или даже джаве. Удел этих технологий — сервисы для частных лиц с рюшечками на фронтенде, модные стартапчики или наоборот — суперсовременные системы в научных сферах, ИИ, МЛ и вот это всё.
Но мы же говорим про сферу учета — а для автоматизации предприятий 1С подходит практически идеально, и никто не смог еще написать ничего похожего, хоть на микросервисах, хоть на ООП с паттернами.
Потому что только в конфе «1С: Управление предприятием» больше 3 миллионов строк кода бизнес-логики — кто возьмется всё это переписать? И это только одна конфа, а есть еще «Управление холдингом», раза в 2 больше, для которой методологию учета помогал строить Ernst&Young, и на которой например запустили всего за тройку лет учет финансов во всей структуре Ростеха. Посмотрел бы я как это все писали бы с нуля на джаве, описывая кодом или в DTO в пяти местах каждое поле каждого справочника, там только у договора 400 реквизитов было.
Я знаю примеры, когда один программист запускал мебельный завод в одиночку на типовой 1С ERP за несколько месяцев — поставил, данные перенес и все начали работать, дальше уже рихтовка в мелочах. Как вы тут поможете с паттернами и ООП? В 1С нет ООП и это просто отлично, потому что ты берешь и решаешь задачу в терминах предприятия, а не в терминах СУБД или абстрактных сущностях.
Так что 1С сейчас двигатель экономики и цифровизации реального бизнеса, без нее сейчас были бы зависимы от софта с запада (привет санкции) или в каждой фирме сидел бы штат бухгалтеров и экономистов плюс несколько программистов. Или было бы несколько софтин как в 90-х, несовместимых и отличающихся. И все равно бы появилась 1С но в другом виде и названии.
Я лучше буду решать проблемы, реально проблемы западного человека

Вы, похоже, на эмоциях начали всё в одну кучу валить.

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

Вы бы уточнили и развернули свои мысли что ли, а то очень дико и не серьёзно звучит.
НЛО прилетело и опубликовало эту надпись здесь
Красивый и качественный код не зависит от ЯП.
Зато язык может подталкивать как к написанию хорошего кода, так и к говнокоду.
Точно, а если посмотреть на количество примеров кода на «говнокод.ру», то C++ и С# обходят 1С, вот они — истинные языки для говнокодеров.
Язык подталкивает к говнокоду, марка автомобиля подталкивает к нарушениям ПДД, нож подталкивает к убийству, гениталии подталкивают к изнасилованиям, знак зодиака — к будущей профессии. Так?

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

Если сделать поправку на рыночную долю…
марка автомобиля подталкивает к нарушениям ПДД

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

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

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

Я только мягко намекаю, что виноват в говнокоде не язык, а конкретный человек. Если какое-то решение на 1С без говнокода написать нельзя — возможно, не стоило использовать 1С?
А может быть вмешались экономические факторы и конечному заказчику на говнокод плевать и это было осознанное решение разработчика?
Конечно оффтоп, но говнокод говнокоду рознь и иногда, а иногда и не иногда, виноват в говнокоде таки и язык и среда и сами задачи и сроки и бюджеты, выделяемые на эти задачи и само поведение заказчика и состояние легаси и данных.
И, к сожалению или к чести 1С, тут как посмотреть, в силу специфики работы 1С как раз со всеми этими говнозадачами, говнолегаси, говноданными и говнозаказчиками, говносроками и говнобюджетами им удалось сколотить во многом из бывших и нынешних домохояек общество «программистов1С», таки говнорешающих, но реально решающих в текущий момент на этих вводных данных проблемы пользователей. При том что работу хорошего программиста 1С большинство этих мелких контор в принципе не сможет потянуть финансово. Как и работу хорошего ГБ, хорошего финдира и т.д.
Если владельцы авто конкретной марки совершают нарушения в 2 раза чаще, то действительно стоит присмотреться, может, там спидометр врёт.

Это отличный пример распространенного когнитивного искажения — подмены корреляции причинно-следственной связью.

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

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


Вы таки будете смеяться, но к примеру в Калифорнии при оформлении страховки (даже аналога ОСАГО) не только ее модель учитывается, но и цвет машины при расчете стоимости именно потому, что есть статистика, показывающая что машины ярко-красного цвета чаще творят дичь на дороге. И да, когда владеешь молотком, то все проблему начинают казаться гвоздями.
Я не буду смеяться, я вообще ждал комментариев на тему «водитель BMW». Но я все равно считаю, что «машины ярко-красного цвета творят дичь», это неверный посыл. Дичь творят водители с кризисом среднего возраста, за рулем красного феррари, а не сама машина.
Таки 1с именно подталкивает к написанию плохого кода. Писать хороший код на процедурщине с динамической типизацией куда сложнее. Даже в БСП хвосты этой проблемы видны когда процедурщиной и встроенными объектами платформы пытаются ООП имитировать, но выходит так себе.
Плюс отсутствие замыканий и (еще год назад) асинк/авейт — тоже так себе помошники в написании кода.
Код одного и того же программиста на 1с и на kotlin/C#/dart/java и т.п. всегда будет выгодно отличаться в пользу второго варианта, если он конечно имеет соответствующий опыт как в 1с так и во второй технологии и соответствующих парадигмах/паттернах.
Весьма и весьма спорные утверждения! И это мягко говоря. Здесь уже поясняли разумные люди, что плохой или хороший код зависит от программиста, и только от него!
И потом, все Ваши утверждения голословны. Подтвердите их хотя бы своей практикой. Может чего-то и докажите. А пока только себя выставили в неприглядном виде.
А что подтверждать? Писал 4.5 года на 1с в хорошем франче где прививали в т.ч. и хорошие практики написания кода на 1с. Свой продукт писали. Сейчас 2 года как пишу на котлине. Пробовал еще несколько других языков. Так что могу судить как по своему опыту, так и по многим прочитанным статьям и книгам что статическая типизация и ООП (особенно с элементами ФП) на порядок облегчают написание хорошего кода.
Это даже если забыть про прибитые гвоздями, а не опциональные, архитектуру и некоторые паттерны в 1с, которые когда в кассу конечно хорошо, но когда не в тему — от них не откажешься, что нередко вынуждает городить те еще костыли.
статическая типизация и ООП (особенно с элементами ФП) на порядок облегчают написание хорошего кода.


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

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

ООП — да, тайп хинты — это не типизация, а красивые картинки в IDE
в Go только интерфейсы и есть, и куча костылей как сделать то что надо делать с ООП но без него, а за неявную утиную типизацию я бы вообще руки бы оторвал тому кто это придумал.
Собственно описанные вами причины и есть то почему крупные системы предпочитают на языках вроде java и C# писать, а не на питоне или го.
тайп хинты — это не типизация, а красивые картинки в IDE

В PHP в нестрогом режиме это автоприведение, в строгом это Exception.
Вы когда говнокодите в 1с — вам это нравится?

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

Вы взрослый человек всерьёз вот это пишете на айтишном ресурсе?

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

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

Вы реально так думаете или вы представляете какое-то сообщество (возможно, секту), где ВСЕ так думают?

Лентяи, «имбурдешники», ремесленники, новаторы, исследователи присутствуют везде независимо от сферы айти или даже не айти.
На моем опыте те кто начинали интересоваться миром и технологиями за границами 1с спустя время либо сваливали из 1с, либо готовятся к этому. Многих останавливает только временное понижение в доходах (что кстати не обязательно произойдет).
Вот интересно, что же это за специалисты 1С, которые не интересовались технологиями за границами 1С?! И Вы их приводите в качестве примера?!
Я думаю, что их останавливало не «понижение в доходах», а то, что они не удосужились чего-то узнать за «границами 1С». Им просто некуда идти, да и кому они нужны?!
В системе 1С лучшая корпоративная программа повышения квалификации из всех, что я знаю. Бери и «учись, учись и еще раз учись», как завещал нам наш дедушка Ленин. А Вашему поколению не знаю кто-чего завещает.
Под интересовались имею в виду целенаправленно изучали длительное время, либо писали пет проекты какое то время. Те кто просто прочел книгу/другую или там курс какой прошел не считаются.
В системе 1С лучшая корпоративная программа повышения квалификации из всех, что я знаю.

Мдааа… Как же вам не везло что вы «это» считаете лучшим.
Поверьте долгое время рынок был наполнен предложениями построить учет и некогда было голову поднять. Но с 14го года уж очень много клиентов стали тупо оптимизировать затраты, без развития. Бюджеты режут, задачи мельчают, жирные коты похудели. Смысла дальше разгребать конюшни российского учета все меньше.
Я предпочитаю не верить, а знать, или хотя бы понимать. И «долгое время рынка» знаю не понаслышке. И все, что Вы с такой печалью здесь описали, было всегда. И «оптимизация затрат» и «бюджеты режут» и «жирные коты» всегда худели. А стенания про «конюшни чего-то российского» наслушался до тошноты.
Сами будьте творческим человеком и тогда даже разгребать чьи-то конюшни будет интересно. Глядишь и оценят Ваши потуги.
Подождите, подождите, коллега. «За границы 1С» понятие крайне расплывчатое. Само 1С выстроено аккурат по границе соприкосновения ИТ и учета, являясь своего рода драйвером и выполняя прежде всего функции этого драйвера, предоставляя пользователям «универсальный интерфейс 1С» к ИТ, поэтому не выйти настройщику этого драйвера за его границы даже теоретически невозможно. Вопрос в направлении выхода. И то же 1С долгое время инкапсулировало (да и сейчас тяготеет к этому) всю систему общения с ИТ в свою платформу, предоставляя программисту обширный и неплохой инструментарий решения основных задач учета именно средствами своего языка и своей платформы. И основное направление автоматизации учета в наших палестинах было постановка того самого учета, т.к. с толковыми финансистами, бухгалтерами в стране дело не шибко лучше чем с толковыми программистами. Поэтому по моим наблюдениям много спецов 1С выходили за границы в 1С только не в строну ИТ, а в предметную сторону, ближе к заказчику. Некоторые так и сменили профессию или получили второе образование. К слову их в этом движении более чем активно одно время поддерживало и само 1С. И хочу заверить это очень неплохие и востребованные «что же это за специалисты 1С» (одно время особенно в сфере расчета).

ADD: И в свое время именно выход в этом направлении приносил основной профит, продвижение к целям заказчика и основную премию. А сейчас времена изменились и движение в этом направлении, особенно в долларовом эквиваленте потребления, не является безусловно прибыльным. Не сделает его прибыльным и предлагаемый Вами творческий подход. К слову предложение такового подхода в экосистеме вендора в принципе предложение к его деградации. Благо помним еще времена творческих туробобухгалтеров и еще более творческих RS-балансов.
1. У Вас какие-то странные представления о программах 1С. Они устарели лет на 25. Уже на версии 7.5 можно было строить системы управления, а не только складского учета. А на 8-ке можно решать любые задачи управления любыми объектами. Подчеркиваю — любые!
По моим наблюдениями возможности 1С намного превосходят творческие возможности подавляющего большинства из массы нынешних программистов.
2.
много спецов 1С выходили за границы в 1С только не в строну ИТ, а в предметную сторону, ближе к заказчику
Очень интересное рассуждение, только со знаком минус. Значит Вы утверждаете, что можно программировать не зная предметной области? И есть программные средства, которые сами автоматизируют «предметную сторону» да еще и подальше от заказчика?
3. Ну а сравнение 1С с турбобухгалтером и с «более творческим RS-балансом» просто смешно. Вы их когда сравнивали? Да и где они? Ау!
Честно говоря я уже потерял мысль, которую Вы хотите донести.
1). «А на 8-ке можно решать любые задачи управления любыми объектами.» — Можно, но не нужно. Или попытки решать их этими средствами на данный момент будут походить на камасутру. 1С является платформой с предметно-ориентированным языком и при этом не подразумевает создания ни своих «предметов», ни тем более своих «объектов». И с новой сущностью весь кодинг вырождается в «выразить новый объект посредством структур, соответствий и тз и тд.» исключительно в предопределенных модулях запуска этого кода. В 77плюсах это попробовали обойти, но в 8ке 1С решило что закидает эту дыру множеством новых объектов, которых, видимо, должно хватить всем. И нет, не хватает. Не выходя за пределы самой платформы 1С. Это экзистенциальная проблема подхода. Мне — не хватает. И тот код, та его структура, что я вижу в типовых — очевидно указывает что и самой 1С не хватает. Поэтому что код и сама архитектура решения некоторых вопросов, повторюсь, в некоторых местах похож на камасутру.

2)Я утверждаю что знаю множество спецов 1С которых полностью устраивала подсистема интеграции с «другим ИТ», предоставляемая самой платформой 1С поэтому они занимались изучением мат-части заказчика в чем очень сильно преуспели, вплоть до смены профессий с математика на финансового директора или аудитора. Вы говорите: нет, ты не прав, нельзя программировать не зная мат-части. Я лично не вижу здесь противоречия с моим утверждением, но вижу противоречие с Вашим: «что это за специалист 1С, который». Потому что такие спецы есть и они отличные спецы, без выхода за пределы экосистемы 1С.
И, как мне показалось в п.1. Вы сами топили за такой же вариант. Цитирую: «Подчеркиваю — любые!».

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

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

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

на мой взгляд это процентов 80 всех одинесников

помню объяснял азы http человеку который был очень крутым одинесником, пришлось нам делать связь между сервисами, человек всегда делал через ole, а вебсервисы и вообще все эти get post put и т.п. для него были космическими заклинаниями…
и таких людей в отрасли я очень много видел
1. Вполне с Вами соглашусь. Только признайтесь: а 80 процентов неодинэсников, как «Птица-говорун отличаются умом и сообразительностью»? Как Вы их оцениваете?
2. А «очень крутой одинесник» решил с Вашей помощью свою задачу? Если да, то значит все нормально: он действительно крутой автоматизатор! Так и должно быть: профессионал — это не тот, кто все знает и умеет, а тот, кто умеет найти решение проблемы, или знает где найти и может оценить нужного специалиста.
Если да, то значит все нормально: он действительно крутой автоматизатор!

Ученик, решающий задачу с помощью учителя — не крутой автоматизатор.
Соглашусь с коллегой выше про 80%. Как по мне таких все 90%. Причем действительно, как только активно погружаешься в http, soap, wss, rmq, понимаешь что ты в тоннеле, а там где-то свет.
боты — на 1С?

В ноябре в платформе 8.3.18 появился стандартный объект конфигурации — Бот. ссылка
Создание и подключение эхо-бота в демо Управление Торговлей 11 к Telegram через сервер взаимодействия 1С: Диалог занимает 5-10 минут.
Сервер взаимодействия поддерживает ещё интеграцию с ВКонтакте.
На Инфостарте и без этого объекта куча ботов для различных месенджеров.
1С очень негибкий и ограниченный язык. В принципе оно и понятно — никто из него и не старался делать универсальный инструмент. Поэтому расти там мало куда. Там, где в других языках придумывают новые паттерны, подходы в 1С очень часто приходится копи пастить с трудностями в дальнейшей поддержке, и/или костылить. Увлеченному областью программирования специалисту там с годами становится скучновато и нудновато. Просто возьмите и сравните статьи как сделать что нибудь клевое на блогах 1С и на серьезных языках программирования: то, что публикуют в блогах по 1С как правило детсад для программистов других сфер. И от того, что ты в профессиональной деятельности не столкнешься ни с чем интересным в плане программирования становится печально.

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

Три дровосека. МФ, 1959

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

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

«Разработчик 1С – довольно странное создание. Есть несколько легенд о том, как эти зверушки появились на нашей планете, об этом напишу отдельную статью.»
Было бы любопытно.

Так что да, ситуация складывается уникальная, не характерная для других отраслей разработки, ведь описанные сущности суть неотъемлемые части полноценного организма, икринки паладина, не всем из которых суждено стать крупными осетрами.
Ситуацию усугубляет то, что со времён 6-7 версии платформа стала монолитнее и сложнее в освоении, хотя и более функциональной.

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

Вы там держитесь!

на делос дела
То есть те 1с-дебилоиды, с которыми мне чаще всего доводилось общаться — это скорей всего или 1с разработчик или консультант :))

Это не дебилоиды, а менеджеры.
Менеджер по менюшкам 1С ("консультант"), менеджер по коду 1С ("погроммист"), менеджер по чтению вслух стандартов бухучета ("аналитик"), менеджер по бумажкам ("бухгалтер"), менеджер по банку (платежи сверять), менеджер по менеджерам ("Менеджер", "Ваш менеджер" ("Бонд. Джеймс Бонд.")).

Бинго!

Обсуждали как раз только-что вые особенности поведения менеджеров по продажам.
Логические заключения:


  • на менеджеров где учат? Правильно — нигде.
  • вывод №1: менеджер — это человек без [специального] образования.
  • вывод №2: человеку без [специального] образования одна дорога — в менеджеры. Больше его никуда не возьмут.
не дебилоиды, а менеджеры
Шикарная фраза, возьму на вооружение.

В 2006 году, в августе я последний раз работал программистом 1С. Пришел, выслушал хотелку (как правильно учитывать незавершенное производство ж/б плит в конце периода. Открыл прямо перед главбухом ПБУ и справочник по типовым проводкам, выписал какие ресурсы идут на производство, выписал этапы, сделал типовую операцию и протянул руку за деньгами. Что сделала главбух? Правильно — позвонила знакомой и по её совету попросила меня сделать всё поперёк нормативной документации. На мой вопрос — вы, когда к вам камеральная приедет, как будете это обосновывать, тем, что "ваша знакомая так делает"? Ответ гениальный — ну у неё же прокатило пару лет назад…
В общем это была последняя капля. Я развернулся и ушел оттуда и из отрасли.
Прочитал сейчас и так порадовался, что бросил тогда это всё. Спасибо )

Ответ гениальный — ну у неё же прокатило пару лет назад

правильно, это её геморрой, а не ваш, вы довели до её сведения что она ошибается, но если она всёравно так хочет, то почему бы и нет, «любой каприз за ваши деньги» ©
… я и более страшные штуки делал… и ничё, народу нравилось ;)

p.s. я из отрасли ушел в 09 и в 16 годах (пришлось вернутся по стечению обстоятельств на пару лет), и не потому что там такое как вы описали сплошь и рядом, а просто потому что все задачи одинаково скучные
Есть целый пласт клиентов, которые готовы платить деньги за «кнопки в удобных для них места» и «создать один документ вместо трёх». Проверки органов, методология — глупости. Я хочу так, я за это заплачу. И если вы настаиваете на методологически правильном решении, такие клиенты просто найдут того, кто удовлетворит их фантазии.
Не вижу ничего плохого в удобном расположении кнопок. Если софт будет использоваться годами это имеет еще и практический смысл.
Если для проверок «прокатывало», то значит это известное и приемлемое решение. В справочник по типовым проводкам весь мир не уместишь — там только основные схемы. Если главбух берет на себя ответственность и готов отвечать за свои решения перед Законом, то не нужно перед ним «кидать понты».
Но если клиент по-прежнему платит франчам — то всё нормально же? Или нет?
А какой у них есть выбор? Все жёстко подсажены на 1С — ректальная монополия.
Про выбор — это глубоко философский вопрос, не готов его обсуждать в рамках этой статьи.

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

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

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

На покупку условного SAP годового дохода вашего бизнеса может и не хватить, не говоря уже про оплату ежегодной подписки, кабалу с лицензиями на модули, поиск специалиста, а затем денег, которые Вам нужно будет заплатить этому специалисту. Толку от прекрасной системы, лучших аналитиков и прекрасных программистов, если Ваш бизнес это себе позволить не может.
Это вы сейчас серьёзно назвали SAP прекрасной системой?)
Ну её используют, чего бы это ни стоило в любом смысле… Помнится, двадцать лет назад она стоила $1M, а установка-настройка-поддержка на год — $10M.
Прекрасная, как костюмы от Hugo Ferdinand Boss und Karl Diebitch :) Каждый раз, когда имею дело с описанием их UI, хочется поздравить авторов с 9 мая

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

Потому что просто учет — сложная вещь.
А задача трансформации и трансляции — вдвое более сложная вещь.
Если знаешь один учет — молодец, другой — тоже молодец.
Но чтобы понимать трансляцию из одного учета в другой, надо их оба знать назубок, и не на уровне зубрежа, а понимания, почему они так устроены и что там под капотом у них. И еще дополнительно, нужно понимать сами механизмы трансляций и трансформаций (которых в БФ несколько).
Если человек весь БФ выучил и умеет настраивать — то его можно и на автоматизацию МСФО параллельным учетом выпускать, и на трансформацию, и на трансляцию, и на «управленческий учет из бухучета», такие задачи раньше делались и сейчас делаются целыми командами специалистов, а специалист по трансформации БУ=>МСФО стоит несколько сотен тысяч рублей в месяц, и там везде эти их сертификаты нужны.
Другое дело, что в большинстве случаев весь БФ не нужен, и клиенты пользуются тем что им при внедрении настроили.
НЛО прилетело и опубликовало эту надпись здесь
Есть такой продукт «1С: Бухгалтерия» называется.
На удивление вполне вменяемый продукт «из коробки», в отличие от, например, от УТ11, в которой иногда чёрт ногу сломит.
Да, на УТ 11, раньше тоже плевался после 10.3, но сейчас после детального изучения все больше нравиться УТ 11.
вот видите как вы попались в сети 1С, сейчас вам УТ понравится, потом КА, а потом и ЕРП, ведь и УТ и КА суть вырезки из ЕРП, полученные последовательным исключением опций.
В УТ вообще сложно что-то не автоматизировать и не понять.
полный учет (не важно какой, БУ, УУ или МСФО) мы в ней не собираем, только торговля, купили-продали… а что в ней сложного? посчитали наскоро маржу — и радуемся. данные потом перегрузили в БП, где уже пусть бух мучается и балансы сводит, мы наторговали.

БП 3 очень внимательно сделанный продукт, прямо душа радуется, даже жалею что я не бух. Все делается настройками, все нужные субконто включаются-отключаются галочками, даже изыски вроде факторингов и комиссий продумали, котики везде, опять же. платежи сама отправляет-получает, работает в облаке — погромист и системщик вообще не нужен, что еще нужно для счастья?
например, от УТ11, в которой иногда чёрт ногу сломит.

ЗУП и её пробабушку ЗИК никто не переплюнет
Первое основание этой «такой большой проблемы» не очень качественно составленное ТЗ, т.е. нормативная база.
Второе — очень, скажем так, запущенный процесс обновления этой базы.
Третье — несоответствие этой базы наблюдаемым за окном реалиям.
Четвертое — несоответствие пользователей стоящим перед ними задачами.
При попытке создать что-нибудь «действительно качественное» из этих исходных Вы (или кто другой) при таких исходных создаст продукт во первых сложный, во вторых несоответствующий чему-нибудь из перечисленного, благо им не соответствовать очень легко по их определению.
Опять этот «вырви глаз» — разработчик — кусок программиста. Я понимаю, что 1С на другой планете живет, но если Вы используете заимственную классификацию то делайте, то корректно, а не как фишка ляжет.
Всегда статьи автора читаю до этого пункта, очень интересные статьи, но этот пункт выносит мозг.
Скажите мне наконец откуда Вы взяли эту классификацию, какой ГОСТ, какая методика?
"-Имя сестра, имя! Назови мне его имя сестра!"

Во вселенной 1С верно неравенство Профессионал < Джуниор < Специалист, а вы тут к программист/разработчик придираетесь ;)


Пруф

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

Тут просто «так исторически сложилось».
Изначально сертификация была двух уровней — пользовательский «Профессионал» и внедренческий «Специалист».
В рамках сертификации для «чистых» разработчиков ("… по платформе") те же два уровня оставили, для единообразия. Сертификации же «1С Джуниор» до 2020 не было вообще и она еще официально не является обязательной для получения следующей за ней «лычки».
Всегда считал, что программист — часть умений разработчика. Потому что программист = тот кто пишет программу, а разработчик = тот кто разрабатывает продукт, то есть кроме написания кода ещё и архитектуру и всё сопутсвующее. Но в мире 1с «программист» почему то и с заказччиком общается, то есть выполняет работу аналитика… В общем терминология с ног на голову перевёрнута.
А еще если в тексте статьи заменить «1С» на пустую строку, то ни смысл, ни достоверность, не пострадают.
Вымирающая профессия «1с программист» как и бухгалтерия. Государство уже несколько лет думает как облегчить учет компаниям, а про последнюю новость многие слышали, что Министерство экономического развития России разработало введение единого оборотного налога в размере 6,2% вместо действующих четырех. Не хотят уже считать отдельно НДС, налог на прибыль, страховых взносов и НДФЛ.
Не прокатит. Смысл НДС не в том чтобы им собирать деньги, а чтобы им вынимать мозги бизнесу, делить бизнес на «осмотрительных», благонадежных и потенциально преступников. Недавно так же была и инициатива делить бизнес на три категории а-ля светофор, красный-желтый-зеленый, и красных подвергать например наказанием вроде запрета платежей. А на каком основании делить на категории? Да вот же, какие у вас контрагенты, а подозреваем ли мы вас что вы не так счета-фактуры выставляете и т.п. Единый оборотный налог — это почти не будет поводов нашивки категории присваивать.
pravo.ru/news/227864/amp
В отношении лиц с желтым уровнем риска сохраняется возможность при наличии подозрений в отмывании денег отказать в открытии банковского счета и в проведении операций. Для красного уровня устанавливаются запреты на открытие новых банковских счетов, на проведение любых операций (как собственных, так и в их адрес), запрет или прекращение доступа к услугам по переводу денежных средств с использованием сервиса быстрых платежей (СБП), а также запрет использования электронного средства платежа.
Смысл НДС, как и любого налога как раз в его сборе. И НДС довольно простой налог и, как раз, простота расчета налога тут играет против него.

Касаемо бизнеса, ССЗБ, услуги «по уменьшению НДС» до сих пор довольно популярная услуга. Но и государству тут делать честное лицо не стоит — существенная часть «высвободившихся» таким образом средств направляется бизнесом на «целевую» оплату государственных услуг.
А получается как всегда. Теперь я работаю по 12 часов, чтоб всем успеть рассказать, как они теперь будут сдавать отчетность. Сколько они будут платить за ИТС 1С. И соответственно бухгалтеру. И честный знак до сих пор не все осилили. А уж какой подарок для мелких ларьков сделали(Я про сети)! Теперь каждый продавец имеет навыки эникея, мастера ЦТО! Когда там говорите бухгалтера станут не нужны? Когда мы перестанем сдавать квартальный отчет по алкоголю. Ведь все в ЕГАИС есть. Когда программисты перестанут быть нужны? Ведь все есть из коробки.
Государство уже несколько лет думает как облегчить учет компаниям

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

Вот оборотный налог 6.2, думаете всё просто? А там ведь, авансы, возврат товаров, возврат авансов, перевод собственных средств, перевод собственных средств внутри холдинга, курсовые разницы… как платить с них налог? как возвращать налог на возврат авансов? а если они в долларах? и вот уже правила расчета этого простого налога начинают тянуть на один том войны и мира

Уже 15 лет работаю программистом 1С. Для себя взял важное правило: не притрагиваться к бухучету в принципе, не общаться с бухгалтерами. Зато могу поставить с нуля управленческий учет любой сложности буквально с пустой конфигурации, разумеется, с применением БСП. Встречал и консультантов, и аналитиков, и разработчиков, плохого сказать ничего не хочу, но могу. Найти толкового программиста 1С, который и пользователя опросит, и ТЗ себе составит, и архитектуру продумает, и реализует, и сдаст пользователю, действительно крайне тяжело даже на 160.000 рублей.

крайне тяжело даже на 160.000 рублей.

проблема в том что никто практически не ищет на такую сумму специалистов в этой отрасли. просто открыть hh и выбрать десяток вакансий как в случае с явой или питоном — не получится.

Мне вот проще было свалить из отрасли чем быть архитектором за 160тыр и ж… рвать (а что вы не знаете УПП/ЕРП/КА и сертификатов нет? Нуууу… мы вам только 60к можем предложить, досвидания)
Мне вот проще было свалить из отрасли чем быть архитектором за 160тыр

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

только попробуй такую работу еще найди и 'И опыт нужен огромной, по моему мнению не менее 15 лет. " — вот вот

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

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

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

Вы так аккуратно себя похвалили, что не все поняли, что сказочный богатырь Программист 1с, который "прийдет и порядок наведёт" это Вы.
Мы прекрасно помним творения чудо богатырей, как то перегруженные элементами, кнопками формы.
Функции типа:
Функция ВернутьПять()
Возврат 5;
КонецФункции
Пустые процедуры в БСП.

тем временем(конечно вырвано из контекста, но все же) в типовой конфе.
Заголовок спойлера
//! workaround
Если ПараметрыФискализацииЧека.ТипРасчета =		ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств") Тогда
					
ПараметрыФискализацииЧека.ТипРасчета =					ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ВозвратДенежныхСредств");
ИначеЕсли ПараметрыФискализацииЧека.ТипРасчета =
					ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ВозвратДенежныхСредств") Тогда
					
ПараметрыФискализацииЧека.ТипРасчета =
						ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств");
					
КонецЕсли;
				
Результат = МенеджерОборудованияКлиент.ВыполнитьФискализациюЧекаКоррекцииНаФискальномУстройстве(			ПодключаемоеОборудованиеКлиент.ИдентификаторКлиентаОборудования(),
					ОборудованиеПечати,
					ПараметрыФискализацииЧека,
					ВыходныеПараметры
				);
				
//! workaround
Если ПараметрыФискализацииЧека.ТипРасчета =		ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств") Тогда
					
ПараметрыФискализацииЧека.ТипРасчета =			ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ВозвратДенежныхСредств");
					
ИначеЕсли ПараметрыФискализацииЧека.ТипРасчета =				ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ВозвратДенежныхСредств") Тогда
					
ПараметрыФискализацииЧека.ТипРасчета =		ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств");
					
КонецЕсли;

Вот интересно, почему примерно тоже самое на английском мозг воспринимает нормально, а на русском — хочется блевануть?
У меня, конечно есть догадки (на английском мозг не пытается читать текст на формальном языке, как на жийтеском), но надо бы поискать соответствующее исследование.
И как только программируют англоязычные программисты…
Это не потому что на русском. а нарушение правила «максимум три слова» в именовании.
MostHighlyValueFromDatabaseOrAnyRandomValue() — и так везде, гарантированно сведёт с ума.
Код с картинки и на английском будет выглядеть тем же говнокодом с магическими строками, несколькими ответственностями, копипастой и многословностью.

На что собственно и намекает "//! workaround". Обход это всегда говнокод.

Тут дело не в том что это обход, а в том что строки можно было бы вынести в константы, само изменение типа расчета в отдельный метод.
Как то так
Результат = МенеджерОборудованияКлиент.ВыполнитьФискализациюЧекаКоррекцииНаФискальномУстройстве(
    ПодключаемоеОборудованиеКлиент.ИдентификаторКлиентаОборудования(),
    ОборудованиеПечати,
    ПараметрыФискализацииЧека.СТипомРасчетаДляФискализации(),
    ВыходныеПараметры
);

.............

Функция ПараметрыФискализацииЧека.СТипомРасчетаДляФискализации()
    ПриходДС = ПредопределенноеЗначение(ПРИХОД_ДЕНЕЖНЫХ_СРЕДСТВ)
    ВозвратДС = ПредопределенноеЗначение(ВОЗВРАТ_ДЕНЕЖНЫХ_СРЕДСТВ)
    Возврат Скопировать(
        ТипРасчета = Если (ТипРасчета == ПриходДС) Тогда
            ВозвратДС
        ИначеЕсли (ТипРасчета = ВозвратДС) Тогда
            ПриходДС
        Иначе
            ТипРасчета
        КонецЕсли;
    );
КонецФункции

Конст ПРИХОД_ДЕНЕЖНЫХ_СРЕДСТВ = "Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств"
Конст ВОЗВРАТ_ДЕНЕЖНЫХ_СРЕДСТВ = "Перечисление.ТипыРасчетаДенежнымиСредствами.ВозвратДенежныхСредств"


это могло бы выглядеть на чуть более выразительном языке.
Впрочем даже на 1с можно было бы вынести смену типа расчета в отдельный метод, предопределенные значения в локальные переменные, и код уже бы стал куда лучше.
  1. Это не волшебные константы, это поддержанные IDE метаданные. То, что они в кавычках это такое слегка недоразумение/особенность языка. Выносить в константы смысла нет, и вроде в курсеровском курсе по андроид имена ресурсов тоже в константы не пихали, но кроме этого курса я за пределы 1С особо не выбирался.
  2. Судя по тому, что перещелкивают значение не только перед вычислением результата, но и после, то эта структура используется где-то ниже. Возможно во время "ВыполнитьФискализациюЧекаКоррекцииНаФискальномУстройстве" в неё что-то пишется и заменять переменную вызовом функции может быть ошибкой.
    Хотя 2 раза повторяющийся одинаковый блок просится на выделение в функцию. Но она будет всего из 5 строчкек, и добавить еще пару на заголовок и конец, так что экономия 3 строки.
Это не волшебные константы, это поддержанные IDE метаданные. То, что они в кавычках это такое слегка недоразумение/особенность языка. Выносить в константы смысла нет, и вроде в курсеровском курсе по андроид имена ресурсов тоже в константы не пихали, но кроме этого курса я за пределы 1С особо не выбирался.

Имена ресурсов не выносятся так как и так уже вынесены. R.string.something это уже константа а не ее имя. И проверка идет на этапе компиляции. В 1с же строковые имена метаданных хоть и могут в автокомплит, но при сохранении конфигурации проверка не происходит.
Судя по тому, что перещелкивают значение не только перед вычислением результата, но и после, то эта структура используется где-то ниже. Возможно во время «ВыполнитьФискализациюЧекаКоррекцииНаФискальномУстройстве» в неё что-то пишется и заменять переменную вызовом функции может быть ошибкой.

Именно поэтому в приведенном мной варианте я не изменяю значение поля, а копирую объект и меняю значение только в копии. Это как раз тот сахарок про который писал в комментарии выше.
А оригинальный объект остается без изменений. Это избавит от возможных ошибок если кто то забудет добавить возврат поля в изначальное состояние, или подумает что это дублирующийся код и его нужно удалить.
Хотя 2 раза повторяющийся одинаковый блок просится на выделение в функцию. Но она будет всего из 5 строчкек, и добавить еще пару на заголовок и конец, так что экономия 3 строки.

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

Именно это и опасно. Функция поставит в вашей копии "Фискальный УИД = 123"
а потом будет использоваться оригинал с Фискальный УИД = 0 и 123 потеряется навсегда.


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

Повторяю:


МенеджерОборудованияКлиент.ВыполнитьФискализациюЧекаКоррекцииНаФискальномУстройстве(
    ПодключаемоеОборудованиеКлиент.ИдентификаторКлиентаОборудования(),
    ОборудованиеПечати,
    ПараметрыФискализацииЧека.СТипомРасчетаДляФискализации(),
    ВыходныеПараметры
)

внутри будет иметь строчку


ПараметрыФискализацииЧека.ФискальныйУИД = 123;

И ваше оборачивание в функцию приведет к ошибке. Так как снаружи этот 123 потеряется. Потому, что будет уставнолен в копии, а не в объекте.


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

Так как снаружи этот 123 потеряется.

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

С точки зрения здравого смысла "Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств" это в чистом виде магическая константа, строковый литерал наделённый особым смыслом в голове разработчика.


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


"Объявление в одном месте" происходит в дереве метаданных.

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

Это не более магическая константа, чем обращение к любому методу класса и объекта во «взрослых» языках программирования.

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

Если и заводить константу, то сразу для всей конструкции ПредопределенноеЗначение(«Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств») и при условии, что их больше 1 в текущем модуле.
Конст ПРИХОД_ДЕНЕЖНЫХ_СРЕДСТВ = "Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств"

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

Код
ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств") 

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

"В тем времена далёкие, таперь почти былинные" (с) В.С. Высоцкий, (конец 90-х, начало 2000-х), когда я закончив ВУЗ, начал свою трудовую деятельность, прикладной программист, обслуживающий бухгалтерию, должен был знать эту самую бухгалтерию на уровне хорошего бухгалтера. Так вот. Читая ваши материалы, у меня всё время вертелся вопрос: а какова сейчас ситуация в этой сфере. И вот вы отвечаете на этот вопрос. Фантастическая фантастика, однако!
ЗЫ. На самом деле ситуация — она по отрасли в целом такая, не только среди 1С-распространителей.
Эффективный манагемент во все поля: для того, чтобы корова давала больше молока, её надо больше доить и меньше кормить. :(

Что-то уж слишком мрачно и всех под одну гребёнку...

Собственно, не так уж на деле всё плохо. Здесь, в первую очередь, следует обратить внимание на то, что автор высказал в самом начале: «Всё сказанное в тексте является сугубо моим личным мнением».
То есть, на всеобщность и целостность понимания и раскрытия состояния отрасли он и не претендует. Это — взгляд конкретного человека из конкретного положения.

Система 1С: Предприятие осваивает новые пределы — крупных промышленных предприятий и холдингов, финансовых и торговых компаний национального масштаба, и, сфера разработки и адаптации прикладных решений закономерно трансформируется, приспосабливаясь к новым условиям и новым требованиям.
На языке вертится фраза, что время одиночек-энциклопедистов прошло,… но дело не во времени. Рискну применить такую аналогию: можно продолжать в одиночку скакать по скалам выискивая траву на уступах и в трещинах, или же — спуститься с гор на сочные равнинные пастбища, где, хочешь-нехочешь, а придется сбиться в стадо (с соответствующим разделением труда, кооперацией и координацией), чтоб отбиваться от хищников.
Где-то с 2014, 1С для сокращения затрат все чаще советует заниматься сразу «моделированием» — это значит этап составления ФТ, ТЗ, пропускается, и сразу настраивают в программном продукте то, что хочет заказчик.
По сути вместо аналитика, консультанта и программиста должен быть один человек, который делает сразу всё. И в основном занят именно конфигурированием, то есть включением-изменением опций, вводом настроек, НСИ.
Официальное объяснение — что продукты 1С, особенно флагманские конфигурации (ЕРП, БП, УХ, ДО) достигли такой зрелости, что программировать там не надо.
Очевидное объяснение — клиенты руководствуются расценками и пониманием объема работ 20-летней давности, а при этом доработать тот же ЕРП нетривиальная задача. То есть хотелка пользователя — это выливается в либо «а, и так сойдет», либо «ой как дорого, давайте тогда без этого».
О какой «зрелости» вы говорите?! Посмотрите где-нибудь на сайте госзакупок сколько стоит обслуживание или, не дай бог, внедрение, какой-нибудь «флагманской» конфигурации в более-менее крупной организации. А сколько у официальных франчей заваленных проектов? Это что, из-за «зрелости»?
А предложите-ка типовой продукт от 1С для торговой сети из 3000 магазинов?

Для каких задач?

Не для бухучёта и расчёта ЗП :))
И все же уточните: фронт, склад, логистика, управления цепями поставок, планирование закупок, бюджетирование и казначейство, документооборот или еще что имеете ввиду?
Ну, пусть будет бэк продаж и закупок. А так, по-хорошему, лучше бы всё в одном, ну кроме складской WMS, конечно :)
В целом, ERP имеет немало кейсов внедрения в крупной рознице именно в качестве бэка по закупкам и продажам. Но уверен на 100%, что она сильно уступает таким монстрам, как SAP, Oracle и Axapta. Все-таки эти модули довольно консервативны и универсальны для большиснтва стран мира, поэтому тут у них явно сильнее позиции и методологии.

Насчет всего в одном тоже так думал раньше, но практика показывает, что это не лучшее решение. Просто редко когда один вендор сильнее всех во всех необходимых модулях. Поэтому часто можно видеть солянку из разных систем от SAP, 1С, Oracle, MS и других.
Интересно было бы узнать, где в крупной рознице используется 1C ERP. Я о таком не слышал.
Пардон, а где в ваших ссылках про 1С ERP? Просто про крупные розничные сети на платформе 1С и я порассказать могу, причём из практического опыта :)
Справедливости ради, 1С: Предприятие 8. Управление аптечной сетью — это отраслевка на базе УТ 11. Т.е. тот самый бэк розничной торговли, что вы и спрашивали.

Конкретно по ERP можно рассмореть тот же Бетховен, насколько мне известно.

Гулливер: v8.1c.ru/applied-solutions/797028

Розничная сеть оптик: v8.1c.ru/tekhnologii/tekhnologii-krupnykh-vnedreniy/vypolnennye-proekty-tsktp/1c-rarus-tekhlab/cts-202-018

Но тут я скорее признаю свое бессилие в сборе подтвержденной инфы, так как работа 1С с историями успеха и внедрений довольно топорная.
Эльдорадо. В Украине так 100%.

Это совсем не то значит.
Моделирование это подход к созданию ТЗ. На обследовании берем типовые операции/процессы заказчика, как есть забиваем в ЕРП. Формируем требуемую отчетность.
Выписываем все места, где возникли трудности с вводом, необходимость ручных операций, каких отчетов не хватило.
По выписанным местам рисуется ТЗ.
ФТ косвенно генерируется на этапе подбора процессов для моделирования.

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

Я начал работать в 2005 году, и тогда никто не пользовался термином «разработчик 1С». Были только программисты и консультанты. Соответственно, те люди, которые работали тогда, с их знаниями, подходами, результатами — программисты. Потому что они себя так называли.
Сейчас есть люди, которые называют себя разработчиками. Думать долго не надо — раз сами себя так назвали, будьте разработчиками. Со своими знаниями, подходами и результатами.

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

Не проблема по прошествии лет переименовать профессию, но факт останется фактом: в нулевых люди называли себя «программисты 1С».
А ведь есть ещё «внедренец»…
Автор отчасти прав. Но бывает и обратная сторона медали. Не раз приходилось взаимодействовать с такими былинными богатырями 1С (у самого стаж лишь 7 лет в 1С, и я фулл-стэк), которые с нулевых уже с семерки варятся в 1С. Да, у них обширный кругозор, они и кодят, и методологию знают, и ТЗ напишут, и внедрят. Везде по-немногу, эдакие универсалы. Но зачастую (не всегда, но часто) хорошо они не делают ничего из перечисленного. Ведь универсал — он и есть универсал, full-stack по-импортному, он не является экспертом ни в чем по отдельности. Платформа развивается, сообщество 1С тоже, очень многие практики кодирования заимствуются из других языков. Зачастую новый программист, зеленый, не знающий, как в статье правильно заметили, зачем разрабатывается тот или иной механизм, нормально реагирует на использование современных методов БСП, разметку кода на области, применяет практики структурирования кода, как в Java, и т.д. Словом, он узколобый программист, не чета герою-универсалу, но он делает свое дело хорошо. Лучше, чем былинный герой, эдакий дедуля лет 50, за котором откроешь код, а там методы по 10 листов A4, в которых и записи документов в транзакции, и тут же какие то получения данных, и еще и вывод результата на экран. Оно все, да, работает, но написано настолько олдскульно, что поддерживать это не представляется возможным и желаемым. Этот дедуля смотрит на современные БСП, где запрос в отчете СКД не написан, а собирается по кусочкам из других модулей, рыдает, и делает для пользователя новый отчет по-своему, по-старому, чтобы в типовом не разбираться, потому что непривычно. Я таких примеров навидался. И спорить стакими «опытными» дядями сложно, указывая на их ужасный стиль и подход к работе. Но не все такие, конечно. Я все это к тому, что если на рубеже 10х годов герои могли существовать, на тот момент возможно было объять и кодирование в хорошем исполнении, и методологию, то сейчас… Все так развилось: GIT, различные шины обменов, огромные и сложные конфигурации типа ERP, УХ, сложные методики управления проектами 1С, мобильные приложения, веб-клиенты и т.д. — слишком много областей. Быть универсалом и разбираться во всем, что касается 1С сейчас, в 2020 году, на мой взгляд, невозможно. Необходимо делиться по компетенциям, и быть сеньером в своей области. Отсюда и возникают программисты, разработчики (архитекторы), аналитики, консультанты. Да и их я бы еще поделил. Программист — в какой области спец? Аналитик — в чем спец? Ох уж эти универсалы, могут все, но сперва поковырявшись, разобравшись, научившись этому на твоем же проекте. А первый блин…
У таких былинных богатырей часто просто нулевое желание и мотивация изучать, как и зачем стандартная конфигурация работает, почему она так устроена, как с ней надо работать, каков типовой сценарий работы с ней.
Им проще написать заново и свое, чем искать способ типовыми средствами.
Обращаться к ним нужно только после того, как прошерстили всю конфигурацию, перечитали все мануалы и решения так и не нашлось.
P.S. Был удивлен, что ЕРП 2.5 уже пишется на EDT. Молодцы, не забросили.
а собирается по кусочкам из других модулей,

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


О, а вы пробовали разбираться в ЗУПе?
Где динамически строится запросы к базе с использованием вирт.таблиц, когда 'тут запрос выполняем, контекст в уме держим, здесь в модуле пару табличек дропнем, там добавим'… и это размазано по 150 процедурам, причем контекст чудрым образом в памяти гдето висит… и падает оно гдето на 76 методе… я помнится по 2-3 часа собрал этот запрос в одну кучу чтобы подебажить… реально было желание всё бросить и поехать в 1С бить лицо тому кто это придумал.
Вот сама по себе идея модульной работы на sql сервере — здравая. Т.е. компонуешь запрос из готовых модулей. Если надо получить список сотрудников (и в нем ошибка) ты правишь один запрос в одном модуле и знаешь где он лежит, а не повторяется в 100500 местах в разных запросах. Плюс этот модуль протестят все его пользователи, т.е. он будет чуть более чем идеален. То что временные таблицы на скуле лежать будут — ну где то то они да должны лежать, отчего не на скуле?
А вот реализация, конечно, вышла ущербной.
Ну вот если бы оно было реализовано в виде, допустим, отдельных схем СКД… Да, по производительности бы проседало, в отличие от голого запроса, но хотя бы не было текущим воплощением зла, когда можно часами в отладчике сидеть и по модулям скакать, делая в тетрадочке пометки, чтобы хотя бы примерно понять что вообще происходит =)
//Тут вообще такой философский финт вышел: сначала создаем свою структуру БД и язык которые (в ущерб скорости) во первых должны быть легки в создании, во вторых легки в программном сопровождении. Грохаем этим некоторые базовые возможности производительности на корню. А после на этом «понятном и легком в сопровождении» языке и структурах пытаемся оптимизировать эту самую производительность за счет уже потери легкости создаваемого кода. И то, что используется «упрощенный язык и объектная модель» практически перестало спасать продукт от конечной сложности. Один хрен нужны спецы, способные в этом разобраться. Круг замкнулся. Попытка создавать сложные вещи простыми очевидно в данный момент подходит если не к своей начальной точке, то к следующему витку. И вот тут вопрос — плюнут ли на «упрощенный язык и объектную модель» создатели, т.к. он уже по факту перестал быть упрощенным, а стал вполне себе сложным, вдобавок тупо не описанным (что сильно усложняет сопровождение на нем) или придумают способ перебросить всю эту сложность снова в платформу и снова «железо вытянет» (однако железо уже не тянет, а то, которое тянет стоит очень даже реальных денег).
А после на этом «понятном и легком в сопровождении» языке и структурах пытаемся оптимизировать эту самую производительность за счет уже потери легкости создаваемого кода.

Согласен. Примерно такой же мрак происходит на уровне метаданных, когда для получения нужных индексов/возможности параллелить обработку данных вовсю используются конструкции «Динамический список из подчиненных объектах вместо табличной части», хранение ТЧ в регистре сведений, конструкции из нескольких объектов, т.к. в одном уже невозможно реализовать нужное поведение. И это в одобренных типовых решениях (в книжках и стандартах, что забавно, о таком почему-то не пишут =) )
Ну и вся БСП целиком из такого состоит =)
ну где то то они да должны лежать, отчего не на скуле?


ну как это выглядит то?

Падает запрос, типа РасчетЗП.Расчет() 234324
открываешь код, а там Запрос.Выполнить(текстЗапроса)
открываешь текст… написано 'выбрать данные из результат'… идешь на шаг назад, написано текстзапроса += ИмяТаб[ВыбСтрока+5]… еще на шаг назад… запрос.выполнить(ТекстЗапроса); текстЗапроса= 'выбрать '+данные[текстрока+4353]+' из'
и блин ты еще на 2м шаге из 150, а уже ничерта не понятно что вообще происходит
На такие претензии забавно читать ответы причастных — «да все нормально, я вот вообще за последние N лет не лез код исправлять, внедряем как есть, все отлично работает». Так что вы просто «не вписались в рыночек».
На такие претензии забавно читать ответы причастных — «да все нормально, я вот вообще за последние N лет не лез код исправлять, внедряем как есть, все отлично работает».

так в том то и дело что никто туда не лезет из-за зашкаливающей наркомании в коде, потому что проще подстроится под программу чем программу под себя. У меня был вхлам перепиленный БИТФинанс который очень активно кастомизировали и ЗУП который старались не трогать ибо чревато и даже по пустякам он отжирал кучу времени.
Не просто так среди одноэсников, ЗУПовцы это отдельные, особо ценящиеся люди.

Так что вы просто «не вписались в рыночек».

Это рыночек в меня не вписался, а не я в него
Могу только сказать как это должно выглядеть (очень примерно, не брать как пример):
Открываешь код а там: РасчетЗП.Расчет():
ПодготовкаДанныхРасчета(); //результат Вт_Сотры, ВТ_Табель, ВТ_Показатели;
РасчетБазовыхНачисленийУдержаний(); //результат ВТ_НачисленияУдержания
РасчетЗависимыхНачисленийУдержаний(); //Результат ВТ_ЗависимыеНУ
РасчетНалогов(); //Результат ВТ_Налоги
ПеренестиВРегистрыУчета(); //Пишем ВТ в регистры
После каждого запроса на скуле лежит таблица с результатом запроса. гонять ее на сервер предприятия и обратно нет смыла, управляется все менеджером временных таблиц у которого (вот тут не могу сказать как сейчас) инструментов для дебага этих временных таблиц нет. Т.е. сделать точку останова и посмотреть что собственно в данных без переписания кода именно для этого никак нельзя. Да и собственно оставляя за собой возможность дебага на скуле мы повышаем на него нагрузку — все эти ВТ нам придется хранить до конца исполнения кода (или выписывать в тетрадочку промежуточные результаты).

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

//но это в парадигме что мы оптимизируем передачу данных между скулем и предприятием и реализуем логику на скуле, что само по себе противоречит первоначальному замыслу: данные в БД, логика на предприятии.
Сейчас: Табло>МенеджерВременныхТаблиц.Таблицы[0].ПолучитьДанные().Выгрузить()
Я как раз тот дедуля 50 лет с опытом работы в 1С больше 20 лет. Я не просто универсал, супер универсал, так как ещё и франчайзи. Подобрать и продать клиенту нужный продукт тоже важно. Зачем впаривать ERP если хватит КА2. Или зачем КА2 если подойдёт УНФ.
Почему люди программируют в 1С, сейчас хорошо рассуждать, а в 90-е была другая реальность. Начинал писать на C, C++. Успел поработать год в осколке НИИ создавшем то чего не было в США и Японии. К появлению 1С 7.0 Торговля и Склад у меня была своя подобная система на Delphi, проработавшая в 3 фирмах несколько лет. Выбора не было. Ну не нужно никому, в то время было твое знание объектно-ориентированного программирования. Только эмигрировать, удалённо тогда не поработаешь.
А вот для корявого 1С 7.7 был дефицит «программистов».
Сейчас 1С продукт мирового уровня. Быть спецом во всех областях её
применения сложно. Но и не обязательно, выбираешь свою сферу.
Главное, что даёт мне работа с 1С, это независимость. Я могу стать узким специалистом и получать больше, но тогда придётся пойти работать на дядю, но поверьте дедуле, есть вещи дороже денег.
А ведь действительно были достойные продукты, нередко более функциональные чем 1С. Но по мере роста франчайзинговой сети 1С они вытеснялись с рынка, ведь рост количества их внедрений был ограничен физическими возможностями разработчиков, а без поддержки продукт неживой. Это сейчас небольшой разработчик может заниматься глобальной поддержкой своего продукта удалённо, раньше нужно было поработать ногами.
Вероятно, создание партнёрской сети оказалось определяющим для успеха 1С.

Хорошие аналогии. Не только в 1С так, во многих отраслях.
Я теперь наконец-то знаю кто я — кусок инженера.

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

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


Disclaimer: сам лично не тыкал 1С, никогда не писал в нем и имею представление о нем по рассказам знакомых «пузырей» и «соломинок». «Лаптей» и программистов 1С в жизни не видел ни разу...


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


Банальный пример по моему региону. Фирм занимающихся 1С у нас много. Настолько много, что в любом уважающем себя офисном центре есть как минимум одна такая компания (ИМХО, во всех офисных центрах где я бывал они были).
Как выглядит средняя по региону компания с 1С? Один-два арендованных кабинетика в разных концах здания, компы собранные в 2007м году с windows xp на борту, задолбаные жизнью сотрудники, мебель взятая «за самовывоз» с некоторого сайта объявлений и вишенка на торте: овнер, который после осмотра вышеописанного воодушевляет тебя словами «мы самая о***енная компания во всем городе, у нас в клиентах аш сама [крупная_сеть_магазинов_у_дома]». Это вот прям без шуток, усреднённое описание, которое я слышал от людей, которые бывали в этих фирмах.
Обучение новых сотрудников заключается в просмотре видосиков с тех самых компов из 2007го. А если нет, то это стажировка на несколько месяцев на условиях «вот пройдёшь хорошо, заплатим» (попахивает крепостным правом). Ну и далее в таком духе.
Я уже не говорю о зарплате, которую они предлагают…
А более крупные компании (у которых 1С это только одно из направлений) совершенно не заинтересованы в студентах и людях без опыта.


Краем глаза видел ещё и вебинары по 1С… Там ведущие выступают явно из-под палки. И, кажется, готовы повеситься прям во время вебинара, передавая это настроение всем слушателям оного.


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


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


А вот конкретно с чем категорически не согласен.


Мысль первая. Цитата: «Разрабы, соответственно, это всё сели учить.» Не понимаю почему это плохо.
Ведь это и есть суть эволюции любого познания, когда ты из существующих знаний создаёшь что-то новое.
Это примерно как появление высокоуровневых ЯП.
Или, ещё лучше пример, как расширение стандартных библиотек языка.
Возьмём java.time: мне не нужно париться по поводу перемещения юзера между тайм-зонами, учитывать переводы времени и прочие сложные штуки, связанные со временем. Все эти задачи уже решены в стандартной библиотеке. И я могу ее использовать затратив меньшее количество времени на то, чтобы работа с таймзонами и переводом времени с летнего на зимнее появилось у меня «в крови», как у «первопроходцев».


Мысль вторая. Цитата «широкий набор красиво упакованных методик чего-угодно-про-IT, вроде девопса, скрама, управления техническим долгом, сценарного тестирования, цифровизации, BI, бигдаты и т.д. Процент и качество применения этих знаний в реальной жизни у разрабов 1С примерно такой же, как в большом мире IT – что-то в районе нуля.».
Вообще нет. Вот просто триггернуло у меня на этом. Процент и качество применения этих методик в большом мире IT целиком и полностью зависит от компетентности менеджеров которые вводят эти вещи (в бОльшей степени), а так же от компетентности подчинённых, которые эти вещи исполняют.
Само собой, если эти методики вводят просто потому что «гы а чо мы ойтижнеги чо хуже других шоль», а не с полным осознанием их необходимости, то толку от них действительно ноль.
Может быть мне повезло с компанией, а может быть я живу в мире единорогов и щенят, но у нас, если оторвать взгляд от книжек по методологиям разработки, то можно увидеть что 85-90% процессов работают в полном соответствии с этими самыми книгами.

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

Вообще, разделение — хорошо. В конкретной области (1С) — (с точки зрения заказчиков) — зло. Почему? Потому что 3 сотрудника стоят дороже одного сотрудника, а заказчики в сфере 1С к такому не привыкли.
И (ИМХО) существует кадровый голод в сфере 1С, по части хороших аналитиков, хороших программистов и т.д. Возможно, со временем ситуация исправится (заказчики привыкнут, что цена выросла, но зато будут получать более качественные услуги) или не исправится («большое IT» окончательно засосет всех молодых специалистов, а старые уйдут на пенсии), посмотрим.

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

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

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

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

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

И тут мы возвращаемся в начало — в сфере 1С ИМХО, хуже обстоят дела с компетентными менеджерами и мотивированными сотрудниками. С учетом количества слез, которые на хабре проливаются на тему скрама, аджайла, даже в «большом мире IT» с ними не все хорошо.
А теперь учтем, что хороший менеджер сможет с одинаковой эффективностью управлять проектом и на 1С и на Java, а потолок зарплаты на Java может быть выше и попробуем угадать — где чаще будут встречаться компетентные менеджеры и успешные примеры скрама, а где — карго-культы?
Интересно, а откуда пошло, что разработчик это кусок программиста, а не наоборот? Я вот всегда считал, что программирование это лишь часть разработки продукта, куда кроме программирования входит методическая проработка решения для предметной области, проектирование интерфейсов, работа с обратной связью от пользователей, например.
Спасибо, поржал.

Но не вижу ничего плохого в разделении труда на аналитика и программиста. Видимо вне сферы 1с — это все же стало более общепринятой практикой. И вакансии где программист должен делать всё — получают порцию критики за человека-оркестра. Да, для разделения труда нужно строить процессы и взаимодействие между участниками команды и заказчиком (ну всякие там аджаилы же), что удорожает. Вне сферы 1с участники так же имеют разную квалификацию. Может в светлом будущем все наладится. И будет найден оптимальный формат взаимоотношений.
Там скорее не про разделение труда, а про замену одного специалиста тремя малокомпетентными людьми, которые могут только что-то одно и могут это плохо.
Вы меня очень повеселили.
но не от хорошей жизни это.
Наблюдаю нечто подобное и в геофизике. К сожалению.
Так вот почему я не помираю с голоду на фрилансе 1800 в час.
Всё потому что я тру-программист, который заменяет эту троицу.
Спасибо, польстил.
Эвона кто тут нашёлся…
ндык
Автор как обычно пишет на интересные темы, но слишком обильно набрасывает для большего кипения. Ну да, есть разделение по функциональной специализации, есть проблемы с кадрами по причине роста рынка и масштабов внедрений, и что? Это текущие рабочие вопросы, все кто в индустрии их решает с разной успешностью, рынок показывает кто лучше кто хуже. Принципиальные выводы какие?

А комментаторы из взрослых языков и технологий какие альтернативы предлагают? Есть реальные конкуренты 1С для автоматизации среднего предприятия в разумные сроки и бюджеты?
Комментаторы в основном считают, что ограничиваться рынком России — моветон :)
Может что то могут предложить не из России?
Я вот знаю с десяток проектов на 1С не в России, и даже не в СНГ
Ну, вы сами ответили — всего десяток проектов…
Ну это только то что я знаю
А вот успешной замены 1С чем то другим не знаю и десятка
Автор забыл описать одну важную часть процесса. Это превращение самой 1С из простого и понятного программного продукта, который можно было понять самостоятельно, в тупого неповоротливого монстра, который сейчас является скорее маркетинговым макетом для презентации, чем программным продуктом.
Понятно, что расчет сложность задач, которые должна решать система, но качество разработки внутри самой 1С катастрофический падает. Код той же УПП ещё можно довольно легко читать, за исключением некоторых модулей. Внутренности же современной ЕРП — это понос на стенах: в документах километрами идет непонятный код. Отсутствуют даже зачатки архитектуры.
При этом главная фишка современной 1С — структура базы со всеми этими уже готовыми механизмами регистров, правами доступа, модулями, средствами разработки, СКД, в конце концов — всё это в итоге хоронится бредовыми методиками учета (который 1с придумывает), кривыми бизнес-процессами, уродским интерфейсом, маркетингом на грани обмана.
Это превращение самой 1С из простого и понятного программного продукта

типовых конфиг, народ не понимает что платформа и конфиги — это разные вещи
Какую систему можно привести в пример как должно быть?
Соизмеримой сложности и универсальности
НЛО прилетело и опубликовало эту надпись здесь
Простите, я, может быть, неправильно понял вашу мысль, но вы утверждаете, что современные продукты 1С имеют интерфейс уровня MS DOS?

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

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

Относительно отчета, если говорить про прибыль с точки зрения БУ и НУ, то, дейстивтельно, чаще смотреть нет смысла. Но если смотреть аналоги по управленческому учету и операционному, то вполне есть смысл оцнивать оперативные показатели.

Если я вас не так понял, то поправьте.
Мне кажется как раз неоперативное проведение очень большое зло 1С-овцев

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


Если взять почти любую учетную систему для SMB, то там почти везде реализован неоперативный учет с, фактически, перепроведением документов. И я говорю про решения для США и Германии.

НЛО прилетело и опубликовало эту надпись здесь
Ну, хоть так, а то совсем удивился про UI. Но на самом деле сейчас 1С уделяет очень много вниманию UI/UX своих решений. И стало все намного лучше, в сравнении с 7.7, 8.0, 8.1 и даже 8.2.

Можно легко посмотреть современные демки, чтобы понять, что 1С ушло далеко: 1cfresh.com/solutions. Тот же 1С: Предприниматель очень хорошо смотрится (по сути это урезанная настройками бухгалтерия). Но для любого решения UI можно сделать лучше. Всегда.

Именно для избегания перепроведения всего и вся и делается восстановление последовательностей по областям учета: НДФЛ, партии, себестоимость, маржа и прочее. Тогда идет пересчет только нужных данных. Но во многих решениях (чаще всего старых) это не реализовано, поэтому проще перепровести все документы. Тут все же необходимо понимать конкретные кейсы.
НЛО прилетело и опубликовало эту надпись здесь

ИМХО управляемые формы против обычных это холивар. "Такси" явно лучше первых управляемых, но когда нужно много полезного на экране обычные формы недостижимы.
Большинство документов было вынуждено уйти на многостраничную верстку там, где раньше все спокойно помещалось на одном экране.
Самый вопиющий пример — табель в Зарплатной конфе.
Раньше помещался весь месяц для 16 человек, теперь полмесяца для 7-8 (фул ХД). Пльцеинтерфейс конечно хорошо выглядит на планшетах, но на них обычно в 1С не сидят.


Но последние варианты выглядят конечно современнее. Обычные формы 8.2 это примерно как офис до верхней панели, последняя косметика этого года — прям стильно модно.

Любые вопрос по UI — это на 99% холивар :)

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

В учете таблицы встречаются чаще, чем космолеты. А когда число ячеек падает в 4-8 раз это огорчает.

Вот как раз бухгалтерия не входит в тройку ERP/Торговля/комплексная автоматизация, так что про "вырванный кусок" — мимо.
Собственно процедура перепроведения и осталась только в регламенте закрытия месяца. Но когда народ торгует с 5% прибылью, то он хочет считать её каждый день, чтобы в конце месяца не узнать, что полмесяца торговал в минус. Так конечно не у всех, но некоторым сильно надо.

НЛО прилетело и опубликовало эту надпись здесь
код разработчика должен как минимум компилироваться (или как это называется в 1с) в то время как планка качества для выделений консультанта и аналитика отсутствует

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

Сильный текст, на сон грядущий

  1. Программисты 1с и франчи, нужны были на первом этапе становления 1с, когда типовые конфигурации отсутствовали или представляли собой эскиз учетной системы, сейчас в 98% случаев нужны аналитики владеющие предметом и знающие продукт.
    2.Программистам 1с просто надоело, каждых 3-4 года начинать свою зарплату в долларах с 1000. (Только они в среде it получают зарплату в локальной валюте).
    3.1С подтянул в свои ряды сильных прикладников, в современных конфигурациях почти не осталось места для проектной разработки, так мелкие адаптации.
    4.Заниженная стоимость типовых решений не оставляет достаточной маржи для достойной оплаты Программиста 1с.
  2. Рынок 1с франчайзи, каким помнит его автор статьи, давно мертв, продавайте лицензии и консультируйте операторов 1с, вот все что оставил 1с этому рынку.
сейчас в 98% случаев нужны аналитики владеющие предметом и знающие продукт.
Заниженная стоимость типовых решений не оставляет достаточной маржи для достойной оплаты Программиста 1с.

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

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

Ну у нас типовой проект был:


  1. Берем голую коробку, заказчика и аналитика
  2. Прогоняем все типовые процессы и записываем, что не получилось.
  3. Рисуем роадмап внедрения (где почти первым пунктом идет обычно загрузка данных из исторической системы, которую уже пилит программист с аналитиком напару)
  4. Пока блоку, на котором нет доработок учат ключевых пользователей, по соседнему идет разработка. Иначе не собрать непрерывного внедрения.

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


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

1.Конвертация данных конфигурация которую могут и должны использовать аналитики и пока они не исчерпают ее базовый функционал, нечего там делать программисту.
2. Я в принципе скептически отношусь к переносу данных, трудозатраты высокие а отдача мизерная.Загрузки требуют проверки. Часто вносить данные, проще чем проверять. Взаиморасчеты например требуют актов сверки с контрагентом. Остатки требуют инвентаризации. Контрагентов можно подгрузить испоьзуя интеграцию с клиент банком с нуля. Мой опыт подсказывает что необходимо переносить только то что содержит более 10000 элементов и точно известно, эти элементы в порядке.
И даже тогда 90% таких переносов решает единоразовая загрузка из табличного документа(Аналитик освоивший полноценно данную загрузку полезнее разработчика которому не лень это писать снова и снова).

Только вот конвертация данных предназначена для обмена с фокспро/аксес/парус примерно никак с одной стороны, и имеет кучу скриптовых обработчиков для которых нужен программист — с другой.
(вы кстати про которую, 2 или 3)?
Разовая загрузка из табличного документа в несколько связанных таблиц без программиста это тоже деньги на ветер. (в смысле аналитик + эксель + программист быстрее и дешевле, чем аналитик + эксель)
А нормальную очередь загрузки (сначала одни НСИ, потом от них зависящие, потом данные об остатках/операциях) построить порой сложно. Особенно когда тебе на вход дают денормализованную простыню, где и остатки, и номенклатура, и сведения о номенклатуре, и основной поставщик и его ИНН КПП и телефон в одной простыне.

Вы недооцениваете аналитиков и их мастерство владения екселем (если мы имеев в виду реального аналитика работавшего с данными какоето количество лет) :) А иерархические данные грузятся в несколько линейных проходов. Программист может потратить много времени на код исполняемый единожды, там где аналитик приведет исходные данные к нужному формату в несколько операций над данными в екселе. Я настаиваю что программист нужен для написания перманентных процедур обмена.
2-ю конвертацию имел в виду. 3-я изначально на разработчика интеграций рассчитана.
(Только они в среде it получают зарплату в локальной валюте).

чтото уж больно сильное заявление
Да переобобщил, среди большинства программистов я имел в виду.
большинство программистов в РФ или в мире? большиство программистов в мире тоже получают зарплату в локальной валюте (в баксах)

а вот количество программистов (абсолютное) в РФ я думают тоже (в рублях)

далеко не многие работают на забугор, много да, но боюсь что даже не половина. У многих с английским то проблемы.
Реалии Украины несколько другие. Программисты в большинстве, работают на страны с стабильными валютами и соответственно зарплата у них привязана к доллару/евро.
Я бы не имел ничего против локальной валюты, если бы она не девальвировалась раз в 4 года на 100%. Начиная с 90-х годов эта тенденция прослеживается по всему бывшему СНГ. Если какая то из стран СНГ пропустила одну девальвацию значит следующая будет x3 :(
так нигде и не упоминалось что речь об Украине
Уверен что в России с программистами которые могут работать как на локальный рынок так и на внешний тоже сильно не поиграешся зарплатой в рублях. Это программисты 1с ненужны никому за пределами СНГ. Вот и бегут из отрасли.
Я помню времена, когда переучивались делфисты и фокспрошники на 1с. Это были лучшие времена :) А экономист, научившийся кодироват на 1с это зло, полезнее когда он не умеет, и изворачивается настройками и организацией процесса (бывают исключения).
Работаю во франче с 98 г. Поначалу была Бухгалтерия 6.0, видел даже досовскую 2.0 или 5.0. Потом пошли всякие 7-ки, 8-ки. Сейчас 8.3.
Раньше конечно работать с программой было легче, изменения в модули 6.0 прямо в режиме работы пользователя вносились. Потом в 7-ке появился режимы «Конфигуратор» и «Предприятие», часть кода можно было перенести в главный модуль. Сейчас в конфигурациях 8-ки множество общих модулей через которые и выполняются записи движений регистров, в модулях документов только собираются параметры и таблицы (тоже через общие модули) и отправляются в общие модуля для выполнения движений. В общем анализировать и вносить изменения в конфигурации стало на порядок сложнее. Зато возможности самой платформы очень сильно расширились и можно организовать решение множества задач.
У нас работники делятся на менеджеров, сервис-специалистов, методистов и программистов. По вашей классификации я отношусь Программистам 1С (у меняя высшее экономическое образование, а программирование 1С на работе изучал, на реальных задачах).
В общем автор описал типовые проблемы внедрения средств автоматизации управления, которые существовали всегда, и которые будут существовать всегда!
Только причем здесь 1С. Уберите из текста «1С» и подставьте туда любой другой бренд — получиться тоже самое. Другое дело, что у 1С хорошо развита система подготовки программистов 1С и при том, что 1С-программы — самый массовый продукт в России, то и программисты 1С — это самый массовый продукт этой системы образования. Качество этого продукта снижается обратно пропорционально массовости. Но это снижение профессионализма — это общий тренд в системе образования и не только в ИТ-сфере, и не только в России. Это отдельная тема для разговора.
Все остальное в мире 1С также, как и у других. По моему опыту, на сопровождении уже действующих систем у клиентов: 3 аналитика загружают 1 программиста. Этого достаточно.
На крупных проектах — все как у всех: работа программистов — это 30-40 процентов времени и бюджета. Остальное архитектура, бизнес и системный анализ, администрирование.
Есть ли решение этих проблем? Есть, но в каждом конкретном случае по разному. Как и на любом рынке, Заказчик должен быть разборчивым и выбирать не тех, кто дешево стоит, а тех, кто что-то умеет. Но для этого сам Заказчик должен иметь мозги.
А в остальном: все, как всегда.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.