怎麼跟經理提你想要重構系統？
「不要告訴經理！」
圖片來源：Martin Fowler, 《Refactoring 》
—
其實這還要針對兩個正反面角度來補充一下：
1) 如果重構可以更快、更正確地讓你交付功能，而這一個目標上你跟經理是有共識的，那就以成果來說明，Show, Don’t Tell. 沒有人可以阻止你寫測試、重構、push 之前多 review 幾次程式碼。
只要你能滿足共同的目標（當然，初期你只能往這方向前進，可能無法做到眼前的又快又好），用成果來說明，比起發出請求允許（permission ）來得對實際產品更有效益。
2) 該針對哪些東西寫自動測試、該對哪些部份進行重構，該怎麼進行重構，都考驗著你的 skill，也都有對應該知道的知識與決策依據。
無意義的重構，針對不必要的東西寫測試，真的是一種極大的浪費。在沒告訴經理之前，你想做這些事，也得先學會對應的技能，而不是憑著開發人員的一腔熱血與衝勁，卻把產品進度、目標甚至品質弄得一團糟。
—
其實最常見的情況，還是拿：「我該怎麼取得主管的同意，讓我能有更多的時間重構呢？」以這來當擋箭牌去迴避自己 skill 仍然不足的現實。
當你需要很多時間來進行重構，又不敢保證對應的效益、品質、進度，那任何一個主管都無法答應你的要求的。如果主管這樣都還答應你，大概是這個系統重要性不高、使用者少，既然重要性不高的系統，針對它投資重構跟自動測試，ROI 肯定也是低落的，這是風險導向而不是價值導向的決策。
—
重構前要有測試保護，對 legacy code 加入測試與重構本來就是帶著風險、要撰寫/改變不少程式碼與設計的動作。
每個人都會碰到 #時間不夠 ，時間不足以讓你把想做的都做上去的限制。然而你怎麼改善 #時間不夠 的問題？你做了什麼？
#又快又好 是種境界，你絕對有機會能比別人同時又快又好，當然你也得先付出代價學習、練習、持續精進技能。
—
要對 legacy code 重構，得先有能力在上面加入單元測試：https://tdd.best/courses/unit-testing-gracefully-with-legacy-code-202104/
有能力加入單元測試之後，如何辨識 code smell, 如何重構凸顯意圖、消除重複、簡單設計, 如何避免再寫出需要花巨量時間寫測試跟重構的 legacy code，怎麼讓新寫的程式又快又好：https://tdd.best/courses/tdd-continuous-refactoring-2021-05/
當具備做好的能力，接下來就是要追求高速、低風險的開發、重構能力：https://tdd.best/courses/extreme-developing-202104/
這三門課其實是一個整體的技能，只有針對 legacy code 為目標的技能培養才夠實務。
註：這三門課都在半年後，但名額已經快滿了（都 < 6 張），請大家視自己的需求參考看看囉。
註2: 就過去經驗，如果沒上過我的課，建議不要先挑 TDD與持續重構 當第一門課，因為一次的資訊量可能會爆炸，會讓你過份燒腦吃不消。
三門課最常見的學員感想：
1）單元測試：原來測試跟我想的不一樣，原來寫測試一點都不難。
2）極速開發：原來我寫 code 真的很慢，原來寫 code 可以這麼行雲流水地讓人舒服。
3）TDD與持續重構：原來我根本不會寫程式。我的重構不是重構。原來不是先寫測試就是 TDD。
