Вопрос по теме- досталась конфигурация с внесенными к типовой изменениями.

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

ни одно из типовых не соответствует на 100% стандартам самой 1с...

а вообще в 1с можно подать эту конфу на значек "1с совместима" если пройдет - все более менее нормально, если не пройдет это ничего не значит

(1) да, я понял - подать на 1с совместимость . Хорошо.
Как бы мнение от самой 1с.

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

У 1с есть конфигурация автоматизированного тестирования. Она умеет

Хорошо, это я посмотрю

а зачем? какова цель этого всего? если что-то не работает - сделай чтоб работало, если все работает - сиди и делай вид что тоже работаешь

(5) Видимо, руководство захотело. Как в том анекдоте "да я знаю, доктор, что нормально, но неаккуратненько как-то"

(5) цель- попытка заставить исправить ошибки )

(7) ошибки или несоответствие стандартам?

(7) ошибки <> несоответствие стандартам

Цель - не платить за разработку под таким предлогом.

(7) соответствие стандартам <> хорошо

Вам чего надо? если надо проверку качества кода - это одно, но это совсем не значит соответствие стандартам...

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

ну а если проверка стандартам - то только в 1с....

кроме всего - сразу определитесь, что является для вас хорошим показателем а что плохим

"найдите по отзывам хорошего спеца и отдайте ему"

Только сначала ОЗК нужно озаботиться...

(12) ну можно и по удаленке

Автоматизированную проверку сначала разверну.
Нравится тем, что элемент субъективизма "хорошего спеца" не будет присуьствовать

Посмотрю, что за результаты она покажет )

Проверить типовые конфы этой автоматизированной проверкой и подать на 1с в суд )))

Количество обнаруженных ошибок 16349 )

(16) Всего лишь?

(16) и что после найденных ошибок - работать функционал перестал ?!

(16) сколько из них в доработках и сколько в типовой)))?

(16) а неизмененная типовая при этом сколько показывает?

(19),(20) проверял только доработки

(21) проверь что- то сравнимое в типовой для интереса

Очень много по орфографии - как бы ладно.

Но есть толковые - про отсутствие блокировок на читаемые данные, про реквизит Ссылка динамического списка, использование текущейдаты,
удивили неверные права- сам бы не догадался

Так в стандартах, же по большей части написано рекомендуется.
Ну получите вы бумагу, где сказано, что то то то то не соответствует стандартам.
А подрядчик скажет, ну так то рекомендуется для общего случая, а у Вас уникальный, и мы вынуждены были так сделать, у Вас же не ларек какой то, а крупная динамически развивающийся компания:)
А вообще договор подписывать надо было с тем как должно работать и за какое время, что б что то еще можно было предъявить.
а так наше доработки представляются AS IS:)

(16) я тестировал доработанную конфигурацию "консолидация" встроенными средствами - мне выдало около 6 тысяч ошибок (обращаю внимание - встроенная проверка), из них около 1000 были СИНТАКСИЧЕСКИМИ !!!!

при этом на этой конфе до сих пор работают (правда не я, я ее похоронил) и говорят "это самая правильная конфа и мы ее любим"

про 1000 синтаксических ошибок не верю

(24) за разработки, не соответствующие стандартам не будем платить (

(27) Что и требовалось доказать.

Скажите ваш ИНН, чтобы в случае чего, вам сразу ставить ценник x5

(28) и предоплату 100%

ВикторП   а в вашем договоре написано, что код должен быть "Совместимо 1с?" Или там написано, что это должен быть самым оптимальным кодом?

Кризис - отличный casus beli не платить за сделанные работы, да Виктор?

Несоответствие высосанным стандартам - тем более.
Будем наедятся, что акты подписаны.

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

(33) Так договора нет? Или как? Вам уже разработали?

(33) Что за бред? Что значит:
не должно быть ошибок по требованиям соответствия стандартам разработки ???
Что значит ошибка требований?

(33) и с чего вы решили, что продукт у вас останется? если вы его не оплатите, то должны будете программу вернуть

(36) Именно поэтому нужно лицензирование с закрытым кодом. Чтобы клиент мог вернуть программу.

(35) в конфигурации АПК есть требования - это  справочник, в которых содержатся программы проверки конфигурации, одно из уже готовых требований- это проверка на соответствие системе стандартов, есть еще по орфографии, есть по 1с: совместимо

(38) Ну написать под АПК можно, только не забудьте еще указать, что бы этот получившийся программный выродок был работоспособен, и учтите, что каждый новый, а мы тут забыли, а вот этому нас не учили будет стоить много дороже, а такие моменты будут.

1С ЕРП получается не совместимо, ибо там такая дичь написана и по модулям рассована, что просто вырви руки.

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

(0) Сонар

(41) >три реквизита типа спр Контрагенты

А вы уже разобрались зачем нужны эти три разные реквизита одного типа?
Предлагаете их заменить на ТЧ с допполями?

(41) > Вообще-то- я сам программирую.
Вы - самый отвратительный тип заказчика.

(44) :-)

(41) ну и что? В конфигурации УПП в документе РеализацияТоваровУслуг есть Контрагент типа Контрагент и Грузополучатель типа Контрагент. 2 реквизита. Конфа более чем успешная, никого эти два реквизита не парят.

(43)+ Например учли что будет с запросами, их усложнением и как следствие тормозами?

(43) да, в одном Элемент, в другом его Родитель, в третьем - Родитель.Родитель , вот так круто )
(44) я не заказчик, я приемщик

Эх... Помнится читал я много лет тому назад рекомендации от 1С делать процедуры и функции не длиннее, чем на 300-400 строчек, дабы поддержка смогла разобраться в этих процедурах и функциях, а потом с печалью изучал типовые конфигурации, где обычные запросы зашкаливали 3000-4000 строчек (тоже, наверное, чтобы проще было разобраться), с тех пор мне не интересны "рекомендации" от 1С...

(44) самый отвратительный тип заказчика - это я, я ничего не заказываю :)

вообщем, дальше пошла миста гулять

(48) в той кофе про которую я писал в RLS было примерно так (помню 7 уровней родителя), я тогда дутко удивился как это вообще работало

где
родитель в (&эл)
или родитель.родитель в (&эл)
или родитель.родитель.родитель в (&эл)
или родитель.родитель.родитель.родитель в (&эл)
или родитель.родитель.родитель.родитель.родитель в (&эл)
или родитель.родитель.родитель.родитель.родитель.родитель в (&эл)
или родитель.родитель.родитель.родитель.родитель.родитель.родитель в (&эл)

(48) >в одном Элемент, в другом его Родитель, в третьем - Родитель.Родитель

Не видя и не разбираясь в конфе сложно понять зачем это надо.

https://forum.infostart.ru/forum9/topic189318/

(52) Что-то подобное, кстати, когда-то видел в типовом коде, вообще не измененном кривыми ручками...

(54) это RLS !!!!!

(48) С постановкой-то задачи вы хоть знакомы, приемщик? Судя по необходимости помощи форума и детской радости при упоминание АПК - нет. И это просто бурлит и пузырится "я бы сам круче сделал".

(54) Одни же люди писали :-))) , или ты думаешь, на RLS каких-то особых спецов подрядили?

(57)->(55)

(56) Функционал АПК относительно http://catalog.mista.ru/public/1089670/ как соотносится

(33) такой договор никто не подпишет, потому что это увеличение трудоемкости в несколько раз. К тому же АПК не всегда понимает контекст и некоторые участки кода приходится помечать спец маркером для исключений.

(27) ыыыыыыыы. В договоре "по стандарту"  прописано?

(60) почему, если работаешь по часовой ставке какая разница ?

просто это будет выглядеть так:

- Почему мне за простой отчет зарядили 12 тыс? а я оценивал у соседей - они сказали только 5?
- Сертифицированый спец стоит 2.5  а не 1.5 и ему дополнительно потребуется еще 2 часа  на приведение к стандарту....


(0) кстати хороший вопрос к ТС - а он свои поделки проверял на соответствие стандартам?

(41) так стандарт и архитектура вообще паралелльны. Вот в каком стандарте прописано, что нельзя делать реквизиты контрагент и родитель.родитель?

