Доброго дня господа программисты.

Есть задача по доработке 1С. Изменения нужно будет вносить в порядка 50 процедур/функций. Эти процедуры и функции писались и дописывались в течении 10 лет 10-ю программистами. В итоге имеется капрокод: переменные не отражают свою суть, в процедурах с именами тоже коряво + в одной процедуре может выполнятся более одного алгоритма совершенно не связанных и тд. и тп. в общем все самые худшие практики программирования. И этот функционал используется интенсивно.

И столкнулся я с Дилеммой которая отражена в заголовке вопроса:
выполнить рефакторинг там где он должен быть или последовать мудрой заповеди "Работает не трогай".

Хочу увидеть мнения по этому поводу.
---
В общем, каждый принимает решение сам, либо следует распоряжению руководителя.
В моем случае, я поступаю следующим образом: те участки кода, которые непосредственно связаны с задачей я подвергаю рефакторингу, если с моей точки зрения он уместен. Остальные участки - не трогаю, чтобы работало:)
Всем спасибо за обсуждение.
---
Дойди до любого зеркала, убедись, что тебя никто не потревожит, что ты в безопасности, что ты можешь позволить себе быть честным, хотя бы перед собой. Посмотри на себя, посмотри себе в глаза, глубоко вздохни и, вот так стоя напротив себя, прямо спроси -"%userName%, ну вот оно тебе надо а?
---
стоит ли вопрос: вернуться к поддержки?
или же стоит вопрос: переработать имеющееся верными методами?
---
Стоит вопрос реализовать задачу. Подробнее в топике.
---
Есть задача по доработке 1С.
Доработка варианты:
1. Переработка конфигурации
2. Переработка расширения
3. Создание расширения

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

я бы за такое взялся. Можете прислать файл конфигурации? *.cf
---
Смотря сколько готов платить заказчик.
---
Если на постоянной поддержке или работаете в этой компании, то обязательно переделывайте. А если аутсорс проект, тогда зависит от бюджета клиента)
---
Если аутсорс, а копаться в говне ой как не хочется, то есть два варианта - повысить ценник или отказаться.
---
если хорошо платят, то приводить код в порядок очень даже приятно
---
Если 10-летняя работа, лучше сделать рефакторинг, привести всё в порядок. (может быть что-то уже и не нужно)
---
Это хорошо, если код только "корявый", иногда бывает что код просто ошибочный, алгоритмы неправильно работают. Вы исправляете это, становясь врагом всех пользователей, которые утверждают, что до вашего вмешательства всё работало отлично. Неблагодарная это работа, лучше не трогать.
---
Ну на мнение пользователей мне до лампочки. Работать должно как следует. Пользователи будут доказывать что работает неправильно своему руководителю.
---
как правило срабатывает только "ползучий" рефакторинг и его суть очевидна:
1. из кошелки методов берем самый простой и в нем приводим к канонам самую простую его часть.
2. далее успешно тестируем.
3. и наконец сразу и без апелляций обновляем у клиента.
...
повторяем п.1-3 N раз.

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

вывод: если связать себе крылья - результат будет 100%
---
Есть задача по доработке 1С

лучше отказаться, как бы это заманчиво не было

функции писались и дописывались в течении 10 лет 10-ю программистами

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

только виноватым буду не я и не инфостарт :) - сами понимаете, кто.
---
Работаю в этой конторе. Правда в том что выполнив рефакторинг, обязательно что то сломаю. Но зато, сделаю качественно задачу которую задали. И само собой тестирование будет простым. Сам склоняюсь к рефакторингу, т.к. время есть. В итоге одна задача разделится на 2: сначала сделать рефакторинг там, где буду дописывать, а затем уже выполню саму задачу.
---
Тут свое-то боишься трогать, т.к. уже многое не помнишь, почему именно так сделал, а вы хотите за другими разгрести. Я переделываю, только когда перестает работать. Вот перешли на SQL, и перестали обрабатываться EXcel файлы. Лезу, меняю алгоритм кардинально, потому что написано было еще на стыке 7.7 и 8, по тем представлениям. А что крутится, то лучше не менять, имхо. Только если уж совсем скучно станет. :-)
---
Да, менять боязно. Но видишь ли, мне потом с эти работать. Я буду менять только то, что нужно в задаче. Остальной код мне не интересен - тут поговорка "Работает - не трогай" к месту. А как мне, к примеру, потом тестировать, процедуру в которой не только мой кусок а ещё 10 чужих, тех которые уже ушли? Это получается нужно тестировать все 11 кусков. Свой и 10-ть остальных. Ну или по крайней мере - обращать на них внимание, следить за ними. И тогда эти условные 50 процедур выльются в 500(!) на которые мне нужно будет обращать внимание при каждом изменении! Нет, к этому я не готов.

Если нужно что-то ПОДПРАВИТЬ - это одно.
А если нужно что-то ДОРАБОТАТЬ - это другое.
---
как давно работаете ?
---
11 месяцев
---
и только сейчас предложили задачу
или присматривались к вам
( а в это время брали кого на доработки ? )

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

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

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

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

