Опрос сообщества разработчиков на 1С

(225) Да-да, и срочно сдают паспорта США и Евросоюза.

(130) Нет, там много чего не довезли. Но я не уверен, что там когда-нибудь появятся обычные формы, или 1С77 ))

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


Никогда не видел в этом проблемы. Что не так то?



Что-то Вы всё в одну кучу сваливаете. Совсем запутали.


Ошибки всегда были и ещё долго будут - это пока неизбежность.
Поэтому и типовые решения сейчас только-только на 14-й релиз платформы перешли. А к тому моменту как перейдут на 16-й - ещё год минимум обкатки пройдёт - так что это уже не ранее 21 года ждите - срок достаточный чтобы и платформу изучить и ошибки выправить.

На 16-й релиз сейчас переходят во основном самописчики, да энтузиасты - но Вы явно не из их числа.

Даже я, хоть и слежу за новинками в технологиях, работаю с 15-ым релизом, на который перешёл лишь полгода назад. Хотя 16-ы тоже стоит - для самообразования!

(473) Это он писал в году 15-м. А добавили - в конце 16го вроде. И то там 8.4 ждали "революция", а получили очередную 8.3)

(490) Потому что ЖР - обрабатывается и контролируется все тем же 1С сервером. А не SQL-сервером. Поэтому и "поближе к кухне".
Потому что MySQL используется. Он несовместим с остальными sql-системами напрямую.
А это 1С так использует очередную "СУБД" MySQL (ну там огрызок в виде библиотеки от целой СУБД) - в своей манере "чем хуже тем лучше".
MySQL, кстати, одна из самых оптимизированных и быстрых в своем "легком" классе БД. Но не у 1С.

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

(165)Да не при чём - я тут на медне на Яве такую фигню в коде нашёл в одной поделке... а ооп полиморфизм наследование.... Вот и унаследовало... Так что идите Вы в сторонку с ООП эта хрень хороша для маленьких проектов. В больших проектах класса ЗУП 3.1 и выше должно всё работать как автомат калашникова максимально надёжно...

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

(82)
Вот попробуйте всеми этими "плюшками" привлечь новых молодых специалистов в профессию.
Пару слов о бизнес-программировании. Последние года 2 половина моих задач - это задачи интеграции со сторонними системами. Пришлось дополнительно обучиться HTML+JS и Python. С++ знаю с ВУЗа. Для толкового специалиста, который знаком с теорией разработки сложных программ - разобраться с понятиями себестоимости, бухг., налогового и упр. учета, осознать вывернутую логику тонких форм и компоновки данных и всей прочей чепухи которой мы так гордимся - это совершенно не проблема, а вот если, наоборот, то редко какой одинэсник без особой подготовки сможет сходу вникнуть в суть ООП, лямбда-функций, паттернов и прочих интересных штук, которых мы лишены. Нашего функционала вроде как хватает для закрытия текущих потребностей, но этого совершенно недостаточно для того, чтобы студенты массово захотели связать с этим свою жизнь.

(82) Никто не понимает, в чём сила 1С. Открываю секрет фирмы - регламентированная отчетность, которая проходит проверку в гос. органах.
Ни одна из веб-поделок этого до сих пор не умеет.

(82) Неверно считать, что только 1С в описанном выше списке языков и технологий - это бизнес-программирование. На Java и .Net не просто пишут код, а решают бизнес-задачи. Это именно языки для корпоративного бэкэнда. Игры на них не делают (ну почти) из-за сборщиков мусора.

Вы имеете в виду, что 1С - это DSL язык? Ну да, но разве это противоречит тому что он может давать возможности, а не забирать их?

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

Когда разработчики пишут про ООП имеется в виду не строгое определение ООП в теоретическом смысле, а возможности языков.

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

Никогда язык без строгой типизации не обеспечит надёжности создаваемых решений и не будет принят как среда разработки корпоративного бэкэнда за пределами СНГ. Как инструмент для МVP решений - вполне возможно. Но для создания MVP можно и что-то подешевле применить, если это не связано с особенностями бухгалтерского учета.


