这是个大哉问，所以资讯太少的状况下有点难回答
但我还是试着从工程师的专业面来讲这问题好了（先不谈管理学或厚黑学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% 的超级高利贷了，那当然越快还越好