Ковырял в ЗУП 3.0 расчет аванса по кнопочке заполнить. Нашел откуда берется ФОТ, не понял почему он не меняется при изменении окладов кадровым изменением, понял что все существующие методы расчета авансов нас не устроят и придется написать внешнюю обработку заполнения табличной части в один маленький запрос и одну процедуру.

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

Объявляю вознаграждение в 20 смарт-маней за самый глубокий стек вызовов в типовой конфигурации 1с. Подведение итогов 30.12.2016 года.
---
Замерял в ерпи 2.1 стек вызовов в процедуре закрытия месяца. Насчитал глубину около 22.
---
philya,
Объявляю вознаграждение в 20 смарт-маней за самый глубокий стек вызовов в типовой конфигурации 1с. Подведение итогов 30.12.2016 года.
А вы в курсе что к указанной дате все эти 20 СМ сгорят?
---
klinval, я еще дам ) У меня есть.
---
20 методом тыка в Бух 3.0 нашел 20 уровней вложенности
---
monkbest, и заметьте - ни одного метода с допиской "Переопределяемый"...
Если честно в шоке, я думал, что автора с 18 никто не побьет! Я находил только 15 глубину (5 до вызова фонового задания и 10 после). Получается тенденция такая - всё что связано с ЗП имеет большую глубину вложенности.
---
klinval, это я еще ЗУП 3.0 не открыл, там думаю можно хорошо нарыть))) я знаю при формировании отчетов там тексты запрсов кодом формируются через одно место и сам расчет ЗП там посложнее чем в Бух 3.0 будет))
---
опа, уже 21, все там же по кнопке рассчитать зарпалату, этим можно заниматься до бесконечности)))
---
18 вызовов? Это мало! Проведение документов в БУХ 3.0 там за 100 улетает!
---
DoctorRoza, и остальные господа! Коль это предмет научного исследования, то давайте подавать факты четко.
Указывать :
1)расположение процедуры (имя общего модуля, имя объекта и т.д.)
2)ее имя
3)глубина (пожалуй, с учетом всех, от головной по последней вызванной).

А мое мнение - это отврат. Я своих программистов бью по рукам за излишнее разбиение. Оно должно быть продиктовано смыслом. А именно, когда процедура реально вызывается из 2-х и более мест. Разбивка просто "для компактности" только убивает сопровождаемость.
---
Dnki, Не соглашусь с вами. Например процедура размещения товара на адресном складе
Поддерживать 600 строк
Или основная процедура с примерно таким текстом
ПолучитьОстаткиРаспределения(Парметры)
ОпределитьгруппыСовместимости(Парам)
Для каждой группа из группы цикл
   РаспределитьГруппу(парам)
КонецЦикла
СоздатьДокПеремещения(Парам);
При этом все указанные процедуры вызываются только из одного места и в сумме примерно те же 600 строк

Какой вариант легче поддерживать? Я считаю, что второй.
---
А если так:

```1c
    Процедура РазмещениеТовараНаСкладе()
    // Получить остатки распределения
    блок какого-то код
    // Определить группы совместимости
    снова блок кода
    // Распределяем группы
    Для Каждого Группа из Группы Цикл
    КонецЦикла;
    // Создать документ перемещения
    код для создания документа
    КонецПроцедуры
```

Все то же самое, все в одной процедуре.
Аккуратно разбито по блокам, и без лишних вызовов...
---
loki03, Но если захотеть повторно использовать код - то придется таки разбивать.
Это первое
Во вторых - где гарантия, что все переменные разнесены по блокам? Что если отделить Выделенный фрагмент, то он сразу заработает?
В третьих - комментарии ставим только между блоками? А если внутри блока захотелось? Как тогда понять где блок, не читаю всю процедуру?
Вывод - разбиение все же увеличивает читабельность кода. Просто увлекаться и злоупотреблять не нужно.
---
Ovrfox, в-3х
(22)
---
loki03,

