這是個大哉問，所以資訊太少的狀況下有點難回答
但我還是試著從工程師的專業面來講這問題好了（先不談管理學或厚黑學XD)
要很簡單的當是非題回答的話，當然是: YES，請重構
一開始需求沒很複雜所以沒設計好是完全正常的
要做到 Design 但又不 Over Design 的精神
就是需求改動撞到問題的時候才重構，對，就是現在
但請不要是全部打掉重練，而是想辦法依據需求擴展該處就好（類似修bug）
我非常喜歡 Modern Web 2018 的一場 Terry Yin 大神的演講
原文連結：https://hackmd.io/c/MW18/%2FefTkc1AFRK-eYdXOOylmfQ
他把這類問題解釋的非常清楚又有趣
我這邊針對你的問題幫你提煉一下重點，但有興趣可以去看看原文
演講中提到 Michael Feather 大師的書
裡面提到重構的五步驟就是
1. 找到改動點
2. 找到測試點
3. 依賴隔離
4. 寫測試
5. 重構＋新測試
而其中最困難的步驟就是：3. 依賴隔離
所以通常爭執點都在這，因為這可大可小
這點指的是，你要先把要改動的點抽離出來
搞清楚他的 input 有誰，output 有誰
最終目標是減少這段"改動點"跟其他人的相依性（解耦）
不要依賴任何神祕的全域變數或外部狀態
而是靠你當下 input 進來的東西就能順利執行，並給出 output
如果有依賴外部系統，例如資料庫
那就把連線用的物件當變數傳進來，而非在裡面自己生成
當然最好也不要有副作用
如果這步驟難度並不太高，你可以先寫個大測試保護好他，再來"抽離"
但如果難度恨天高，要做也只能先把手弄髒、刀開下去了
然後做好後續 code review 與人力測試，確保一切安穩
所以講這麼多才講到重點
重點就是這個抽離的步驟到底有多難，決定你重構要多久
而這時間算出來，配合商業端決策，才能決定你要不要現在做這件事
(重要系統的話遲早要做的，只是是不是現在而已）
至於當你這段程式碼，已經順利解耦之後
一切就回歸到完美的世界了
在只有 input -> 純邏輯 -> output 的時候
重構是很簡單的事了對吧？因為他只剩下
1. 寫測試測原本的邏輯
2. 做你想做的擴展
3. 確保舊測試沒壞
4. 寫新擴展的測試（也可以先4再2）
5. 新擴展的測試也全數通過
完成了，恭喜，世界因為你的努力又更美好了一點
最後聊一下測試這個問題
我想你原文說的歷經很多測試
應該是指線上跑很久沒壞
而不是指他有很完整的 unit/integration test 對吧？
那這其實就是債
沒有被自動測試的 code 就是債，不管你寫的多好
是債遲早就得還，不還還會生利息，除非這系統整個廢掉不用了
利息有的生的快，有的生的慢
生的慢的也就相對不急，可以有空再說
但你現在做的這個 copy 出一份 8.7 成像的 code
等於讓這個債變成 200% 的超級高利貸了，那當然越快還越好