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

推推

推前半，做事真的要看帶來的價值

推

推

台肯

除了半瓶水以外，真的有人喜歡沒事就重購嗎？

是不是少了[心得]?

加功能就容易伴隨著重構 不然經常會變得疊床架屋

中肯

推

中肯

你的標題先重構一下吧

中肯推

E

加功能伴隨重構 那應該會想打寫架構的人

改扣之前先問問自己，這段程式這麼爛大家都有看到，為什麼沒有前人去改它，凡事必有因果。

不過真的就是權限問題 權限夠想把所有功能改掉 不用說物件化 擬人化都可以 每個功能幫它取個名子

中肯

哪來的萬用架構都不用動就可以加功能 不需要dirty work 請務必讓我見識怎麼設計出來的

就是有阿 看過才會讚嘆公司花大錢請 senior 不是沒有原因

能搞出萬用架構應該也不是senior, 是神了不然就是一堆overdesign的garbage code自以為很神

我覺得要refactor要有理由 醜不算

架構總要保留可以擴充跟相容的空間吧 加一個功能就要這就是有問題的重構

年輕人應該多鼓勵重構當練功, 但是請私下做不要影響到大家工作的環境, 重構下去你才會發現很多問題包含自己缺少的, 還有舊架構的涵義等等

如果該專案幾乎沒有後續需求的話 只是醜我可以但是常常有後續一堆需求 加上前人刻意不照公司寫程式規範走 留下很多坑 東西又在線上 不得不選這條路

站在管理者的立場就是沒壞不要改，因為錯了要擔責任但站在開發者的角度，這東西不改我會很難維護跟除錯這篇的立場只是偏前者

推能跑沒問題再爛也不要動code,很難改不知道是否有地雷，可3會付出代價

如果公司沒有自己的規範呢？ 呵呵…

推唷

推一個

說真的我到現在還沒遇到真的懂重構的 2倒是一堆XD

很多人只是看不慣別人寫得而已

這篇整理得很清楚, 但多數人還是只會擷取自己想聽的

premature optimization is the root of all evil重構跟講英文很像，你會看到一堆英文很爛的人很有自信開口講，也會看到英文很好卻不敢開口的人。你會看到一堆該重構的人找理由不去重構，也會看到不該重構的人OCD發作改些沒意義的東西

推

> 凡人登山要確保 超中肯！Testing 先起來再說重構！

抱持code沒壞就不要改的，是爛主管。通常就是他自己coding能力差，不勤練，不好好寫test。還因為他是這種人，整個團隊也慢慢變這種風格。