Re: [心得] 花了很多時間重構卻被打槍用舊code
看板Soft_Job (軟體人)作者SkankHunt42 (凱子爸)時間1月前 (2025/09/14 11:04)推噓14(15推 1噓 17→)留言33則, 22人參與討論串2/12 (看更多)
※ 引述《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 (日本)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1757819043.A.D69.html
※ 編輯: SkankHunt42 (146.70.205.94 日本), 09/14/2025 11:05:00
推
09/14 11:17,
1月前
, 1F
09/14 11:17, 1F
推
09/14 11:33,
1月前
, 2F
09/14 11:33, 2F
推
09/14 11:35,
1月前
, 3F
09/14 11:35, 3F
推
09/14 11:37,
1月前
, 4F
09/14 11:37, 4F
→
09/14 11:37,
1月前
, 5F
09/14 11:37, 5F
我不知道 我離職前還AB兩個版本都還在雙軌運行 算是開放式結局
※ 編輯: SkankHunt42 (154.47.23.51 日本), 09/14/2025 11:49:46
→
09/14 12:38,
1月前
, 6F
09/14 12:38, 6F
推
09/14 12:52,
1月前
, 7F
09/14 12:52, 7F
→
09/14 12:54,
1月前
, 8F
09/14 12:54, 8F
噓
09/14 12:54,
1月前
, 9F
09/14 12:54, 9F
你琢磨是重構還是重寫 問題的本質有變嗎
甲大刀闊斧重構 diff佔整個module 80%
跟乙大規模重寫 diff佔整個module 80%
你覺得區別在哪？ 有人會在意你的commit是用什麼方法論嗎
改程式碼就改程式碼 不會因為你給他一個新的名字改變本質
→
09/14 12:56,
1月前
, 10F
09/14 12:56, 10F
※ 編輯: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:00:52
→
09/14 13:05,
1月前
, 11F
09/14 13:05, 11F
→
09/14 13:05,
1月前
, 12F
09/14 13:05, 12F
→
09/14 13:05,
1月前
, 13F
09/14 13:05, 13F
→
09/14 13:05,
1月前
, 14F
09/14 13:05, 14F
這作法又不是我發明的 關我屁事XD
我入職時就已經是AB雙軌並行了
我從B Team離職前就跟A team主管講了阿 為什麼重構不用局部迭代的方式
他也說不上來阿 就說這是一次錯誤的經驗
原PO內文講的改動幅度我覺得不低啦 所以才舉這個例子
你程式碼差異幅度大到一個程度 本來就會被challenge
你講的小屎逐步翻新那是常規狀況 工作看到就要順便修
有些重構是為了滿足新feature就要整個模組架構跟流程改動的
那種PR一般不會小
※ 編輯: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:13:05
→
09/14 13:06,
1月前
, 15F
09/14 13:06, 15F
→
09/14 13:09,
1月前
, 16F
09/14 13:09, 16F
推
09/14 13:21,
1月前
, 17F
09/14 13:21, 17F
推
09/14 17:07,
1月前
, 18F
09/14 17:07, 18F
→
09/14 17:22,
1月前
, 19F
09/14 17:22, 19F
→
09/14 21:04,
1月前
, 20F
09/14 21:04, 20F
→
09/14 21:18,
1月前
, 21F
09/14 21:18, 21F
推
09/15 00:25,
1月前
, 22F
09/15 00:25, 22F
推
09/15 03:30,
1月前
, 23F
09/15 03:30, 23F
推
09/15 11:17,
1月前
, 24F
09/15 11:17, 24F
推
09/15 11:18,
1月前
, 25F
09/15 11:18, 25F
→
09/15 11:18,
1月前
, 26F
09/15 11:18, 26F
→
09/15 11:19,
1月前
, 27F
09/15 11:19, 27F
→
09/15 11:20,
1月前
, 28F
09/15 11:20, 28F
推
09/15 12:45,
1月前
, 29F
09/15 12:45, 29F
→
09/15 17:08,
1月前
, 30F
09/15 17:08, 30F
推
09/16 16:04,
1月前
, 31F
09/16 16:04, 31F
推
09/16 23:08,
1月前
, 32F
09/16 23:08, 32F
推
09/18 19:56,
1月前
, 33F
09/18 19:56, 33F
討論串 (同標題文章)
完整討論串 (本文為第 2 之 12 篇)：
Soft_Job 近期熱門文章
PTT職涯區 即時熱門文章
133
316
69
171