(41) Это у вас с представлением архитектуры швах, а в справочнике 3 реквизита с одним типом. В ЕРП тоже в регистрах и Организация и Обособленное подразделение тоже одного типа, спр.Организации, но сказать что это швах нельзя. Или можно?

(64) Ну, если верить (48):
"да, в одном Элемент, в другом его Родитель, в третьем - Родитель.Родитель , вот так круто )"
То решение, и правда, прикольное, но, с другой стороны, хвататься в запросах такая структура будет быстрее, чем Родитель.Родитель.Родитель. Поэтому, не зная, зачем такое сделано я бы промолчал.

Меня, скажем, гораздо больше напрягают решения "сертифицированных" спецов 1С в типовых конфах. Как-то примерно годик назад, когда ввели 20% НДС, пришлось ковырять сильно переписанную БП3 на предмет сделать по умолчанию эти самые 20% при вводе нового документа, кажется это был приходник. Открыл я форму дока, поставил точку останова и начал ловить где же эти самые проценты при вводе нового дока проставляются. На отлов у меня ушло примерно пол часа, а когда нашел, я охренел от того, что на месте одного модуля формы, который единственный был открыт, когда я начинал поиск у меня оказались открыты тридцать (30!!!) разных модулей!!! Эта одна строчка кода, которая в семерке была бы в первой же процедуре "ПриВводеНового", ну, или приОткрытии, зачем такое закапывать на глубину в тридцать модулей для меня загадка, причем чем дальше, тем у 1С все больше и больше таких решений...

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

(49) ага, еще с какими нибудь убогими виртуальными таблицами, высраные из глубоких аналов общих модулей, где нибудь аля ЗУП 3.0

(65) Вообще-то 1С дабы избежать Родитель.Родитель.Родитель и рекомендует добавлять реквизит, а не ковыряться в кишках объекта, еще и соединения какие нибудь делать по этому реквизиту, да забыв или наоборот проиндексировав

(65) Это для подобного рода ТС, любящих штамп Совместимо.

(65) Это особенность коллективной разработки. :) Я напишу свою функцию по установке 20%, а архитектор все равно переделает и отдаст в глобальный модуль который установит 20%. Чуть позже будет рефакторинг кода, который уберет лишние переходы.

Кстати,1с совместимо не проверяет наличие трех реквизмтов одинакового типа,если у них разные имена.
опять же,во многих документах есть контрагент,грузополучатель и плательщик,но никому в голову не приходит их запихать в один реквизит.

по стандарту,экспортные процедуры модулей  дрлжны иметь комментарий с описанием передаваемых значений-это,пожалуй,единственное,что из стандарта реально полезно.

Я считаю, что в коде должен быть компромисс между читабельностью и скоростью выполнения. Если система высоконогруженная, то грань стирается, и код становится быстрым и нихрена не понятным, а если код вдруг становится медленным, и не читабельным, то нужен будет товарищь "Гилев и Ко", а там совсем другие бабки.
А так все норм, ТС выслужится, накрячит кого то, потом его метлой поганой выкинут пинком, за то что натворил. Все нормально.

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

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

(70) Читабельность важнее скорости. Иначе невозможна коллективная разработка. Тут на форуме большинство фикси-одиночки, поэтому не до конца понимают сути стандартов 1С.

(73) Ну если специалист хороший, он комментов наставит. Хотя это не всегда возможно.
Я как то написал в запросе

"Выбрать
| Выразить((Таблица.Число + 0.5) КАК число(15,2)) - 1
|Из Таблица"

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

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

(75) > Теперь каждый второй 1сник чуть что занимается бессмысленной и беспощадной оптимизацией
Я, например, не занимаюсь. Значит это ты во всем виноват.

Один из примеров недооптимизации, которая по сути деоптимизация

//длиннющий пакетный запрос, за раз получающий данные из цати разных и несвязанных таблиц
//...
Результат = Запрос.ВыполнитьПакет();
Структура.Вставить("Таблица1", Результат[1].Выгрузить()); // Будет использована через 3 процедуры
Структура.Вставить("Таблица2", Результат[2].Выгрузить()); // Будет использована через 5 процедур
Структура.Вставить("Таблица3", Результат[3].Выгрузить()); // Будет использована через 10 процедур
...
Структура.Вставить("ТаблицаN", Результат[99].Выгрузить()); // Будет использована через 150 процедур

Вот такие кабздецы. Мало того, что получение данных сильно отдаляется от их использования (потом ищи-свищи, где и как эта таблица получена, и не была ли она по пути изменена), так ещё в оперативной памяти порожняком висит тонна информации, которая будет использована когда-то там потом, если вообще пригодится. Вот что мешало получить из БД данные перед их использованием?

(77) Ты сейчас весьма ярко как раз и предлагаешь занятся "бессмысленной и беспощадной оптимизацией".

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

(78) в смысле? Писать запросы перед использованием данных, а не сильно заранее, люто отделяя получение данных от их использования, это "бессмысленная и беспощадная оптимизация"?

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

(48) Не забудь рассказать чем закончилась эта эпопея. ...Если еще там будешь работать...

(80) Как хорошо известно (нет), оптимизация должна начинаться со снятия метрик с реальной базы и демонстрации факта, что текущие значения метрик действительно критичны для данной базы. Иначе ты потом результаты "оптимизации" оценить не сможешь. У тебя есть?

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

Так что извини, твоя борьба за все хорошее против всего плохого бессмыслена.

(23) Сколько ошибок по запросам в цикле?

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

(33)ХМ, интересно , т.е. сейчас вы проверяете без договора. А исполнитель то об этом в курсе был?
Или задним числом планку поднимать стали. Не задумывались что планка затрат тоже возрастет ?

(83) Причем заблокировав все связанные данные на все время обработки этой информации.

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

(75) с помощью кода легко документировать что ты делаешь, но сложно зачем ты это делаешь

(89) а зачем вообще сложно фиксировать. Вот  я на фикси за три месяца переписал 7 раз подсистему, потому что представитель бизнеса долбо*б. Первых три раза еще пытался как то структурировать и делать по стандартам с оптимизацией. Последние 4 раза прикручивал костыли, потому что можно неделю делать красиво, а потом придет этот урод и скажет "ой, оно  так не работает". Да что вы говорите? а когда тебе говорили брызгал слюной и вытаращив глаза визжал что он знает как правильно он десять лет начальник)

(90) сложно но можно

(91) и нужно(!), если ты делаешь хитрые хаки итп

(83) По приведенному коду явно видно, что обрабатываются связанные данные, имеющие смысл только вместе

Я же написал, что это не связанные данные, а просто у программиста зачесалось получить данные на все случаи жизни одним пакетным запросом

(87) за такое вообще надо по рукам бить. Преждевременные блокировки это ещё хуже, чем преждевременные инициализации

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

(33) >> в договоре будет написано , что при проверке разработки конфигурацией АПК не должно быть ошибок по требованиям соответствия стандартам

Во-первых, ты для начала возьми девственно чистую типовую конфигурацию от 1С и прогони её через тесты АПК. Удивись. Уверен, что из 16349 найденных ошибок ~90% (если не больше) относятся не к доработкам, а к исходному коду типовой конфы.
Во-вторых, ни один вменяемый исполнитель такое условие не подпишет. По одной простой причине, что большая часть стандартов 1С являются не более чем общими рекомендациями. Которые, во-первых, не являются обязательными, а, во-вторых, в отдельных частных случаях могут быть просто вредными.
Подобный бред подпишут только два типа исполнителей. Либо некий идеальный, выполняющий все доработки в строгом соответствии с этими самыми стандартами, включая внутренний аудит кода (код ревью), где любая доработка проходит через руки как минимум трёх-четырёх специалистов - методистов и архитекторов, кодеров, аудиторов и тестировщиков. Стоимость такой разработки приблизительно х5 к обычному ценнику, к которому вы привыкли.
Второй вариант исполнителей, готовых подписать такие условия, это те, что не читали вообще текст договора, или прочитали, но заранее знают способ как обойти подобную ересь. А способы обойти предоставляет сама 1С, делая свои стандарты всего лишь рекомендованными, а вовсе не обязательными к исполнению.

(96) ну да, либо супер мега хард эксперт, либо студент который учиться на вашей конфе пришел

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

(27) А вы в договоре это требование писали?

