Вход | Регистрация
    1  2  3  4   
1С:Предприятие :: 1С:Предприятие 8 общая

Аудит конфигурации 1с

Аудит конфигурации 1с
Я
   ВикторП
 
12.04.20 - 08:58
Вопрос по теме- досталась конфигурация с внесенными к типовой изменениями.

Есть ли структура, которой можно отдать конфигурацию на аудит , например , на соответствие стандартам разработки?
Интересуют сроки, стоимость.
   Конструктор1С
 
201 - 19.04.20 - 05:56
(196) в (170) "приведи конкретные сценарии, где проявлялась неоптимальность конкретного кода"

вот я и привел. Тенденция, надесь, заметна. Конкретный код публиковать не имею права, это нарушение лиц. соглашения
   vi0
 
202 - 19.04.20 - 06:02
(201) если код не имеешь права давать, то зачем давать ссылку? я не просил ничего такого что там по ссылке
   vi0
 
203 - 19.04.20 - 06:03
(200) засрал ты эту ветку донельзя, своей теоритезацией
а так хорошо все начиналось
   Конструктор1С
 
204 - 19.04.20 - 06:06
(197) всё зависит от ситуации. Пример из практики. Нужно было периодически получать данные из БД под Oracle. Таблица с данными огроменная, миллиарды записей. А запрос должен был просматривать записи за один или несколько месяцев. В таблице были подходящие индексы, запрос был написан по всем феншуям, но выполнялся он от 7-8 часов до суток... Решение: разбили запрос на множество маленьких, каждый запрос тянул данные только за 1 день, и общее время выполнения сократилось до нескольких минут. Есть ещё примеры, например, как временные таблицы отсасывали у вложенного запроса, и ещё много чего, что "грубейше" нарушает 1сные рекомендации. Но это отдельная история
   Конструктор1С
 
205 - 19.04.20 - 06:08
(203) у меня довольно большой опыт работы с высоконагруженными БД, и я знаю о чем пишу. Поверь, это не теоретизация. Типичные привычки множества 1сников, зародившиеся на мелких БД, сплошь и рядом вылазят  боком, когда их произведения пытаются запустить на больших БД
   Конструктор1С
 
206 - 19.04.20 - 06:24
(202) кажется, мы тут пытаемся обсуждать, как недальновидность при программировании может приводить к проблемам с производительностью. По ссылкам как раз яркие тому примеры. Как-минимум части из этих проектов просто не было бы, если бы разработчики типовых соблюдали правила уровня "мойте руки перед едой": не плодили бездумно временные таблицы, не давали менеджеру ВТ жить подолгу, ну и так далее.
   Бертыш
 
207 - 19.04.20 - 06:35
(194) Коллега, тут посмею с Вами не согласится, не смотря на утверждения коллеги с чудным отчеством Рафаилович о разработке им искусственного интеллекта для написания программного кода.
Мне картина видится несколько иначе. Есть скажем общий блок в отношении которого функция попадает в некий общий модуль. Далее меняется архитектура блоков, ну например из коллекции модулей УТ выделяется в отдельный блок поддержка документа реализациятоваровиуслуг, ну и соответственно меняется архитектура общих модулей во след за изменением архитектуры блоков. Мне бы например чего бы от 1С хотелось бы? Чтобы при разработке всевозможных сущностей программисты не забывали бы про вызовы переопреляемых модулей (каковые мы лнегко к слову сказать можем прокопировать в расширение и там доработать не снимая конфу с замочка и соответственно не меняя её), а то порой приходится ради стейка резать телёнка из-за того что нет вызова переопредляемого модуля соответствующего. Теоретически я могу предположить конечно что не включив вызов переопределямого модуля разработчики нам как бы намекают что они не рекомендуют менять данный объект, но прав то всегда заказчик в конечном итоге.
   vi0
 
208 - 19.04.20 - 07:34
(206) я просил конкретный пример а ты мне какие то ссылки опять же абстрактные кидаешь
хорошо, если с заказчиком ты общаешься не на таком языке
   Конструктор1С
 
209 - 19.04.20 - 07:43
(208) выше я описывал примеры. Условные, но суть та же
   acht
 
