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

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

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

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

Я не прав?

(0) >>В итоге без знаний общепринятых принципов эффективной разработки рождают таких монстров, как УТ 11.

Ну дак напиши свою программу и делай её идеальной, делов-то.

(0) <ни ООП, ничего>

не везде ООП применим

P.s. по мне так самое суровое наркоманство в ЗУПе

(1) +100500 с блэк-джеком непременно.

(0) Умножь это на 100-200 (разрабов которые одновременно пилят ERP2 из которой и обрезают КА2 с УТ11) и учти что там запрещают "просто писать код, ..ять" а писать только по если в ТЗ это предусмотрено ))

(4) По ТЗ что-то реализовывать обязательно именно наркоманским способом?))

(2) >> самое суровое наркоманство в ЗУПе

+100

В УТ всё по большому счету вполне себе ничё... )

>> Я не прав?

Да. Ты не прав.

(2) Не имел дело пока, слава богу))

(6) Обоснуешь? :)

(5) Когда конфигурация пишется/дорабатывается лет пять, то результат непременно будет таким.

(9) Почему?

(0) Ты просто новенький - не въехал в "специфику" :(

(5) Угу.

И самое смешное что эта "манская" идеология идет в массы и лишний раз фра/фикси типовую конфигу не тронет, а будет изобретать кучу внешнего с максимальным использованием типовых извратов

(0) Как избавятся от сурового наследия ЗУП, так все будет гладко. Движение в этом направление есть.
Много кода это универсальность, модульность, гибкость.

(9) Многие крупные разрабы софта поняли что циклы-итерации разработки решений не должны превышать 1-4 лет, лучше вовремя перейти на новую версию чем пытаться поддерживать-допиливать старую.

(14) это с трудом применимо к софту уровня 1С, причём 1С так делает только потому что они монополисты

(13) Сделать маленькую доработку и получить косяк в совершенно неожиданном месте, потому что есть куча неявных и ненужных связей и зависисмотсей это универсальность, модульность, гибкость.? :)

(15) Все прекрасно применимо, особенно в БП когда законы каждые полгода меняются.

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

(15) ЗУП переписали полностью, тащемта

(0) >> Хрен разберешься.

Вряд ли это можно считать поводом для гордости.

>> Почему не сделать так....

Ты подсистему Печать в БСП смотрел?
Там всё вроде как русским языком описано.

>> ...в документе перед вызовом собираем все данные одним запросом

Собственно говоря так и делается. Только не в документе, а в менеджере документа.

>> ... или из самого документа

А вот это неверно, так как БСП-шная подсистема печати заточена под универсальность - возможность печатать не один объект (документ/элемент справочника), а массив объектов - в случае групповой печати.
Лепить запросы в цикле на несколько сотен документов с печатью после каждого запроса - за такое потом 1С-ников в аду на отдельных сковородах держат.

>> Просто, понятно, логично.

Именно так всё и реализовано при помощи механизмов БСП. Просто, понятно, логично.
Если у тебя не хватает мозгов разобраться с одной из самых простых подсистем БСП - подсистемой печати, то... Я даже не знаю, что.... стыдобища какая-то....

(16) если тебе кажется что, что-то плохо, то это еще не означает, что это, действительно, плохо :)

(18) те-же наркоманы которые когдато зик писали, да.. (я пропустил большой кусок развития восьмёрки, для меня ЗУП существует с версии 2.5 и в виде ЗиК)

как был кошмар и ужас, так и остался

(0) процедура печати это почти всегда наркоманство, причем чаще всего сделано именно так, как ты говоришь:
один раз спросили запросом, и потом бегаем с этими "данные шапки" по всем функциям. Ну и строки еще одним запросиком.
Только блин эти печатные формы настолько перевывернуты, что аккуратно в MVC их не засунешь - всегда какая-то работа напильником.

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

(21) Надо есть те же грибы, что и разработчики ЗУП. Тогда можно настроиться на ту же волну )

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

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