```1c
    #Область
    ...
    #КонецОбласти
```
---
Dnki, Я своих программистов бью по рукам за излишнее разбиение. Оно должно быть продиктовано смыслом. А именно, когда процедура реально вызывается из 2-х и более мест. Разбивка просто "для компактности" только убивает сопровождаемость.
Две крайности:
1) 1С-овская крайность - когда тысячи одно строчных методов, попытка на каждый чих создать отдельную процедуру или функцию
2) Вторая крайность - когда всё должно быть в одной процедуре. 1000 строк кода? 5000 строк кода? Уже даже разработчик не может понять что и как - ни в коем случае не разбивать на методы, а то мы станем как программисты фирмы 1С!

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

Разбивка как сама цель, т.е. <Разбивка просто "для компактности"> - такого не должно быть. Но и не разбивать нечитаемый метод только потому что выделенная процедура будет вызываться только из одного места - тоже нельзя. Читаемость уменьшается в обоих случаях.
---
(6) (7) Код разбивают не для красоты, а для облегчения сопровождаемости чужого кода. Ваш любимый вылизанный код, для другого программиста будет сущим адом, если писать функции по 600-1000 строк. Практика показывает, что если код функции занимает более одного экрана, то скорость прочтения и понимания кода падает в разы. Если же те самые блоки разбиты на функции с говорящими названиями, то можно даже избавится от излишнего описания, оставив короткий комментарий по специфическим моментам, которые нельзя вместить в наименование.
---
Артано, вы говорите понятные вещи. Расскажите зачем 1с из обработчика кнопки вызывает метод модуля документа, который тупо вызывает метод формы? Зачем все эти общие модули, в которых однострочные методы вызывают однострочные методы?
---
Это вопрос к разработчикам 1С. Но по практике сказать могу следующее. Если код выполняется много раз, то бывает создаются и функции в 1-3 строки. Особенно если этот участок кода склонен к периодическим изменениям. Очень удобно, в таком случае, выделить участок кода и пользоваться уже им как методом с утвержденной спецификацией. Если потребуется внести изменения, то изменяется лишь один метод. Входящие и исходящие данные не меняются, внутренности инкапсулированы, так что в таком случае выигрыш.
По приведенному примеру сказать мало что могу, возможно это остатки другого кода, когда эти методы были не однострочными.

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

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

В юмористическо-литературной форме эту проблему я когда-то уже излагал
---
Артано, (22)
---
DoctorRoza, я верю, но хочу картинку (у меня не получилось вывести стек вызовов в текстовый документ) и краткое описание в какой момент это случается.
---
Сейчас придет ildarovich, выгрузит всю ERP в хитроумную цепочку графов и напишет запрос, выбирающий максимальную глубину вызовов в этом графе :)
---
Надо было в условиях запретить рекурсию (неуникальные строки в стеке) в любом виде. А без этого запрета первая же рекурсия даст приличную глубину. Например в обработке УниверсальныйОбменДаннымиXML при рекурсивной выгрузке по ссылкам.
---
Это вопрос к разработчикам 1С
Вообще, к разработчикам типовых конфигураций много вопросов.
Но мне понравилось, что топикстартер не задается вопросом "Зачем столько?", а просто предлагает постебатьсячитать. И это правильно!

Подписался на тему.
---
На самом деле все просто. 90% однострочных процедур в БСП и типовых - это претензия не к разработчикам БСП и типовых, а к разработчикам платформы. Кто ж виноват, что эти птеродактили сделали свойства общих модулей (вызов сервера, повторное использование значений и т.п.) статически неизменяемыми. В итоге плодится куча абсолютно бесполезных модулей ТраТаТаПовтИсп. Плюс невозможность переопределять или дополнять средствами платформы методы общих модулей (для модулей форм подобное сделано в расширениях) - значит добавляем ТраТаТаПереопределяемый.
---
Сисой, 90% однострочных процедур в БСП и типовых - это претензия не к разработчикам БСП и типовых, а к разработчикам платформы.
Не знаю что там с платформой, но у меня почему то ни разу не возникло желания написать свой метод из одной строки, который вызовет другой мой метод из одной строки, который в свою очередь вызовет ещё метод...
Двойную вложенность однострочных методов ещё можно объяснить особенностями платформы, но не тройную, четверную.
---
Сисой, похоже в 8.3.9 расширения могут уже почти всё - нужно попробовать.
---
Пришлось однажды переделывать код не 1С-овской конфигурации (скорее всего не 1С-Совместимо) - после этого я стал лучше относится к конфигурациям фирмы 1С. Там перед тем как вызовется реальный код ещё пройдёт 2-10 однострочных вызовов (многие не переходящие по F12). А сам реальный код модулей формы, модулей конфигурации хранится во внешних обработках... Отлаживать и изменить что-то - нереально. Кстати поломать конфу можно прямо из режима предприятия - стоит только удалить какую-нибудь прикрепленную внешнюю обработку.

