作者peanut97 (丁守中)
看板Soft_Job
标题[讨论] 前人的code 後人翻写的机率高吗?
时间Mon Sep 24 20:43:19 2018
大家中秋节快乐，快收心了。
想问一个假设性问题，大家在工作上，如果有一份专案的 code 是某位前人一手写的
後来新人加入，变成前人带新人，此时继续维护那份code。
但再过一阵子，前人离职了，唯一的创始者走了。
新人把旧 code 重构，或是砍掉重链的机率高吗？
我的想像是，如果一份code是出自於1个人之手
那麽code就是他的世界观、他的切入点
後面的人看着他的世界观，有时候不一定能全部接受
而有人的地方就有政治
当他还在的时候，当然就不会乱动。
而当他走了的时候，後面的人，一看不爽，就可能改写成自己看得爽的、
好改的code。
如果是一个团队，那当然要好好讨论为什麽要改
哪些因素造成现在不好的情况，以及主管同不同意改等等的。
只是我很好奇，1,2人的专案，改的机率高吗？
是不是，code只能是「现在还存在公司的人」能控制的才行。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 124.6.15.211
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1537793002.A.FC8.html
1F：推 Dnight: 重构的好处在那里，有比重构完整个系统坏掉的风险高吗 09/24 20:46
2F：→ Dnight: 就算系统重构好可以正常行为，重构花掉的成本算谁的 09/24 20:46
所以大大的经验是 东西没坏 就不要乱重构吗？
※ 编辑: peanut97 (124.6.15.211), 09/24/2018 20:48:15
3F：推 xxtuoo: 想改就改啊..不过我碰到的都是新人装死..懒得改..责任推给 09/24 20:48
4F：→ xxtuoo: 前人XDD 09/24 20:48
5F：推 Dnight: 不是说不要乱重构，你重构的好处要大於重构的成本跟风险 09/24 20:49
6F：→ Dnight: 不然你只是看不顺眼就重构，对之後维护没有特别帮助 09/24 20:50
我知道要看目的，以及成本~ 是想问最後结果会重构的机率高不高XD 八卦一下
7F：→ dalconan: 一般来说，要重构通常是要加需求但是改不动了只好重构 09/24 20:54
8F：→ dalconan: 前人有时候规划时写太死，或是架构只有规划的人懂，後人 09/24 20:54
9F：→ lucky1lk: 要看成本阿 09/24 20:55
是的~ 但想问最後结果是会还是不会XD
10F：→ dalconan: 维护起来太困难就会打掉重写（小公司可能两三年就一个轮 09/24 20:55
11F：→ dalconan: 回 09/24 20:55
感谢回应
※ 编辑: peanut97 (124.6.15.211), 09/24/2018 20:56:43
12F：→ t64141: 我的切入点是重构减少未来的维护成本 09/24 20:56
13F：→ t64141: 漏字，减少未来多少的维护成本 09/24 20:56
※ 编辑: peanut97 (124.6.15.211), 09/24/2018 20:57:54
14F：→ t64141: 但这得要你老板有技术背景听得懂，或是非常信任你 09/24 20:57
15F：推 CGS0: 如果没问题的 code ，重写代表要重测 ，能保证重写的更好吗 09/24 20:57
16F：→ CGS0: ？ 09/24 20:57
17F：推 clamperni: 讲得出来怎麽改善就改阿 比较怕改完只有风格变了而已 09/24 20:57
18F：→ MOONY135: 高不高看时间有没有给你 同时新需求跟重构你赶得上吗 09/24 20:59
19F：推 frog79110: 自己偷偷开一个分支改阿XD 09/24 21:00
20F：推 doranako: 要看，重构花时间成本，老板不一定愿意让你做，除非有 09/24 21:03
21F：→ doranako: 要加几个大功能或效能改进 09/24 21:03
22F：→ doranako: 尤其前人写的很少会有test case 09/24 21:05
23F：→ MOONY135: 我比较机车 第一款出来之後接着改版UI 然後我觉得我写的 09/24 21:08
24F：→ MOONY135: 很烂所以我多要了一个月砍掉重写 但我没说我全部砍掉重 09/24 21:08
25F：→ MOONY135: 来 09/24 21:08
26F：→ pttworld: 通常翻写是换语言，十年以上历史 09/24 21:22
27F：推 yamakazi: FLAG之流的公司 平均年资也是三到五年 难不成这些公司每 09/24 21:23
28F：→ yamakazi: 三到五年就重构吗 09/24 21:23
29F：→ pttworld: 另外一个人只背一个案子真是太幸福了 09/24 21:23
30F：→ alog: 重构是有工时跟时间成本的 不是你爱干嘛就干嘛XD 09/24 21:24
31F：推 alog: 开这条战线出来你要hold住 不然你没弄好大概变战犯 09/24 21:26
32F：推 alog: 而且很多时候除了设计上要做改善或改良，为了求未来稳定或要 09/24 21:28
33F：→ alog: 完整输入出结果不会因为重构影响 还会有很多test要测 09/24 21:28
34F：推 atpx: 看重要性, 越重要越不可能随便重购 09/24 21:29
35F：推 alog: 如果你的问题只是coding style的问题 就看怎麽拿捏 因为在 09/24 21:30
36F：→ alog: 少人团队还是会专注於解决当下问题 09/24 21:30
37F：→ atpx: 主管宁愿多花几倍成本作测试也不会承担重构坏掉风险 09/24 21:30
38F：→ alog: 重构要长期维护跟遇到真实的瓶颈或遇到设计、扩充上的问题才 09/24 21:30
39F：→ alog: 会动刀 09/24 21:30
40F：→ alog: 一个系统的核心程式非常多 你重构几个小部分是没有意义的 09/24 21:31
41F：→ galic: 有一本书 叫做clean code，可以看看 09/24 21:36
42F：嘘 smallcar801: 正常智商的老板不会让你这样干 09/24 22:06
43F：推 lovebridget: 干嘛翻 花自己时间耶 又不是自己公司 09/24 22:38
44F：推 y3k: 除非有重大瑕疵 否则公司又不是做艺术品 当时没做好的就没做 09/24 22:42
45F：→ y3k: 好 像那种程式後面常常会被讲是黑盒子XDD 09/24 22:42
46F：→ fgkor123: 韧体 重构和porting 前人吃过的硬体屎 还要吃一遍... 09/24 22:58
47F：推 chia7712: 对一个已经上production的系统而言，重构跟重新投胎有87 09/24 22:58
48F：→ chia7712: %像... 09/24 22:58
49F：→ fgkor123: 专案数千声音 分类+隐藏规格数十 跨三家IC i/o硬体会错 09/24 23:02
50F：→ fgkor123: 都开卖罗。就问谁敢重构QQ 09/24 23:03
51F：→ MOONY135: 我一介小小打工仔 还是pass 09/24 23:15
52F：推 uller: 有问题谁背 时间太多吗 我会叫你去弄新专案 09/24 23:38
53F：→ uller: 每次离职 code就要重搞 公司又不是疯了 09/24 23:39
54F：→ disk249: 很多时候就算你有实力重改，也因为上面的决定无法重做 09/24 23:43
55F：推 bug147123: 会先写好测试再来谈重构 09/25 00:09
56F：推 Masakiad: 我们team机率是很高啦，前人留下太多债，现在碰到很多 09/25 00:41
57F：→ Masakiad: 评估再加功能会边难以测试的架构，所以常常重构。 09/25 00:41
58F：→ pooznn: 这是政治问题 老板87%不会同意花钱 花时间 做同样的东西 09/25 01:18
59F：→ pooznn: 你的直属长官更不会同意重写 因为这证明以前他走错方向了 09/25 01:19
60F：推 Ghamu: 一般是从小做起 摸到的部分开始一点一点重构 而不是 「我他 09/25 01:26
61F：→ Ghamu: 妈要重构全部程式啦！」这样吧 09/25 01:26
62F：推 jackylu63: 我负责的code + 我看不爽 = 翻 09/25 06:28
63F：推 Killercat: 翻写ok 但是我经验是，不要有一种自己的优越心态去面对 09/25 08:16
64F：→ Killercat: 这种code，很多看起来很诡异的workaround都是因为前人 09/25 08:16
65F：→ Killercat: 碰过某些难以越过的困难才这样做 09/25 08:16
66F：→ Killercat: 这些困难也许是其他系统造成的 也许真的是一开始就长歪 09/25 08:17
67F：→ Killercat: 也许现在也不存在，总之，别太狂战士 09/25 08:18
68F：→ qss05: 除非你能在维持正常工作的情况下还能重写，不然老板干嘛让 09/25 09:36
69F：→ qss05: 你花很长的时间停摆现有工作，只为了让你改你觉得不好的东 09/25 09:36
70F：→ qss05: 西?这种要嘛是流程已经大改，可是前面的人偷懒用很迂回的 09/25 09:37
71F：→ qss05: 方式一直加垃圾，要嘛就是现有方法已经没办法更新新需求或 09/25 09:37
72F：→ qss05: 是你的专案重要性不高，不然通常就加减用。除非你能力真的 09/25 09:37
73F：→ qss05: 很好，超越了你前面的所有人… 09/25 09:37
74F：→ bobju: 手上多少资源做多少事 吃饱太闲才会想要改改改 09/25 10:44
75F：→ bobju: 改不是当下爽就好 要有引发後续种种连动议题的心理准备 09/25 10:46
76F：→ bndan: 时间成本问题 除非有特定原因 EX:想逃避面对旧CODE出的问题 09/25 13:03
77F：→ bndan: 或是"期望公司能更上一层楼"等 不然我想像不到"推翻"旧CODE 09/25 13:04
78F：→ bndan: 的动机..= =a 09/25 13:04
79F：推 jonyig: 看成本啊 09/25 19:28
80F：嘘 KanzakiHAria: Test Case全pass想怎麽改谁管你 09/26 07:52
81F：推 banqhsia: 回楼上，会有这种code，通常也不会做 testing ... 09/26 11:39