(0) платят за количество строк в полотне.

(26) <Понимать, что там скорее всего работают люди более высокой квалификации чем твоя и ты не все можешь понять и правильно оценить. >

Я долго думал об этом в конце 2000х годов глядя на коробку бухгалтерии с пачкой дискет

(19)

>> А вот это неверно, так как БСП-шная подсистема печати заточена под универсальность - возможность печатать не один объект (документ/элемент справочника), а массив объектов - в случае групповой печати.
Лепить запросы в цикле на несколько сотен документов с печатью после каждого запроса - за такое потом 1С-ников в аду на отдельных сковородах держат.

Не понимаю, в чем проблема с запросами из документов. Сделали все запросы, получили все данные, разом распечатали. При чем тут циклы? В чем проблема?  

>>Именно так всё и реализовано при помощи механизмов БСП. Просто, понятно, логично.
Если у тебя не хватает мозгов разобраться с одной из самых простых подсистем БСП - подсистемой печати, то... Я даже не знаю, что.... стыдобища какая-то....

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

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

(26) Есть примеры где эта универсальность реально пригодилась? Хоть 1?

На вкус и цвет...Еще точнее: хозяин-барин....Не нравится - не ешь.

(24) Возьмите муравейник. Универсально, гибко, в тоже время просто и ничего лишнего. Что мешает строить системы такого типа? Максимально независымые, простые элементы?

(34) Построй.

(35) Не про меня речь.

(33) Arguments! We need arguments!

(35) +100500
Автор, ты сначала нарисуй конфигурацию, подобную той же УТ11, которую ты так люто не любишь, только простую и гибкую как муравейник. А потом будешь рассказывать, кто крут, а кто не очень.
З.Ы. Ты не из Новосибирска случаем?

(36) А чего не про тебя-то? Ты считаешь себя умнее разработчиков типовых, так докажи это.

(38) (39) Что-то взорвалось?))

(40) У тебя?

(41) Похоже что нет))

(42) Со мной всё в порядке. Я не считаю себя непризнанным гением)

(43) При чем тут непризнанный гений?)

(37) Аргумент в том, что типовая конфигурация оптимизируется под максимальное количество возможностей использования. В руках внедренца оставить тот код, который он считает необходимым и достаточным. Критика становится продуктивной только при наличии альтернативы. Ты альтернативы не предложил.

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

Представляю как твоя простая общая процедура в итоге начинает обрастать условиями при наличии, хотя бы 10 печатных форм, и потом ты на нее смотришь и видишь фигню полную.

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

P.S. не сказал бы, что в коде 1С все прекрасно, но в большинстве - код достаточно хороший.

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

(47) Ну да, ты все правильно понял))

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

(45) (46) Каких 10 печатных форм? Общая процедура печатает только счет фактуру. Архитектура такая:

У каждого возможного источника (документа) есть своя процедура получения данных, запросом или как-то еще, итогом такого запроса является структура данных, одинаковая для всех источников. Эту структуру они все передают в некую процедуру, которая просто выводит ее на печать. В чем проблема такого кода? Надо напечатать 1 документ, напечатали, надо много, получили структуры со всех источников и разом все напечатали. В чем проблема?

(48) Еще бы не понял, я ж больше 20 лет в IT. И чем дальше, тем больше понимаю муравьев. Вот как раз типовые сейчас - это пример из (47): все в одной куче. А муравьи - молодцы, они придумали распределенную БД.
Поэтому мы сейчас работаем над распределенными базами 1С и взаимодействием между ними через http-сервисы. Производительность расчет на порядки, выживаемость в разы, масштабируемость - практически бесконечно.

+(51) Просто рано или поздно наступает момент, когда в одной комнате жить невозможно как минимум потому, что куча муравьев нагрет в ней воздух до уровня сворачивания белка, и погибнет. Вот и распределяют горизонтально и вертикально.

(51) (52) Я наркоман, ты молодец, успокойся :)

