※ 引述《VScode (VSisBestIDEinTheWorld)》之铭言：
: 假设以下情境
: 有个功能A、B都会用到相同逻辑，且有两份重复的code
: (没有unit test保护，而且年久失修 要加入unit test会需要更多时程)
: 现在要加入C，也会用到相同逻辑
: 身为合格的工程师 应该会把ABC重复的部份提取出来
: 而不是让这逻辑重复三次
: 但以公司营运的角度来看 这次专案就只会测试C的部份
: 不应该动到A、B
: 这时就要冒着A、B坏掉风险重构，或是因为来不及加入unit test
: 就干脆让相同逻辑存在三个地方
: 身为专业工程师，我很想选择重构
: 但过去的经验告诉我
: 绝对要以kpi为最优先考量
: 于是程式充满了注解、重复片段
: 虽然靠着笔记、git log，能还原当时写code的思路
: 但这些脏code就会永远留存在程式里
: 想问大家遇到这情况会怎么做?
我觉得有个盲点就是 重复程式码的逻辑
我的经验是在需求还没稳定前
一样的程式码复制到不同地方才是最佳解
你根本不知道什么时候 某个地方要用的逻辑不同 一但要改写的逻辑不通
你就会被共用的程式码卡住
就如你提到的案例 你只能砍掉重写
不然你就要很痛苦的把问题解决这时你就会写出 共用的难以维护的程式码 ，这反而比重复程式码还糟糕，看了很痛苦要改还要花大量时间 测试哪边会坏掉
另一种方式就是 C 不要共用的程式码 独立写一份
之后找时间把 共用程式码放回AB
你这样反而会干净很多 通常能拆出去的程式码是无属性的
不然只是目前刚好有一样的逻辑 而不是可以共用的程式码