前段時間同事參加ITEYE的試讀有獎， 沒想到得了個獎，拿到一本書。由於同事的推薦我也認真讀了一下試讀章節，一下就入迷了，於是直接買了一本（當時還不知道他參加試讀有獎活動）。上個月ITEYE又舉行這個活動，我也一起參加，當時寫下了這篇讀書筆記。

今天無意中看到，把自己寫的讀書筆記又仔細看了一遍，居然無法想像是出自自己的手中，心中有些感慨，於是轉到這裡收藏之！

==========實用主義===========

不知什麼時候國內的技術人士開始流行大話技術了，不少《大話XXX》的書出現在世面上，這些書中最早也是比較經典的一本應該算是《大話設計模式》了，不得不說用這種方式來說技術問題，讓不少人更容易理解，這種方式傳遞的應該是一種思想：實用！

從《大話重構》試讀的兩章中可以看出這本書應該也是本著這樣的思想，正如書中所說關於重構的書籍很多，各公司的技術大佬們看的時候“激情洋溢、熱血澎湃"，但是到了實踐中”卻無所適從，經過一番苦苦掙扎之後，從此作罷“，所以看任何書都應該本著實用的角度去看，有用的我們就拿來，如果是沒用就捨棄，等到有用的時候再拿出來用。

最近我們的團隊在推敏捷開發，我們是一個小團隊，總共也就10來個人，還分成了三個組，個別成員還是身兼多職，所以很多好的敏捷開發實踐、理論、方法在我們的團隊中並不實用，我們堅持”持續改進“，堅持實用主義，對我們有用的我們拿來嘗試，嘗試過效果不好的，就要果斷捨棄，尋求更好的方法。

對於重構，我們還沒有大範圍的開展這項工作，但是這個計劃已經提上了日程，不久的將來就會遇到這些問題，我想對於這本書或任何書應該持同樣的態度：實用主義

正如武俠大師金庸所說的“無招勝有招”，如此多的重構方法不是要讓你去生搬硬套，而是應該對其進行深刻理解以後，最終變成你自己的重構方法。我們在實際工作中不要過於介意我們用了什麼重構方法，哪次重構是用的哪個方法，只要是合適的設計就OK。但是，在無招勝有招之前，我們必須要有招，即學會了、理解了各個招式，在實際工作中你才能想起這些招式，去運用這些招式。

==========過度設計===========

第二章中講的例子很好，開始的時候，本著看看這書中用什麼樣的重構方式的態度來看，當我隨著筆者重構的思路走下去的時候，發現一個簡單的例子居然用上了介面，這裡不得不說介面讓程式的擴充套件性，但是對程式的可閱讀性、可維護性卻大大降低。

很多時候閱讀程式碼看到引數什麼的都是介面，文件中也講到什麼地方用什麼介面，可是應該用介面的哪一個實現卻沒有說，這讓程式設計師們情何以堪。讀到最後才發現原來筆者用了一個反面教材，原來這裡是想說明什麼是過度設計。

就這一章中的例子來說簡單的業務應該不需要這麼複雜的設計，如果真的需要，那麼就必須要說明介面的各種實現，並且要在這個介面的說明中編寫。我覺得在公司內部WIKI中可以這樣來做：

建立建口的時候除了要說明這個介面之外，還要說明這個介面目前有哪些實現，每一種實現分別在什麼情況下使用。這樣無論是新程式設計師還是老程式設計師一看就能明白這個介面的用法了。

=========小步大步==========

小步還是大步是個問題。

大步往往是推倒重來，很少有人有這個勇氣和這個能力。我見過一個50多歲老程式設計師，經常有勇氣推倒重來，人家可以說是共和國高考恢復後第一批大學生，而且是數學專業，功底不是一般人能比的了得，隨著一次次的重構，對業務、需求瞭解的深入，設計思路會逐漸的成熟更加科學，重來對他來說不是難事。

而對於大多數人和很多從其它程式設計師中接手過來的程式設計師讓他們來重構的風險可想而知，推倒重來也好，小步快跑也好，都要做到很細小的細節，沒有對需求的充分的認識，小步也好，大步也好都有風險，相比之下小步可能更容易控制一些。所以小步還是大步，視情況而定，大步的重構需要做好充分的準備。

如果沒有底氣，不如敏捷一點，定一個大目標，分解成若干個小目標，做成一個一個小迭代，每個小迭代完成後分析一下目標是否需要修正。（曾經聽過一個管理高手說過一句話，計劃做的好不是高手，計劃改的好才是高手）

以前的一個領導的做法我覺得可以借鑑，重構前要先明確目標，是提升程式碼規範性，還是提升效能，還是提升擴充套件性。

例如：想要提升程式碼規範性，這一目標可能會涉及到全部程式碼，這領導把規範性問題總結了一下一共有若干個點，例如：

1、資料庫命名規範

2、頁面命名規範

3、變數命名規範

4、業務處理規範

.....

每一種規範例舉幾個反例，例舉幾個正例。

這樣一來有了最終目標，有了階段目標，而且目標清晰，有條理，無論誰來做都很清楚明白。下來就開始劃分階段，第一階段開始資料庫命名規範調整。完成以後全面測試，然後再進行下一階段的任務。

而我所在的團隊正在採取這種辦法，目前所做的手術還沒有遇到過提升擴充套件性、重構為外掛式結構之類的大小術，都是以提升效能為主，之所以沒有做提升擴充套件性之類的重構是因為目前的程式還沒有達到效能的需求，這個時候做那樣的重構先不說對效能有沒有損失，效能優化達到目標後是不是還需要再重構擴充套件性都不知道。

所以我們訂下了最終目標：每執行緒每秒鐘處理7筆業務。（我們的產品涉及到多執行緒處理）

有了最終目標，那先要了解目前的情況，經過測試我們知道當時的情況是平均每秒鐘處理4筆業務，

我們把這個目標的達成分解為：

1、單執行緒每秒鐘處理10筆業務。

2、實現多執行緒處理業務。

3、多執行緒環境下每筆業務處理平均耗時達到100毫秒以內。

4、多執行緒情況下達到與CPU顆數的最佳匹配。

5、網路通訊環境下達到每秒鐘處理7筆業務。

目前我們進行到了第5步。但是最開始的時候並不是這樣。

1、單執行緒每秒鐘處理10筆業務。

2、實現多執行緒處理業務。

3、每執行緒每秒鐘處理7筆業務。

之所以現在的目標分解比原來多了是因為我們每進行一步的時候發現了很多問題需要去解決，隨著測試的深入對於多執行緒的理解也更加深刻，每一個目標達成後我們都會討論下一個要解決什麼問題，從而調整目標。

雖然我們沒有規範的文件，甚至程式碼都不規範，但是我們正一步一步向著更好的方向前進。

===================

重構的目的很簡單，就是為了讓產品更好，更強，但是具體下來怎麼才算更好、更強，誰也說不出個標準。

只要能證明比以前好，就要用，無論是技術層面的規範、程式碼、需求、過程，還是管理方面的績效考核、激勵方式、文件、制度，都要遵循一個規律：世界上唯一不變的就是變化！

而敏捷開發就是應對變化最好的辦法：持續改進。而重構也是一樣，不變是等死，變也許死得更快，也許不一定死。借一句古話：千里之行始於足下，無論怎樣重構，都是一步一個腳印走出來，想要走的穩，每一步都要紮紮實實。