(53) Тут сегодня еще ветка про психов была ;-)

(0) "делаем структуру и ее печатаем простой общей процедурой"
Позвольте усомниться в простоте общей процедуры, которая будет печатать сотню печатных форм по полусотне видов документов, притом делать это корректно для ОП, УСН, ОСН, импорта и прочих-прочих особенностей.

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

(56) "Код в типовых всегда был дерьмом"
... как и почти любой код в достаточно старом развивающемся проекте. Красивый код бывает только короткое время. А потом превращается в legacy-код со всеми вытекающими...

(54) Ты во всех ветках про психов отмечаешься? :)

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

(56) для тех, кто не видел отраслевых

(58) Тянет к своим, что тут сделаешь.

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

(53) Вот тут теория объясняется

http://narisoval.ru/

(50) А ты уверен что 1С не упадет от твоей огромной структуры, которая может сформироваться когда-нибудь? Судя по количеству колонок в счет-фактуре и доп. полей это вполне может случиться.

(65) Сколько там 10, 15 колонок? Ну конечно упадет.

А, и проголосовать

сам всегда удивлялся, как можно так запутать простую печатную форму, нагородить кучу кода процедур и функций.

(30) >> в чем проблема с запросами из документов. Сделали все запросы, получили все данные, разом распечатали. При чем тут циклы?

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

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

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

Для создания внешней печатной формы на основе типового и дальнейшей доработки не нужно во всём этом разбираться.
Нужно лишь локализовать нужный участок кода и доработать его.

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

Приведи примеры.

(0) Да не в коде проблема у 1С а в методологии :( Но это проблема пользователей а не фирмы 1С :)

(55) Для самой ПФ эти различия не так существенны, их не сложно реализовать, у нас же будут ссылки на объекты, будет понятно, для кого что печатать.

(69) Не обязательно, что мешает получить от метода объекта данные по всем объектам этого типа сразу, если надо? А не обязательно по 1. Такой запрос не сложно сделать.

Плюс к тому, при такой архитектуре мы получаем:

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

Таким образом у нас получается простой, понятный и независимый код, который просто править и поддерживать, настоящая универсализация, как она реализована в ООП. В данном случае - это инкапсуляция, объект (например - реализация) работает со своими данными, никто туда кроме самого объекта не лезет. Счет-Фактура данные только печатает.

Чем плоха такая архитектура?

(70) Я написал "как мне кажется", к сожалению, я не знаю никого из разработчиков 1С, а так бы спросил, самому интересно ))

(0) Потому что БСП. Сама по себе идея БСП - это большой плюс. Но вот реализация идеи - через заднее место.

А, ну да, я все же не уверен пока, что разработчики 1С сплошные наркоманы, поэтому:

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

(76) Каких библиотек? Я про 1с-ный код говорил. То есть в модуле менеджера Счета-Фактуры работу с данными вообще не ведем, никаких СформироватьВременнуюТаблицуТоваровДляПечати(), только их вывод, сами данные, готовые к печати, нам передают объекты. У них у каждого своя процедура, все они возвращают одинаковую стурктуру с данными, по одному или нескольким объектам своего типа. Т.е. 1 объект (например - реализация) возвращает структуру с данными по 1-й или нескольким реализациям, уже готовую к печати, а модуль менеджера Счета-Фактуры их на печать только выводит, ничего ниоткуда не получает.

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

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

(72) >> "У каждого объекта метод свой, независимый"

В этом плюсы, в этом и минусы.

Завтра наш любимый законотворец объявит, что в пустых графах счета-фактуры должно быть вместо знака "-" (прочерк) печататься, например, "х" (крестик).
И будешь ты вместо того, чтобы в одном-двух местах подправить ковыряться в каждом из своих независимых объектов править те места, где необходимые данные собираются. И с вероятностью 99% какой-нибудь объект обязательно забудешь.

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

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

(80)

>> Завтра наш любимый законотворец объявит, что в пустых графах счета-фактуры должно быть вместо знака "-" (прочерк) печататься, например, "х" (крестик).