(33) Ищешь Ылиту?

(95) крапотливая - это от слова "крап", что ли? Как крапленая карта? :)

(98) вот как раз непонятно, какие тараканы бесились в голове у программиста, когда он данные из БД получал сильно загодя. Особенно умиляют менеджеры временных таблиц, протаскиваемые через 100500 процедур и функций. Перед использованием данные-то никак не получить, не-а. Нужно чтобы они в менеджере ВТ как следует потомились, и только потом их можно использовать

(102) без конкретного примера можно что угодно осуждать, и не придерешься

(33) Да без проблем.
Сделать как в БСП, с поставкой поставлять файл особенностей.
На самом деле сделать так что бы АПК не ругался очень просто, но это мало относится к качеству кода.
Я приводил нетленку к совместимо, несколько тысяч ошибок за 2 вечера поправил.
Но еще раз повторю - АПК и качество кода - разные вещи.

Просто к чему спич выше - прописав требования к прохождению АПК - будь готов получить код, который проходит АПК.
Есть конечно BSL, но он еще только развивается.
Готового автоматизированного средства для проверки кода нет.
Только глазами.
Но это уже субъективная оценка, и в договор не всунешь.
Объективных на 100% метрик нет.

(51) ЭТО ТЫ СЕЙЧАС КОГО ПОСЛАЛ?

Ясно, в общем тема норм, слепой укажет всем дорогу.

Оказалось что наш аутдитор чуть смекалистее подавана, но гонору то гонору.

У меня вопрос, аудитор из (0) ты какими сертификатами обладаешь? Какие у тебя ордена? есть спец по платформе? Или эксперт? Может ты владеешь сертификатом 1с Эксплуататор?

(105) "Есть конечно BSL"
Что такое сие?

(110) https://github.com/1c-syntax/bsl-language-server
Погугли, ребята интересную штуку делают.

для тех кому джава не вставляет - https://github.com/lead-tools/bsparser

ну а для тех кому и 1С не вставляет - https://gitlab.com/wwall/styleguide - но там давно затишье

(109) ну скажем так Эесплуататор и Эксперт это не про качество кода.

(114) Да я и не говорю про качество кода, у меня сомнения в комтенециях ТС. Совершает детскую ошибку, что то увидал, не понял, сразу ломать начал

Провел еще одну проверку в конфигурации АПК

До этого я проверял только добавленные объекты
Этих объектов 759 , ошибок было - 16349
провел проверку всей конфы - объектов 50 729 , ошибок 33602

т.е. расклад такой -на примерно 50 тыс объектов у разработчиков 1с ошибок 33602-16349=17253 , т.е. примерно 17 тыс
или примерно 1 ошибка на 3 объекта

у разработчика/ов допиленной конфигурации 16 тыс  ошибок на 700 объектов,
или примерно 23 ошибки на 1 объект конфигурации

т.е. разработчики типовой в десятки раз меньше делают ошибок по требованиям соответствия стандартам разработки

измерения проводил в демо-базе конфигурации автоматизированная проверка конфигураций редакция 1.2.5.30

(116) Отлично, т.е. теперь ты начал в кале разбираться. Этот калл значит хороший, этот калл плохой. Продолжайте самодеградацию и слепое превращение себя в человека с низкой социальной ответственностью.

обожаю радость от АПК.
был опыт пиления отраслёвки. АПК в среднем давало 400-600 ошибкок, из которых 90% были синтаксическими (ну не знает АПК массы специфических терминов).
подтребовалось добавить БСП. добавили. совместимо само себя не сдаст, требуется отчет из АПК. прогнали, 18к ошибок в БСП.

наслаждайтесь качеством кода типовых, да.

(102) Есть такая рекомендация при работе с БД - "По возможности получай все нужные данные за один запрос". За память переживать не стоит, не восьмидесятые года вроде на дворе.

(119) Дааааа, особенно в зупе 3.0, она как как при инфаркте, еле дышит со своими мегазапросами. Про ерп молчу, это вообще труп.

(118) орфографических, наверное

(121) О какихОшибкахИдетРечьКогдаВ1С_ПишетсяВсеВОднуСтроку????

контагент  , например считается орфографической ошибкой

(123) а КонтАгент?

(123) МожноПисатьМатомГлавноеКаждоеСловоС_БольшойБуквыИБудетНормНоПродуктБудетФиговый

(118) Когда это было? 2 года назад с файлом особенностей . который был в поставке АПК выдавал 0

(119) то то при внедрении ЗУП 3.1 клиенты при расчете зп падали с нехваткой памяти ))))
а на 64х 2д коды не работали... эхъ

(127) Потому что ЗУП 3.1 рожден при обмороке с инфарктом.

Зуп 3 - это топ тяжелых конфигураций 1с, никакой erp (его части без блока зуп) и близко не лежали

(129) Ну да, установка цен номенклатуры в ерп просто кладет базу если очень крепкий прайсик пригрузить

А если пригружать в ЕРП хорошие файлики, да помногу, то работа в базе просто останавливается.

(130) ога, там в целом с РС проблемы, лучше отдельно текущие цены хранить

ну и ЗУП по архитектуре тупой отстой, да простят меня коллеги

(132) Да маза фака! Там лучше цены вообще не трогать, все делается через анус маркетинговых мероприятий, это такое очко! Это просто очеллО!!!!!! Зафакать того кто это вообще пустил в продакшн этот ерп

(133) Да все нормально брат. ЗУП 3.1 мера вынужденная, но тупая глупая и долгая. А в кишках вообще без пол литры не разобраться

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

(119) рекомендация-то хорошая, только вот некоторые трактуют её по-своему. Под "одним запросом" фирма 1с, очевидно, имела ввиду однократное полученые данных из одной таблицы. А не получение одним запросом данные из 15-ти таблиц на будущее и на всякий случай

"За память переживать не стоит, не восьмидесятые года вроде на дворе"

Ну давай теперь будем бездумно разбрасываться ресурсами. А потом "чё это ваша 1с такая тормозная" и "чё это 1с сожрала всю память". Это ещё хорошо, что с разделением на клиент и сервер фирма 1с перекрыла кислород некоторым извращенцам. Менеджер временных таблиц не сериализуется и не сохраняется между серверными вызовами. Во времена ОФ неоднократно сталкивался с особым видом извращения - хранением менеджера ВТ в глобальной переменной

(137) "Под "одним запросом" фирма 1с, очевидно, имела ввиду однократное полученые данных из одной таблицы. А не получение одним запросом данные из 15-ти таблиц на будущее и на всякий случай" // Ошибаешься

(137) > только вот некоторые трактуют её по-своему.
Бинго, толкователь.

(138) поясни

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

(141) Я так думаю, что они в конце концов придут к состоянию "безобразно, зато однообразно". Если уже не пришли.

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



Ветку не читал, но вангую, что заказчик про*бался с ТЗ, получил 10% того, о чем мечтал, и теперь пытается получить бесплатно остальные 90% того, о чем не сказал.

Старше этой истории - только первый анкдот про проститутку

(142) пока что безобразность выглядит вот так:

Процедура ИзлюбленныйГовнокодинг()

  МногоТаблиц = ВытащитьИзБазыДлиннющимПакетнымЗапросомПятьГигабайтДанных();

  ПерваяПроцедураНаПолчаса(МногоТаблиц.ПерваяТаблица); // Все 5 Гб висят в памяти
  ВтораяПроцедураНаПолчаса(МногоТаблиц.ВтораяТаблица); // 5 Гб продолжают висеть в памяти
  ТретьяПроцедураНаПолчаса(МногоТаблиц.ТретьяТаблица); // 5 Гб по прежнему висят в памяти
  ЧетвертаяПроцедураНаПолчаса(); // Данные уже давно не нужны, но пускай ещё повисят в памяти

КонецПроцедуры // фух, наконец-то память можно очистить

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

