作者leo5916267 (封膜猎人)
看板Soft_Job
标题Re: [讨论] 重构跟kpi的考量
时间Sun Feb 27 00:32:59 2022
※ 引述《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
你这样反而会乾净很多 通常能拆出去的程式码是无属性的
不然只是目前刚好有一样的逻辑 而不是可以共用的程式码
--
Sent from nPTT on my iPhone SE (2 Gen)
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.233.146.252 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1645893181.A.443.html
1F：→ Gaitz: 这麽说来你们会在所谓的需求稳定後，停下来大规模的重写重 02/27 01:10
2F：→ Gaitz: 构改好架构？还是最後根本没有时间而且又要开发新需求，然 02/27 01:10
3F：→ Gaitz: 後说需求没有稳定？永远没有做好？ 02/27 01:10
4F：→ Gaitz: 有新需求会被共用的地方卡住这件事听起来很奇怪，觉得单一 02/27 01:14
5F：→ Gaitz: 责任原则没有做好。 02/27 01:14
6F：嘘 accessdenied: 不赞成。初期就这样做，只会遗留一大堆90%相似只有1 02/27 01:16
7F：→ accessdenied: 0%客制的程式码，然後未来修改，只敢全文搜索 find 02/27 01:16
8F：→ accessdenied: replace 02/27 01:16
9F：→ accessdenied: 而且，一旦分开管理，我保证没人有勇气统整回来 02/27 01:17
10F：推 xenorock: 我看法同楼上，没有先Design好，分割完全，全部搞在一起 02/27 01:27
11F：→ xenorock: 後面有的痛苦 02/27 01:27
12F：→ t64141: 初期到处贴你要有把握後期能整理，不然後面维护的人就会 02/27 01:33
13F：→ t64141: 变下一个原原po，很容易恶性循环的 02/27 01:33
14F：→ t64141: 至於被共用卡住的问题，遇到特例难以扩充再另外实作就好 02/27 01:37
15F：→ t64141: ，维护时因为特例而重复比初期就到处贴的副作用小多了 02/27 01:37
16F：推 MyNion: 我觉得你会被卡住，就代表一开始方法＆功能就没拆好了 02/27 02:23
17F：推 MyNion: 将程式模组化，增添弹性的接口供外部呼叫 02/27 02:25
18F：→ MyNion: 如果这样还不行，那就代表从一开始这两者就毫无相同之处 02/27 02:29
19F：→ MyNion: 本来就要分开写了 02/27 02:29
20F：→ TakiDog: 程式码要增加很容易，要减少太难，那为何一开始不规划好 02/27 02:39
21F：→ labbat: 本来只要做加法函数，结果做成通用算数函数 02/27 03:06
22F：→ labbat: 不如一开始就设计通用算数函数 改坏了也只是大家一起坏掉 02/27 03:09
23F：推 geroge0820: 推文完全文不对题... 重点是需求还不稳定这件事吧 02/27 03:14
24F：推 wulouise: 可以共用的code怎麽可能会大到需求改变就一堆特例 02/27 09:40
25F：→ wulouise: 通常都是srp没处理好才在怕改A错B 02/27 09:41
26F：嘘 handsomeLin: 如果会有发现重复code然後还复制贴上的话就是design 02/27 11:28
27F：→ handsomeLin: 不行 02/27 11:28
28F：嘘 kkes0001: 绝对不要这样做 02/27 11:48
29F：→ foreverk: 会被共用程式码卡住，就代表没抽乾净，应该要去厘清逻 02/27 13:42
30F：→ foreverk: 辑，而不是跑去贴一堆重复code然後事後才要处理吧，本 02/27 13:42
31F：→ foreverk: 末倒置 02/27 13:42
32F：→ foreverk: 会觉得要花大量时间测试，就代表一开始你就没有写好uni 02/27 13:44
33F：→ foreverk: t test 02/27 13:44
34F：→ srwhite: 反了吧应该先写一起等真的有不同要复制再复制啊 02/27 13:50
35F：→ t64141: 需求不稳定不是重点，一开始到处复制，需求变化过程要改 02/27 14:46
36F：→ t64141: 就已经需要到处翻找了，即使等需求确定後也是要面临重构 02/27 14:46
37F：→ t64141: 的问题，万一届时已经上线更悲剧 02/27 14:46
38F：→ neo5277: 这篇是用接案公司的想法出发写MVP的时候吧? 02/27 15:17
39F：推 viper9709: 对系统还不够了解时,这才是比较实用的+1 02/28 00:08
40F：推 Nonsense8: 楼主没说错，这适用於未上线的专案，如果老板在开发中 02/28 10:19
41F：→ Nonsense8: 要求大改，主管有责任争取上线後重构时间。甚至需求大 02/28 10:19
42F：→ Nonsense8: 改也不是老板的责任，尤其市场上没有其他竞品可以参考 02/28 10:19
43F：→ Nonsense8: 时，才会不时在开发中更改需求 02/28 10:19
44F：→ Nonsense8: 但原文的情境应该是上线後营运很久的专案，就不适合这 02/28 10:21
45F：→ Nonsense8: 种作法了 02/28 10:21