210 - 19.04.20 - 10:21
(209) "Как можно работать над проектом, если в космосе хаос?"
   vi0
 
211 - 19.04.20 - 10:28
(209) к чему эти условные примеры?
Ну если тебе нравятся условные примеры, то я повторю вопрос на который ты не ответил: запрос в цикле это плохо?
   Комрад1
 
212 - 19.04.20 - 10:34
(211) Ответ так-то очевиден - когда как :)
   acht
 
213 - 19.04.20 - 10:45
(211) Он попытался начать формулировать идею, что в каждом конкретном случае надо разбиратся. Но, к сожалению, испугался и свалился в рассказ о своей персональной героической борьбе :
   acht
 
214 - 19.04.20 - 10:46
(209) Почему ты при рассмотрении этих условных примеров активно сопротивляешься даже самой вероятности наличия альтернативной точки зрения на анализ ситуации?
   Фрэнки
 
215 - 19.04.20 - 10:58
(214) как это "почему ..."?
Жизнь - это борьба!!!
Тут нельзя без сопротивления.
   Конструктор1С
 
216 - 19.04.20 - 12:06
(211) ну так-то я ответил на этот вопрос. Если не понятно, напишу ещё раз. Всё зависит от ситуации, и иногда множество маленьких запросов в цикле это намного лучше, чем один большой запрос
   Конструктор1С
 
217 - 19.04.20 - 12:09
(214) воу-воу, чувак, притормози. Вообще-то это ты начал докапываться до моих слов и учить меня "правильно мыслить". Если забыл, вернись на первую страницу топика и перечитай
   acht
 
218 - 19.04.20 - 12:57
(217) Гм. Начал я, а нафлудил на три страницы ты. Мистика!
   1CnikPetya
 
219 - 19.04.20 - 15:42
(204) И в чем же была причина столько долгого чтения? Вы ведь провели исследование плана запроса? Могу предположить, что запрос был на писан все же не "по всем феншуям" и приводил к фулл сканам. А сделав запрос за каждый день отдельно, вы наконец добились Index Seek за счет максимально простого условия на равенство конкретной дате.
   Сияющий в темноте
 
220 - 19.04.20 - 17:49
(219) там,скорей всего,результат запроса просто в память не помещается,тогда будут тормоза,но делить надо было не на дни,а следить за памятью,но это же долго,проще разбить на дни и не думать.
   Конструктор1С
 
221 - 19.04.20 - 17:56
(220) на кофейной гуще гадаешь? Совершенно мимо
   Конструктор1С
 
222 - 19.04.20 - 18:06
(219) нет, с запросом и попаданием в индексы всё тип-топ. А разбить запрос на дни мне посоветовали ораклисты
   080808Ник
 
223 - 19.04.20 - 22:01
(205) простите, но "ипичные привычки множества 1сников, зародившиеся на мелких БД, сплошь и рядом вылазят  боком, когда их произведения пытаются запустить на больших БД" звучит как использование домашнего инструмента вылазит боком когда его используют на профессиональной стройке. каждой задаче свой инструмент и в одном случае нужна максимальная оптимизация кода, а в другом оптимальный код зло. Для бизнеса естественно. Мелким предприятиям не так критичная скорость работы, как скорость доработки и стоимость, крупным производительность в приоритете. Поэтому когда произведения для мелких баз запускают на больших бд, то это проблема не разработчика, а того, кто запускает на большой базе
   1CnikPetya
 
224 - 19.04.20 - 23:02
(222) Так в чем же были причины тормозов?
   Сияющий в темноте
 
225 - 19.04.20 - 23:09
у оракла еще есть традиция выполнения транзакции в режиме снапшот,то есть на данные ставится отметка,что они получены в запрос и при их изменении,нужно создавать копию-по иден,при разбивке на дни,отметка снимается после завершения обработки дня.
   vi0
 
226 - 20.04.20 - 04:16
(216) ну так, а к чему тогда твои абстрактные примеры, если все зависит от ситуации
   Конструктор1С
 
227 - 20.04.20 - 05:53
(226) и какая же ситуация оправдывает, например, незакрытый менеджер временных таблиц, если этот менеджер ВТ заведомо больше не будет использоваться?

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

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

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


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


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