Специально сделал скрины с той конфигурации. Из них мы видим, что ПриСозданииНаСервере формы документа мы обращаемся к внешней обработке, в которой тоже есть обращение к другой внешней обработке...
---
klinval, это позволяет менять функционал, не выгоняя юзеров
для базы 24/7 это выход
---
tailer2, это база для управления IT (заявки пользователей, учет картриджей и т.д.). Явно не 24/7!
Да даже для базы 24/7 - это спорное решение. Как таковой отладки для такой базы нет. Изменения/внесение/поиск/доработка которые в нормальной базе заняли бы пол часа, тут пришлось делать целый день, т.к. пока разберёшься как что устроено... Случайно затёрли одну обработку - база вообще перестала открываться.
---
klinval, для базы 24/7заняли бы пол часа
^)))

пришлось делать целый день хоть неделю, юзеры юзают
или у нас с вами разные 24/7?

про "случайно затерли", -...
ну, молодцы :))
---
tailer2, хоть неделю, юзеры юзают
или у нас с вами разные 24/7?
Я о другом - о труде программиста и сопровождаемости. Если организация переходит на такой вариант, то помимо <это позволяет менять функционал, не выгоняя юзеров> появляется сложности с сопровождением, следовательно увеличиваются временные затраты на исправление и денежные на труд программиста. Т.е. помимо плюсов есть и минусы. Насколько я знаю организации 24/7 обычно балуются динамическим обновлением.

И ещё: Если <1) База не 24/7 и 2) Работа которая заняла бы пол часа ушло 8 часов из-за такой специфики> Тогда вопрос зачем это нужно? А база, я повторюсь, для учета заявок пользователей IT отделу. Такая база в принципе 24/7 не нужна даже на большом предприятии. 5 минут простоя для обновления этой базы явно не вызовут миллионные убытки, т.к. в такой базе не ведется коммерческая деятельность. Т.е. логика разработчиков конкретно этого решения мне вообще не понятна.
---
klinval, аврально допиливали на ходу, потом ещё перепиливали при обнаружении прорех.
А потом, как всё отладилось, прибираться не стали, ибо как всегда есть другие задачи, да и "работает - не трожь!".

И да, тот разработчик, который запустил это нечто, разбирался бы с проблемой не день, не 8 часов, а не больше часа с перекурами.
---
корум, аврально допиливали на ходу, потом ещё перепиливали при обнаружении прорех.
А потом, как всё отладилось, прибираться не стали, ибо как всегда есть другие задачи, да и "работает - не трожь!".
Не разбирался на 100% в конфе, но судя по тому что я видел: практически всё выведено во внешние обработки. Например движений документы не делают напрямки, зато есть одна подписка на все документы, которая вызывает внешнюю обработку, в которой и есть весь код. Плюс все формы фактически внешние. Причём внутренние нарисованы так-же как и внешние, но весь код состоит из перенаправлений на внешнюю...

