作者VScode (VSisBestIDEinTheWorld)
看板Soft_Job
标题[讨论] 重构跟kpi的考量
时间Thu Feb 24 01:13:40 2022
假设以下情境
有个功能A、B都会用到相同逻辑，且有两份重覆的code
(没有unit test保护，而且年久失修 要加入unit test会需要更多时程)
现在要加入C，也会用到相同逻辑
身为合格的工程师 应该会把ABC重覆的部份提取出来
而不是让这逻辑重覆三次
但以公司营运的角度来看 这次专案就只会测试C的部份
不应该动到A、B
这时就要冒着A、B坏掉风险重构，或是因为来不及加入unit test
就乾脆让相同逻辑存在三个地方
身为专业工程师，我很想选择重构
但过去的经验告诉我
绝对要以kpi为最优先考量
於是程式充满了注解、重覆片段
虽然靠着笔记、git log，能还原当时写code的思路
但这些脏code就会永远留存在程式里
想问大家遇到这情况会怎麽做?
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 115.43.126.106 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1645636422.A.77F.html
※ 编辑: VScode (115.43.126.106 台湾), 02/24/2022 01:14:25
1F：→ labbat: 一堆重复程式码以及注解，真的好脏 02/24 01:17
2F：推 acgotaku: 要我一定改,既然改就不要单纯抽离,用clean code层面思考 02/24 01:21
3F：推 devilkool: 为了预防DEFG也用到一样的东西，至少这次写乾净点 02/24 01:23
4F：→ acgotaku: 会这样就代表中间业务逻辑更动了,无法遵循open-closed 02/24 01:24
对 看似重覆 却有一点地方不太一样
5F：推 f496328mm: 考绩只是一时的，继续写烂 code，对职涯发展不好，长期 02/24 01:32
6F：→ f496328mm: 来看就是自废武功 02/24 01:32
我也是这样想 不想为了kpi昧着良心
7F：→ yyc1217: 看你的份量 跟要不要对三个月後的自己好一点 02/24 01:44
这倒是还好 这个地方的code好几年没动了
8F：推 wadechen: If it ain’t brake , don’t fix it 02/24 01:46
9F：→ yyc1217: 至少C要写的话一定会加上unit test 02/24 01:46
10F：→ wadechen: 先把C逻辑的泛用性处理好 之後让A,B可以简单引用又方便 02/24 01:47
11F：→ wadechen: 测试 02/24 01:47
12F：推 wadechen: 大家写久了多少会有洁癖 但出来工作有时候要克制这种洁 02/24 01:51
13F：→ wadechen: 癖 尤其负责的专案越大 协同作战的人又多时 重构的成本 02/24 01:51
14F：→ wadechen: 可能超乎想像 02/24 01:51
是啊 功能复杂的地方要重构 要有很完整的测试
15F：推 wadechen: 我是觉得未来自己写的扣 尽量保持乾净易扩充易读即可 02/24 01:53
16F：推 neo5277: 有钱吗？有就切没有就算了老板不会在意 02/24 01:55
17F：→ angusyu: 没时间就到没看到，又不是你的问题。有时间也要看公司文 02/24 01:58
18F：→ angusyu: 化跟趴数够不够，改了很容易产生副作用，还要不怕被干谯 02/24 01:58
19F：嘘 MoonCode: 重复跟脏有什麽关系？ 02/24 02:01
20F：→ asadman1523: 先看看A、B坏掉你能负责吗... 02/24 02:12
kpi会很惨...
21F：推 MoonCode: 02/24 02:20
22F：推 CoNsTaR: 先让 C 再重复一次，等确认 C 没问题了再来讨论要怎麽重 02/24 03:13
23F：→ CoNsTaR: 构啊 02/24 03:13
24F：推 ctrlbreak: 政治问题 如果出事情你能不能负责 02/24 03:58
25F：推 airtsubasa: 写的乾净没人感激你 前人挖洞 你也一起玩啊 反正专案 02/24 05:40
26F：→ airtsubasa: 也是会轮流的 颗颗 02/24 05:40
27F：嘘 peter98: 工程师搞KPI? 哪间公司啦 说来笑笑 02/24 05:49
28F：推 CoNsTaR: 楼上，Amazon 和 Facebook 平时都是你嘲笑的对象吗？ 02/24 05:55
29F：→ james732: 如果有足够的时间与把握让A B C都正常再说吧 02/24 06:07
30F：→ james732: 原本好好的改坏这个问题有时会非常严重 02/24 06:08
31F：→ james732: 我应该会新增C但预留了日後整合A/B的弹性 02/24 06:09
32F：→ james732: 或者一口气改好但先验证C是OK的再把AB切换过去 02/24 06:10
33F：→ james732: 如果时间不够的话就不要碰AB了把C做好验好就好 02/24 06:13
嗯嗯 我觉得我应该会这样做
等未来要改A B时，再重构A B
34F：嘘 peter98: C大很懂?在哪高就? 02/24 06:16
35F：推 RINPE: 看薪水吧 薪水到位 一切好谈 02/24 06:43
36F：推 Solinarymoon: 先把重复逻辑的地方独立出来给C用并预备给A、B用， 02/24 07:13
37F：→ Solinarymoon: 後续有动到A、B的时候再修改？ 02/24 07:13
目前会这样做
38F：推 del680202: 会问这种问题 就是你的不专业了 02/24 07:39
要如何兼顾专业跟绩效呢?
※ 编辑: VScode (115.43.126.106 台湾), 02/24/2022 08:45:52
39F：→ ericthree: 历史包袱啊 02/24 08:42
40F：→ foreverk: 过去遇到这情况，我先把共用抽出来给C使用，後面有空再 02/24 08:43
41F：→ foreverk: 陆续套上A和B以及各自的unit test，这个逻辑可以套用所 02/24 08:43
42F：→ foreverk: 有你想重构的场景，视情况变化一下而已 02/24 08:43
43F：→ ericthree: 如果团队不想解决 就大家一起放着烂 02/24 08:43
44F：→ foreverk: 多做这件事不一定有钱啦，但是熟练以後时间成本会越来 02/24 08:45
45F：→ foreverk: 越低，久了你就不会再把KPI和clean code放在天秤上衡量 02/24 08:45
46F：→ foreverk: 半天 02/24 08:45
只是这地方可能好几年才动一次
会有一股冲动想一口气弄好
※ 编辑: VScode (115.43.126.106 台湾), 02/24/2022 08:48:18
47F：→ foreverk: 这个风险跟相信我能反杀差不多高，最好别吧 02/24 08:53
48F：→ bheegrl: 你可以考虑做C的时候先把和A、B重复的逻辑各别提出来 02/24 09:20
49F：→ bheegrl: 也就写成C + A~C共用逻辑(假定是两只method) 02/24 09:21
50F：→ bheegrl: 你实际上只用写了C，等以後有人要改A、B时再顺便重构就好 02/24 09:22
51F：→ bheegrl: 这样你概做出弹性来又不用一次性担太多风险 02/24 09:23
52F：→ bheegrl: *既 02/24 09:27
53F：推 LeoSW: 想想看怎麽把重构变成KPI啊 02/24 09:30
54F：推 t64141: 共用部分抽吃来，只有C套用，接着开单做AB重构 02/24 09:39
55F：→ t64141: *抽出来 02/24 09:39
56F：→ ssccg: 你可以把C写成以後DEFG可以用，但先别动AB 02/24 09:56
57F：→ ssccg: 以後真要改AB时也能引用C，是说很可能以後改AB又另一个故事 02/24 09:57
改AB 可能是几年後别人改
这时要把注解写很清楚
哪里重覆 哪里要移去哪里
我觉得也满麻烦的
※ 编辑: VScode (203.67.131.41 台湾), 02/24/2022 10:18:51
58F：→ l8th: 为什麽在这里跟局外人纠结？go talk to your mgr and call a 02/24 10:49
59F：→ l8th: design session. present pros and cons to your team. thi 02/24 10:49
60F：→ l8th: s is a team decision, not yours. 02/24 10:49
61F：推 LIN810116: 有版本跟分支控制不用怕改坏啊 02/24 11:23
62F：推 CoNsTaR: @peter98 敝司某 fortune 20，没有 kpi 不用为我担心 02/24 12:00
63F：→ knives: 现在没有坏的东西，不要没事找事做，有空看ptt不好吗 02/24 14:52
64F：→ lazarus1121: 我之前是用类似蓝绿部属，用一个if控制新旧版本 02/24 15:39
65F：→ lazarus1121: 然後用设定档控制切换，如果发现有错就立刻切回旧版 02/24 15:40
66F：推 sniper2824: 理论上是跟你同事讨论才对 02/24 16:06
67F：→ sniper2824: 但你重构的够好 注解就不用写得像之前那样了不是吗？ 02/24 16:07
重构当然就不用注解了
问题是会冒着其他功能坏掉的风险
68F：推 asleisureto: 等C稳定後再逐渐把AB功能加进去，这期间还是继续用A 02/24 16:10
69F：→ asleisureto: B，稳点来不要一口气直接改AB 02/24 16:10
70F：→ asleisureto: 重构很多时候看你年资跟老板主管挺不挺就是 02/24 16:12
是啊 以更上层的想法 一定是不要坏掉就好了
71F：推 somefatguy: A B不动但rename加上deprecated，并加注解说明请改用 02/24 16:19
72F：→ somefatguy: 重构过的A’ B’。然後抽出共用模组给A’ B’ C用。这 02/24 16:19
73F：→ somefatguy: 样以後的人也知道新功能不要再呼叫旧的A B改用A’ B’ 02/24 16:20
74F：→ somefatguy: 。 02/24 16:20
这个方法不错 都忘了有obsolete attribute可以用
75F：推 enthos: A、B=>AI程式分析软体->AI程式产生器->C.再修改成D 02/24 16:54
76F：推 fantasystar: 把共用的部分复制一份出来，弄好unit tests. 开发 C 02/24 18:07
77F：→ fantasystar: 的时候做好integration tests. A/B 的重构 （改成用 02/24 18:07
78F：→ fantasystar: 之前抽出来的模组）就另外跟 product owner 谈。 02/24 18:07
79F：推 mathrew: C先抽，AB先暂时放着，等有空再改AB 02/24 19:37
80F：→ MonyemLi: 下个看到你程式的会说同样的话，无论你又没有重构 02/24 20:27
81F：→ MonyemLi: 後面有空，不会发生的 02/24 20:29
82F：推 jej: 我会了解这个系统还会多久EOS 02/24 22:12
83F：→ jej: 如果一年内 那就让他臭吧 02/24 22:12
84F：→ jej: 如果还有很长的路要走 当然重构阿 02/24 22:12
85F：→ jej: 软体维护的思绪往往和直觉颠倒 02/24 22:12
86F：→ jej: 今天有3个案例再重复 代表很有大的机会往後也要有 02/24 22:12
87F：→ jej: 你今天不重构 就是往後一直痛下去 02/24 22:12
88F：推 TakiDog: 今天你不重构，痛的是自己，那就重构吧 02/24 22:50
89F：推 jack0204: 问主管阿，主管都不在意的话你在意干嘛 02/24 23:46
90F：→ jack0204: 你可以C额外写一个引入用的，然後去AB的注解写todo 02/24 23:47
主管是不在意啦 他也知道重构影响太大了
91F：推 avril9950: 先说服你主管你们的扣超脏，再继续下去叠床架屋要垮了 02/25 00:31
92F：→ avril9950: ，一直恐吓他到他愿意排时程跟QA让你重构 02/25 00:31
93F：→ viper9709: 这个很标准的就是先抽C,AB等之後有改的时候再接 02/25 00:46
※ 编辑: VScode (115.43.126.106 台湾), 02/25/2022 01:16:28
94F：推 j9d9: 选KPI，长期来说不好， 可以考虑换工作 02/25 08:12
95F：推 anandydy529: 以前我是把AB也换成新的，但有人跟我说没坏的东西为 02/25 10:37
96F：→ anandydy529: 什麽要动，想想也是很有道理 02/25 10:37
97F：推 t64141: 不是没就不能动，是要有计画的修正 02/25 10:47
98F：→ t64141: 开发时先求有再求好，维护时没坏就不动，分开看看 02/25 10:56
99F：→ t64141: 都合理，放在一起常常是悲剧 02/25 10:56
100F：推 youtuuube000: 改了之後有bug客户一直叫然後公司营收受损这样有比 02/25 17:08
101F：→ youtuuube000: 较好吗 02/25 17:08
102F：推 aidansky0989: 他已经烂这麽多年没事，说明并没有重 02/26 00:30
103F：→ aidansky0989: 构的价值 02/26 00:30
104F：→ aidansky0989: 你很闲没事干可以 02/26 00:31
105F：推 xluds24805: 先上 C，写测试。上线确认没问题後再把 A、B 改用 C 02/26 01:38
106F：→ xluds24805: 的新函式 02/26 01:38
107F：推 sunsamy: 建议要入境随俗 02/26 03:58
108F：→ sunsamy: 要不然你会被程度差的码农当成你程度差,来乱的! 02/26 03:59
109F：推 jej: 楼上 那是一时的 本肥年轻时也曾经因此被瞧不起 02/26 08:02
110F：→ jej: 前辈们看到就干谯一次 後来他们不爽公司 离职的离职 02/26 08:02
111F：→ jej: 升迁的升迁 最後剩下要维护的你 继续因为烂code 被逼到离职 02/26 08:02
112F：嘘 pttano: 你应该是菜鸟，两段code的逻辑相同就要重构？ 02/26 11:33
113F：→ f763guy: 愿赌服输，赌输别怨 02/26 14:54
114F：→ yourinfo: 写好C，然後在AB注解就好，以後有人要动AB再改好了 02/26 21:46
115F：→ yourinfo: 有时候花时间做烂了不会有人感谢的，最大限度做好事就好 02/26 21:47
116F：→ daddy29: 再过几年你会发现其实就是自己能力没这麽猛 需要时间多 02/27 01:46
117F：→ MonyemLi: 写详细点，你们怎麽测试的，人工，那你今天改A,B有人测 02/27 19:14
118F：→ MonyemLi: 吗？那就是跟挖个机率坑给主管跳。请上报，一路报上去 02/27 19:14
119F：→ MonyemLi: 。不允许，商业理念与你待着干吗？但时间压力加保守主 02/27 19:14
120F：→ MonyemLi: 义下多半不允许。 02/27 19:14
121F：→ iamshiao: 看你打算在这间待多久 03/02 01:58
122F：推 zenuo: 真的照bheegrl说的是比较合理的做法 不影响kpi又先把架构 03/06 00:08
123F：→ zenuo: 做好但不影响实际功能 03/06 00:08
124F：推 hellophoenix: 你好像我以前的同事，剩没几天要release然後说要 03/14 01:56
125F：→ hellophoenix: 重构 03/14 01:56