|
![]() |
#1 |
NavAx
|
Цитата:
короче ремонтировать данный костыль а не программировать новый
учитывая, что по результату работы логов новый костыль отдавал на 100% корректные данные? зачем мучить старый костыль, развейте мысль
__________________
"Моей лошадке ядрышком полмордочки снесло..." А.В.Суворов, письма к дочери |
|
![]() |
#2 |
Участник
|
Ну хотя бы вот по каким причинам:
насколько я понимаю кусок периодически нерабoтающего кода ("старый костыль") - не Ваш customizing а родом из какого-то AddOn'a третьей конторы (инкадеа или что другое). Допустим у клиента опять возникла проблема со складом, он обращается в суппорт, в суппорте смотрят: ага, затронут процесс привязки user&location который является частью AddOn'a от инкадеа и отсылают в суппорт этой конторы (инкадеа). Программист из инкадеа начинает анализировать и натыкается на то место, где инкадеевский код закомментен Вами и земенен Вашим кодом ==> программист из инкадеа умывает руки, дескать, мы здесь не причём и суппорт-вопрос возвращается в Вашу контору. Или другой случай: инкадеа выпустила обнобление по своему АddOn'у, в котором теперь, например, костыль исправлен, или костыль расширен на доп. функционал -> что, будете, дублировать доп. функционал в Вашу SingleInstance-CU? A если это обновление клиенту заливаете не Вы а другой программист (Вы в отпуске и Вас временно замещает например какой-нибудь Сергей ![]() |
|