數月前，我曾經寫過一篇博文《在**重構中蛻變》，文中提到了我對重構的一些認識，今天再談重構，緣起於近期針對重構進行了6次技術分享，每次對應《重構——改善既有**的設計》一書中的一章內容，在此過程中與團隊一起再學習了一次重構，因此，這次再談重構，就從學習的角度說起。
當再次拿起這本書時，想到的就是第一次閱讀時的體會。幾年前，第一次開啟書，讀完了第六章——重新組織你的函式，知道了大體上重構是怎麼回事，如何完成，然後就再也讀不下去了。當時心裡想，雖然書裡列出了若干條重構手法，但看上去好像千篇一律了，像提煉函式、將函式內聯、將臨時變數內聯……實在是太簡單了，只要我想改，隨手就把**改了，還要這些手法幹嘛呢？這就是我當時的實際想法，由此，我就學完了重構，書也束之高閣了。
再學重構時，我認識到了很多當時的侷限。
首先，重構手法只是便於表達和記錄，不是要死記硬背的東西，更不是放之四海而皆準的數理化公式定理。我們要學的不是每一條手法的名稱、動機、作法，而是要深刻領會每一條手法背後所適用的場合。我們可以乙個名稱都記不住，但我們要形成用這種思路提公升**可讀性的認識。
其次，重構本身是一種理念。學習重構，就是要學習從能識別出**中的壞味道，到能消除**中的壞味道的思維過程，就是要形成這樣的意識，並且能在實際工作當中加以實踐運用，就是要想方設法的讓**清爽。一些必要的手法可以開拓我們改進**的思路，但並不是只有這種方法才行。
再次，重構還是一種決策過程。程式是平衡的，不僅架構師在面對各種決策，所有工程師其實都要面對，要在各種約束中做出選擇。重構也是如此，我們看到很多的重構手法是互相矛盾的，比如『將單向關聯改為雙向』對應的就是『將雙向關聯改為單向』，比如『提煉子類』與『提煉超類』等等，具體用哪種更合適，那是需要我們在實際情況中去決策的。
最後，重構從更廣泛的意義上來講，裡面除了有修改**的方法以外，更包含了程式設計標準或規範，以及程式設計思維。裡面的很多手法就是設計模式，所以學習重構，就不能只把它當成乙個修改**的手段來學了。
很顯然，重構對於提高**質量，提高編碼能力是非常重要的，那麼怎樣才能快速的掌握這一工程師必備技能呢？一句話，在明白重構本質的前提下去實踐。
看書無疑還是枯燥的，只有把它轉化成實際應用，才能加深認識。如果手中有實際的**，不妨從自己能把握的小範圍開始，重新命名、提煉、內聯、搬移……看看改完了是否讓別人能更容易理解。如果手中沒有實際**，可喜的是書中的範例很不錯，要在ide中嘗試著來做一下。但要注意三點：一是要頻繁測試，尤其是產品**，一定不能改變現有的功能，不能引入新的bug；二是只在自己能控制的範圍內修改，不要修改其他人的**甚至整體結構，慎重；三是書中的**是示意性的，很多是編譯通不過的，要自己親自動手才能領會其中的細節。
我想，對重構有了正確的認識，再加上勤於實踐，把思路著重於重構手法的應用場景而不是作法細節甚至對手法名稱的背誦，就一定能夠用最短的時間掌握這種技能了。
重構之路系列 首篇之我對重構的看法
首先承認，我不是牛人，並且距牛人也差的很遠。雖然有三年多的.net開發經驗和若干年的front end開發經驗，但是對於.net，當然也可以說是c 了解的並不多。由於所在公司的原因，我在從第一家軟體公司跳槽後基本就是處於吃老本的姿態。因為對於我現在的公司而言，專案的穩定性是第一位的，至於projec...
對《重構比從頭開始更麻煩》的一些看法
第一，度的把握。專案開發的控制有四個要素 成本，時間，質量，範圍。現在時間，質量已經決定，而且不由我們控制，那麼為了控制成本，我們就只有對範圍進行界定。首先要制定出乙個這段時間結束後要達到的目標。包括專案的效能，可擴充套件性，可以執行性，穩定性，友好性等等。乙個清晰的目標能指引每個人向這個努力。而且...
再談PN學習
分類 cv相關 2012 06 09 09 35 6780人閱讀 收藏 舉報演算法c 之前翻譯過一篇pn學習的文章 但該文章的內容還是略顯生澀，不太容易理解。尤其是在tld跟蹤演算法中，pn學習又是乙個很重要的模組。如果不能很好理解該部分，是很難完全掌握tld演算法精髓的。所以，這裡我在上次翻譯的基...