假设以下情境
有个功能A、B都会用到相同逻辑，且有两份重复的code
(没有unit test保护，而且年久失修 要加入unit test会需要更多时程)
现在要加入C，也会用到相同逻辑
身为合格的工程师 应该会把ABC重复的部份提取出来
而不是让这逻辑重复三次
但以公司营运的角度来看 这次专案就只会测试C的部份
不应该动到A、B
这时就要冒着A、B坏掉风险重构，或是因为来不及加入unit test
就干脆让相同逻辑存在三个地方
身为专业工程师，我很想选择重构
但过去的经验告诉我
绝对要以kpi为最优先考量
于是程式充满了注解、重复片段
虽然靠着笔记、git log，能还原当时写code的思路
但这些脏code就会永远留存在程式里
想问大家遇到这情况会怎么做?

一堆重复程式码以及注解，真的好脏

要我一定改,既然改就不要单纯抽离,用clean code层面思考

为了预防DEFG也用到一样的东西，至少这次写干净点

会这样就代表中间业务逻辑更动了,无法遵循open-closed

考绩只是一时的，继续写烂 code，对职涯发展不好，长期来看就是自废武功

看你的份量 跟要不要对三个月后的自己好一点

If it ain’t brake , don’t fix it

至少C要写的话一定会加上unit test

先把C逻辑的泛用性处理好 之后让A,B可以简单引用又方便测试大家写久了多少会有洁癖 但出来工作有时候要克制这种洁癖 尤其负责的专案越大 协同作战的人又多时 重构的成本可能超乎想像我是觉得未来自己写的扣 尽量保持干净易扩充易读即可

有钱吗？有就切没有就算了老板不会在意

没时间就到没看到，又不是你的问题。有时间也要看公司文化跟趴数够不够，改了很容易产生副作用，还要不怕被干谯

重复跟脏有什么关系？

先看看A、B坏掉你能负责吗...

先让 C 再重复一次，等确认 C 没问题了再来讨论要怎么重构啊

政治问题 如果出事情你能不能负责

写的干净没人感激你 前人挖洞 你也一起玩啊 反正专案也是会轮流的 颗颗

工程师搞KPI? 哪间公司啦 说来笑笑

楼上，Amazon 和 Facebook 平时都是你嘲笑的对象吗？

如果有足够的时间与把握让A B C都正常再说吧原本好好的改坏这个问题有时会非常严重我应该会新增C但预留了日后整合A/B的弹性或者一口气改好但先验证C是OK的再把AB切换过去如果时间不够的话就不要碰AB了把C做好验好就好

C大很懂?在哪高就?

看薪水吧 薪水到位 一切好谈

先把重复逻辑的地方独立出来给C用并预备给A、B用，后续有动到A、B的时候再修改？

会问这种问题 就是你的不专业了

历史包袱啊

过去遇到这情况，我先把共用抽出来给C使用，后面有空再陆续套上A和B以及各自的unit test，这个逻辑可以套用所有你想重构的场景，视情况变化一下而已

如果团队不想解决 就大家一起放著烂

多做这件事不一定有钱啦，但是熟练以后时间成本会越来越低，久了你就不会再把KPI和clean code放在天秤上衡量半天这个风险跟相信我能反杀差不多高，最好别吧

你可以考虑做C的时候先把和A、B重复的逻辑各别提出来也就写成C + A~C共用逻辑(假定是两只method)你实际上只用写了C，等以后有人要改A、B时再顺便重构就好这样你概做出弹性来又不用一次性担太多风险*既

想想看怎么把重构变成KPI啊

共用部分抽吃来，只有C套用，接着开单做AB重构*抽出来

你可以把C写成以后DEFG可以用，但先别动AB以后真要改AB时也能引用C，是说很可能以后改AB又另一个故事

为什么在这里跟局外人纠结？go talk to your mgr and call adesign session. present pros and cons to your team. this is a team decision, not yours.

有版本跟分支控制不用怕改坏啊

@peter98 敝司某 fortune 20，没有 kpi 不用为我担心

现在没有坏的东西，不要没事找事做，有空看ptt不好吗

我之前是用类似蓝绿部属，用一个if控制新旧版本然后用设定档控制切换，如果发现有错就立刻切回旧版

理论上是跟你同事讨论才对但你重构的够好 注解就不用写得像之前那样了不是吗？

等C稳定后再逐渐把AB功能加进去，这期间还是继续用AB，稳点来不要一口气直接改AB重构很多时候看你年资跟老板主管挺不挺就是

A B不动但rename加上deprecated，并加注解说明请改用重构过的A’ B’。然后抽出共用模组给A’ B’ C用。这样以后的人也知道新功能不要再呼叫旧的A B改用A’ B’。

A、B=>AI程式分析软件->AI程式产生器->C.再修改成D

把共用的部分复制一份出来，弄好unit tests. 开发 C的时候做好integration tests. A/B 的重构 （改成用之前抽出来的模组）就另外跟 product owner 谈。

C先抽，AB先暂时放著，等有空再改AB

下个看到你程式的会说同样的话，无论你又没有重构后面有空，不会发生的

我会了解这个系统还会多久EOS如果一年内 那就让他臭吧如果还有很长的路要走 当然重构阿软件维护的思绪往往和直觉颠倒今天有3个案例再重复 代表很有大的机会往后也要有你今天不重构 就是往后一直痛下去

今天你不重构，痛的是自己，那就重构吧

问主管阿，主管都不在意的话你在意干嘛你可以C额外写一个引入用的，然后去AB的注解写todo

先说服你主管你们的扣超脏，再继续下去叠床架屋要垮了，一直恐吓他到他愿意排时程跟QA让你重构

这个很标准的就是先抽C,AB等之后有改的时候再接

选KPI，长期来说不好， 可以考虑换工作

以前我是把AB也换成新的，但有人跟我说没坏的东西为什么要动，想想也是很有道理

不是没就不能动，是要有计画的修正开发时先求有再求好，维护时没坏就不动，分开看看都合理，放在一起常常是悲剧

改了之后有bug客户一直叫然后公司营收受损这样有比较好吗

他已经烂这么多年没事，说明并没有重构的价值你很闲没事干可以

先上 C，写测试。上线确认没问题后再把 A、B 改用 C的新函式

建议要入境随俗要不然你会被程度差的码农当成你程度差,来乱的!

楼上 那是一时的 本肥年轻时也曾经因此被瞧不起前辈们看到就干谯一次 后来他们不爽公司 离职的离职升迁的升迁 最后剩下要维护的你 继续因为烂code 被逼到离职

你应该是菜鸟，两段code的逻辑相同就要重构？

愿赌服输，赌输别怨

写好C，然后在AB注解就好，以后有人要动AB再改好了有时候花时间做烂了不会有人感谢的，最大限度做好事就好

再过几年你会发现其实就是自己能力没这么猛 需要时间多

写详细点，你们怎么测试的，人工，那你今天改A,B有人测吗？那就是跟挖个机率坑给主管跳。请上报，一路报上去。不允许，商业理念与你待着干吗？但时间压力加保守主义下多半不允许。

看你打算在这间待多久

真的照bheegrl说的是比较合理的做法 不影响kpi又先把架构做好但不影响实际功能

你好像我以前的同事，剩没几天要release然后说要重构