Комментарии 237
Я тоже вспомнил эту сказку, но сразу вспомнил еще и древнюю песню Лаэртского про трёх нелепых персонажей (один из которых — муравей). Даже не знаю, какая аналогия из этих двух лучше отражает состояние индустрии.
Да, статья в стиле "чукча-стайл" что вижу то и пою. Развлекательная.
Для пикабу пойдет, но для хабра — это понижение планки/качества контента.
Расти есть куда и можно это делать бесконечно, пока развивается всё остальное ИТ. Было бы желание.
Что есть развитие программиста в вашем понимании? Может мат алгоритмы должен прокачивать? Или в asm спускаться?
Пилить микросервисную архитектуру на 1С никто не мешает- у 1С есть и формат для шины данных, и коннекторы к AMPQ (платформенные и сторонние).
Ну а для пытливых умом, есть OneScript.Web.
В EDT сейчас есть интеграция с фреймворком БСП
БСП не фреймворк, а просто библиотека. Причем ее нельзя подключить, а только полностью скопировать в свой проект. Причем вы не сможете безболезненно перейти на более современную версию так как в ней зачастую отсутсвует обратная поддержка.
Пилить микросервисную архитектуру на 1С никто не мешае
Никто не мешает однако никто не переходит, потому что интеграция в 1С это костыль на костыле.
потому что интеграция в 1С это костыль на костыле
Любопытно, в чем именно вы видите «костыль на костыле»?
БСП не фреймворк, а просто библиотека.
Так то и Spring просто библиотека. И БСП совсем необязательно полностью включать в свой проект.
Причем вы не сможете безболезненно перейти на более современную версию так как в ней зачастую отсутсвует обратная поддержка.
В смысле отсутствует? В базовой подсистеме до сих пор живы и работают методы еще с самого первого релиза.
Никто не мешает однако никто не переходит, потому что интеграция в 1С это костыль на костыле.
Если что, что интеграция это обоюдоострая вещь. И бодрячкового хардкода я навидался вовсю. Начиная от ручного парсинга xml-к (с соответствующими требованиями вплоть до количества пробелов в отступах), и REST-интерфейсов которые всегда возвращающих 200, COM-объектов которые работают только на Windows 2000, самопальных RPC разной степени вменяемости. Про интеграции с системами на Excel я даже говорить не буду. И все это добро сделано «с применением лучших паттернов проектирования и самых современных фреймворков», да.
А с 1С не так?
404 — не найден ресурс,
403 — у учетки нет прав
500 — вам вернули исключение, см. тело ответа
Или вы обычно пишите сервисы в которых этих ошибок возникнуть не может по определению?
Пилить микросервисную архитектуру на 1С никто не мешает
Это уже совсем сову на глобус. Мешает почти всё. Я прям аж завис от того с чего начать.
- Невозможность (ну или очень высокая сложность) интеграции с классическими инструментами MSA. Ввод-вывод в stdio — его нет, получение переменных окружения — нет (тут мы сразу прощаемся с Vault), поднятие неСУБД компонент как подов, сложность интеграции с kafka, низкая производительность HTTP, аутентификация/авторизация между микросервисами не такая лёгкая.
- "Неотчуждаемость" многих компонентов платформы. Вся 1С построена фактически вокруг пользовательских сеансов, начиная от лицензирования. Попробуйте сделать 3 конфигурации, так чтобы 2 из них были "микросервисами", а одна "фронтом" — у вас "фронт" либо начнёт бизнес-логику "МС" затягивать, либо вы упоретесь в интеграции.
- Модульность решений на уровне кода на встроенном языке почти никакая.
- Оверхед по производительности относительно монолита есть и в Java/.Net, что уж там, но в 1С это будет просто блокер проекта.
- РСУБД-центричность. Микросервис нередко вообще не требует РСУБД (файлы, кешики, простые key-value, плюс 1-5 табличек в постгре). Это быстро станет техническим ограничением.
Формально нельзя сказать, что совсем невозможно сделать MSA на 1C, но, право, найти более неподходящий инструмент непросто.
Для конфигурации 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С. Таких примеров тоже хватает.
и какой же фреймворк можно подключить в 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С? Она хороша только в плане учета, не более! Не нужно превозносить ее на все случаи жизни, эта платформа создавалась для учета!
Ну хорошо. Как тогда быть с архитектурными слоями в 1С ??? Что, например, можете сказать по поводу паттерна DTO?
А что вы можете сказать о проблеме шаманизма на дальнем севере?
Никто не превозносит 1С и не доказывает, что на ней можно (и тем более нужно) делать все. Просто недоумение вызывают попытки доказать, что на 1С вообще ничего сделать нельзя.
По поводу «для учета». Ну да, для учета. И SQL создавалась «для учета». И что?
Хотя у нас например, сайт спокойно получает и проводит онлайн-платежи(! это, на минутку, настоящие живые деньги) используя 1С как микросервис. 1С в свою очередь взаимодействует с любыми внешними сервисами, в т.ч. платежными шлюзами банков, только через AMPQ работая при этом и в качестве клиента, и в качестве сервиса.
Да, это та самая специфичная роль 1С — для учета. И 1С с этой ролью справляется и как приложение для пользователя, и как микросервис.
Что, например, можете сказать по поводу паттерна DTO?
хм, 1С-ный Enterprise Data DTO в чистом виде.
А что именно мешает? Например, вынести расчет себестоимости в отдельную «базу» или сервис и дергать его по мере надобности?
Мешает то, что задолбаетесь отковыривать логику и данные, нужные для расчёта себестоимости в отдельную БД. Микросервисы — это про "low coupling high cohesion".
Мешает то, что задолбаетесь отковыривать логику и данные, нужные для расчёта себестоимости в отдельную БД
Но это ограничение не 1С как платформы, а предметной области, разве нет?
И да, и нет.
Да: учётные системы c ACID, с взаимосвязанными объектами/разрезами учёта, с большой и нагруженной СУБД действительно отвратительный кандидат на "микросервисность". Говоря откровенно, на рынке в мире нет ни одного примера реализации учетной системы уровня предприятия на микросервисах. Хотя и есть системы/платформы в которых модульность на порядок лучше, чем в 1С.
Нет: в рамках платформы 1С сложно отковырять почти любой блок.
А если вглубь? И не в рамках хардкорного хайлоада?
Так пока другие программисты изучают новые паттерны проектирования… и делают то, чего не было, нет и не будет в 1С, "«сеньеры» 1С" помогают не загнуться локальной экономике, т.к. пока другие программисты трудятся на другие экономики, замену 1С, основанную на правильных принципах и паттернах, сделать некому, а на готовые правильные инструменты она перейти не сможет.
Я лучше буду решать проблемы, реально проблемы западного человека, чем копаться в какашках локальной рашки.
Вот как раз в учетном плане в западных конторах такое древнее/монструозное ПО, что то что оно до сих пор работает реально заслуга их стабильности и неприхотливости налоговых органов.
Вот даже местами не знаешь, что лучше — тихое учетное болото в котором могут успешно работать foxpro-шные программы, или наше вот это все с QR кодами и т.п., где не отсидеться без постоянных доработок и обновлений.
Выше я жаловался на кейс с ручным разбором XML-ек на той стороне — как раз была ИХ древняя учетная прога, и их разраб сказал, что ему проще захардкодить формат, чем реализовать нормальную поддержку XML.
Но мы же говорим про сферу учета — а для автоматизации предприятий 1С подходит практически идеально, и никто не смог еще написать ничего похожего, хоть на микросервисах, хоть на ООП с паттернами.
Потому что только в конфе «1С: Управление предприятием» больше 3 миллионов строк кода бизнес-логики — кто возьмется всё это переписать? И это только одна конфа, а есть еще «Управление холдингом», раза в 2 больше, для которой методологию учета помогал строить Ernst&Young, и на которой например запустили всего за тройку лет учет финансов во всей структуре Ростеха. Посмотрел бы я как это все писали бы с нуля на джаве, описывая кодом или в DTO в пяти местах каждое поле каждого справочника, там только у договора 400 реквизитов было.
Я знаю примеры, когда один программист запускал мебельный завод в одиночку на типовой 1С ERP за несколько месяцев — поставил, данные перенес и все начали работать, дальше уже рихтовка в мелочах. Как вы тут поможете с паттернами и ООП? В 1С нет ООП и это просто отлично, потому что ты берешь и решаешь задачу в терминах предприятия, а не в терминах СУБД или абстрактных сущностях.
Так что 1С сейчас двигатель экономики и цифровизации реального бизнеса, без нее сейчас были бы зависимы от софта с запада (привет санкции) или в каждой фирме сидел бы штат бухгалтеров и экономистов плюс несколько программистов. Или было бы несколько софтин как в 90-х, несовместимых и отличающихся. И все равно бы появилась 1С но в другом виде и названии.
Я лучше буду решать проблемы, реально проблемы западного человека
Вы, похоже, на эмоциях начали всё в одну кучу валить.
Если айти-профессионал работает на западную контору, то он автоматом решает проблемы западного человека, а не помогает хозяину(хозяевам) западной конторы обогатиться?
Вы бы уточнили и развернули свои мысли что ли, а то очень дико и не серьёзно звучит.
Язык подталкивает к говнокоду, марка автомобиля подталкивает к нарушениям ПДД, нож подталкивает к убийству, гениталии подталкивают к изнасилованиям, знак зодиака — к будущей профессии. Так?
Можно обсуждать вопрос «исторически так сложилось что в конкретной области больший процент инженеров/ученых/дизайнеров/бухгалтеров, что накладывает отпечаток на написанный код», но «подталкивает» к говнокоду — отсутствие времени/знаний/мотивации писать хороший код, а никак не язык.
Так что в хорошо спроектированных языках процент хорошего кода будет выше
Вполне возможно, но там говнокод будет уходить на уровень архитектуры.
Я-то с вами по сути не спорю — вполне допускаю, что в сфере 1С процент говнокода выше, чем в системах такого же масштаба и предметной области, написанных не на 1С. Проверить, увы, не могу.
Я только мягко намекаю, что виноват в говнокоде не язык, а конкретный человек. Если какое-то решение на 1С без говнокода написать нельзя — возможно, не стоило использовать 1С?
А может быть вмешались экономические факторы и конечному заказчику на говнокод плевать и это было осознанное решение разработчика?
И, к сожалению или к чести 1С, тут как посмотреть, в силу специфики работы 1С как раз со всеми этими говнозадачами, говнолегаси, говноданными и говнозаказчиками, говносроками и говнобюджетами им удалось сколотить во многом из бывших и нынешних домохояек общество «программистов1С», таки говнорешающих, но реально решающих в текущий момент на этих вводных данных проблемы пользователей. При том что работу хорошего программиста 1С большинство этих мелких контор в принципе не сможет потянуть финансово. Как и работу хорошего ГБ, хорошего финдира и т.д.
Если владельцы авто конкретной марки совершают нарушения в 2 раза чаще, то действительно стоит присмотреться, может, там спидометр врёт.
Это отличный пример распространенного когнитивного искажения — подмены корреляции причинно-следственной связью.
Причем тут подмена? нам не важна связь, вина водителя, логика связи для того чтобы выбросить флажок.
Устойчивая корреляция это повод или разобраться в вопросе, или использовать её как примету.
Если птицы низко летают к дождю, то это повод взять зонтик даже если не птицы вызывают дождь.
Так что корреляция это не всегда причина-следствие, но всегда измерение (иногда косвенное).
марка автомобиля подталкивает к нарушениям ПДД
Вы таки будете смеяться, но к примеру в Калифорнии при оформлении страховки (даже аналога ОСАГО) не только ее модель учитывается, но и цвет машины при расчете стоимости именно потому, что есть статистика, показывающая что машины ярко-красного цвета чаще творят дичь на дороге. И да, когда владеешь молотком, то все проблему начинают казаться гвоздями.
Плюс отсутствие замыканий и (еще год назад) асинк/авейт — тоже так себе помошники в написании кода.
Код одного и того же программиста на 1с и на kotlin/C#/dart/java и т.п. всегда будет выгодно отличаться в пользу второго варианта, если он конечно имеет соответствующий опыт как в 1с так и во второй технологии и соответствующих парадигмах/паттернах.
И потом, все Ваши утверждения голословны. Подтвердите их хотя бы своей практикой. Может чего-то и докажите. А пока только себя выставили в неприглядном виде.
Это даже если забыть про прибитые гвоздями, а не опциональные, архитектуру и некоторые паттерны в 1с, которые когда в кассу конечно хорошо, но когда не в тему — от них не откажешься, что нередко вынуждает городить те еще костыли.
статическая типизация и ООП (особенно с элементами ФП) на порядок облегчают написание хорошего кода.
забавно было бы сюда адепта питона или Go, такие захватывающие холивары бывают по поводу 'ненужно' то статической типизации то ООП, а в случае с 1С то и того и другого.
==
вообще ява (и её производные типа котлина) вырабатывает своеобразное мышление, и надо не забывать что оно не единственно верное в мире
Ту-же яву сильно ругают за перебор с абстракциями в коде… вроде как архитектура… но черт ногу сломит похлеще 1С, если программеры упоролись в конец
Ту-же яву сильно ругают за перебор с абстракциями в коде… вроде как архитектура… но черт ногу сломит похлеще 1С, если программеры упоролись в конец
Упарывание в абстракции я не очень одобряю, но тем не менее когда после 1с начал изучать другие языки (начинал с того же питона) — мне сразу стали видны многие проблемные места и перестало хватать средств 1с для обеспечения простоты поддержки и читабельности, в сравнении с другими языками.
В питоне есть вполне себе ООП, да и тайп хинты
ООП — да, тайп хинты — это не типизация, а красивые картинки в IDE
в Go только интерфейсы и есть, и куча костылей как сделать то что надо делать с ООП но без него, а за неявную утиную типизацию я бы вообще руки бы оторвал тому кто это придумал.
Вы когда говнокодите в 1с — вам это нравится?
Мне например, нравится изучать и применять новые знания (паттерны) в проектах и вообще, получаю удовольствие от красивого и качественного кода.
Вы взрослый человек всерьёз вот это пишете на айтишном ресурсе?
Как коррелирует айтишник в «1С»/«не 1С», далее «говнокод»/«не говнокод», также изучение новых областей, технологий, языков программирования, приёмов, шаблонов и получение/не получение от этого удовольствия?
Исходя из вашего поста получается, что если человек профессионал в сфере 1С, то он по умолчанию «говнокодит», «не изучает ничего нового» и «не способен получать удовольствие от творческого созидания в айтишной (инженерной) сфере»?
Вы реально так думаете или вы представляете какое-то сообщество (возможно, секту), где ВСЕ так думают?
Лентяи, «имбурдешники», ремесленники, новаторы, исследователи присутствуют везде независимо от сферы айти или даже не айти.
Я думаю, что их останавливало не «понижение в доходах», а то, что они не удосужились чего-то узнать за «границами 1С». Им просто некуда идти, да и кому они нужны?!
В системе 1С лучшая корпоративная программа повышения квалификации из всех, что я знаю. Бери и «учись, учись и еще раз учись», как завещал нам наш дедушка Ленин. А Вашему поколению не знаю кто-чего завещает.
В системе 1С лучшая корпоративная программа повышения квалификации из всех, что я знаю.
Мдааа… Как же вам не везло что вы «это» считаете лучшим.
Сами будьте творческим человеком и тогда даже разгребать чьи-то конюшни будет интересно. Глядишь и оценят Ваши потуги.
ADD: И в свое время именно выход в этом направлении приносил основной профит, продвижение к целям заказчика и основную премию. А сейчас времена изменились и движение в этом направлении, особенно в долларовом эквиваленте потребления, не является безусловно прибыльным. Не сделает его прибыльным и предлагаемый Вами творческий подход. К слову предложение такового подхода в экосистеме вендора в принципе предложение к его деградации. Благо помним еще времена творческих туробобухгалтеров и еще более творческих RS-балансов.
По моим наблюдениями возможности 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 и т.п. для него были космическими заклинаниями…
и таких людей в отрасли я очень много видел
2. А «очень крутой одинесник» решил с Вашей помощью свою задачу? Если да, то значит все нормально: он действительно крутой автоматизатор! Так и должно быть: профессионал — это не тот, кто все знает и умеет, а тот, кто умеет найти решение проблемы, или знает где найти и может оценить нужного специалиста.
Если да, то значит все нормально: он действительно крутой автоматизатор!
Ученик, решающий задачу с помощью учителя — не крутой автоматизатор.
Соглашусь с коллегой выше про 80%. Как по мне таких все 90%. Причем действительно, как только активно погружаешься в http, soap, wss, rmq, понимаешь что ты в тоннеле, а там где-то свет.
боты — на 1С?
В ноябре в платформе 8.3.18 появился стандартный объект конфигурации — Бот. ссылка
Создание и подключение эхо-бота в демо Управление Торговлей 11 к Telegram через сервер взаимодействия 1С: Диалог занимает 5-10 минут.
Сервер взаимодействия поддерживает ещё интеграцию с ВКонтакте.
На Инфостарте и без этого объекта куча ботов для различных месенджеров.
А так 1С вполне клевый инструмент для бизнес задач. И сделать там можно много обалденных вещей. Правда для большинства бизнеса это не востребовано. Вернее как — многие хотели бы получить класных фишек, но за почти бесплатно.
Этот кадр из мультфильма "Три дровосека", снятого в 1959 г. по мотивам той самой русской народной сказки, кмк наилучшим способом демонстрирует картину — пока консультант в поле и аналитик в офисе только всматриваются в будущую проблему, разработчик уже прикидывает варианты решения.
«разработчик 1С – это кусок программиста 1С. Тот кусок, который умеет писать код»
Кстати да, встречал грамотных разработчиков, не работающих с внешними интерфейсами. Т.е. внутри — царь, синтаксис — хоть спросонья, любую заумную обработку — легко, а подключить через dll железку — нужен отдельный специалист.
«Разработчик 1С – довольно странное создание. Есть несколько легенд о том, как эти зверушки появились на нашей планете, об этом напишу отдельную статью.»
Было бы любопытно.
Так что да, ситуация складывается уникальная, не характерная для других отраслей разработки, ведь описанные сущности суть неотъемлемые части полноценного организма, икринки паладина, не всем из которых суждено стать крупными осетрами.
Ситуацию усугубляет то, что со времён 6-7 версии платформа стала монолитнее и сложнее в освоении, хотя и более функциональной.
Мораль хорошо ложится из басни Крылова:
«Когда в товарищах согласья нет,
На лад их дело не пойдет,
И выйдет из него не дело, только мука.»
Вы там держитесь!
Это не дебилоиды, а менеджеры.
Менеджер по менюшкам 1С ("консультант"), менеджер по коду 1С ("погроммист"), менеджер по чтению вслух стандартов бухучета ("аналитик"), менеджер по бумажкам ("бухгалтер"), менеджер по банку (платежи сверять), менеджер по менеджерам ("Менеджер", "Ваш менеджер" ("Бонд. Джеймс Бонд.")).
Обсуждали как раз только-что вые особенности поведения менеджеров по продажам.
Логические заключения:
- на менеджеров где учат? Правильно — нигде.
- вывод №1: менеджер — это человек без [специального] образования.
- вывод №2: человеку без [специального] образования одна дорога — в менеджеры. Больше его никуда не возьмут.
не дебилоиды, а менеджерыШикарная фраза, возьму на вооружение.
В 2006 году, в августе я последний раз работал программистом 1С. Пришел, выслушал хотелку (как правильно учитывать незавершенное производство ж/б плит в конце периода. Открыл прямо перед главбухом ПБУ и справочник по типовым проводкам, выписал какие ресурсы идут на производство, выписал этапы, сделал типовую операцию и протянул руку за деньгами. Что сделала главбух? Правильно — позвонила знакомой и по её совету попросила меня сделать всё поперёк нормативной документации. На мой вопрос — вы, когда к вам камеральная приедет, как будете это обосновывать, тем, что "ваша знакомая так делает"? Ответ гениальный — ну у неё же прокатило пару лет назад…
В общем это была последняя капля. Я развернулся и ушел оттуда и из отрасли.
Прочитал сейчас и так порадовался, что бросил тогда это всё. Спасибо )
Ответ гениальный — ну у неё же прокатило пару лет назад
правильно, это её геморрой, а не ваш, вы довели до её сведения что она ошибается, но если она всёравно так хочет, то почему бы и нет, «любой каприз за ваши деньги» ©
… я и более страшные штуки делал… и ничё, народу нравилось ;)
p.s. я из отрасли ушел в 09 и в 16 годах (пришлось вернутся по стечению обстоятельств на пару лет), и не потому что там такое как вы описали сплошь и рядом, а просто потому что все задачи одинаково скучные
Ректальная монополия. Мне понравилось. В статье уже было сказано о том, что нынешний бухгалтер, это оператор 1С. Бухгалтера старой школы, к несчастью, альтернативы знать не хотят. А они есть.
1С просто меньшее зло для тех кто не является как минимум корпорацией. Недоучки 1Сники через боль и страдания Вам таки выдадут результат за приемлемые деньги. И вы продолжите делать бизнес.
На покупку условного SAP годового дохода вашего бизнеса может и не хватить, не говоря уже про оплату ежегодной подписки, кабалу с лицензиями на модули, поиск специалиста, а затем денег, которые Вам нужно будет заплатить этому специалисту. Толку от прекрасной системы, лучших аналитиков и прекрасных программистов, если Ваш бизнес это себе позволить не может.
А ещё есть различные надстройки, БИТ финанс например. И вот в этой ситуации количество адекватных разработчиков сводится к нулю. А те кто есть особы коронованные. Добиваться от них внятного результата долго и трудно. Если вообще возможно.
А задача трансформации и трансляции — вдвое более сложная вещь.
Если знаешь один учет — молодец, другой — тоже молодец.
Но чтобы понимать трансляцию из одного учета в другой, надо их оба знать назубок, и не на уровне зубрежа, а понимания, почему они так устроены и что там под капотом у них. И еще дополнительно, нужно понимать сами механизмы трансляций и трансформаций (которых в БФ несколько).
Если человек весь БФ выучил и умеет настраивать — то его можно и на автоматизацию МСФО параллельным учетом выпускать, и на трансформацию, и на трансляцию, и на «управленческий учет из бухучета», такие задачи раньше делались и сейчас делаются целыми командами специалистов, а специалист по трансформации БУ=>МСФО стоит несколько сотен тысяч рублей в месяц, и там везде эти их сертификаты нужны.
Другое дело, что в большинстве случаев весь БФ не нужен, и клиенты пользуются тем что им при внедрении настроили.
В УТ вообще сложно что-то не автоматизировать и не понять.
полный учет (не важно какой, БУ, УУ или МСФО) мы в ней не собираем, только торговля, купили-продали… а что в ней сложного? посчитали наскоро маржу — и радуемся. данные потом перегрузили в БП, где уже пусть бух мучается и балансы сводит, мы наторговали.
БП 3 очень внимательно сделанный продукт, прямо душа радуется, даже жалею что я не бух. Все делается настройками, все нужные субконто включаются-отключаются галочками, даже изыски вроде факторингов и комиссий продумали, котики везде, опять же. платежи сама отправляет-получает, работает в облаке — погромист и системщик вообще не нужен, что еще нужно для счастья?
например, от УТ11, в которой иногда чёрт ногу сломит.
ЗУП и её пробабушку ЗИК никто не переплюнет
Второе — очень, скажем так, запущенный процесс обновления этой базы.
Третье — несоответствие этой базы наблюдаемым за окном реалиям.
Четвертое — несоответствие пользователей стоящим перед ними задачами.
При попытке создать что-нибудь «действительно качественное» из этих исходных Вы (или кто другой) при таких исходных создаст продукт во первых сложный, во вторых несоответствующий чему-нибудь из перечисленного, благо им не соответствовать очень легко по их определению.
Всегда статьи автора читаю до этого пункта, очень интересные статьи, но этот пункт выносит мозг.
Скажите мне наконец откуда Вы взяли эту классификацию, какой ГОСТ, какая методика?
"-Имя сестра, имя! Назови мне его имя сестра!"
Правда и здесь есть пища для костров семантической инквизиции за
Профессионал < Джуниор < Специалист.
Профессионал < Джуниор < Специалист
Тут просто «так исторически сложилось».
Изначально сертификация была двух уровней — пользовательский «Профессионал» и внедренческий «Специалист».
В рамках сертификации для «чистых» разработчиков ("… по платформе") те же два уровня оставили, для единообразия. Сертификации же «1С Джуниор» до 2020 не было вообще и она еще официально не является обязательной для получения следующей за ней «лычки».
pravo.ru/news/227864/amp
В отношении лиц с желтым уровнем риска сохраняется возможность при наличии подозрений в отмывании денег отказать в открытии банковского счета и в проведении операций. Для красного уровня устанавливаются запреты на открытие новых банковских счетов, на проведение любых операций (как собственных, так и в их адрес), запрет или прекращение доступа к услугам по переводу денежных средств с использованием сервиса быстрых платежей (СБП), а также запрет использования электронного средства платежа.
Касаемо бизнеса, ССЗБ, услуги «по уменьшению НДС» до сих пор довольно популярная услуга. Но и государству тут делать честное лицо не стоит — существенная часть «высвободившихся» таким образом средств направляется бизнесом на «целевую» оплату государственных услуг.
Государство уже несколько лет думает как облегчить учет компаниям
я про это слышу еще с начала 2000х… оно всё облегчает и облегчает, а геморрой в учете всё растет и растет… помнится был ЕСН который заменял некоторые налоги… типа упрощение… но он имел мозгоразрывающую методологию учета… отменили сделали опять отдельно… не менее мозгоразрывающе.
Вот оборотный налог 6.2, думаете всё просто? А там ведь, авансы, возврат товаров, возврат авансов, перевод собственных средств, перевод собственных средств внутри холдинга, курсовые разницы… как платить с них налог? как возвращать налог на возврат авансов? а если они в долларах? и вот уже правила расчета этого простого налога начинают тянуть на один том войны и мира
Уже 15 лет работаю программистом 1С. Для себя взял важное правило: не притрагиваться к бухучету в принципе, не общаться с бухгалтерами. Зато могу поставить с нуля управленческий учет любой сложности буквально с пустой конфигурации, разумеется, с применением БСП. Встречал и консультантов, и аналитиков, и разработчиков, плохого сказать ничего не хочу, но могу. Найти толкового программиста 1С, который и пользователя опросит, и ТЗ себе составит, и архитектуру продумает, и реализует, и сдаст пользователю, действительно крайне тяжело даже на 160.000 рублей.
крайне тяжело даже на 160.000 рублей.
проблема в том что никто практически не ищет на такую сумму специалистов в этой отрасли. просто открыть hh и выбрать десяток вакансий как в случае с явой или питоном — не получится.
Мне вот проще было свалить из отрасли чем быть архитектором за 160тыр и ж… рвать (а что вы не знаете УПП/ЕРП/КА и сертификатов нет? Нуууу… мы вам только 60к можем предложить, досвидания)
Мне вот проще было свалить из отрасли чем быть архитектором за 160тыр
Конкретно в МСК (а я думаю высокий уровень архитектора востребован больше в столице) архитектор сейчас может получать от 250. Проблема в том, что не все кто зовет себя «архитектором» является им. И опыт нужен огромной, по моему мнению не менее 15 лет. Архитектор в среде 1С персонаж очень редкий, а во франчах вообще невиданный.
Конкретно в МСК (а я думаю высокий уровень архитектора востребован больше в столице) архитектор сейчас может получать от 250.
только попробуй такую работу еще найди и 'И опыт нужен огромной, по моему мнению не менее 15 лет. " — вот вот
а от 250к это зарплата толкового сеньора на яве с ф-циями тимлида. и геморроя в сто раз меньше… про забугорные зарплаты я вообще молчу
толкового сеньора на яве с ф-циями тимлида. и геморроя в сто раз меньше… про забугорные зарплаты я вообще молчу
Звучит как-то пренебрежительно. Хотя думается мне стать толковым сеньером по джаве с функциями тимлида посложнее будет.
Вы так аккуратно себя похвалили, что не все поняли, что сказочный богатырь Программист 1с, который "прийдет и порядок наведёт" это Вы.
Мы прекрасно помним творения чудо богатырей, как то перегруженные элементами, кнопками формы.
Функции типа:
Функция ВернутьПять()
Возврат 5;
КонецФункции
Пустые процедуры в БСП.
У меня, конечно есть догадки (на английском мозг не пытается читать текст на формальном языке, как на жийтеском), но надо бы поискать соответствующее исследование.
MostHighlyValueFromDatabaseOrAnyRandomValue() — и так везде, гарантированно сведёт с ума.
На что собственно и намекает "//! workaround". Обход это всегда говнокод.
Результат = МенеджерОборудованияКлиент.ВыполнитьФискализациюЧекаКоррекцииНаФискальномУстройстве(
ПодключаемоеОборудованиеКлиент.ИдентификаторКлиентаОборудования(),
ОборудованиеПечати,
ПараметрыФискализацииЧека.СТипомРасчетаДляФискализации(),
ВыходныеПараметры
);
.............
Функция ПараметрыФискализацииЧека.СТипомРасчетаДляФискализации()
ПриходДС = ПредопределенноеЗначение(ПРИХОД_ДЕНЕЖНЫХ_СРЕДСТВ)
ВозвратДС = ПредопределенноеЗначение(ВОЗВРАТ_ДЕНЕЖНЫХ_СРЕДСТВ)
Возврат Скопировать(
ТипРасчета = Если (ТипРасчета == ПриходДС) Тогда
ВозвратДС
ИначеЕсли (ТипРасчета = ВозвратДС) Тогда
ПриходДС
Иначе
ТипРасчета
КонецЕсли;
);
КонецФункции
Конст ПРИХОД_ДЕНЕЖНЫХ_СРЕДСТВ = "Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств"
Конст ВОЗВРАТ_ДЕНЕЖНЫХ_СРЕДСТВ = "Перечисление.ТипыРасчетаДенежнымиСредствами.ВозвратДенежныхСредств"
это могло бы выглядеть на чуть более выразительном языке.
Впрочем даже на 1с можно было бы вынести смену типа расчета в отдельный метод, предопределенные значения в локальные переменные, и код уже бы стал куда лучше.
- Это не волшебные константы, это поддержанные IDE метаданные. То, что они в кавычках это такое слегка недоразумение/особенность языка. Выносить в константы смысла нет, и вроде в курсеровском курсе по андроид имена ресурсов тоже в константы не пихали, но кроме этого курса я за пределы 1С особо не выбирался.
- Судя по тому, что перещелкивают значение не только перед вычислением результата, но и после, то эта структура используется где-то ниже. Возможно во время "ВыполнитьФискализациюЧекаКоррекцииНаФискальномУстройстве" в неё что-то пишется и заменять переменную вызовом функции может быть ошибкой.
Хотя 2 раза повторяющийся одинаковый блок просится на выделение в функцию. Но она будет всего из 5 строчкек, и добавить еще пару на заголовок и конец, так что экономия 3 строки.
Это не волшебные константы, это поддержанные IDE метаданные. То, что они в кавычках это такое слегка недоразумение/особенность языка. Выносить в константы смысла нет, и вроде в курсеровском курсе по андроид имена ресурсов тоже в константы не пихали, но кроме этого курса я за пределы 1С особо не выбирался.
Имена ресурсов не выносятся так как и так уже вынесены. R.string.something это уже константа а не ее имя. И проверка идет на этапе компиляции. В 1с же строковые имена метаданных хоть и могут в автокомплит, но при сохранении конфигурации проверка не происходит.
Судя по тому, что перещелкивают значение не только перед вычислением результата, но и после, то эта структура используется где-то ниже. Возможно во время «ВыполнитьФискализациюЧекаКоррекцииНаФискальномУстройстве» в неё что-то пишется и заменять переменную вызовом функции может быть ошибкой.
Именно поэтому в приведенном мной варианте я не изменяю значение поля, а копирую объект и меняю значение только в копии. Это как раз тот сахарок про который писал в комментарии выше.
А оригинальный объект остается без изменений. Это избавит от возможных ошибок если кто то забудет добавить возврат поля в изначальное состояние, или подумает что это дублирующийся код и его нужно удалить.
Хотя 2 раза повторяющийся одинаковый блок просится на выделение в функцию. Но она будет всего из 5 строчкек, и добавить еще пару на заголовок и конец, так что экономия 3 строки.
Дело не в экономии строк (хотя и в этом немного). Дело в:
1) Упрощении поддержки и рефакторинга. Меняя в одном месте точно не забудут про другое.
2) Упрощение чтения кода. Смена типа расчета лежит на более низком уровне абстракции чем выполнение целевой операции метода, и потому его лучше вынести отдельно. Также это упрощает чтение кода даже не столько из за меньшего количества строк, но и потому что метод в который вынесена смена типа расчета можно логично и коротко обозвать, и не нужно будет вникать в логику этого изменения, перепроверять все ветки исполнения и т.п.
- Вы не поняли
а копирую объект и меняю значение только в копии.
Именно это и опасно. Функция поставит в вашей копии "Фискальный УИД = 123"
а потом будет использоваться оригинал с Фискальный УИД = 0 и 123 потеряется навсегда.
- Строковое имя метаданного это имя ресурса, то, что на этапе компиляции не происходит проверка не меняет этого факта. Выносить немагические константы в константы — масло маслянное.
Кстати, проверки нет просто на данный момент, в ЕДТ она может и добавится. - Про вынос в функцию повторяющихся кусков я согласен. Про можно логично и коротко обозвать — ой сложно, но не повод не стремиться.
По поводу строковой константы — как раз объявление в одном месте и проверка на этапе компиляции меняют все.
Повторяю:
МенеджерОборудованияКлиент.ВыполнитьФискализациюЧекаКоррекцииНаФискальномУстройстве(
ПодключаемоеОборудованиеКлиент.ИдентификаторКлиентаОборудования(),
ОборудованиеПечати,
ПараметрыФискализацииЧека.СТипомРасчетаДляФискализации(),
ВыходныеПараметры
)
внутри будет иметь строчку
ПараметрыФискализацииЧека.ФискальныйУИД = 123;
И ваше оборачивание в функцию приведет к ошибке. Так как снаружи этот 123 потеряется. Потому, что будет уставнолен в копии, а не в объекте.
"Объявление в одном месте" происходит в дереве метаданных. Проверку на этапе компиляции ждем в EDT, конфигуратор не развивается, а тот вполне. С точки зрения синтаксиса языка (а не свойств конкретного компилятора) это не строковая волшебная константа, а именованный ресурс переупаковка его в константы приводит только к лишним бедам.
Так как снаружи этот 123 потеряется.
Если обратите внимание на изначальный код — он и должен снаружи откатиться к старому значению. А не новое сохранять.
С точки зрения здравого смысла "Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств"
это в чистом виде магическая константа, строковый литерал наделённый особым смыслом в голове разработчика.
Легко допустить опечатку или забыть поменять значение в одном из мест использования и трудно найти такие ошибки.
"Объявление в одном месте" происходит в дереве метаданных.
Когда вы переименуете что-то в дереве метаданных вам придётся вручную менять все строковые константы с именем переименованной сущности. И чем меньше таких мест будет, тем лучше.
Тем более 1С предоставляет из коробки статический контроль за такими ситуациями (переименование объекта метаданных, опечатка при его вводе).
Если и заводить константу, то сразу для всей конструкции ПредопределенноеЗначение(«Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств») и при условии, что их больше 1 в текущем модуле.
Конст ПРИХОД_ДЕНЕЖНЫХ_СРЕДСТВ = "Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств"
Вот этим вот решением был убит статический анализатор кода 1С в данном случае.
Код
ПредопределенноеЗначение("Перечисление.ТипыРасчетаДенежнымиСредствами.ПриходДенежныхСредств")
будет корректно проверен статическим анализатором 1С и выдаст ошибку при сохранении модуля. Так же ошибка будет выведена при запуске полной проверки конфигурации. Это позволяет свести к минимуму возможные ошибки при переименовании перечисления в конфигурации.
"В тем времена далёкие, таперь почти былинные" (с) В.С. Высоцкий, (конец 90-х, начало 2000-х), когда я закончив ВУЗ, начал свою трудовую деятельность, прикладной программист, обслуживающий бухгалтерию, должен был знать эту самую бухгалтерию на уровне хорошего бухгалтера. Так вот. Читая ваши материалы, у меня всё время вертелся вопрос: а какова сейчас ситуация в этой сфере. И вот вы отвечаете на этот вопрос. Фантастическая фантастика, однако!
ЗЫ. На самом деле ситуация — она по отрасли в целом такая, не только среди 1С-распространителей.
Эффективный манагемент во все поля: для того, чтобы корова давала больше молока, её надо больше доить и меньше кормить. :(
Что-то уж слишком мрачно и всех под одну гребёнку...
То есть, на всеобщность и целостность понимания и раскрытия состояния отрасли он и не претендует. Это — взгляд конкретного человека из конкретного положения.
Система 1С: Предприятие осваивает новые пределы — крупных промышленных предприятий и холдингов, финансовых и торговых компаний национального масштаба, и, сфера разработки и адаптации прикладных решений закономерно трансформируется, приспосабливаясь к новым условиям и новым требованиям.
На языке вертится фраза, что время одиночек-энциклопедистов прошло,… но дело не во времени. Рискну применить такую аналогию: можно продолжать в одиночку скакать по скалам выискивая траву на уступах и в трещинах, или же — спуститься с гор на сочные равнинные пастбища, где, хочешь-нехочешь, а придется сбиться в стадо (с соответствующим разделением труда, кооперацией и координацией), чтоб отбиваться от хищников.
По сути вместо аналитика, консультанта и программиста должен быть один человек, который делает сразу всё. И в основном занят именно конфигурированием, то есть включением-изменением опций, вводом настроек, НСИ.
Официальное объяснение — что продукты 1С, особенно флагманские конфигурации (ЕРП, БП, УХ, ДО) достигли такой зрелости, что программировать там не надо.
Очевидное объяснение — клиенты руководствуются расценками и пониманием объема работ 20-летней давности, а при этом доработать тот же ЕРП нетривиальная задача. То есть хотелка пользователя — это выливается в либо «а, и так сойдет», либо «ой как дорого, давайте тогда без этого».
Для каких задач?
Насчет всего в одном тоже так думал раньше, но практика показывает, что это не лучшее решение. Просто редко когда один вендор сильнее всех во всех необходимых модулях. Поэтому часто можно видеть солянку из разных систем от SAP, 1С, Oracle, MS и других.
v8.1c.ru/applied-solutions/729503
v8.1c.ru/applied-solutions/1049290
Конкретно по ERP можно рассмореть тот же Бетховен, насколько мне известно.
Гулливер: v8.1c.ru/applied-solutions/797028
Розничная сеть оптик: v8.1c.ru/tekhnologii/tekhnologii-krupnykh-vnedreniy/vypolnennye-proekty-tsktp/1c-rarus-tekhlab/cts-202-018
Но тут я скорее признаю свое бессилие в сборе подтвержденной инфы, так как работа 1С с историями успеха и внедрений довольно топорная.
Это совсем не то значит.
Моделирование это подход к созданию ТЗ. На обследовании берем типовые операции/процессы заказчика, как есть забиваем в ЕРП. Формируем требуемую отчетность.
Выписываем все места, где возникли трудности с вводом, необходимость ручных операций, каких отчетов не хватило.
По выписанным местам рисуется ТЗ.
ФТ косвенно генерируется на этапе подбора процессов для моделирования.
Я начал работать в 2005 году, и тогда никто не пользовался термином «разработчик 1С». Были только программисты и консультанты. Соответственно, те люди, которые работали тогда, с их знаниями, подходами, результатами — программисты. Потому что они себя так называли.
Сейчас есть люди, которые называют себя разработчиками. Думать долго не надо — раз сами себя так назвали, будьте разработчиками. Со своими знаниями, подходами и результатами.
Т.е. я называю людей так, как они называли себя сами. Сейчас некоторые программисты стали называть себя разработчиками. Есть и обратный процесс — разработчики хотят быть, как программисты. Примерно так же некоторые современные люди пытаются чему-то научиться, например, у дворян 19-го века, или самураев, или прусской военной машины.
Не проблема по прошествии лет переименовать профессию, но факт останется фактом: в нулевых люди называли себя «программисты 1С».
Им проще написать заново и свое, чем искать способ типовыми средствами.
Обращаться к ним нужно только после того, как прошерстили всю конфигурацию, перечитали все мануалы и решения так и не нашлось.
P.S. Был удивлен, что ЕРП 2.5 уже пишется на EDT. Молодцы, не забросили.
Этот дедуля смотрит на современные БСП, где запрос в отчете СКД не написан, а собирается по кусочкам из других модулей, рыдает, и делает для пользователя новый отчет по-своему, по-старому, чтобы в типовом не разбираться, потому что непривычно
О, а вы пробовали разбираться в ЗУПе?
Где динамически строится запросы к базе с использованием вирт.таблиц, когда 'тут запрос выполняем, контекст в уме держим, здесь в модуле пару табличек дропнем, там добавим'… и это размазано по 150 процедурам, причем контекст чудрым образом в памяти гдето висит… и падает оно гдето на 76 методе… я помнится по 2-3 часа собрал этот запрос в одну кучу чтобы подебажить… реально было желание всё бросить и поехать в 1С бить лицо тому кто это придумал.
А вот реализация, конечно, вышла ущербной.
А после на этом «понятном и легком в сопровождении» языке и структурах пытаемся оптимизировать эту самую производительность за счет уже потери легкости создаваемого кода.
Согласен. Примерно такой же мрак происходит на уровне метаданных, когда для получения нужных индексов/возможности параллелить обработку данных вовсю используются конструкции «Динамический список из подчиненных объектах вместо табличной части», хранение ТЧ в регистре сведений, конструкции из нескольких объектов, т.к. в одном уже невозможно реализовать нужное поведение. И это в одобренных типовых решениях (в книжках и стандартах, что забавно, о таком почему-то не пишут =) )
Ну и вся БСП целиком из такого состоит =)
ну где то то они да должны лежать, отчего не на скуле?
ну как это выглядит то?
Падает запрос, типа РасчетЗП.Расчет() 234324
открываешь код, а там Запрос.Выполнить(текстЗапроса)
открываешь текст… написано 'выбрать данные из результат'… идешь на шаг назад, написано текстзапроса += ИмяТаб[ВыбСтрока+5]… еще на шаг назад… запрос.выполнить(ТекстЗапроса); текстЗапроса= 'выбрать '+данные[текстрока+4353]+' из'
и блин ты еще на 2м шаге из 150, а уже ничерта не понятно что вообще происходит
На такие претензии забавно читать ответы причастных — «да все нормально, я вот вообще за последние N лет не лез код исправлять, внедряем как есть, все отлично работает».
так в том то и дело что никто туда не лезет из-за зашкаливающей наркомании в коде, потому что проще подстроится под программу чем программу под себя. У меня был вхлам перепиленный БИТФинанс который очень активно кастомизировали и ЗУП который старались не трогать ибо чревато и даже по пустякам он отжирал кучу времени.
Не просто так среди одноэсников, ЗУПовцы это отдельные, особо ценящиеся люди.
Так что вы просто «не вписались в рыночек».
Это рыночек в меня не вписался, а не я в него
Открываешь код а там: РасчетЗП.Расчет():
ПодготовкаДанныхРасчета(); //результат Вт_Сотры, ВТ_Табель, ВТ_Показатели;
РасчетБазовыхНачисленийУдержаний(); //результат ВТ_НачисленияУдержания
РасчетЗависимыхНачисленийУдержаний(); //Результат ВТ_ЗависимыеНУ
РасчетНалогов(); //Результат ВТ_Налоги
ПеренестиВРегистрыУчета(); //Пишем ВТ в регистры
После каждого запроса на скуле лежит таблица с результатом запроса. гонять ее на сервер предприятия и обратно нет смыла, управляется все менеджером временных таблиц у которого (вот тут не могу сказать как сейчас) инструментов для дебага этих временных таблиц нет. Т.е. сделать точку останова и посмотреть что собственно в данных без переписания кода именно для этого никак нельзя. Да и собственно оставляя за собой возможность дебага на скуле мы повышаем на него нагрузку — все эти ВТ нам придется хранить до конца исполнения кода (или выписывать в тетрадочку промежуточные результаты).
А по факту имеем микс из динамически составляемых текстов запросов с данными, передаваемыми посредством менеджера которые еще попробуй проанализируй. Как то сами себя перехитрили.
//но это в парадигме что мы оптимизируем передачу данных между скулем и предприятием и реализуем логику на скуле, что само по себе противоречит первоначальному замыслу: данные в БД, логика на предприятии.
Почему люди программируют в 1С, сейчас хорошо рассуждать, а в 90-е была другая реальность. Начинал писать на C, C++. Успел поработать год в осколке НИИ создавшем то чего не было в США и Японии. К появлению 1С 7.0 Торговля и Склад у меня была своя подобная система на Delphi, проработавшая в 3 фирмах несколько лет. Выбора не было. Ну не нужно никому, в то время было твое знание объектно-ориентированного программирования. Только эмигрировать, удалённо тогда не поработаешь.
А вот для корявого 1С 7.7 был дефицит «программистов».
Сейчас 1С продукт мирового уровня. Быть спецом во всех областях её
применения сложно. Но и не обязательно, выбираешь свою сферу.
Главное, что даёт мне работа с 1С, это независимость. Я могу стать узким специалистом и получать больше, но тогда придётся пойти работать на дядю, но поверьте дедуле, есть вещи дороже денег.
Вероятно, создание партнёрской сети оказалось определяющим для успеха 1С.
Хорошие аналогии. Не только в 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с участники так же имеют разную квалификацию. Может в светлом будущем все наладится. И будет найден оптимальный формат взаимоотношений.
но не от хорошей жизни это.
Наблюдаю нечто подобное и в геофизике. К сожалению.
Всё потому что я тру-программист, который заменяет эту троицу.
Спасибо, польстил.
А комментаторы из взрослых языков и технологий какие альтернативы предлагают? Есть реальные конкуренты 1С для автоматизации среднего предприятия в разумные сроки и бюджеты?
Понятно, что расчет сложность задач, которые должна решать система, но качество разработки внутри самой 1С катастрофический падает. Код той же УПП ещё можно довольно легко читать, за исключением некоторых модулей. Внутренности же современной ЕРП — это понос на стенах: в документах километрами идет непонятный код. Отсутствуют даже зачатки архитектуры.
При этом главная фишка современной 1С — структура базы со всеми этими уже готовыми механизмами регистров, правами доступа, модулями, средствами разработки, СКД, в конце концов — всё это в итоге хоронится бредовыми методиками учета (который 1с придумывает), кривыми бизнес-процессами, уродским интерфейсом, маркетингом на грани обмана.
Это превращение самой 1С из простого и понятного программного продукта
типовых конфиг, народ не понимает что платформа и конфиги — это разные вещи
Соизмеримой сложности и универсальности
Относительно перепроведения тоже не совсем понятно, как вы предлагаете исправлять операционные ошибки ввода данных или предоставление первичных документов через неделю-две после совершения операции? Документы ведь перепроводят не от скуки, а потомучто были введены данные в прошлом периоде.
Расчет себестоимости в большинстве реений — это уже давно отдельная операция, которая выполняется в фоне отдельно от основного проведения документа.
Относительно отчета, если говорить про прибыль с точки зрения БУ и НУ, то, дейстивтельно, чаще смотреть нет смысла. Но если смотреть аналоги по управленческому учету и операционному, то вполне есть смысл оцнивать оперативные показатели.
Если я вас не так понял, то поправьте.
Неоперативное проведение — это следствие построения учета на предприятии, требований законодательства в купе с объективной реальностью. При чем тут 1С и 1С-ники я никак не могу понять.
Если взять почти любую учетную систему для SMB, то там почти везде реализован неоперативный учет с, фактически, перепроведением документов. И я говорю про решения для США и Германии.
Можно легко посмотреть современные демки, чтобы понять, что 1С ушло далеко: 1cfresh.com/solutions. Тот же 1С: Предприниматель очень хорошо смотрится (по сути это урезанная настройками бухгалтерия). Но для любого решения UI можно сделать лучше. Всегда.
Именно для избегания перепроведения всего и вся и делается восстановление последовательностей по областям учета: НДФЛ, партии, себестоимость, маржа и прочее. Тогда идет пересчет только нужных данных. Но во многих решениях (чаще всего старых) это не реализовано, поэтому проще перепровести все документы. Тут все же необходимо понимать конкретные кейсы.
ИМХО управляемые формы против обычных это холивар. "Такси" явно лучше первых управляемых, но когда нужно много полезного на экране обычные формы недостижимы.
Большинство документов было вынуждено уйти на многостраничную верстку там, где раньше все спокойно помещалось на одном экране.
Самый вопиющий пример — табель в Зарплатной конфе.
Раньше помещался весь месяц для 16 человек, теперь полмесяца для 7-8 (фул ХД). Пльцеинтерфейс конечно хорошо выглядит на планшетах, но на них обычно в 1С не сидят.
Но последние варианты выглядят конечно современнее. Обычные формы 8.2 это примерно как офис до верхней панели, последняя косметика этого года — прям стильно модно.
Но для того же такси, стоит заметить, есть возможность выбрать обычный или компактный вариант. Т.е. есль есть необходимость нарисовать контрольную панель космолета, то 1С уже мешать не будет.
Вот как раз бухгалтерия не входит в тройку ERP/Торговля/комплексная автоматизация, так что про "вырванный кусок" — мимо.
Собственно процедура перепроведения и осталась только в регламенте закрытия месяца. Но когда народ торгует с 5% прибылью, то он хочет считать её каждый день, чтобы в конце месяца не узнать, что полмесяца торговал в минус. Так конечно не у всех, но некоторым сильно надо.
Это автоматически выделяет быдлокодера из тройки как наиболее ответственного и компетентного специалиста.
Но его конечно слушают меньше всего
Сильный текст, на сон грядущий
- Программисты 1с и франчи, нужны были на первом этапе становления 1с, когда типовые конфигурации отсутствовали или представляли собой эскиз учетной системы, сейчас в 98% случаев нужны аналитики владеющие предметом и знающие продукт.
2.Программистам 1с просто надоело, каждых 3-4 года начинать свою зарплату в долларах с 1000. (Только они в среде it получают зарплату в локальной валюте).
3.1С подтянул в свои ряды сильных прикладников, в современных конфигурациях почти не осталось места для проектной разработки, так мелкие адаптации.
4.Заниженная стоимость типовых решений не оставляет достаточной маржи для достойной оплаты Программиста 1с. - Рынок 1с франчайзи, каким помнит его автор статьи, давно мертв, продавайте лицензии и консультируйте операторов 1с, вот все что оставил 1с этому рынку.
сейчас в 98% случаев нужны аналитики владеющие предметом и знающие продукт.
Заниженная стоимость типовых решений не оставляет достаточной маржи для достойной оплаты Программиста 1с.
Это вы сейчас про Зарплату и Бухгалтерию в средне-мелкой конторе?
Стоимость типового решения при его запуске это меньше 10% затрат заказчика. ЗУП и БП покрывают достаточно зарегулированные области, чтобы со скрипом, но обойтись без программиста вообще.
Торговый блок, отражение бизнес процессов в системе — это всегда программирование. Удобные АРМ операторов и аналитиков, дополнительные контроли на заполнение/согласованность реквизитов документов — это всегда программисты. Спец отчеты, даже не влезая в код, а просто настраивая то, что финдир говорит словами — это тоже программисты.
Другое дело, что затраты на аналитиков (сюда же обучение пользователей) зачастую выше, чем затраты на кодирование. Но не всегда.
Ну у нас типовой проект был:
- Берем голую коробку, заказчика и аналитика
- Прогоняем все типовые процессы и записываем, что не получилось.
- Рисуем роадмап внедрения (где почти первым пунктом идет обычно загрузка данных из исторической системы, которую уже пилит программист с аналитиком напару)
- Пока блоку, на котором нет доработок учат ключевых пользователей, по соседнему идет разработка. Иначе не собрать непрерывного внедрения.
Мы так и с учетом тракторов для сельхоза делали, и для литро/килограммов топлива для ребят с большим автопарком, но не бензоторговцев (поэтому отраслевка по бензину не подошла), и для просто складского/закупочного хозяйства в холдинге делали.
Так как первичку по складу даже с заказами сделать можно, а вот поддержать трех (с инициатором — четырех) уровневую систему управления складскими запасами уже никак из коробки. К тому же здесь она сложилась так, в соседнем холдинге — иначе.
Можно конечно сказать "пока мы будем учить ваших кладовщиков документы в 1С вносить и пусть они и в старую систему тоже все вбивают" и тогда программисты 1С не нужны, но зачем так делать?
2. Я в принципе скептически отношусь к переносу данных, трудозатраты высокие а отдача мизерная.Загрузки требуют проверки. Часто вносить данные, проще чем проверять. Взаиморасчеты например требуют актов сверки с контрагентом. Остатки требуют инвентаризации. Контрагентов можно подгрузить испоьзуя интеграцию с клиент банком с нуля. Мой опыт подсказывает что необходимо переносить только то что содержит более 10000 элементов и точно известно, эти элементы в порядке.
И даже тогда 90% таких переносов решает единоразовая загрузка из табличного документа(Аналитик освоивший полноценно данную загрузку полезнее разработчика которому не лень это писать снова и снова).
Только вот конвертация данных предназначена для обмена с фокспро/аксес/парус примерно никак с одной стороны, и имеет кучу скриптовых обработчиков для которых нужен программист — с другой.
(вы кстати про которую, 2 или 3)?
Разовая загрузка из табличного документа в несколько связанных таблиц без программиста это тоже деньги на ветер. (в смысле аналитик + эксель + программист быстрее и дешевле, чем аналитик + эксель)
А нормальную очередь загрузки (сначала одни НСИ, потом от них зависящие, потом данные об остатках/операциях) построить порой сложно. Особенно когда тебе на вход дают денормализованную простыню, где и остатки, и номенклатура, и сведения о номенклатуре, и основной поставщик и его ИНН КПП и телефон в одной простыне.
(Только они в среде it получают зарплату в локальной валюте).
чтото уж больно сильное заявление
а вот количество программистов (абсолютное) в РФ я думают тоже (в рублях)
далеко не многие работают на забугор, много да, но боюсь что даже не половина. У многих с английским то проблемы.
Я бы не имел ничего против локальной валюты, если бы она не девальвировалась раз в 4 года на 100%. Начиная с 90-х годов эта тенденция прослеживается по всему бывшему СНГ. Если какая то из стран СНГ пропустила одну девальвацию значит следующая будет x3 :(
Я помню времена, когда переучивались делфисты и фокспрошники на 1с. Это были лучшие времена :) А экономист, научившийся кодироват на 1с это зло, полезнее когда он не умеет, и изворачивается настройками и организацией процесса (бывают исключения).
Раньше конечно работать с программой было легче, изменения в модули 6.0 прямо в режиме работы пользователя вносились. Потом в 7-ке появился режимы «Конфигуратор» и «Предприятие», часть кода можно было перенести в главный модуль. Сейчас в конфигурациях 8-ки множество общих модулей через которые и выполняются записи движений регистров, в модулях документов только собираются параметры и таблицы (тоже через общие модули) и отправляются в общие модуля для выполнения движений. В общем анализировать и вносить изменения в конфигурации стало на порядок сложнее. Зато возможности самой платформы очень сильно расширились и можно организовать решение множества задач.
У нас работники делятся на менеджеров, сервис-специалистов, методистов и программистов. По вашей классификации я отношусь Программистам 1С (у меняя высшее экономическое образование, а программирование 1С на работе изучал, на реальных задачах).
Только причем здесь 1С. Уберите из текста «1С» и подставьте туда любой другой бренд — получиться тоже самое. Другое дело, что у 1С хорошо развита система подготовки программистов 1С и при том, что 1С-программы — самый массовый продукт в России, то и программисты 1С — это самый массовый продукт этой системы образования. Качество этого продукта снижается обратно пропорционально массовости. Но это снижение профессионализма — это общий тренд в системе образования и не только в ИТ-сфере, и не только в России. Это отдельная тема для разговора.
Все остальное в мире 1С также, как и у других. По моему опыту, на сопровождении уже действующих систем у клиентов: 3 аналитика загружают 1 программиста. Этого достаточно.
На крупных проектах — все как у всех: работа программистов — это 30-40 процентов времени и бюджета. Остальное архитектура, бизнес и системный анализ, администрирование.
Есть ли решение этих проблем? Есть, но в каждом конкретном случае по разному. Как и на любом рынке, Заказчик должен быть разборчивым и выбирать не тех, кто дешево стоит, а тех, кто что-то умеет. Но для этого сам Заказчик должен иметь мозги.
А в остальном: все, как всегда.
Да раньше и деревья были зеленее и девушки красивее... ;) Стандартная мантра про "в наше время такого бардака не было...". Автор стареет просто. ))))))
Именно так. Экология была лучше, а нравственность крепче, определённо.
не скажите, нравственность всегда на одном уровне. Разврат и насилие.
Ну не соголашусь. Посмотрите, например, исследования нравственности русских девушек немецкими врачами на оккупированных вермахтом терориториях СССР. Цифры приятно удивят и потрясают. Это факт. А сейчас.такая статистика здорово просела после западнной толерантности. Теперь бабники и соответственные особи женского пола ... это норма, пока ещё не норма говномесы, но и этот бастион падёт под западной толерантностью (терпимостью к инородной инвазии).А на морального человека уже давно косятся и подозревают во всех грехах как на педика или педофила, в крайнем случае как на слабоумного идиота и это если ещё повезёт.
Пузырь, соломинка и лапоть. Что происходит с программистами 1С