КонецПроцедуры// Наконец-то МВТ закрылся
   Конструктор1С
 
228 - 20.04.20 - 05:59
(224) уже не помню. Мне объясняли, но т.к. в тонкостях работы оракла не силён, это объяснение быстро выветрилось из головы
   Конструктор1С
 
229 - 20.04.20 - 06:14
Я ведь это не из вредности пишу, и не придумываю. Мелочи в конфигурации, если база становится большой и многопользовательской, превращаются в большие проблемы
   Бертыш
 
230 - 20.04.20 - 08:09
(225) Так вот почему в Юкосе использовали документ закрытия дня в торговой системе, а не регистры. Вон оно как оказывается :)
 
 Рекламное место пустует
   acht
 
231 - 20.04.20 - 08:39
(229)
День первый.
Хакер приходит в общественную столовую и с возмущением обнаруживает, что солонку на столе может открутить кто попало и насыпать туда что угодно. Хакер приходит домой и пишет гневное письмо директору столовой: "Я, meG@Duc|, обнаружил уязвимость солонки в Вашей столовой. Злоумышленник может вскрыть солонку и насыпать туда яду! Примите меры срочно!"
   Конструктор1С
 
232 - 20.04.20 - 08:41
(231) т.е. культура кодирования это зло и нафиг не надо?
   Cyberhawk
 
233 - 20.04.20 - 10:19
(227) Почему ты все придумываешь примеры, ведущие к избыточному расходу памяти? У тебя памяти не хватает?
   acht
 
234 - 20.04.20 - 12:07
(232) Культура кодирования это не зло. Зло - это считать, что только твои ситуации уникальны, поэтому там можно нарушать рекомендации. А все остальным задумываться о разборе твоих абстрактных примеров запрещено, чтобы не дай бог не нашли вариант конкретизации, приводящий к тому же самому отступлению от правил.
   Конструктор1С
 
235 - 20.04.20 - 12:57
(233) я их не придумываю, я с ними регулярно сталкиваюсь
   vi0
 
236 - 20.04.20 - 13:00
(227) ты опять приводишь абстрактный код
покажи реальный код
   Конструктор1С
 
237 - 20.04.20 - 13:00
(234) так ты и не пытался разбирать мои примеры, ты сразу занял позицию "ща я чем-нибудь под...бу этого рукожопого оптимизатора"
   Cyberhawk
 
238 - 20.04.20 - 13:03
(235) Какие проблемы от избыточного потребления памяти?
   Конструктор1С
 
239 - 20.04.20 - 14:04
(236) извини, говнокод не коллекционирую. Но если очень хочешь, могу поискать

(238) ты это серьёзно?
   H A D G E H O G s
 
240 - 20.04.20 - 14:08
(239) Епстественно он это серьезно. Избыточное потребление памяти не так критично, как, например, не разобраться, почему помогло разбиение по дням.
   acht
 
241 - 20.04.20 - 14:21
(237) См. (93):

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

Кажется я понял, почему ты так беспокоишся об объеме памяти.
   Конструктор1С
 
242 - 20.04.20 - 14:25
(240) н-да. Разве из моих каментов не понятно, что в проблеме разбирался профессиональный ораклист? Это в небольших организациях 1сник и швец, и жнец, и на дуде игрец, и админ домена впридачу. А в крупных сервера админят одни узкие специалисты, винду админят другие узкие специалисты, БД админят третьи узкие специалисты... и у рядового 1сника там просто нет возможностей в каждую БД с админскими правами заныривать
   Конструктор1С
 
243 - 20.04.20 - 14:26
(241) ну, рассказывай свою очередную додумку, не томи
   H A D G E H O G s
 
244 - 20.04.20 - 15:00
(242) "А в крупных сервера админят одни узкие специалисты, винду админят другие узкие специалисты, БД админят третьи узкие специалисты..."

и получается дырка от бублика.
   dmpl
 
245 - 20.04.20 - 15:00
(204) А у нас замена вложенных запросов на временные таблицы в восстановлении партионного учета УПП сократила время в 4 раза (не запроса - а полное время восстановления последовательности, сам запрос в десятки раз ускорился). Мы потом с усмешкой где-то с полгода смотрели на потуги фирмы 1С решить эту проблему, ее так и не решили. Так что к чему эти абстрактные примеры? Их можно для любой ситуации привести.
   palsergeich
 