Думаю это было продиктовано не авралом, а это целеноправленное решение делать именно так. Причём есть ощущение, что у разрабов есть нормальная база, просто они в релиз атоматизированными средствами делают из неё базу с внешними обработками. Тем самым завязывают пользователя чисто на себя, т.к. сторонний программист в таком бреде будет разбираться гораздо дольше. Ну и конечно плюс в том, что исправить ошибку можно через внешнюю обработку, которую пользователь может сам прикрепить.
---
Пришлось однажды переделывать код не 1С-овской конфигурации
О того, что кто-то пишет еще хуже, код типовых лучше не становится.
---
papami, чисто психологический эффект: видишь, что где то намного хуже и твоя оценка от "Отвратительно" меняется в пользу "Плохо, но терпимо"
---
И да, тот разработчик, который запустил это нечто, разбирался бы с проблемой не день, не 8 часов, а не больше часа с перекурами.
Точняк! Проблема с потерей времени не в методике, а в том, что контора потеряла ценного (того самого) разработчика...
...И возня с 18-ю вложенными функциями связана не с тем, что их так много, а с тем, что тот самый разработчик типовой работает не в нашей конторе.
---
Недавно в Бухгалтерии 3.0 дописывали небольшой функционал! Я чуть с ума не сошел пока прописал нужные обработки в загрузку с банка выписки... Это не реально туда суда!!! ССЫЛКА НА ССЫЛКЕ И ССЫЛКОЙ ПОГОНЯЕТ ВЕСЬ функционал )))

P.S. просто не выдержал (крик души)
---
Вообще про оптимальную длину метода всё уже изучено вдоль и поперёк, см. С. Макконнел "Совершенный код", например. А большой стек это частично следствие отсутствия ООП и костылей по некоторому эмулированию этого же ООП.

В целом в текущей платформе подход 1С адекватен, я считаю.
---
zqzq, цитата из книги:

Под принципы изложенные Макконнеллом 1С вроде подходит, но это не значит, что код у них получается всегда понятным. Лично я на опрос ответил "немного напрягает".

Меня больше беспокоит качество техподдержки, которая порой всеми правдами-неправдами старается не принять заявку. Даже хотел выложить безграмотные ответы ТП на инфостарте (просто вопрос-ответ без комментариев, чтобы пользователи сами оценили кто неправ), но как-то подостыл... Но и эту проблему обошёл: просто перестали писать в ТП)) Пишем сейчас в основном только про ошибки платформы, т.к. мы их исправить не можем, да и такие ошибки с первой линии обороны обычно быстрее переадресовывают техническому специалисту.
---
klinval, есть другая умная книжка, называется "Чистый код", так вот вней не то что 100-200 допускается, там строчки 3 рекомендуют писать в одной процедуре не более. Автор настаивает на3ех строках, но допускает 1 экран. Если процедура не лезет на эуран, то это говно код. И такой подход тоже имеет право на существование

(1) Однострочные вызовы глубиной 10 и более раз - следствие не методики "Чистого кода" Роберта Мартина, а разработанной 1Сом методологии доработок типовых конфигураций. А суть его в том, что надо сторонним разрабам (нам с Вами) четкое место, куда они будут вживлять свой говнокод и это место не будет "мигрировать" от релиза к релизу, что упростит обновление. Этим местом являются модули с постфиксом "Переопределяемый" в имени, в них нет вообще кода, а только вызов следующего метода. Таким образом каждое место, куда теоретически можно внести доработку должно проходить через переопределяемый модуль увеличивая глубину стека на 2. Т.е. если в алгоритме 5 таких мест + бегаем с формы в модуль, с клиента на сервер, вот и получим 15 и более глубину стека.

Все оказывается ради нас сделано. Но я согласен с возмущением автора, т.к. это нечитабельный бред и эта методология яйца выеденного не стоит.
---
monkbest, Автор настаивает на3ех строках, но допускает 1 экран.
1 экран тоже понятие относительное. В зависимости от настроек винды и конфигуратора у меня может поместится от 1 до 1000 строк на 1 экран. Лучше измерять в строках.
Мне ближе мнение: Пусть длину метода определяют не искусственные ограничения
Т.к. можно и на 1 экран написать код который никто (даже сам авто на следующий день) не разберёт, а можно и на 10 экранов написать понятный код. Всё индивидуально, а все почему-то всегда предлагают одну из крайностей: разбить на 100 методов по 10 строк или написать 1 метод на 1000 строк. В зависимости от ситуации правильным может оказаться любой вариант или средний между ними.
---
klinval,
1 экран тоже понятие относительное. В зависимости от настроек винды и конфигуратора у меня может поместится от 1 до 1000 строк на 1 экран.
относительное, но не в таком широком диапазоне.

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

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

