作者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/m.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