246 - 20.04.20 - 15:08
(244) тут уж как повезет.
Иногда и правда не очень выходит, иногда летит, тут уже вопрос к кадрам, бывают хуже бабок персонажи.
   palsergeich
 
247 - 20.04.20 - 15:11
(246) хотя к нашей отрасли это тоже относится
   Конструктор1С
 
248 - 20.04.20 - 15:33
(244) не, получается каждый занят своим делом
   Конструктор1С
 
249 - 20.04.20 - 15:36
(245) примеры всего-лишь к тому, что "незыблемые" рекомендации не могут быть на все случаи жизни
   vi0
 
250 - 20.04.20 - 15:47
(239) теперь ты говнокод не коллеционируешь, а выше сказал, что не можешь привести, т.к. нарушишь закон
я же пока вижу, что ты теоритетик, не готовый обсудить конкретику с кейсами и замерами
   Конструктор1С
 
251 - 20.04.20 - 16:06
(250) ты предлагаешь ради показушничества на форуме нарушить закон и внутренние регламенты моего предприятия? Выше я писал:
"Типичные привычки множества 1сников, зародившиеся на мелких БД, сплошь и рядом вылазят  боком, когда их произведения пытаются запустить на больших БД"

ты же понимаешь, что на домашнем ПК я никак не воспроизведу то, что происходило в базе с огромными таблицами?
   Cyberhawk
 
252 - 20.04.20 - 17:47
(239) "ты это серьёзно?" // Ну да. Какие проблемы из-за незакрытого МВТ или преждевременного запроса в плане памяти?
   vde69
 
253 - 20.04.20 - 18:02
(251) тут все сложно... вот например у нас было 5 1с ников и еще 8 дельфистов, и человек 30 админов в перемешку с аникейщиками... догадайся кто админит SQL ???

мелкой такую контору язык не поворачивается назвать
   Конструктор1С
 
254 - 20.04.20 - 19:26
(252) они сжирают ресурсы. Когда пользователей много и/или обрабатывается большое количество данных, это может стать серьёзной проблемой
   ДедМорроз
 
255 - 20.04.20 - 20:11
Кстати,менеджер временных таблиц умрет не сразу после освобождения последней переменной,а после сборки мусора,так что тут есть свои камни.
   Cyberhawk
 
256 - 20.04.20 - 20:51
(254) А какие симптомы проблемы?
   Гобсек
 
257 - 21.04.20 - 04:55
(236) у абстракного кода преимущество в том, что он простой и наглядный. Мне пример понравился. Приму к сведению.
   Конструктор1С
 
258 - 21.04.20 - 05:06
(255) из синтакис-помощника
МенеджерВременныхТаблиц (TempTablesManager)
Закрыть (Close)
Синтаксис:
Закрыть()
Описание:
Закрывает менеджер временных таблиц. При этом удаляются все временные таблицы, в нем находящиеся. Дальнейшая работа с данным объектом невозможна

Когда там физически удалится ссылка на МВТ пофиг, главное что он таблички грохает
   Конструктор1С
 
259 - 21.04.20 - 05:13
(256) усиленно "сжираются" дисковое пространство и свободная оперативная память. Во время пиковых нагрузок может получиться "бутылочное горлышко"
   Конструктор1С
 
260 - 21.04.20 - 05:30
Не стоит думать, что я такой ярый противник незакрытых МВТ или подолгу в холостую висящих в памяти переменных. Потенциальных источников проблем и "тормозов" большое количество. Просто, судя по обсуждению, некоторые не хотят верить в существование подобного рода проблем. Поэтому так долго и мусолим эту тему
 
 Рекламное место пустует
   dmpl
 
261 - 21.04.20 - 07:36
(249) Вот поэтому обсуждать какие-то решения в отрыве от контекста их использования и приоритетов, поставленных разработчику, - некорректно. Для предметного разговора нужен конкретный пример с совершенно конкретным кодом + предыстория вопроса.
   dmpl
 