Выводит у нас только модуль менеджера Счета-Фактуры, там это легко правится, можно даже с условиями. В (77) я уточнял.

(82) Ваша логика сходу разбивается об УПД.

(83) Почему? В чем проблема реализовать его печать таким методом?

(84) Потому что УПД печатается из документа реализации.

(81) Как мило. Столько эмоций

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

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

(88) >а кодеры - в основном девочки с небольшим опытом работы.

Рыдалъ

Вообще в УТ 11 они (1С-ники) сами отошли от многих своих же принципов по сравнению с УТ 10.3

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

А мне нравятся в БСП комменты для пустых процедур и функций типа: "сохранено для совместимости, теперь эта функция находится в ....". Это-же гениально перенести код из одного общего модуля в другой, могу предложить наименования для общих модулей делать с признаком цвета, например СинийФизическиеЛица или КрасныйСтроковыеФункции, творчество должно быть разнообразно и дизайнерам то-же хочется кушать :)

(91) Это смешно ровно до той поры, пока ты не начнешь писать и поддерживать свой коробочный продукт и планировать что поломается у не одновременно обновляющейся и пропускающей релизы пары сотен тысяч клиентов.

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

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

(91) Глядя на конечный результат всегда легко обвинять.

Бог - некудышный конструктор

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

Но если понять, что это эволюционный процесс, а не изначально конечная задумка, то всё встаёт на свои места.

Такое расположение нервов и сосудов млекопитающие унаследовали от рыб, у которых шея отсутствует.

(92) (94) Не надо пытаться объять необъятое, есть основной функционал с определенными функциями и ограниченным количеством справочников, то есть многократно используемые коды функций и процедур и основные справочники, это организации, контрагенты, физлица, пользователи, адресный классификатор, валюты, ед. измерения, страны, обмены, доп.сведения для всего, ну может ещё что-нибудь пропустил. А всё остальное в БСП от лукавого, в начале надо сделать основание, а дальше пусть будет на совести писателя конфы.

(89) Мухаха.

сам ты лишний.

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

обстрагироваться = абстрагироваться

обстругироваться...

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

(0) За этот код кто-то получил зарплату.

+(102) Больше кода - больше зарплата. Все очень просто.

В 2003 году начинал с 77, в течении полугода...года с нуля самостоятельно изучил Бух, ЗИК, в т.ч. программировал несложные отчеты... При этом особо информации не было, форумо, литературы.
В 2007...08 году Предприятие 8.0, Бух 1.6 ЗУП 2.5- уже сложнее... Далее УТ10

Сейчас УТ11, КА2.2 - очень замуженно, сложно...

П.С. Возможно, просто я старый

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

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

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

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

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

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

"3) Обратная совместимость " - с кем? Её просто нет
"4) Унификация по системам налогообложения.
5) Унификация по типовым конфигурациям " - это тоже МИФ. Ибо как они не стараются а все равно БП и УПП(ЕРП) разные

P.S Или речь идет о УТ11/КА2/ЕРП2 в которой фактически 1С единным и универсальным кодом пытается покрыть несколько разных конфигураций?

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

(109) а с зарплатой было проще ибо бухии никогда не понимали как там и что и туда кривыми ручонками старались не лазить

(0) Все не читал. Но тем не менее выскажу свое мнение.
Картина мира простого 1Сника она очень плоской может быть то есть "двухмерной". А разрабы пишут в "трехмерном" пространстве. Но не исключено что есть среди простых 1Сников и те кто может владеть "трехмерным" мышлением а то и редко бывает кто-то и может увидеть 4ое измерение.

Когда-то года 3-4 наза когда сел писать самописку плюнул на БСП и писал с нуля. А теперь понимаю что стоило писать на БСП. Такие вот дела.
А сейчас решил вообщее в ближайшей перспективе не писать самописки. ДА и вообще писать код не стоит сейчас лучше правильно выбрать продукт!

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