или лапшу вешают,
что у них уровень не того, а у вас - супер..но мы не знали....вот и мечтаем, что вы сделаете , так ?
---
Бро, я на постоянке. И те 10 тоже на постоянке были. Уровень у всех разный. Это зависит от опыта и желания. Молодняк должен работать под присмотром старших, как и везде, чтобы во-первых, не натворить делов, а во-вторых набраться опыту. Почему сложилась такая ситуация с кодом? Это вопрос риторический...
---
т.е. вели дело как-нибудь, а потом решили начинать хорошо.
может и так, но только кроме желаний - люди остались такими же
и вопрос времени, когда опять начнется...на вас или с вас..

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

но по-хорошему,
я бы отказался.

работа есть .. подработать можете ...
недостаточно клиентов со стороны ?

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

Буду я главным или нет - это не важно в данном контексте. Важно что я буду отвечать за свой кусок кода.
---
а взаимодействие и связи ?

нет главного - нет порядка
нет отвечающего за порядок в конфигурации и внесение изменений
тогда толку, что вы лучший специалист, чем Гилев:)

разве вам будут платить миллион и не требовать гарантий или не будет претензий
но такое даже в кино нет :)

_______

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

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

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

Ну нет отвечающего да и ладно - мне то какое дело. Я сам за себя.

Конечно миллион мне не будут платить. А кому будут?

Да, мне нравится вести и делать задачу как я считаю правильным. Это доставляет определенное удовольствие.

Да, я Волк в овечьей шкуре, бро;)
---
в некоторой степени я также принимаю

________
 делаю я как для себя,
мне нравится вести и делать задачу как я считаю правильным.
____________

но, это действует хорошо только, когда ты один.

но если желающих делать не мало и у них нет таких желаний ( как для себя и качественно )
и тем более -нет хорошего управляющего, который обрубает хвост работнику за кривой код
тогда .....
вобщем ,если будем живы и Христос не придет раньше, чем через два года - напишите, как в 2023 будут дела.
в той компании и с этой конфигурацией.
---
Если напомнишь, напишу:)
---
Бро, делай рефакторинг своих сообщений пожалуйста:)
---
полчасика прошло :)
приму во внимание.
---
Конечно руководство присматривается а ты притераешся... Эту задачу предложили только сейчас. Другую - более трудоемкую - ранее. Но по той задаче я сразу ответил что работы на 2 года (условно) (обновить УПП на 120 релизов с учетом великого множества неизвестных никому доработок).
---
напишите тесты , сравните результаты тестов , в случае совпадения заменяйте код.
Вы счастливчик . я ни разу не встречал понимания у начальства в русском желании переписать копрокод.
---
Вряд ли начальство вообще в курсе об этом русском желании. Именно поэтому все и говорят об оплате. Если начальство готово платить именно за это - ок. Только надо предупредить, что результат этой работы неизмеряем и незаметен (если все хорошо).
---
Спросил разрешения - ответили что рефакторинг это хорошо. На самом деле не первый год работаю, и все зависит от позиции руководства и степени запущенности кода. В основном нужно вчера, и времени на рефакторинг нет, а иногда даже нет времени чтобы сделать задачу по человечески. Вот и получаем капрокод.
---
кОпро
---
Спасиб за поправочку:)
---
Если заказчик оплатит, то конечно все сделать хорошо. Хотя смысла в этом нет никакого о)
---
Речь о постоянке.
---
постоянная работа это точно такая же работа на заказчика. Только заказчик платит не за результат, а за нахождение сотрудника в офисе. Если заказчик готов оплачивать это заведомо безрезультатное сидение на стуле - ну ему флаг в руки, а исполнителю приятно и с пользой провести время )
---
Ну почему же "безрезультатное"? Выполняя рефакторинг, я, как тут выразился один ГУРУ, устраняю технический долг!
---
ну я и говорю, это можно рассматривать как развитие своих навыков и умений. Все лучше чем в фейсбучеке проводить рабочее время. Если работодатель не против, то ничего плохого в этом нет.
Хотя я бы все же предпочел что-то более функциональное. Все конфигурации 1с написаны плохо, потому что исходные от 1с написаны очень плохо и потом в них еще пихают всякую фигню разные люди, очень часто не очень сильно задумываясь. Лучше все равно не станет, а время потрачено. За то же время можно какой-нибудь сертификат по сиквелу например получить, будет при следующем найме плюс в карьеру.
---
Я слишком стар чтобы сидеть в Фейсбуках.
Развитие навыков работника тоже приносит пользу работодателю.
ПС. Это офф-топ, но меня есть 2 специалиста по 1С. И я заметил что они негативно влияют на мое трудоустройство. Обычно на них смотрят люди, у которых завышенное мнение о соискателе. И моя работа в таких конторах превращается в рабство. ИМХО.
---
сертификаты 1с смысл имеют только для франчей. Думаю, это все понимают.
А вот курсы по базам данных например. Или еще что-то смежное. Это совсем другое дело, можно много полезного узнать.
---
+

