覺得最近很多文章都有些不求甚解的問題，來寫點論述。
1. 重構不是什麼了不起的事情
2. 變更程式碼，重寫舊的程式碼成自己爽的樣子，不一定是重構。
3. 重構是一種相對安全的工具型開發方法論，
但仍然有不少風險跟誘惑。
4. 如果你不應該或沒權力改的程式碼，
不要以為自稱是重構就能取得變更的權力。
5. 測試(單元或整合)，是一種快速驗證，
程式是否符合自己預期的工具，但並不是不會犯錯的保證。
因為，自己的預期可能就是錯的，也可能測試相依過深，
一時半刻沒有足夠好的介面，測不到真正的主要情境。
6. 不論重寫或重構，所有的程式碼變更都有一個本質，
要把時間花在刀口上，對重要的程式碼優先處理，
不重要的程式碼延後處理，程式碼都有優先權問題。
所謂的程式碼沒壞就不要修他，
本質上是「如果他的現況不影響別的事情，暫時不用管他」。
但如果他已經卡到別的功能的擴充或維護，
造成 DEBUG 困難，常出問題等，修改他就有了價值。
那個狀態就又是另一回事。
======
另外，有些話我覺得講的不夠白，做點翻譯：
1. 東西沒壞就不要改他：
你最近改壞的東西太多了/
你最近正常改好的東西太少了/
這段扣不關你的事情你沒有權限可以碰。
2. 開發應該要先做測試：
你最近改壞的東西太多了/
你最近正常改好的東西太少了
3. 要重構之前應該要先做測試：
你現在的 CODE 搞不好都已經在亂寫了，
再大規模改 CODE 會不會死的更難看。
4. 這 CODE 寫的很爛：
我想把 CODE 改成我看起來爽的樣子
=====
坦白說，你寫程式品質高的話，要怎麼炫技都可以，
凡人登山要確保，很多高手可以無確保登山，
但這些人每隔幾年也就會有一兩個摔死上新聞。
嗯，反正說到底改程式碼的權限是個政治問題。
打著重構或效能調整的名義變更是沒關係，
但有沒有做好，是一翻兩瞪眼的事情。
個人 Credit 喪失事小，
把使用這個工具的人給搞成白癡事大，
還麻煩大家，量力而為。
自己爛，不會開發，不要牽拖工具方法論。
要重構先還是要測試先，會問這種問題的，
還不如先練習看看什麼是重構，什麼是測試。