Процедура УчимсяНеРазбазариватьВычислительныеРесурсы()

  ПорцияДанных = ВыполнитьПервыйЗапрос(); // Получили только то, что требуется в данный момент
  ПерваяПроцедураНаПолчаса(ПорцияДанных);
  ПорцияДанных = Неопределено; // Удалили из памяти

  ПорцияДанных = ВыполнитьПервыйЗапрос(); // Получили только то, что требуется в данный момент
  ПерваяПроцедураНаПолчаса(ПорцияДанных);
  ПорцияДанных = Неопределено; // Удалили из памяти

  ПорцияДанных = ВыполнитьВторойЗапрос(); // Получили только то, что требуется в данный момент
  ВтораяПроцедураНаПолчаса(ПорцияДанных);
  ПорцияДанных = Неопределено; // Удалили из памяти

  ПорцияДанных = ВыполнитьТретийЗапрос(); // Получили только то, что требуется в данный момент
  ТретьяПроцедураНаПолчаса(ПорцияДанных);
  ПорцияДанных = Неопределено; // Удалили из памяти

  ЧетвертаяПроцедураНаПолчаса();

КонецПроцедуры

(140) В (139) тебе тоже говорят, что ты понял все наоборот

(145) Да вроде вполне очевидно, что в некоторых случаях лучше сразу вытащить все данные из БД, а в некоторых вытаскивать данные по месту. А вот как отличить одни случаи от других, 1С как-то не определилась :(

(145) серьёзно? Ну ок, тогда поясни, у кого и что отвалится, если вот такой запрос превратится в три отдельных запроса. Каждый из которых выполнится там, где данные будут нужны, а не там, где разработчику приспичило сделать один длинный запрос

Запрос = Новый Запрос;
Запрос.УстановитьПараметр("Номенклатура", Номенклатура);
Запрос.УстановитьПараметр("Касса", Касса);
Запрос.Текст =
" // Эти данные нужны сразу
|ВЫБРАТЬ
|    ДвижениеТоваровОбороты.Номенклатура КАК Номенклатура,
|    ДвижениеТоваровОбороты.Характеристика КАК Характеристика,
|    ДвижениеТоваровОбороты.ПланируемоеПоступлениеОборот КАК ПланируемоеПоступлениеОборот,
|    ДвижениеТоваровОбороты.ПланируемоеПоступлениеПодЗаказОборот КАК ПланируемоеПоступлениеПодЗаказОборот
|ИЗ
|    РегистрНакопления.ДвижениеТоваров.Обороты(, , , &Номенклатура) КАК ДвижениеТоваровОбороты
|;
|
|////////////////////////////////////////////////////////////////////////////////
| // Эти данные понадобятся через 3 тысячи строк кода
|ВЫБРАТЬ
|    ТоварыНаСкладахОстатки.Номенклатура КАК Номенклатура,
|    ТоварыНаСкладахОстатки.Характеристика КАК Характеристика,
|    ТоварыНаСкладахОстатки.ВНаличииОстаток КАК ВНаличииОстаток,
|    ТоварыНаСкладахОстатки.КОтгрузкеОстаток КАК КОтгрузкеОстаток
|ИЗ
|    РегистрНакопления.ТоварыНаСкладах.Остатки(, Номенклатура = &Номенклатура) КАК ТоварыНаСкладахОстатки
|;
|
|////////////////////////////////////////////////////////////////////////////////
| // Эти данные понадобятся через 7 тысяч строк кода
|ВЫБРАТЬ
|    ДенежныеСредстваНаличныеОстатки.СуммаОстаток КАК СуммаОстаток,
|    ДенежныеСредстваНаличныеОстатки.СуммаУпрОстаток КАК СуммаУпрОстаток,
|    ДенежныеСредстваНаличныеОстатки.СуммаРеглОстаток КАК СуммаРеглОстаток
|ИЗ
|    РегистрНакопления.ДенежныеСредстваНаличные.Остатки(, Касса = &Касса) КАК ДенежныеСредстваНаличныеОстатки";
Результат = Запрос.ВыполнитьПакет();

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

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

(144) Весьма показательная упоротость разработчика-"оптимизатора", кстати. То, что обработка данных занимает 2 часа (4 x 0.5) - это похер, будем бороться за чистоту помыслов.

(148) Чуви, 1С - многопользовательская система. И когда ты полчаса в чем-то ковыряешься, у тебя данные базы могут изменится так, что тебе придется выбросить свои расчеты.

(151) Транзакции с блокировками? Не, никогда не слышал...

(152) Ты ветку-то почитай

(144) ты какие то куски кода в вакууме приводишь
приведи реальный код с замерами

(152) То-же, интересный вопрос - возьмём заказ на 1000 позиций, получаем цены на все 1000, и далее до конца наших хитрых расчетов блокируем любые изменения цен?

(155) А зачем нам все цены сразу и держать их? Получать и сразу записать...
(153) Это не наш метод.

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

(151) если ты такими способами борешься за чистоту данных, то тебе лучше уйти из 1с

(154) нет под рукой. Но поверь, такое встречается частенько

(157) Да, сэр! Так точно, сэр! Разрешите не касаясь пола, сэр?

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

(160) уже неделю почти обсасываешь эти запросы в вакууме

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

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

(162) если система так чувствительна к timestamp, то скорее всего проблема в архитектуре, или в организации работы. На моём предприятии все сложные и чувствительные к изменениям расчеты выполняются регламентными заданиями в ночное время

(164) >На моём предприятии все сложные и чувствительные к изменениям расчеты выполняются регламентными заданиями в ночное время

Что, в свою очередь, говорит о проблемах в архитектуре. Ну, или в организации работы.

(163) А кто сказал, что конфигурации разработаны для крупных компаний?

(165) не-а. С архитектурой и организацией работы всё тип-топ. Фирма 1с сама рекомендует выносить сложные расчеты в незагруженные периоды

(166) никто не говорил. Но фирма 1С позиционирует же свои типовые как "подходящие всем"

(168) В хайлоаде свои правила, и чаще противоположные всяким официальным рекомендациям и стандартам разработки

(163) что "наступает веселье"? приведи конкретные сценарии, где проявлялась неоптимальность конкретного кода
а так ты воду в ступе толчешь

(168) нет такого позиционирования у 1с

(0)
>Есть ли структура, которой можно отдать конфигурацию на аудит,

Я делаю такой аудит в части РСБУ и МСФО.


>например , на соответствие стандартам разработки?

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


>Интересуют сроки, стоимость

Всё очень сильно зависит от анализируемого объёма. Могу сказать свои расценки, у коллег лучше узнать напрямую.

(16)
>Количество обнаруженных ошибок 16349 )

Так тебе нужен аудит кода. Извини за (172) - это не ко мне.

P.S. Имей в виду, что далеко не все из 16349 обнаруженных ошибок являются реальными ошибками. Более того, многие их них - порождение типовой конфигурации.

(170) не могу найти, раньше на сайте у фирмы 1с был специальный раздел про крупные проекты. Там описывалось, как обвешавшись ЦУПами и APDEXами, франчи заставляли работать типовые с приемлемой для клиентов производительностью

А, нашел)
https://v8.1c.ru/tekhnologii/tekhnologii-krupnykh-vnedreniy/vypolnennye-proekty-tsktp/

Там таких примеров - вагон и маленькая тележка

(174) > обвешавшись ЦУПами и APDEXами
Вот тебя в (83) про что спрашивали, оптимизатор с сабелькой?

(176) оптимизатор без сабельки, а ты в курсе, что помимо производительности (под которой почему-то у многих принято считать только время выполнения кода), есть ещё масса аспектов качества программного продукта? И если ты до сих пор не понял, я веду речь не про оптимизацию, а просто про использование здравого смысла при разработке. Оптимизация, это когда есть узкое место в конфигурации, и ты переписываешь его, ради повышения производительности. А здравый смысл, это когда при разработке ты пишешь запросы сразу оптимально, с учетом индексов БД, менеджер ВТ закрываешь сразу после использования, переменные инициализируешь перед их использованием, а не хрен пойми где, ну и так далее...

Ещё яркий пример распространеннейшего рукожопства:

ТаблицаНаСтоТыщСтрок = ПолучитьМассивнуюТаблицу();

// тысяча строк кода, не использующих таблицу
//...

// тысяча-первая строка кода, в которой наконец-то используется полученная таблица
Для Каждого СтрокаТаблицы Из ТаблицаНаСтоТыщСтрок Цикл

что помешало разработчику получить таблицу непосредственно перед использованием? На кой ляд нужно было так разлучать инициализацию переменной и её использование?

(178) например наложение блокировки, а тысяча код кода критичны к изменению данных...

