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

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

(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) А где гарантия что заплатите подрядчику, проводящему аудит конфигурации?