Что такое ООП в Вашем понимании?
Разве мы в 1С не работаем исключительно с объектами используя их методы и свойства?
Разве с появлением модуля менеджера в 1С не появилось разделение на методы объекта и класса?

На самом деле 1С со времен 7.7 - самое настоящее ООП с одним ограничением: мы не можем создавать свои классы.
Но тут вопрос: а зачем нам убирать это ограничение и разрешить создавать свои классы и заниматься наследованием?

Это не минус, такой подход позволяет разрабатывать со скоростью света, все однотипно и единообразно, есть своя методология и т.д. и т.п.
Плюс усложнение синтаксиса снизит скорость работы интерпритатора.
---
Замерял в ерпи 2.1 стек вызовов в процедуре закрытия месяца. Насчитал глубину около 22.
Прикладываю в файле замер. Вроде максимальная глубина в строке 2853
---
yurii_host, а как получить такой файл?
---
monkbest, http://infostart.ru/public/511930/
---
В ERP на формировании движений по расчетам с партнерами - 17.
(48) yurii_host, кстати, на ERP 2.1.3.199 ругается на "Не обнаружен метод Оповестить".
---
видимо запускаете на серверной. Этот вопрос уже был в комментариях к статье)
Для моих задач хватало пока использовать демо версии развернутые в файловой базе. Поэтому в работает пока только в толстом клиенте. Но вообще, если добавить в конфигурацию серверный ГЛОБАЛЬНЫЙ модуль и объявить в нем процедуру Оповестить, то в ней можно было бы и прописать логирование. Но там нужно подумать, как это сделать оптимальнее. У меня пока руки до этого не дошли
---
да, я уже наступил на эти грабли, но проблема была не в том, что база серверная, а в том, что клиент - тонкий. В толстом почему-то работает. Хотя работать не должно нигде, т.к. метод оповестить не доступен на сервере и в серверных модулях его нельзя вызывать..
---
Нет, в файловой демке делал, читал же требования.
---
если пишет, что не обнаружен метод оповестить, значит запуск был в тонком клиенте, надо в толстом. Тогда он видит этот метод. Тоже запускал на ерпи, проблем не было.
Вообще, если вопрос актуален, готов разобраться в конце недели, если кинете мне конфу в личку
---
Абсолютно точно запускал в толстом клиенте, в управляемом приложении. Может проблема в платформе? У меня 8.3.7.1917. Мне не критично, я эту демку-то развернул только из-за этого топика, чтоб вашу разработку потестировать. Если вам нужно/интересно - могу выложить CF на яндекс-диск.
---
yurii_host, в закрытии месяца сложность алгоритмов хотя бы как-то объяснима. Я тыкался в начисление аванса процентом от оклада!!

Вы пока лидер. )
---
philya, мне даже интересно, что победит в итоге: Зарплата или планирование производства в ERP...
---
Наш победитель! Ему отданы 20 смарт маней. Ура!
---
В 1с люди работают с утра и до упаду, есть конечно гики, которые живут на работе как дома, но в целом это нарушение режима нормальной жизни. Как результат мысли в кучу программисты собрать не могут. А наличие короткого кода быстро облечит неграмотность, поэтому есть негласная договоренность закидать стороннего наблюдателя шаблонами программирования и нещадно огромным количеством вспомогательных функций с элементами защитного программирования (это значит функция всегда относится к вызывающему коду, как к коду идиота, который что-то вызвал и ожидает сервис пятизвездочного отеля). Это последнее порождает вложенность, которая сбивает ваши мысли с нити ходы выполнения программы, что без отладчика вообще не ясно "откуда пришло и куда полетит".
---
Полностью согласен с вашим мнением. А программа 1с должна быть интуитивно понятная и в плане интерфейса и в плане написания (оптимизации) кода, а когда запрос на 100 страниц это уже никуда не годится и хочется этому программеру прописать пилюлю в глаз :)
---
Да, мне интересно. Если она еще сохранилась, то выложите, плиз. Я ее протещу. Если там вдруг ошибка в алгоритме - исправлю. Ссылку можно в личку скинуть.
Я эту схему периодически пользую на проектах, поэтому хочу, чтоб она работала