(179) не-а. В том-то и дело, что у многих манера инициализировать переменные где попало и без объективных на то причин

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

простой пример, у меня в самописке примерно с десяток видов документов, у них сложные формы где в зависимости от статьиДР в табличной части меняются колонки доп данных (их может быть штук 20), я во всей конфе предусмотрел 2 режима первый в виде портянке, второй в виде дерева, куча кода, все работает, всех устраивает, и тут один документ мне тычут - сделай как в ТЗ, долго спорил, но пришлось сделать отдельную форму которая ну ни как не вписывается в стройную систему. И ради этого там подобного (178) просто море, а все по тому, что основную систему нельзя ломать ради кастомного решения...

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

(181) Не спорь. Конструктору лучше знать. Кто мы такие на фоне это мощнейшего человечища? Он все всех знает, всех всему научит, у него регламентные по ночам работают!

(183) заканчивай уже со своим пафосным троллингом

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

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

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

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

Но как же... тысячи строк? Ярчайшие примеры? ;(

Звонила давеча коллега с прошлой работы по поводу очередного обновления типового зупа 3. Не работает рсв. Полезли на сайт официальный, а там код который надо поправить указан в ошибках. Поправили. Всё равно вешает сервер и не работает. Коллега полез далее правки по коду, а там конструкция безупречная с точки зрения орфографии и наверное автоматическая проверка её бы даже ошибкой не стала бы считать. Что-то начинающееся с
Пока Истина Цикл

Пример другой. Привлекали к доработке ЗУП 2.5 для ФГУП Почта России. Внедрение на 13 тысяч+ рабочих мест. 1С овская рекомендация по использованию временных таблиц с таким числом пользователей показала что узким местом при таком количестве становится дисковая подсистема, то есть лаги возникают из-за обилия обращений туда-сюда к ней. Коллеги перекрутили весь типовой код запросов на работу без временных таблиц. Вероятнее всего тестирование такого перепахивания показало бы ошибок при тестировании овер много, но всё в отличии от безошибочного кода работало в высшей степени разумно.

При очной сдаче 1С специалиста ведь недаром существуют две части
1) изменение каркасной
2) защита своего решения преподавателю из разряда а почему сделаны такие то изменения

Я бы например по своему текущему опыту вместо тч документа делал бы регистры сведений отображаемые в форме, но я бы смог объяснить преподавателю почему я так сделал, по своему опыту

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

(186) Верно всё говоришь. Плюс ты забыл упомянуть что разбиение процедур и функций по общим модулям с вменяемыми названиями делает добработку типовых, да той же ерп, более или менее комфортным. То есть после замера производительности при анализе где мы побывали более или менее понятно куда лезть и куда рыть

просто,у 1с нет цикла do ... loop while/until вот и приходится писать.
кроме того,есть классическая модель выхода на конец,когда для выхода используется break внутри цикла с условием true и обязательным break перед концом цикла.

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

что касается структур-это еще и модель обьектно-ориентированного подхода
когда структура хранит поля обьекта,а в коныигурации есть модуль с именем обьекта,где все функции типа
функция ИмяКласса_ИмяМетода(АналогThis,ДругиеПараметры)

Я им кстати сказал что в контексте эпидемии это программный код из разряда

откуйте меня от батареи :)

то есть крик профессионала о помощи

опять же,применяя автоматический сборщик кода можно код на ООП перевести в код 1с и даже разные функции разнести по разным модулям на основании фильра-а потом народ будет гадать,почему функуии из одного модуля в другой переехали ^_^

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

(175) ну и зачем мне эта ссылка?

(178) я смотрю ты продолжаешь воду в ступе толочь
скажи, запрос в цикле это плохо?

(185) в книге "Рефакторинг" Мартина Фаулера есть раздел про "запахи" в коде. Запахами называют как раз дурной тон при кодировании, который приводит к проблемам с доработкой программы. Одним из таких запахов является "стрельба дробью":
https://refactoring.guru/ru/smells/shotgun-surgery

это как раз тот случай, когда данные получаем "где-то там", а обрабатываем "где-то здесь"

(186) вот тут правильно. А про блокировки не согласен. Множество алгоритмов не накладывают блокировок на данные. В большинстве случаев данные блокируются только на уровне СУБД и только на время чтения данных. Как только СУБД завершит запрос, блокировка будет снята. Если данные обрабатываются сразу же после запроса, то ещё есть шанс поработать с актуальными данными. А если данные были получены полчаса назад, то актуальными такие данные назвать нельзя

(188) "1совская рекомендация по использованию временных таблиц с таким числом пользователей показала что узким местом при таком количестве становится дисковая подсистема"

Воот. Про подобное я выше тоже писал. Есть такая болезнь в нашей 1сной отрасли: где надо и где не надо использовать временные таблицы, и давать жить менеджеру ВТ пока не надоест... И вылазит это как раз при высоконагруженной работе системы.

(196) в (170) "приведи конкретные сценарии, где проявлялась неоптимальность конкретного кода"

вот я и привел. Тенденция, надесь, заметна. Конкретный код публиковать не имею права, это нарушение лиц. соглашения

(201) если код не имеешь права давать, то зачем давать ссылку? я не просил ничего такого что там по ссылке

(200) засрал ты эту ветку донельзя, своей теоритезацией
а так хорошо все начиналось

(197) всё зависит от ситуации. Пример из практики. Нужно было периодически получать данные из БД под Oracle. Таблица с данными огроменная, миллиарды записей. А запрос должен был просматривать записи за один или несколько месяцев. В таблице были подходящие индексы, запрос был написан по всем феншуям, но выполнялся он от 7-8 часов до суток... Решение: разбили запрос на множество маленьких, каждый запрос тянул данные только за 1 день, и общее время выполнения сократилось до нескольких минут. Есть ещё примеры, например, как временные таблицы отсасывали у вложенного запроса, и ещё много чего, что "грубейше" нарушает 1сные рекомендации. Но это отдельная история

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

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

(194) Коллега, тут посмею с Вами не согласится, не смотря на утверждения коллеги с чудным отчеством Рафаилович о разработке им искусственного интеллекта для написания программного кода.
Мне картина видится несколько иначе. Есть скажем общий блок в отношении которого функция попадает в некий общий модуль. Далее меняется архитектура блоков, ну например из коллекции модулей УТ выделяется в отдельный блок поддержка документа реализациятоваровиуслуг, ну и соответственно меняется архитектура общих модулей во след за изменением архитектуры блоков. Мне бы например чего бы от 1С хотелось бы? Чтобы при разработке всевозможных сущностей программисты не забывали бы про вызовы переопреляемых модулей (каковые мы лнегко к слову сказать можем прокопировать в расширение и там доработать не снимая конфу с замочка и соответственно не меняя её), а то порой приходится ради стейка резать телёнка из-за того что нет вызова переопредляемого модуля соответствующего. Теоретически я могу предположить конечно что не включив вызов переопределямого модуля разработчики нам как бы намекают что они не рекомендуют менять данный объект, но прав то всегда заказчик в конечном итоге.

(206) я просил конкретный пример а ты мне какие то ссылки опять же абстрактные кидаешь
хорошо, если с заказчиком ты общаешься не на таком языке

(208) выше я описывал примеры. Условные, но суть та же

(209) "Как можно работать над проектом, если в космосе хаос?"

(209) к чему эти условные примеры?
Ну если тебе нравятся условные примеры, то я повторю вопрос на который ты не ответил: запрос в цикле это плохо?

(211) Ответ так-то очевиден - когда как :)

(211) Он попытался начать формулировать идею, что в каждом конкретном случае надо разбиратся. Но, к сожалению, испугался и свалился в рассказ о своей персональной героической борьбе :

(209) Почему ты при рассмотрении этих условных примеров активно сопротивляешься даже самой вероятности наличия альтернативной точки зрения на анализ ситуации?

(214) как это "почему ..."?
Жизнь - это борьба!!!
Тут нельзя без сопротивления.

(211) ну так-то я ответил на этот вопрос. Если не понятно, напишу ещё раз. Всё зависит от ситуации, и иногда множество маленьких запросов в цикле это намного лучше, чем один большой запрос

