雖然本人是計算機專業 畢業，但是也學過軟件工程這本課程的。但是在開發這幾年中，聽到架構二字，心中總是充滿敬畏。
後來和公司後端部門的架構師聊了以後，發現其實架構並沒有那麼神祕，給我的建議是——人人都可以做架構師。最起碼一位合格的程序員都要有一顆做架構師的心。
拿破崙曾說—— 不想做將軍的士兵不是好士兵。重構項目之後，也有了一些心得體會，所以再來拜讀重構改善既有代碼的設計 這本業內經典。
1. What’s 好的程序員？
任何一個傻瓜都能寫出計算機可以理解的代碼，唯有寫出人類容易理解的代碼，纔是優秀的程序員。
2. What’s 重構
所謂重構(refactoring) 是這樣一個過程：
在不改變代碼外在行爲的前提下，對代碼作出修改，以改進程序的內部結構。重構是一種經千錘百煉形成的有條不紊的程序整理方法，可以最大限度地減少整理過程中引入錯誤的機率。本質上說，重構就是在代碼寫好之後改進它的設計。
對此，I can not agree more…
重構確實是一個長期的過程，而且重構不是什麼非得把代碼大刀闊斧地改進一番才叫重構。在日常開發中，我們修改一函數名使之便於理解，也算是重構。
而且書中提到：
重構技術就是以微小的步伐修改程序，這樣如果犯錯，可以立即發現並糾正它。
對此，我深有體會，我在重構項目中，有時候會修改大量的代碼，最後編譯運行以後報錯，無奈只能回滾代碼。
2.1 容易被忽略的重構行爲
更改變量名是值得的行爲嗎？
書中給出我們的答案是：絕對值得
因爲好的代碼應該清楚表達出自己的功能，變量名稱是代碼清晰的關鍵。這就暗示我們，在閱讀自己的代碼時，也時刻保持着重構的心。
相信我，遇到變量名亂起的代碼，你會發瘋的。
書中也提到，合理地使用臨時變量，因爲它往往會引發問題。
3. Why 重構
- 改進軟件設計；
- 使軟件更容易理解；
- 幫助找出BUG；
- 提高編程速度；
良好的設計是快速開發的根本。
Kent Beck “兩頂帽子”的比喻：
- 添加新功能；
- 重構
4. When 重構
在現實開發中，往往出現開發者對CTO提出重構需求，然後申請時間去專門處理重構這件任務。然後夾雜着新需求，痛不欲生啊…
書中的作者也提到：反對幾乎任何情況下專門抽出時間進行重構。重構應該隨時隨地地進行。
這裏作者貼心給我們一個三次法則——事不過三，三則重構。
- 第一次做某件事只管去做；
- 第二次做類似的事會產生反感，但無論如何還是可以去做；
- 第三次再做類似的事，就應該重構；
在項目開發過程中，什麼時候去考慮重構：
- 添加新功能時重構；
- 修復問題時重構；
- 複審代碼時重構；
審視一下自己的代碼是否需要立刻重構：
- 難以閱讀的程序，難以修改；
- 邏輯重複的程序，難以修改；
- 添加新功能時還需要改動已有代碼的邏輯，難以修改；
- 帶複雜的判斷條件的程序，難以修改；
5. 個人總結
團隊最好能先制定一些開發規範，避免代碼差異化過大；
團隊成員應該時刻關注自己的代碼質量；
書中有些方案不錯，但是在現實中實行起來卻非常困難…