https://www.youtube.com/c/PostgresProfessional/featured
---
Можно, но это уже другой уровень. У нас например, это не нужно. Базой данных занимается админ, и более того он даже доступ туда не дает. И я его понимаю, ибо это его зона ответственности.
---
нет,

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

 и как они окажут " Давление " на субд.

а так ваш админ будет искать , что же так сервак повисает, если у него не соответственный уровень .
---
Да, бро:)

Когда я пишу код, я знаю какое давление он окажет на СУБД, и для этого не нужны сертификаты от Мелкософта. Достаточно следовать рекомендациям от фирмы 1С. За исключением, редких случаев.

Ну а админ, как говорится, он и в Африке админ. И проблемы СУБД, в нашем случае, это его проблемы.
---
не хочу вас растроить , но

админ, как говорится, он и в Африке админ. И проблемы СУБД, в нашем случае, это его проблемы.
--- совсем нет, если программист напишет кривой код или тяжелую процедуру ( запрос )

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

возможно ваше представление изменится :)
---
Дружище, у тебя не получится меня расстроить. Я не первый год занимаюсь разработкой, а второй десяток.
Я целенаправленно избегаю работы с высоконагруженными системами, т.к. нервы дороже. А для обычной разработки достаточно знать как работает замер производительности + иметь опыт оптимизации запросов, и программного кода, основанный на рекомендациях кормилицы 1С. Как показывает практика, в большинстве случаев этого более чем достаточно.
Я буду менять свое представление тогда, когда мой путь приведет меня к проблемами с производительностью скуля, которые повесят на меня. Но надеюсь такого никогда не случится, т.к. я уже взрослый и сам выбираю свой путь.
---
Тут правильно один товарищ написал. Не пытайся съесть кусок больше, чем пролезет в глотку. Слишком высок риск смерти от удушья. Грызи понемногу этот код, приводя в порядок структуру алгоритмов и стек вызовов. Потом, как код отдельных функций будет приведен в относительный порядок, то можно задуматься об архитектуре всего модуля/подсистемы или чего там есть в наличии.
---
Умные посоны из забугорья, напридумавшие всяких там аджайлов, скрамов и прочей ереси, говорят, что технический долг - это плохо, поэтому если есть время и силы - нужно от него избавляться, уменьшать его влияние.

НО!

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

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

Вердикт: признай свое поражение сразу.
---
Поддерживаю
в одной процедуре может выполнятся более одного алгоритма совершенно не связанных и тд. и тп.
Есть такая обработка типовая загрузка наполеона в ут11. вот там написано "по правилам" читать и разобраться сходу там невозможно потому что любой алгоритм в отдельной процедуре и читать и понять что происходит там сходу невозможно.
---
потому что любой алгоритм в отдельной процедуре и читать и понять что происходит там сходу невозможно Это называется "хреновый нейминг" процедур. Не более того. А сам подход с "отдельному алгоритму - отдельная процедура" очень даже верный.
---
Ага, только нужно понимать где это нужно а где нет. Если создание файла, заполнение и сохранение выполяется в одном месте, то и нет смысла каждую из операций делить.
---
Еще какой смысл есть! Ибо DRY превыше всего!
---
Так я ж не спроста туда полез. Передо мной стоит задача . Я выполнил анализ. Эти 50 процедур мне придется менять. А там, в каждой из них хаос. Меня смущает перспектива тестирования этого хаоса, и затем, дальнейшей доработки, т.к. с требованиями у начальства не гладко.

А на счет остального кода в конфе - да ехало болело оно мне. Как говорится: "Работает - не трогай":)
---
Иногда проще рядом свое написать...
---
Это мое любимое занятие. Но не в этот раз.
---
Почистите 1 функцию с сохранением предыдущей версии. И недельку посмотрите на результат. Посмотрите что у кого сломается и какая будет реакция общественности. Чистить код - дело благое, но иногда слишком велики риски
---
Чистить код - дело благое, но иногда слишком велики рискиКак показывает моя личная практика, поправить отвалившееся занимает меньше времени, чем переиграть со старыми записями.
---
Но тут же встает вопрос долговечности - что дольше проживет: поправленное отвалившееся или новое капитальное.
---
Такой подход эффективен с точки зрения реакции пользователей и системы. Но совершенно не подходит с точки зрения сроков:)))
---
если есть конкретная задача и сроки - тогда руби, потом надо будет собрать осколки. Возможно сперва предупредить ключевых пользователей. Куда деваться то
---
https://www.facebook.com/plugins/post.php?href=https%3A%2F%2Fwww.facebook.com%2FUskorim1C%2Fposts%2F1602818199917812&show_text=true&wi­dth=500
---
В общем, каждый принимает решение сам, либо следует распоряжению руководителя.
В моем случае, я поступаю следующим образом: те участки кода, которые непосредственно связаны с задачей я подвергаю рефакторингу, если с моей точки зрения он уместен. Остальные участки - не трогаю, чтобы работало:)
Всем спасибо за обсуждение.