(214) воу-воу, чувак, притормози. Вообще-то это ты начал докапываться до моих слов и учить меня "правильно мыслить". Если забыл, вернись на первую страницу топика и перечитай

(217) Гм. Начал я, а нафлудил на три страницы ты. Мистика!

(204) И в чем же была причина столько долгого чтения? Вы ведь провели исследование плана запроса? Могу предположить, что запрос был на писан все же не "по всем феншуям" и приводил к фулл сканам. А сделав запрос за каждый день отдельно, вы наконец добились Index Seek за счет максимально простого условия на равенство конкретной дате.

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

(220) на кофейной гуще гадаешь? Совершенно мимо

(219) нет, с запросом и попаданием в индексы всё тип-топ. А разбить запрос на дни мне посоветовали ораклисты

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

(222) Так в чем же были причины тормозов?

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

(216) ну так, а к чему тогда твои абстрактные примеры, если все зависит от ситуации

(226) и какая же ситуация оправдывает, например, незакрытый менеджер временных таблиц, если этот менеджер ВТ заведомо больше не будет использоваться?

Процедура КакДелатьНеНадоНоЧастоДелают();

  МенеджерВТ = Новый МенеджерВременныхТаблиц;

  ПроцедураИспользующаяМВТ(МенеджерВТ); // На выходе из процедуры в МВТ 100500 таблиц

  ПроцедураНаПолчасаНеИспользующаяМВТ(); // МВТ жиф

  ВтораяПроцедураНаПолчасаНеИспользующаяМВТ(); // МВТ продолжает жить

КонецПроцедуры // Наконец-то МВТ закрылся

(224) уже не помню. Мне объясняли, но т.к. в тонкостях работы оракла не силён, это объяснение быстро выветрилось из головы

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

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

(229)
День первый.
Хакер приходит в общественную столовую и с возмущением обнаруживает, что солонку на столе может открутить кто попало и насыпать туда что угодно. Хакер приходит домой и пишет гневное письмо директору столовой: "Я, meG@Duc|, обнаружил уязвимость солонки в Вашей столовой. Злоумышленник может вскрыть солонку и насыпать туда яду! Примите меры срочно!"

(231) т.е. культура кодирования это зло и нафиг не надо?

(227) Почему ты все придумываешь примеры, ведущие к избыточному расходу памяти? У тебя памяти не хватает?

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

(233) я их не придумываю, я с ними регулярно сталкиваюсь

(227) ты опять приводишь абстрактный код
покажи реальный код

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

(235) Какие проблемы от избыточного потребления памяти?

(236) извини, говнокод не коллекционирую. Но если очень хочешь, могу поискать

(238) ты это серьёзно?

(239) Епстественно он это серьезно. Избыточное потребление памяти не так критично, как, например, не разобраться, почему помогло разбиение по дням.

(237) См. (93):

>(83) По приведенному коду явно видно, что обрабатываются связанные данные,
>имеющие смысл только вместе
>
>Я же написал, что это не связанные данные, а просто у программиста зачесалось
>получить данные на все случаи жизни одним пакетным запросом

Кажется я понял, почему ты так беспокоишся об объеме памяти.

(240) н-да. Разве из моих каментов не понятно, что в проблеме разбирался профессиональный ораклист? Это в небольших организациях 1сник и швец, и жнец, и на дуде игрец, и админ домена впридачу. А в крупных сервера админят одни узкие специалисты, винду админят другие узкие специалисты, БД админят третьи узкие специалисты... и у рядового 1сника там просто нет возможностей в каждую БД с админскими правами заныривать

(241) ну, рассказывай свою очередную додумку, не томи

(242) "А в крупных сервера админят одни узкие специалисты, винду админят другие узкие специалисты, БД админят третьи узкие специалисты..."

и получается дырка от бублика.

(204) А у нас замена вложенных запросов на временные таблицы в восстановлении партионного учета УПП сократила время в 4 раза (не запроса - а полное время восстановления последовательности, сам запрос в десятки раз ускорился). Мы потом с усмешкой где-то с полгода смотрели на потуги фирмы 1С решить эту проблему, ее так и не решили. Так что к чему эти абстрактные примеры? Их можно для любой ситуации привести.

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

(246) хотя к нашей отрасли это тоже относится

(244) не, получается каждый занят своим делом

(245) примеры всего-лишь к тому, что "незыблемые" рекомендации не могут быть на все случаи жизни

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

(250) ты предлагаешь ради показушничества на форуме нарушить закон и внутренние регламенты моего предприятия? Выше я писал:
"Типичные привычки множества 1сников, зародившиеся на мелких БД, сплошь и рядом вылазят  боком, когда их произведения пытаются запустить на больших БД"

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

(239) "ты это серьёзно?" // Ну да. Какие проблемы из-за незакрытого МВТ или преждевременного запроса в плане памяти?

(251) тут все сложно... вот например у нас было 5 1с ников и еще 8 дельфистов, и человек 30 админов в перемешку с аникейщиками... догадайся кто админит SQL ???

мелкой такую контору язык не поворачивается назвать

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

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

(254) А какие симптомы проблемы?

(236) у абстракного кода преимущество в том, что он простой и наглядный. Мне пример понравился. Приму к сведению.

(255) из синтакис-помощника

МенеджерВременныхТаблиц (TempTablesManager)
Закрыть (Close)
Синтаксис:
Закрыть()
Описание:
Закрывает менеджер временных таблиц. При этом удаляются все временные таблицы, в нем находящиеся. Дальнейшая работа с данным объектом невозможна

Когда там физически удалится ссылка на МВТ пофиг, главное что он таблички грохает

(256) усиленно "сжираются" дисковое пространство и свободная оперативная память. Во время пиковых нагрузок может получиться "бутылочное горлышко"

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

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

(259) Чрезмерная оптимизация - одна из самых распространенных ошибок. Вот если при нагрузочном тестировании оно будет бутылочным горлышком - будет иметь смысл что-то предпринимать. А до этого это просто необоснованная трата ресурсов без экономического эффекта.

(258) Во-первых не грохает, а усекает. Во-вторых, неплохо было бы тебе документацию почитать, например https://its.1c.ru/db/v839doc#bookmark:dev:TI000000517, где явно рассказано когда удаляются таблички. Ну или профайлер в руки взять, но это явно не твой метод.

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

(255) Ю

(255) > а после сборки мусора
Поподробней не расскажешь?

(260) > и мусолим эту тему
s/мусолим/мусолишь/gi;

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

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

(259) Чтоб кончился диск и память - это надо сильно постараться. Вероятность наступления этого оцениваю как весьма низкую. Если конечно у тебя на сервере 1С не 16 Гб ОЗУ и 50 Гб диска.

(262) ни о какой оптимизации речи не идет. Многие вещи делаются/не делаются на уровне культуры программирования

МВТ = Новый МенеджерВременныхТаблиц;

// Код использующий МВТ
//...

// Код НЕ использующий МВТ
//...

// МВТ убился только по выходу из процедуры

как-то сложно назвать оптимизацией, если разработчик протянет руку и сделает вот так:

МВТ = Новый МенеджерВременныхТаблиц;

// Код использующий МВТ
//...

МВТ.Закрыть();

// Код НЕ использующий МВТ
//...

(263) читатель но не пониматель документации, что тебе не понятно из справки?

МенеджерВременныхТаблиц.Закрыть()
Описание:
Закрывает менеджер временных таблиц. При этом удаляются все временные таблицы, в нем находящиеся

"А вообще, ты раскрываешь довольно концептуальную картину мироздания, в которой ораклисты занимаются оптимизацией запросов и рассказывают одинесникам что надо делалать"

Welcome to the Real World. Когда-нибудь и тебе доведется побывать на крупных проектах (но не уверен), где работает большая команда узких специалистов, каждый из которых отвечает за свой участок. А пока что смотри на мир через свою призму восприятия, в которой 1сник и швец, и жнец, и на дуде игрец, и первый DBA на деревне

(269) Этот пример более дорогой в сопровождении, ибо сегодня тот последующий код не использует МВТ, а завтра уже использует

(269) Чтобы сделать "вот так" надо точно знать, что этот МВТ нигде дальше не используется. Это уже растрата ресурсов (времени разработчиков на анализ кода), которая не дает экономического эффекта.

