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

Ну а по факту там куча вопросов: Скорость, задействование внешних сервисов, переписывание в случае перехода на другой язык и т.д.

Да и просто если баги есть. Ведь тут говорили о запрете трогать вообще, как я понял. Такой запрет может быть, когда есть большие вопросы к техническим навыкам программиста/ов, которые туда могут залезть. Это как раз понятно... И это один из тех частных случаев о которых я говорил.

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

> ставит бизнес, и если задача хорошо поставлена,

в мире розовых пони и единорогов

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

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

Ну трогать это не всегда переписывать.

мм, а что еще?

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

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

Если 0, то незачем, конечно

для бизнеса может быть 0, хотя казалось бы ты скажем в 10 раз ускорил что либо или в 100 раз уменшил потребление памяти

Тогда это не ноль, особенного когда он платит за память, жёсткие и т.д.

@tig_ran вы подходите очень узко к концепции "работает - не трожь". В вашем понимании, как я понял - это "удволетворяет потребностям - не трожь". Это разные понятя. Но давайте рассмотри ваш вариант...
У вас есть метод А, который делает Х. Рядом сделали метод Б, который скопипастил 90% метода А, но он делает Y. Внимание вопрос: Надо-ли выносить 90% из метода Б и Z% из метода А в метод В?

По вашей логике - нет.

Зависит от...

Вот )) Это значит что бывают ситуации, когда "работает не трожь" - не работает. Следовательно аксимотичность принципа под вопросом. Я это и пытаюсь доказать.

Мне достаточно предоставить хотя-бы один кейс когда правило не соблюдается в этом споре просто.

Я пока не спорю, я просто ответил на вопрос. :)

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