Re: [心得] 花了很多時間重構卻被打槍用舊code

※ 引述《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幹

人要跳槽 比起被人抱大腿 抱別人大腿不管是待遇還是精神衛生 都比較香

--

我不知道 我離職前還AB兩個版本都還在雙軌運行 算是開放式結局

你琢磨是重構還是重寫 問題的本質有變嗎 甲

diff佔整個module 80% 跟乙

diff佔整個module 80% 你覺得區別在哪？ 有人會在意你的commit是用什麼方法論嗎 改程式碼就改程式碼 不會因為你給他一個新的名字改變本質

這作法又不是我發明的 關我屁事XD 我入職時就已經是AB雙軌並行了 我從B Team離職前就跟A team主管講了阿 為什麼重構不用局部迭代的方式 他也說不上來阿 就說這是一次錯誤的經驗 原PO內文講的改動幅度我覺得不低啦 所以才舉這個例子 你程式碼差異幅度大到一個程度 本來就會被challenge 你講的小屎逐步翻新那是常規狀況 工作看到就要順便修 有些重構是為了滿足新feature就要整個模組架構跟流程改動的 那種PR一般不會小