作者 SkankHunt42 (凱子爸)標題 Re: [心得] 花了很多時間重構卻被打槍用舊code時間 Sun Sep 14 11:04:01 2025
※ 引述《kingofsdtw (塔綠班)》之銘言：
: 最近案子快收尾在收斂bug
: 身為救援大隊長的老人我被指派到維護一個很老的API
: 老API的設計已經無法滿足擴充需求
: 新的擴充功能造成BUG
: 於是我花了大量時間甚至debug到天亮甚至請無薪假
: 新的API經過我反覆測試各種case都完美無缺
: 但是code review卻被質疑:
: 1. 是不是沒找到root cause
: 2. 幹嘛改動如此大? 只不過新加一點點功能幹嘛改架構?
: 心中五味雜陳...
: 好歹我也是coding master，我說該重構了就是該開始還技術債了
: 更上頭還是希望用最鴕鳥的方法繼續用舊架構一堆workaound當作root cause
: 是該離職了嗎? QwQ
分享我遇過的鬼故事
某公司裡面有A team跟B team
B team負責維護的是一個堪稱屎山等級的legacy code
A team覺得B team維護的程式碼真他媽臭 隔了一個module都能聞到臭味
花費了半年多 去寫了一個跟功能99%像的程式碼 然後也有unit tests
現在問題來了 A team有沒有要release他的傑作
答案是 沒有
因為A team也沒有勇氣 原本B team的程式碼雖然屎 但是整個產品的核心
一旦錯 客戶的機子不work FAE等著被幹 (而且A team也不熟B team業務)
所以A team又搬出了一個天才的做法 說那我們就在軟體中同時執行AB兩個版本
只要AB兩個版本結果不同 我們就能收集到錯誤case
這樣方法搞了兩三年 AB team每天都在忙著找 這個錯誤case到底是哪個版本的錯
因為誰跟你講legacy code 沒有bug?
B team還是最熟這個feature的邏輯的人 所以基本上也都是B team在處理
幾年過去後 A team的版本落地了嗎？還是沒有
但A team決定先剪綵 說：「我們要把這個新版本正式交接給B team」
B team接不接 B team心想 幹0糧我接個雞巴毛
但B team還是接了 因為開發部門的總主管是A team的
從這個鬼故事 我覺得有三種層級的經驗可以學習
1. 有unit test比沒有unit test好 但你的unit test是先射箭再畫靶嗎
你的test case能反映真實的使用狀況嗎
2. 這個module的owner到底是誰 誰平常要幫忙擦屁股
3. 你主管是誰 誰授意你去執行重構
這個三層級的經驗中 實作只是最淺的那層 也是最不重要的那層
就算你能夠證明你的程式碼是對的 只要問題2 owner不是你 owner不可能接受
因為平常是他要擦屁股
但是在這個鬼故事中 最重要的是問題3
因為A team的主管最大 B team人微言輕 所以問題2跟問題1就顯得更微不足道
只要你政治實力夠強大 懶覺要塞誰嘴裡就塞誰嘴裡
反正永遠都有需要這份工作的人
所以軟體板到底要不要重構的月經文 頻率越來越少 大家越來越懶得吵
因為幹了幾年就發現 程式碼問題最小 人問題最大
況且誰能夠證明自己的程式碼是對的 你會寫形式化證明嗎
會寫形式化證明也不會待在這種鳥公司
然後test 100%綠燈反對的人還是會說"又沒有涵蓋100%真實案例"
阿他是在槓嗎 是阿 但人家講的也有道理阿
所以吵這個沒完沒了 最後還是在炒 誰擦屁股 你主管是誰
※
可能有人以為我是那種"程式碼好好的就不要去動他"的人
啊我自己是很喜歡重構啦 以前不是被派去救火 就是跟主管提案重構然後升等加薪
只是現在公司的程式碼大家都寫得比我好 我的code反而最屎的 每天被AI幹
人要跳槽 比起被人抱大腿 抱別人大腿不管是待遇還是精神衛生 都比較香
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 146.70.205.94 (日本)
※ 作者: SkankHunt42 2025-09-14 11:04:01
※ 文章代碼(AID): #1enZ2Zrf (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1757819043.A.D69.html
※ 同主題文章:
Re: [心得] 花了很多時間重構卻被打槍用舊code
09-14 11:04 SkankHunt42
※ 編輯: SkankHunt42 (146.70.205.94 日本), 09/14/2025 11:05:00
推 mozume: 這個故事好眼熟，應該在很多地方發生過2F 09/14 11:33
推 kurtsgm: XD 看完這鬼故事笑了 但我好奇切換到A module之後是大爆炸還是真的順利完成迭代4F 09/14 11:37
我不知道 我離職前還AB兩個版本都還在雙軌運行 算是開放式結局
※ 編輯: SkankHunt42 (154.47.23.51 日本), 09/14/2025 11:49:46
→ fgh81113: 那A幹嘛生類似的功能？是因為通通都要用B的程式？6F 09/14 12:38
推 jack0204: 可以強烈建議但不能不說直接做，因為責任是決定的人扛分兩個版本不是不行，但要想好怎麼做才不會失敗7F 09/14 12:52
你琢磨是重構還是重寫 問題的本質有變嗎
甲
大刀闊斧重構 diff佔整個module 80%
跟乙
大規模重寫 diff佔整個module 80%
你覺得區別在哪？ 有人會在意你的commit是用什麼方法論嗎
改程式碼就改程式碼 不會因為你給他一個新的名字改變本質
→ jack0204: 我是覺得RD應該要多了解infra相關知識才能避免一些問題10F 09/14 12:56
※ 編輯: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:00:52
→ lturtsamuel: 重構就是要限縮範圍 第一步是把一大坨屎改成許多坨小屎 再把每一坨屎改正 中間每一步都要有足夠的信心才能走下去 當然這是理想情況很難完全做到 但你這做法跟理想情況也差太多？11F 09/14 13:05
這作法又不是我發明的 關我屁事XD
我入職時就已經是AB雙軌並行了
我從B Team離職前就跟A team主管講了阿 為什麼重構不用局部迭代的方式
他也說不上來阿 就說這是一次錯誤的經驗
原PO內文講的改動幅度我覺得不低啦 所以才舉這個例子
你程式碼差異幅度大到一個程度 本來就會被challenge
你講的小屎逐步翻新那是常規狀況 工作看到就要順便修
有些重構是為了滿足新feature就要整個模組架構跟流程改動的
那種PR一般不會小
※ 編輯: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:13:05
→ lturtsamuel: 等整個東西都99%完成了才要對接 當然就是重寫啊==15F 09/14 13:06
推 gino0717: 我覺得維持兩年換一份工作的良好職涯紀律可以避免這些事17F 09/14 13:21
→ MoonCode: 有測試是要先針對舊系統寫 再來新系統測試19F 09/14 17:22
→ lucky4283: A team是不是太閒，還有時間做重複的功能20F 09/14 21:04
→ xam: 可以考慮job rotation吧.. 看是搬一些人過去或是兩team互換21F 09/14 21:18
推 marra: 故事好聽，給讚！^_^23F 09/15 03:30
推 CRPKT: 重構有具體定義的啦，你要能確保行為不改變才是重構24F 09/15 11:17
→ CRPKT: 很多時候靠既有手段重構無法走到你想要的地方
那個時候跳一小步就已經是重寫了，重寫很正常
是不用太糾結名詞，但的確太多人重寫都說自己在重構26F 09/15 11:18
--