序言中，熊傑對重構的思考：
認為存在的問題：
1. 認為掌握思想就夠了，不重重構手法
2. 大刀闊斧的修改，甚者重建整個專案
重新認識：
1. 不要大刀闊斧——重構的基本定義：重構是在不改變軟體可觀察行為的前提下改善其內部結構。
依靠的是那些已經被證明是行為保持的重構手法：整理出可測試的介面，給它新增測試，以此為重構的立足點。
2. 不要只重視思想——讓重構發揮威力，就必須做到「不需了解軟體行為」。
這個過程之所以可行，全賴你在腦子裡記錄著乙份壞味道與重構手法的對應表。
安全的方式重構的話，我們仍然必須遵循這些看似瑣碎的做法指導（加上語言特有的細節調整），按部就班地進行。
我的總結：
重構手法，是安全的，經過反覆實踐證明的。
只掌握思想是遠遠不夠的，要勤學苦練，記住所有壞味道，記住他們對應的重構手法，才能夠面對各種複雜的情況。
重構誘人和神奇的地方在於，我們可以不需要理解「軟體行為」，即可開始重構，進而幫助我們更好的理解「軟體行為」。
前言部分：
1. **被閱讀和被修改的次數遠遠多於它被編寫的次數。保持**易讀、易修改的關鍵，就是重構——對框架而言如此，對一般軟體也如此。
2. 設計模式為重構提供了目標。然而「確定目標」只是問題的一部分而已，改造程式以達到目標，是另乙個難題。
3. 所謂重構（refactoring）是這樣乙個過程：在不改變**外在行為的前提下，對**做出修改，以改進程式的內部結構。重構是一種經千錘百鏈形成的有條不紊的程式整理方法，可以最大限度地減少整理過程中引入錯誤的機率。本質上說，重構就是在**寫好之後改進它的設計。
**前設計：
**修改階段，整體結構容易衰落，從而難以嚴謹的編寫設計良好的**
重構：正好相反，重構可以從乙個糟糕到**，加工成設計良好的**
因此，**前設計和重構，是相輔相成的維護良好設計的手段。
這就是在說將設計過程，融合到整個開發過程中。
重新認識container
我還清楚的記得，第一次從 那兒聽說container這個詞 結果他給我解釋了半天還是似懂非懂的。今天，偷閒翻了下posa4,發現裡面對container的解釋特別清楚。粗略的理解下來是，為了分離關注點，而實現的對系統資源的封裝。豁然開朗的發現，os就是應用程式的container。突發奇想的，開發乙...
重新認識測試
以前總覺得測試是軟體開發的邊緣職位，開發人員才是軟體生命週期的核心人員。隨著對網際網路公司的了解，逐步了解到測試的重要性。以bat為例，三家公司均設定了測試開發工程師崗位，該崗位的主要職責就是編寫自動化測試案例，通過對 的邏輯進行分析，設計出能夠覆蓋大部分 的測試用例。如阿里的測試開發工程師的崗位描...
重新認識ARC
雖然用了很久的arc，感受了 簡潔。但是對arc底層實現並不了解。今天抽空研究了下，做些簡單地總結。一 strong 1.區域性變數 對於區域性變數來說，在超出作用域的地方由編譯器自動插入release。大概轉化為 在非arc返回的autorelease型別的方法 在blog手碼大概 如有錯誤還望指...