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

看板Soft_Job (軟體人)作者 (凱子爸)時間3周前 (2025/09/14 11:04), 3周前編輯推噓14(15117)
留言33則, 22人參與, 2周前最新討論串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, 3周前 , 1F
09/14 11:17, 1F

09/14 11:33, 3周前 , 2F
這個故事好眼熟,應該在很多地方發生過
09/14 11:33, 2F

09/14 11:35, 3周前 , 3F
09/14 11:35, 3F

09/14 11:37, 3周前 , 4F
XD 看完這鬼故事笑了 但我好奇切換到A module之後是大爆
09/14 11:37, 4F

09/14 11:37, 3周前 , 5F
炸還是真的順利完成迭代
09/14 11:37, 5F
我不知道 我離職前還AB兩個版本都還在雙軌運行 算是開放式結局 ※ 編輯: SkankHunt42 (154.47.23.51 日本), 09/14/2025 11:49:46

09/14 12:38, 3周前 , 6F
那A幹嘛生類似的功能?是因為通通都要用B的程式?
09/14 12:38, 6F

09/14 12:52, 3周前 , 7F
可以強烈建議但不能不說直接做,因為責任是決定的人扛
09/14 12:52, 7F

09/14 12:54, 3周前 , 8F
分兩個版本不是不行,但要想好怎麼做才不會失敗
09/14 12:54, 8F

09/14 12:54, 3周前 , 9F
你這又不是重構 是重寫 先搞清楚問題在哪==
09/14 12:54, 9F
你琢磨是重構還是重寫 問題的本質有變嗎 甲大刀闊斧重構 diff佔整個module 80% 跟乙大規模重寫 diff佔整個module 80% 你覺得區別在哪? 有人會在意你的commit是用什麼方法論嗎 改程式碼就改程式碼 不會因為你給他一個新的名字改變本質

09/14 12:56, 3周前 , 10F
我是覺得RD應該要多了解infra相關知識才能避免一些問題
09/14 12:56, 10F
※ 編輯: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:00:52

09/14 13:05, 3周前 , 11F
重構就是要限縮範圍 第一步是把一大坨屎改成許多坨小
09/14 13:05, 11F

09/14 13:05, 3周前 , 12F
屎 再把每一坨屎改正 中間每一步都要有足夠的信心才
09/14 13:05, 12F

09/14 13:05, 3周前 , 13F
能走下去 當然這是理想情況很難完全做到 但你這做法
09/14 13:05, 13F

09/14 13:05, 3周前 , 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, 3周前 , 15F
等整個東西都99%完成了才要對接 當然就是重寫啊==
09/14 13:06, 15F

09/14 13:09, 3周前 , 16F
有改動AB test不是很正常嗎
09/14 13:09, 16F

09/14 13:21, 3周前 , 17F
我覺得維持兩年換一份工作的良好職涯紀律可以避免這些事
09/14 13:21, 17F

09/14 17:07, 3周前 , 18F
推人的問題最大+1
09/14 17:07, 18F

09/14 17:22, 3周前 , 19F
有測試是要先針對舊系統寫 再來新系統測試
09/14 17:22, 19F

09/14 21:04, 3周前 , 20F
A team是不是太閒,還有時間做重複的功能
09/14 21:04, 20F

09/14 21:18, 3周前 , 21F
可以考慮job rotation吧.. 看是搬一些人過去或是兩team互換
09/14 21:18, 21F

09/15 00:25, 3周前 , 22F
不意外啊。
09/15 00:25, 22F

09/15 03:30, 3周前 , 23F
故事好聽,給讚!^_^
09/15 03:30, 23F

09/15 11:17, 3周前 , 24F
重構有具體定義的啦,你要能確保行為不改變才是重構
09/15 11:17, 24F

09/15 11:18, 3周前 , 25F
馬上又有槓精跳出來 最後一段推給每一個人
09/15 11:18, 25F

09/15 11:18, 3周前 , 26F
很多時候靠既有手段重構無法走到你想要的地方
09/15 11:18, 26F

09/15 11:19, 3周前 , 27F
那個時候跳一小步就已經是重寫了,重寫很正常
09/15 11:19, 27F

09/15 11:20, 3周前 , 28F
是不用太糾結名詞,但的確太多人重寫都說自己在重構
09/15 11:20, 28F

09/15 12:45, 3周前 , 29F
好讚,最喜歡開放式結局
09/15 12:45, 29F

09/15 17:08, 2周前 , 30F
喜歡你暖暖的文字
09/15 17:08, 30F

09/16 16:04, 2周前 , 31F
好聽的故事 期待多多分享
09/16 16:04, 31F

09/16 23:08, 2周前 , 32F
A team蠻爽的,不用maintain屎code沒產值還不會被lay
09/16 23:08, 32F

09/18 19:56, 2周前 , 33F
幹 真好聽
09/18 19:56, 33F
文章代碼(AID): #1enZ2Zrf (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1enZ2Zrf (Soft_Job)