Сейчас чтобы понять какого типа действительно прилетает аргумент в метод нужно не только прочитать код всего метода, нужно ещё посмотреть все вызовы этого метода! Попытка сэмулировать типизацию через комментарии к методам не решает задачи от слова "совсем". Разве что в БСП она решается, видимо за счёт очень высокой дисциплины при разработке. Да и то подсказки к методам не всегда соответствуют реальности.

Никогда при отсутствии типизации мы не получим адекватных подсказок от IDE и нормального рефакторинга. Не нужно на EDT надеяться - всё будет то же самое. При переименовании одного из полей среда разработки по прежнему будет выдавать предупреждение, что "Поле 'Сумма' содержится в 15005005059 объектах метаданных, везде переименовать или поштучно?". И нужны не тайп-хинты. Их не хватит для того, чтобы перебороть текущие подходы к разработке и культуру, распространяющую MVP-подход на крупные системы.


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

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

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

Любой реквизит объекта метаданных - это public реквизит. Даже у тех объектов, которые не имеют отображения на СУБД и где нет необходимости в создании public-полей. Есть реквизиты модулей объектов. Но там опять же нет типизации. Хочешь типизацию - используй public поле (реквизит) или делай геттеры-сеттеры для неэкспортных переменных модулей объектов, а в геттерах-сеттерах проверку типов входящих параметров. Это слишком трудозатратно и массово никогда не будет применяться. Да и нет ни у кого стимула задумываться над этим.

Гордость за 5 000 000 строк кода (сейчас уже вроде все 7 000 000) - это разве не индийское/китайское программирование? Ведь гордится нужно тем, что задача решена лаконично, а не то что "у нас очень большая система, в ней 7 000 000 строк кода и даже этот ваш буржуйский git захлёбывается".


А что самое замечательное - озабоченность наблюдается не этими вопросами, а тем "как заманить начинающих программистов".

Надо над качеством работать, а дешёвая рабочая сила подтянется сама.

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

(82) Нет понятия бизнес программирования. Есть либо хорошее, либо плохое программирование. Верней плохой или хороший программный продукт. Так вот, если в вашем, так вами называемом бизнес программировании, нет средств оптимизации работы с базами данными, большими данными, современных средств разработки, средств для написания высокопроизводительных веб сервисов и так далее по списку то программный продукт ваш никому не интересен кроме маленького ларечка или вас самих. Соответственно денег вы за свое "бизнес" программирование серьезных не получите.

(82) Давайте тогда определимся, что такое вообще 1С? Если для вас 1С - это вижуалбейсик для бухглатера - то это один вопрос. Сама 1С себя в последнее время позиционирует как платформу для самых разнообразных приложений. И лично я действительно очень сильно впечатлён, какими темпами они перепрыгнули бухкалькулятор и действительно стали платформой. Я сам себе дома на 1С такой комбайн написал - закачаешься, и почту принимает-анализирует-отправляет, и боты в мессенджерах, и печать документов, и сборки-автотесты релизов и ещё куча всякого. Это действительно платформа. Да, не всё гладко, многое ещё предстоит, но путь проделан огромный. И ваши рассказы о том, что 1С-ник - это бухгалтер с небольшими познаниями в хтмл-подобной разметке - это уже довольно устаревшее видение. Современный 1С-ник и тем более будущий 1С-ник обязан быть больше программистом, чем бухгалтером. Для прикладной области есть аналитики. А от 1С-ника сейчас и тем более потом будет больше требоваться, чтобы код не убивал железо, чтобы при любых раскладах была стабильная ветка релизов, чтобы не нужен был штат тестировщиков, а тесты бегали круглосуточно сами, чтобы коммиты-сборки-тесты-внедрения проходили автоматом и безболезненно. Да, ещё много областей, где ещё всякие УПП с обычными формами, даже 7.7 ещё живее всех живых. Но это уже "вчера". Если мы принялись обсуждать "сегодня" и даже "завтра" - там нужны именно программисты, а не бухгалтеры, мутирующие в недопрограммистов.