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

※ 引述《kingofsdtw (塔綠班)》之銘言： : 最近案子快收尾在收斂bug : 身為救援大隊長的老人我被指派到維護一個很老的API : 老API的設計已經無法滿足擴充需求 : 新的擴充功能造成BUG : 於是我花了大量時間甚至debug到天亮甚至請無薪假 : 新的API經過我反覆測試各種case都完美無缺 : 但是code review卻被質疑: : 1. 是不是沒找到root cause : 2. 幹嘛改動如此大? 只不過新加一點點功能幹嘛改架構? : 心中五味雜陳... : 好歹我也是coding master，我說該重構了就是該開始還技術債了 : 更上頭還是希望用最鴕鳥的方法繼續用舊架構一堆workaound當作root cause : 是該離職了嗎? QwQ

我的建議是:

1. 要幹嘛要先講

2. 要耗用的資源多少要先講

3. 要達成的目標是啥要先講

還技術債也要看怎麼還，該決定的人去決定，

你不一定是錯的，但是決定答案的人不是你。XD

你可以找一個你可以決定答案的位置或角色，

你會發現那個位置要煩的可能就不是這件事情，所以他們判斷的可能跟你不一樣。

然後我是不建議耗用自己的資源作太多，因為職場上的習慣是，

你做得到的話就會以這個角度當你的標準，

除非你想/願意常態性的耗用自己的資源進行工作，不然不是很建議這個策略。

基本上重構跟技術債都是髒字，工作上有人跟我講這兩個字，

我基本上都會拿著放大鏡重新檢查他想幹嘛。

這輩子工作到現在，我覺得能把這兩個字用得好的可能不到一成，

我是建議大家用【功能更新】取代【重構】，用【複雜度過高】取代【技術債】。

然後再看一次你的論述，是不是講起來還有道理。

ex. 因為這系統【複雜度過高】，所以我們要進行大規模【功能更新】。

一般情況下這個描述應該都會比，

因為這系統【有技術債】，所以我們要進行大規模【重構】，

看起來可怕很多，而且需要解釋得更多。

而這就是作這件事情的時候該做的事情，

找出問題，說明原因，進行解釋、安排資源。

--

I have a dream, it's silly but beautiful.

--

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.34.27.1 (臺灣) ※ 文章網址 ※ ※ 編輯: TonyQ (114.34.27.1 臺灣), 09/14/2025 14:48:08 ※ 編輯: TonyQ (114.34.27.1 臺灣), 09/14/2025 14:51:42