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.

--