Привет, почему так?

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

Например, процедура печати счета-фактуры в УТ. 2000 строк чистого кода. Хрен разберешься. Почему не сделать так - в документе перед вызовом собираем все данные одним запросом, или из самого документа, делаем структуру и ее печатаем простой общей процедурой. Просто, понятно, логично.

Как мне все больше кажется теперь, люди, которые это пишут, ничего кроме 1С-ного конфигуратора не знают вообще, ни ООП, ничего, живут в своем мире, где плодят фантазии на тему, как же это все должно быть, не имея знаний, как все это грамотно реализовать. Не общаясь с конечными пользователями вообще. При этом стараясь по максимуму не писать код, а юзать объекты конфигурации даже там, где это нафиг не нужно. В итоге без знаний общепринятых принципов эффективной разработки рождают таких монстров, как УТ 11.

Я не прав?

количество строк кода не принципиально для работы

(0) Код в типовых всегда был дерьмом

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

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

Я считаю, что совершенствование типовых до сферического идеала в вакууме лишь увеличит количество кода.

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

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

1С пытаются универсализировать решение, отсюда куча неизвестных которые надо учесть. есть моменты, которые я в УТ 11 не понимаю - заполнение табличной части виды запасов сделано так, словно пользаки не делают ошибок в документах, или должны сами догадываться какие документы по цепочке перепроводить и еще неизвестно как виды запасов заполнятся, ведь кнопку "открыть виды запасов" убрали. и еще - код УТ 11 мне почему-то показался запутанее УПП 1.3. есть завязочки на невидимые по функциональным опциям реквизиты, которые потом всплывают в проводках. как будто эту конфигурацию писали в синагоге.

1) Измененения в законодательстве
2) Сроки
3) Обратная совместимость
4) Унификация по системам налогообложения.
5) Унификация по типовым конфигурациям

В совокупности это дает ЦФ-ки весом по 600-800 мб.

В клюшках под каждую систему писали отдельную конфигурации и отдельные комплекты регалментированной отчетности.

Для программистов и разработчиков - действительно было проще - а вот конечным пользователям - этот зоопарк не особо нравился.

А унифицированная Комплексная конфигурация - для нормального программирования - тоже требовала напряжения извилин. А работать с единым глобальным модулем в комплексной - удовольствие было прямо скажем ниже среднего. При этом поддержка систем налогообложения была сильно похуже, чем в БП 2.0/3.0

Так что как то так.

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

Моё мнение такое.В целом разработчики на правильном пути,и если сначала не врубаешься и начинаешь беситься ,почему всё так сложно,то потом осознаешь алгоритм и всё ложится по полочкам.
Но у меня есть сильно переписанная БСХП,и вот при её обновлении именно со стороны разработчиков я видел очень много косяков.У меня был допилленный запрос,я им даже писал поэтому поводу приложил скрин с кодом запроса,на что они мне сказали,что они вынуждены выпускать релизов столько же сколько и БП корп,но такого штаба программиста 1С у них нету,поэтому в последнее время особенно халтурят.

Сама идея БСП в том виде, как она применяется в типовых - порочна до невозможности. Вот скажите, нафига выносить в общие модули процедуры типа "ЗаполнитьРабочееВремяВТабеле(ТабельСсылка)"? Чего в этом "общего"?
Еще могу обратить внимание на деградацию принципа модульности. Фактически перестали использовать модуль объекта и модуль менеджера. Код пишется или в модуле формы (что относится к форме) или в общем модуле (и пофиг, что код используется лишь одним объектом). Это и вызывает тот горький катаклизм, который мы здесь наблюдаем.

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