PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (凱子爸)時間6小時前 (2025/09/14 11:04), 4小時前編輯推噓5(6推 1噓 10→)
留言17則, 9人參與, 4小時前最新討論串2/3 (看更多)
※ 引述《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, 6小時前 , 1F
推
09/14 11:17, 1F
推
09/14 11:33, 5小時前 , 2F
這個故事好眼熟，應該在很多地方發生過
09/14 11:33, 2F
推
09/14 11:35, 5小時前 , 3F
推
09/14 11:35, 3F
推
09/14 11:37, 5小時前 , 4F
XD 看完這鬼故事笑了 但我好奇切換到A module之後是大爆
09/14 11:37, 4F
→
09/14 11:37, 5小時前 , 5F
炸還是真的順利完成迭代
09/14 11:37, 5F
我不知道 我離職前還AB兩個版本都還在雙軌運行 算是開放式結局 ※ 編輯: SkankHunt42 (154.47.23.51 日本), 09/14/2025 11:49:46
→
09/14 12:38, 4小時前 , 6F
那A幹嘛生類似的功能？是因為通通都要用B的程式？
09/14 12:38, 6F
推
09/14 12:52, 4小時前 , 7F
可以強烈建議但不能不說直接做，因為責任是決定的人扛
09/14 12:52, 7F
→
09/14 12:54, 4小時前 , 8F
分兩個版本不是不行，但要想好怎麼做才不會失敗
09/14 12:54, 8F
噓
09/14 12:54, 4小時前 , 9F
你這又不是重構 是重寫 先搞清楚問題在哪==
09/14 12:54, 9F
你琢磨是重構還是重寫 問題的本質有變嗎 甲大刀闊斧重構 diff佔整個module 80% 跟乙大規模重寫 diff佔整個module 80% 你覺得區別在哪？ 有人會在意你的commit是用什麼方法論嗎 改程式碼就改程式碼 不會因為你給他一個新的名字改變本質
→
09/14 12:56, 4小時前 , 10F
我是覺得RD應該要多了解infra相關知識才能避免一些問題
09/14 12:56, 10F
※ 編輯: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:00:52
→
09/14 13:05, 4小時前 , 11F
重構就是要限縮範圍 第一步是把一大坨屎改成許多坨小
09/14 13:05, 11F
→
09/14 13:05, 4小時前 , 12F
屎 再把每一坨屎改正 中間每一步都要有足夠的信心才
09/14 13:05, 12F
→
09/14 13:05, 4小時前 , 13F
能走下去 當然這是理想情況很難完全做到 但你這做法
09/14 13:05, 13F
→
09/14 13:05, 4小時前 , 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, 4小時前 , 15F
等整個東西都99%完成了才要對接 當然就是重寫啊==
09/14 13:06, 15F
→
09/14 13:09, 4小時前 , 16F
有改動AB test不是很正常嗎
09/14 13:09, 16F
推
09/14 13:21, 4小時前 , 17F
我覺得維持兩年換一份工作的良好職涯紀律可以避免這些事
09/14 13:21, 17F
‣ 更多 SkankHunt42 的文章
文章代碼(AID): #1enZ2Zrf (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 SkankHunt42 的文章
文章代碼(AID): #1enZ2Zrf (Soft_Job)