※ 引述《VScode (VSisBestIDEinTheWorld)》之铭言：
: 假设以下情境
: 有个功能A、B都会用到相同逻辑，且有两份重复的code
: (没有unit test保护，而且年久失修 要加入unit test会需要更多时程)
: 现在要加入C，也会用到相同逻辑
: 身为合格的工程师 应该会把ABC重复的部份提取出来
: 而不是让这逻辑重复三次
: 但以公司营运的角度来看 这次专案就只会测试C的部份
: 不应该动到A、B
: 这时就要冒着A、B坏掉风险重构，或是因为来不及加入unit test
: 就干脆让相同逻辑存在三个地方
: 身为专业工程师，我很想选择重构
: 但过去的经验告诉我
: 绝对要以kpi为最优先考量
: 于是程式充满了注解、重复片段
: 虽然靠着笔记、git log，能还原当时写code的思路
: 但这些脏code就会永远留存在程式里
: 想问大家遇到这情况会怎么做?
如果 A, B 都没有任何 tests，建议不要动他。
帮 C 实做这个功能的时候，把 unit test 写好写满，确保 C 是对的
行有余力，针对 A, B 的使用情境也加上 test case，确保未来在 A, B 确实能重用
(这点很重要，否则很容易程式长得很像你以为可以重用，实际上根本不能)
就先做到这样就好，确保 C 的品质，同时你获得了高品质的 reusable 模组
随着时间推演，有几种情况:
1. A, B 的生命周期已经结束，直接淘汰，不用 refactor (这超常发生)
2. A, B 只是在维护修 bug，不会再有新功能，那通常也不值得花时间去弄
但若经常造成 bugs 的地方，正是跟 C 共用的那段程式，
那 refactor 就很有商业价值，长官也不会反对你做。
这种时候 refactor A, B 会变成重要的工作，你就不会没时间做。
Refactor 完毕之后改善多少，就可以变成 Kpi，做起来名正言顺
3. 如果真的发展到有机会 refactor A, B，这时就先帮最主要商业逻辑加上
"大范围" 的 "integration tests" (不用花时间补写 A, B 的 unit tests)
接着把 A, B 重复的逻辑抽换成 C 的 (之前开发 C 已 unit test 过，确保正确)
抽换完毕后，大范围整合测试确认整体行为没改变，就可以收工了
上线后持续监测，万一遇到问题，直接 rollback 回上一版
专业的工程师，在开发的时候也会考虑实务面，以及这些 code 的商业价值，
来决定事情的先后顺序，帮助产品获得成功。
好的外科医师，手术开刀，目标是病人要治好，而不是手术成功，病人死亡。