(270) О, оптимизация в дикой природе,как она есть. Для экономии памяти по ссылкам не ходим, вторую часть описания мироздания не читаем.

(270) > Когда-нибудь и тебе доведется побывать на крупных проектах
Чота ржу.

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

(271) вот когда начнет использовать, тогда грохнешь закрытие МВТ. Кстати, почитай Макконела, что он пишет про область видимости переменных
https://www.ozon.ru/context/detail/id/138437220/
глава 10.4
Макконел доходчиво объясняет, почему не надо так делать

(273) давай помогу тебе прочитать твою же ссылку

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

(276) "когда начнет использовать, тогда грохнешь закрытие МВТ" // Это влечет две лишние правки: комментирование закрытия исходного МВТ в прежнем месте и добавление его закрытия где-то там, дальше.
Жертвовать таким усложнением сопровождаемости в угоду преждевременной оптимизации - явно не стоит.

(273) вряд ли до тебя дойдёт, поэтому поясню. Оракловой БД занимается целая команда профессиональных ораклистов. Они эту БД разрабатывают, споровождают, настраивают... и вообще полностью за неё отвечают.  При наличии целой толпы ораклистов никто в здравом уме не будет пускать какаого-то там 1сника в базу с админскими правами. И это нормально, это естественно, и так во всех крупных организациях

(278) как раз сопровождаемость усложняется когда переменные инициализируются "где-то там", а используются "где-то здесь". Когда всё на своих местах, никаких проблем с сопровождаемостью нет

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

(281) "жертвуют качеством кода в угоду стоимости и скорости разработки"

Это взаимоисключающие вещи. Небрежный код обходится намного дороже качественного

(280) Зато есть проблемы с велосипедами и консистентностью.

(282) Попробуй это доказать, рассчитав экономический эффект, например, от вовремя закрытого МВТ.

(283) откуда бы им взяться?

(284) мне незачем это доказывать. Это уже на тысячу раз обсосано и давно известно. Почитай, например, Роберта Мартина:
https://www.ozon.ru/context/detail/id/5011068/
в первой же главе он поясняет, почему плохой код обходится дорого

(285) Данных нет, их надо получить. Про закрытый 100500 строк кода назад МВТ разработчик ничего не знает.

(286) Еще раз. Сколько рублей сэкономит на этом конкретный клиент? К любому проекту составляют ТЭО, несмотря на то, что в книжках уже всё написано. И решение принимается исходя из ТЭО, а не книжек. Книжка - это один из вариантов. Не факт что оптимальный.

Вообще для бизнеса, лучше плохая программа, чем вообще никакой.

(288) +100500. С маленькой поправкой - лучше плохая программа сейчас чем хорошая когда нибудь)

(287) "Данных нет, их надо получить. Про закрытый 100500 строк кода назад МВТ разработчик ничего не знает"

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

"Еще раз. Сколько рублей сэкономит на этом конкретный клиент? К любому проекту составляют ТЭО, несмотря на то, что в книжках уже всё написано. И решение принимается исходя из ТЭО, а не книжек. Книжка - это один из вариантов. Не факт что оптимальный"

Встречный вопрос. А сколько клиент потеряет, если разработчик сразу же будет по-человечески писать код?

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

(290) 1. Вот пример из практики: есть печатная форма. Ее можно переделать с использованием технологий копрокода - это будет стоить 2 часа по 1500 руб. (делает вчерашний студент). Ее можно переделать "правильно". Это будет стоить 10 часов по 5000 руб. (придется с нуля писать, и делать придется квалифицированному программисту, который за 400 руб./час не работает). Результат для клиента - одинаковый. Попробуйте обосновать, зачем владельцу бизнеса надо потратить лишние 47 тыр. и получить доработку на 2 дня позже.

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

(291) вот видишь, проблема выявилась ещё в постановке задачи. А потом бизнесу понадобится доработать ПФ ещё раз, но из-за заложенного в неё копрокода сложность доработки заметно увеличивается. Через пару-тройку копродоработок ПФ превратится в вообще не дорабатываемую, проще будет написать с нуля, чем копаться в накопившемся дерьме. Можно конечно надеяться, что ПФ дальше не будет дорабатываться. Но что если всё-таки будет? Например, если это печатная форма договора, условия в котором собираются по кускам, то такая ПФ может дорабатываться и 5 раз, и 10, и даже 30 раз. А каждая последующая доработка будет всё сложнее и сложнее, дороже и дороже. И изначально "сэкономленные" на копрокоде несколько тысяч превратятся в переплаченные десятки, а то и сотни тысяч.
Разумеется, есть участки программы, которые пишутся один раз и остаются неизменными до следующего пришествия Христа. Такие могут стерпеть небрежный говнокод, при этом клиент будет счастлив и доволен. НО! Заранее прогнозировать, что больше никогда не придётся дорабатывать, а что будет перепиливаться неоднократно, довольно сложно

P.S. твой пример слишком уж эмоциональный. Плохой код пишется не на столько быстрее, чем хороший

(292) Доработка печатной формы может потребоваться и после "хорошего" программиста, и переписать ее вполне может потребоваться в связи с изменением требований. Конкретно эта доработка позволяет сэкономить 3000 руб. в месяц на зарплате персонала. Так что "хорошему" программисту ее просто не отдадут, ибо невыгодно. Тут вариант или копрокод, или ручками операторы будут править.

P.S. Именно что настолько. Потому что в одном случае пара костылей, в другом надо переписывать полностью. В 1С очень много тех, кто даже до джуниора не то что не дотягивает, а в принципе не пригоден, даже после обучения.

P.P.S. Samsung в Galaxy S20 правила безопасность, а попутно поломала цветопередачу экрана в режиме 120 Гц. Отличный пример, когда копрокод и его скорость важнее качества.

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

(292) + (294) в этом и есть разница между разрабами мелких баз и крупных. маленькую систему через несколько лет выбросят и заменят на более современную и большинство доработок просто утратят смысл, с крупной системой на базе ерп2 / упп так не прокатит. Там жизнь базы идет от пяти лет. И доработки нужно делать с "запасом"

(293) только после хорошего программиста дорабатывать ПФ будет легко, а после плохого долго и дорого

(294) "то бы сравнялась быдлокодерская доработка по стоимости с качественной понадобится переписать пф раз десять"

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

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

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

(298) откуда могла взяться экономия, если первое внедрение полностью вылетело в трубу, угробив время, нервы пользователей и затраченные на него деньги? Как-минимум двойная переплата вышла. Это всё равно что купить сначала плохой телевизор, промучиться с ним, потом ещё раз купить телевизор, но только хороший

(299) А кто сказал, что это самое первое внедрение было? Куча костылей обычно говорит как раз о самовнедрении. А оно, что ни говори, в разы дешевле обходится.

(300) сложно назвать дешевизной, когда за деньги бизнеса на нем тренируется рукожоп, по-итогу оставивший тот бизнес у разбитого корыта

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

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

(303) к (302)

(296) так тут немного другое. Это неудачное внедрение рукожопом. Основная проблема которого в жлобстве на обучении. Как показывает опыт, в таких конторах основная проблема безграмотность пользователей. И не потому что они не могут, а потому что обучение пользователей считается в СНГ делом постыдным самими руководителями бизнеса. Если бы пользователи прошли ЦСОшные курсы по конфе, то "внедрение" КА и без доработок прошло бы. В описанной тобой ситуации проблема не в быдлокодинге как таковом, а в том, что программист не зная типовую ее запорол. Так он может запороть и делая доработки чистым идеальным кодом, который нарушает логику конфигурации. Мы же о неоптимальном но функционально правильном коде говорим.

(299) Вот интересно, как в "оптимизаторской" голове уживаются посылы про "большую команду узких специалистов" и авторитетное мнение о том, как бизнесу надо расходовать и экономить деньги?

(306) может ты удивишься, но крупные предприятия тратят на ИТ миллиарды, и это нормально, естественно и полностью оправдано. Например, ИТ-департамент Сбербанка ака СберТех насчитывает более 5 тысяч человек. Нетрудно догадаться, что только на оплату труда этой орды айтишников уходят сотни миллиардов. Welcome to the Real World №2