262 - 21.04.20 - 07:41
(259) Чрезмерная оптимизация - одна из самых распространенных ошибок. Вот если при нагрузочном тестировании оно будет бутылочным горлышком - будет иметь смысл что-то предпринимать. А до этого это просто необоснованная трата ресурсов без экономического эффекта.
   acht
 
263 - 21.04.20 - 07:47
(258) Во-первых не грохает, а усекает. Во-вторых, неплохо было бы тебе документацию почитать, например https://its.1c.ru/db/v839doc#bookmark:dev:TI000000517, где явно рассказано когда удаляются таблички. Ну или профайлер в руки взять, но это явно не твой метод.

А вообще, ты раскрываешь довольно концептуальную картину мироздания, в которой ораклисты занимаются оптимизацией запросов и рассказывают одинесникам что надо делалать. Одинесники же, в свою очередь, поучают других на форумах, как надо писать код. Продолжай, пожалуйста.
   acht
 
264 - 21.04.20 - 07:47
(255) Ю
   acht
 
265 - 21.04.20 - 07:48
(255) > а после сборки мусора
Поподробней не расскажешь?
   acht
 
266 - 21.04.20 - 07:49
(260) > и мусолим эту тему
s/мусолим/мусолишь/gi;
   strange2007
 
267 - 21.04.20 - 08:13
(0) Работа ради работы, не приносящая бизнесу ничего. Нафига? Какие структуры посчитают технический долг? Сколько специалистов смогут оценить денежные потери, если и дальше работать на такой конфе? Как бороться с заинтересованными в том, что бы учёт был максимально кривой? Как это посчитать?
Вот-вот((((((

Примечание: Я не имею в виду конкретную конфу, а описываю общие проблемы большинства контор.
   Cyberhawk
 
268 - 21.04.20 - 08:41
(259) Чтоб кончился диск и память - это надо сильно постараться. Вероятность наступления этого оцениваю как весьма низкую. Если конечно у тебя на сервере 1С не 16 Гб ОЗУ и 50 Гб диска.
   Конструктор1С
 
269 - 21.04.20 - 08:49
(262) ни о какой оптимизации речи не идет. Многие вещи делаются/не делаются на уровне культуры программирования

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

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

//...

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

//...

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


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

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

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

//...

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

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

//...
   Конструктор1С
 
270 - 21.04.20 - 08:57
(263) читатель но не пониматель документации, что тебе не понятно из справки?

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

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

Welcome to the Real World. Когда-нибудь и тебе доведется побывать на крупных проектах (но не уверен), где работает большая команда узких специалистов, каждый из которых отвечает за свой участок. А пока что смотри на мир через свою призму восприятия, в которой 1сник и швец, и жнец, и на дуде игрец, и первый DBA на деревне
   Cyberhawk
 
271 - 21.04.20 - 09:00
(269) Этот пример более дорогой в сопровождении, ибо сегодня тот последующий код не использует МВТ, а завтра уже использует
   dmpl
 
272 - 21.04.20 - 09:01
(269) Чтобы сделать "вот так" надо точно знать, что этот МВТ нигде дальше не используется. Это уже растрата ресурсов (времени разработчиков на анализ кода), которая не дает экономического эффекта.
   acht
 
273 - 21.04.20 - 09:03
(270) О, оптимизация в дикой природе,как она есть. Для экономии памяти по ссылкам не ходим, вторую часть описания мироздания не читаем.
   acht
 
274 - 21.04.20 - 09:04
(270) > Когда-нибудь и тебе доведется побывать на крупных проектах
Чота ржу.
   dmpl
 
275 - 21.04.20 - 09:05
(271) Угу, и разработчик изобретет свой велосипед по получению нужных данных. В итоге, в лучшем случае получим двойное получение данных, в худшем - проблемы с консистентностью данных и попытками их решить, например, ковровой блокировкой или более высоким уровнем изоляции транзакций.
   Конструктор1С
 
276 - 21.04.20 - 09:07
(271) вот когда начнет использовать, тогда грохнешь закрытие МВТ. Кстати, почитай Макконела, что он пишет про область видимости переменных
https://www.ozon.ru/context/detail/id/138437220/
глава 10.4
Макконел доходчиво объясняет, почему не надо так делать
   Конструктор1С
 
277 - 21.04.20 - 09:10
(273) давай помогу тебе прочитать твою же ссылку

"Все временные таблицы, созданные в данном экземпляре менеджера, существуют до тех пор, пока существует сам экземпляр менеджера временных таблиц. При уничтожении экземпляра менеджера все временные таблицы, которые содержатся в нем, также удаляются.
Менеджер временных таблиц можно закрыть принудительно при помощи метода Закрыть(). При этом будут удалены все созданные в нем таблицы. Дальнейшая работа с данным экземпляром менеджера будет невозможна"
   Cyberhawk
 
278 - 21.04.20 - 09:21
(276) "когда начнет использовать, тогда грохнешь закрытие МВТ" // Это влечет две лишние правки: комментирование закрытия исходного МВТ в прежнем месте и добавление его закрытия где-то там, дальше.
Жертвовать таким усложнением сопровождаемости в угоду преждевременной оптимизации - явно не стоит.
   Конструктор1С
 
279 - 21.04.20 - 09:23
(273) вряд ли до тебя дойдёт, поэтому поясню. Оракловой БД занимается целая команда профессиональных ораклистов. Они эту БД разрабатывают, споровождают, настраивают... и вообще полностью за неё отвечают.  При наличии целой толпы ораклистов никто в здравом уме не будет пускать какаого-то там 1сника в базу с админскими правами. И это нормально, это естественно, и так во всех крупных организациях
   Конструктор1С
 
280 - 21.04.20 - 09:24
(278) как раз сопровождаемость усложняется когда переменные инициализируются "где-то там", а используются "где-то здесь". Когда всё на своих местах, никаких проблем с сопровождаемостью нет
   dmpl
 
281 - 21.04.20 - 09:26
(276) Сейчас вполне осознанно жертвуют качеством кода в угоду стоимости и скорости разработки. Все эти правильные книжки в пролете, когда надо платить больше без очевидного профита.
   Конструктор1С
 
282 - 21.04.20 - 09:27
(281) "жертвуют качеством кода в угоду стоимости и скорости разработки"

Это взаимоисключающие вещи. Небрежный код обходится намного дороже качественного
   dmpl
 
283 - 21.04.20 - 09:27
(280) Зато есть проблемы с велосипедами и консистентностью.
   dmpl
 
284 - 21.04.20 - 09:28
(282) Попробуй это доказать, рассчитав экономический эффект, например, от вовремя закрытого МВТ.
   Конструктор1С
 
285 - 21.04.20 - 09:28
(283) откуда бы им взяться?
   Конструктор1С
 
286 - 21.04.20 - 09:32
(284) мне незачем это доказывать. Это уже на тысячу раз обсосано и давно известно. Почитай, например, Роберта Мартина:
https://www.ozon.ru/context/detail/id/5011068/
в первой же главе он поясняет, почему плохой код обходится дорого
   dmpl
 
287 - 21.04.20 - 09:35
(285) Данных нет, их надо получить. Про закрытый 100500 строк кода назад МВТ разработчик ничего не знает.

(286) Еще раз. Сколько рублей сэкономит на этом конкретный клиент? К любому проекту составляют ТЭО, несмотря на то, что в книжках уже всё написано. И решение принимается исходя из ТЭО, а не книжек. Книжка - это один из вариантов. Не факт что оптимальный.
   dmpl
 
288 - 21.04.20 - 09:37
Вообще для бизнеса, лучше плохая программа, чем вообще никакой.
   080808Ник
 
289 - 21.04.20 - 09:45
(288) +100500. С маленькой поправкой - лучше плохая программа сейчас чем хорошая когда нибудь)
   Конструктор1С
 
290 - 21.04.20 - 09:46
(287) "Данных нет, их надо получить. Про закрытый 100500 строк кода назад МВТ разработчик ничего не знает"

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

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

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

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

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

P.S. твой пример слишком уж эмоциональный. Плохой код пишется не на столько быстрее, чем хороший
   dmpl
 
293 - 21.04.20 - 10:35
(292) Доработка печатной формы может потребоваться и после "хорошего" программиста, и переписать ее вполне может потребоваться в связи с изменением требований. Конкретно эта доработка позволяет сэкономить 3000 руб. в месяц на зарплате персонала. Так что "хорошему" программисту ее просто не отдадут, ибо невыгодно. Тут вариант или копрокод, или ручками операторы будут править.

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

P.P.S. Samsung в Galaxy S20 правила безопасность, а попутно поломала цветопередачу экрана в режиме 120 Гц. Отличный пример, когда копрокод и его скорость важнее качества.
   080808Ник
 
294 - 21.04.20 - 10:46
(292) "А потом бизнесу понадобится доработать ПФ ещё раз" так в том и вопрос - что бы сравнялась быдлокодерская доработка по стоимости с качественной понадобится переписать пф раз десять. Но качественную тоже придется дорабатывать, и понадобится при доработке минимум один час - ибо за меньшее никто и не возьмется. Поэтому копродоработка практически всегда будет дешевле. Это как жигуль и бэнтли. жигуль ты ремонтируешь раз в месяц, а бэнтли раз в году. Но стоимость одной запчасти бэнтли перекрывает стоимость всех запчастей жигуля.
   080808Ник
 
295 - 21.04.20 - 10:50
(292) + (294) в этом и есть разница между разрабами мелких баз и крупных. маленькую систему через несколько лет выбросят и заменят на более современную и большинство доработок просто утратят смысл, с крупной системой на базе ерп2 / упп так не прокатит. Там жизнь базы идет от пяти лет. И доработки нужно делать с "запасом"
   Конструктор1С
 
296 - 21.04.20 - 11:08
(293) только после хорошего программиста дорабатывать ПФ будет легко, а после плохого долго и дорого

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

Когда-то давно работал во франче, и был свидетелем интересной истории. Уверен, многие с подобным встречались. В одной фирме какой-то рукожоп внедрял КА. В работающей конфигурации он загубил всё что можно. Из кое-как внедрённого и работающего были только продажи, да и то, остатки расползшиеся и неконтролируемые, номенклатура задвоена. Остальное мрак, заросший костылями. Бухгалтерия самостоятельно пыталась как-то там вести бухучет, но у них ничего не шло, только несколько счетов мало-мальски соответствовали действительно. Судя по словам главбушки, работал этот васёк с ними несколько лет. "Внедрял" конфу не покладая рук. Потом видимо слился, в ужасе сбегая от той страхоты, которую сам же натворил. Надо ли рассказывать, что выправляли после этого рукожопа долго и дорого? Вот тебе и "экономия" на говнокоде
   Bigbro
 
297 - 21.04.20 - 11:16
(294) я пришел к простому принципу - там где надо быстро и требования постоянно меняются нет никакого смысла тратить время на идеальный код.
проще, быстрее, дешевле лепить костыли и заплатки.
до определенного предела разумеется. по достижении которого можно уже код причесать и переписать более менее нормально.
нюанс в том что к моменту причесывания задача может измениться от исходной до неузнаваемости несколько раз.
   dmpl
 
298 - 21.04.20 - 11:30
(296) 1. Никого не интересует, легко ли будет дорабатывать или тяжело. Всех интересует выхлоп с этой операции.
2. "Выправляли" - читай внедряли. Только не надо забывать, что бизнес работал, и неплохо так сэкономил на внедрении до этого. Так что еще вопрос, какой экономический эффект от этого. Вполне возможно, что если бы правильно внедряли с самого начала - бизнеса уже не было бы. Потому что деньги вместо дела ушли бы на красивый код.
   Конструктор1С
 
299 - 21.04.20 - 11:47
(298) откуда могла взяться экономия, если первое внедрение полностью вылетело в трубу, угробив время, нервы пользователей и затраченные на него деньги? Как-минимум двойная переплата вышла. Это всё равно что купить сначала плохой телевизор, промучиться с ним, потом ещё раз купить телевизор, но только хороший
   dmpl
 
300 - 21.04.20 - 12:38
(299) А кто сказал, что это самое первое внедрение было? Куча костылей обычно говорит как раз о самовнедрении. А оно, что ни говори, в разы дешевле обходится.
  1  2  3  4   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.