(112) Не глаз, а щуп.

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

(112) Ага, если бы еще руки доходили до того, что видят :)

(114) Вот. Руки. Я же говорю - все наощупь и не пойми с какой стороны.

Кстати, на заметку ТС, который слинял. Даже люди, которые поливали код, не выбрали вариант "Нет знания принципов прикладного программирования". Вообще. Никто. (:

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

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

(118)>>почему всё так сложно,то потом осознаешь алгоритм и всё ложится по полочкам.

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

(118) Не до конца правильно сформулировал сообщение,там в запросе просто был добавлено два поля,со значениями НЕОПРЕДЕЛЕНО .Зачем это было сделано,даже они ответа не дали.Я так понимаю они просто взяли кусок нового запроса из БП Корп ,а этих полей у них тупо нету в конфигурации,но вместо того чтобы отладить дальнейший алгоритм тупо вставили вместо них два поля Неопределено .А мне пришлось тоже во все мои подзапросы в  объеденении добавлять это Неопределено .

(0) "не знают вообще, ни ООП, ничего" эти слова запрещено говорить на этом форуме :)

у 1С-ников свое болото и со своим уставом в него не принято соваться. иначе узнаешь о себе и их болоте много нового.

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

(122) "Фактически перестали использовать модуль объекта и модуль менеджера" - управляемые формы "подкосили" идею.

(123) Да, пыхыписты оккупировали 1с

(0) Я тоже раньше думал что нужно писать код короче, и использовать универсальные процедуры.
Но потом я вырос из этого возраста, набрался опыта, и пишу сразу много строк чтобы потом не переделывать по много раз.

(122) За общий модуль больше денег платят.

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

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

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

(129) Программирование - не язык.

С автором солидарен, новый стиль написания решений просто УГ.Новый решения очень тормозные из за такого стиля.

УПП 1.3 пока на этом фоне смотрится просто отлично.


Естественно на новые конфы типа ERP и УХ никто не хочет переходить, потому что архитектура часто меняется. Глюков несчетное количество. Не понятно что там в голову взбредет разработчикам, напилили кучу никому не нужного функционала, который толком и не работает. Вообще , пока что смотрится все это, к сожалению, как провал.

(0) Тема из разряда - "Я не осилил УТ11, пойду напишу об этом на форуме."
Напиши печать счета-фактуры  хотя бы, посмотрим на количество кода.

(131) >>напилили кучу никому не нужного функционала, который толком и не работает
Ну им же деньги надо как-то зарабатывать, вот и напилили.
Всем остальным одноэсникам это тоже кстати выгодно - есть что продавать и сопровождать.
Код местами действительно тяжеловат, можно было и пооптимальней написать, но у них нет времени на оптимизацию, не успевают они и вперед идти и законодательство поддерживать и код оптимизировать.
Поэтому - "мыши плакали, кололись, но продолжали жрать кактус"

(85) И в чем проблема сделать процедуру вывода УПД?

(134) Сделай

(103) Этот вариант стоило добавить в голосовалку, не подумал))

(135) Не о том речь.

(137) Речь о тебе. Вот ты весь такой недовольный, но где пример твоих разработок, чтобы мы могли оценить твой оптимальный код?

(132) (138) Много раз тут уже написал, как можно сделать, (72) (77) например.

(127) "Если же код шарится между несколькими типами метаданных, то он пишется в общем модуле, что абсолютно логично и понятно."
Загляните в типовые и ужаснитесь. Там больше половины процедур из общих модулей узкой специализации.

(139) Это всё слова. Ты код покажи

(136) Ты сейчас практически подписался, что цель опроса - просто поглумиться над типовыми.

(142) Почему ты так решил?))

(142) Да, согласен. Засим ветка закрывается.

Правило 1С-6. Запрещена публикация чисто чтобы поглумиться различных косяков в типовых конфигурациях, примеров кривого и неоптимального кода, а также программных комментариев.