(307) Какой смысл тратить на ИТ миллиарды, если оборот, например, 100 миллионов? Таких организаций на несколько порядков больше, чем крупных предприятий. И именно они являются нормой, а крупные предприятия - это меньшинства ;)

(280) Т.е. технический долг напрочь отрицаешь?

(305) обычно рукожопство всестороннее. А качественная разработка подразумевает комплексных подход, в котором есть место и нормальному коду, и пониманию автоматизируемых бизнес-процессов, и юзабилити, и ещё много чему, что часто называют "ненужным"

(308) крупные конторы могут себе позволить тратить миллиарды на ИТ. А судя по тому, как они бодро это делают, такие затраты полностью оправдывают себя

(309) в смысле? Так-то техническим долгом как раз и будет ситуация, когда МВТ висит "на всякий случай"

(310) Если ты можешь перечислять 90% зарплаты на благотворительность - это не означает, что ты будешь это делать. Тратят миллиарды, потому что есть экономический эффект. Не было бы эффекта - не тратили бы миллиарды. И тратят их не за хороший код, а потому что по-другому при их масштабе уже не получится. А 1С, вроде как, никогда на такие масштабы не претендовала.

(311) Да, не спорю.
Отрицаешь сам факт таких ситуаций, когда оставить технический долг может быть оправдано?

(312) "И тратят их не за хороший код"

Сложно себе представить крупную организацию, в которой не было бы внутренних стандартов и требований к написанию кода

(313) есть такая поговорка - нет ничего более постоянного, чем временное. Зачастую "потом переделаю" остаётся в таком виде навсегда

(227) Это уже излишний перфекционизм. Чтобы конкретно этот случай привел к заметным проблемам - надо сильно постараться.

(178) Это вообще ловля мышей. У вас очень специфичный опыт работы с нагруженными базами.
У меня пример с противоположного края (вот где, действительно, полный пэ): документ, хранящий в строках ХранилищаЗначений (таблицы значений прайсов поставщиков). Один такой мегадокумент занимал в базе 100 мб. А его открытие очень тормозило :)
Переписывал всю эту систему несколько месяцев.  Яркий пример экономии на разработчиках - заплатил сначала первому "писателию", а потом - мне.
Но только вот первый "разработчик" продолжает в той фирме работать. Не хочет руководство платить больше и более дорогого, оно просто не осознает масштаб потерь бизнеса из-за кривого кода.

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

(317) а никто этим и не заморачивается. Вот  в САП интерфейс кривой как моя жизнь. И что? миллионы мух не жужжат

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

(316) это был лиш условный пример одной из множества проблем, порождаемых ленью/незнанием программистов

(314) Стандарты разработки в конкретной организации вполне могут не соответствовать рекомендациям из умных книжек. Внезапно. Потому что универсального алгоритма нет.

(321) ты не совсем прав. Многие вещи в программировании опробованы годами, буквально выстраданы. Так что их легко встретить и в умных книжках, и во внутренних стандартах

(322) Многие, но не все.

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

(324) А долго это продолжалось?

(324) на одном из прошлых мест работы мне достался обвешенный костылями ЗУП. Всё также работало и крутилось. А потом головное предприятие решило сделать РИБ ЗУПа, и спустила нам почти типову конфу. Отказаться от счастья перейти на типовой ЗУП было не вариант, проблемы индейцев, как говорится... Месяца четыре пришлось выправлять данные и переписывать как бы готовые отчеты и обработки, прежде чем типовой ЗУП начал полноценно работать. В доставшейся в наследство конфе царил жуткий трэш. Предшественник, вместо того чтобы разобраться, есть ли в типовой конфе уже готовое и как оно работает, быстренько прикручивал костыль. У него даже свой кривой расчет НДФЛ был сделан, с которым рег. отчетность, естественно, не работала. По-итогу, два года работы этого костылёвщика обернулись тем, что после него два 1сника и шестеро бухов-расчетчиков в течении четырех месяцев практически перевнедряли ЗУП. Вот чем оборачивается скоростное велосипедирование

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

(326) Главный вопрос - доживет ли фирма до момента, когда всё это аукнется? Если нет - значит, костылеваятель оказался прав.

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

(325) 4 года (326) опять ты за человека не шарящего в конфе. Но даже так. вот есть КА уже десять лет на маленьком производстве. Переписанная в хламину. на новую редакцию ты не перейдешь, только с нуля. Но работает. Обновления добавляются только самые критичные. С одной стороны да, все через жопу, с другой у них за пять лет сменились два студента получавшие ниже рыночной, а 5 лет вообще приходяший кодер подправлял им по мелочи. и они работают. Да, в какой то момент вылезет боком все, но сэкономленные деньги за десять лет того стоят. (327) +100500. Вот именно. Мне тут рассказали как один заводик выкупили европейцы и перевели на сап. Юзверя начали бузить - а у нас в 1с был такой отчетик удобный а в сап такого нет. На что европейский манагер сказал - а чего я должен платит овердофига саперам что бы вам было удобно?) (328) или редакция) как люди жили в БП 1.6 а потом на БП 2.0 переходили выбрасывая свои доработки)

(330) не не шарящего, а не желающего разбариться

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

>> а чего я должен платит овердофига саперам что бы вам было удобно?
Дык надо было ему в деньгах разницу предоставить, что бы он понимал свои ошибки. Они же думают стереотипами, навязанными авторитетами. Если им показывать реальную картинку, то они сразу признаются, что не в деньгах дело, а в том, что бы люди превращались в бездумные инструменты

(329) в этом по идее должно помочь периодическое обновление конфы и платформы.

(333) После определённого момента обновить ничего не получается. Для этого иногда достаточно менее 1 года. Встречал. Лечил.

(330) печально то что в результате скорее всего в компании развивается синдром екселинга :(
который кстати почему-то в свежих версиях работает неидеально !!

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

(331) потому что платят, не жжужат и не контроллируют = всем пофиг

(334) дык обновлятор-разработчик должен об этом беспокоиться или ты про то когда это разные люди ?

(338) Разработчик должен, даже обязан, разрабатывать так, что бы сразу думать лет на 10 вперёд. Если разраб делает наикрутейший код, который актуален только здесь и сейчас, тогда происходит кочевряживание общей логики, растёт тех.долг и вся общая работа затрудняется до жути. Ну и про обновления можно забыть уже через короткое время.
Один умный человек переписал расчёт НДФЛ в наикривейшей ЗУПе (как не крути, а там ещё пока много кривостей). Ну а что, сейчас работает же? А через пару месяцев уж это ваши проблемы. И контора вся гудит, что айтишники дэбилы, что не могут вовремя обновлять новые плюшки, которые появлятся по 3 раза в месяц. Потом 1С-ники полностью меняют модули расчёта налогов и народ вообще взвывает.
Уже наверное с десяток контор прошёл и везде одно и тоже - то, что описал. Всегда никто ничего не может обновить, учёта нет, всё разваливается и никто не может ничего сделать. А я всегда с самого начала начинаю удалять нафиг все переписки-дописки, что бы хоть как-то приводить учёт в порядок.

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

(339) т.е. все сводится к извечному "вам это не надо"

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

(340) Нет! Всё надо! Вообще всё. От и до, кроме самодурства.

(341) Только наисложнейшие предприятия. Всегда одно и тоже - все разрабы, которых выгоняли напоследок говорили, что ещё на коленях просить будем, что бы они помогли. В некоторых конторах даже свой налоговый учёт был. При чём структуры такие по размеру, что только юзверей под 400 штук было.
Так что если есть трубейная контора, зовите меня и всё исправим))))))))))))))

(341) >> добавляя очередной костыль.
Деление по видам времени, пропорционально скачкам сотрудников с территорию на территорию, с различными правилами и сложными расчётами. Это просто? Например, франч начал всю конфу менять, ведь надо все начисления делить. 1С-ники как-то вяло к этому подошли и много лет не делали. А мы сделали в виде внешнего модуля, который позволяет работать без программиста и никак не влияет на обновление.
И так во всём и всегда. Секрет не в крутости, а в использовании простейших методик, которые всем известны, но которые никто почему-то не использует. Никто! С 2009 года всем про них талдычу, а они только кивают головами и всё равно делают по старинке - загоняют и себя и конторы в ямы

(27) А где гарантия что заплатите подрядчику, проводящему аудит конфигурации?