前段時間同事參加ITEYE的試讀有獎， 沒想到得了個獎，拿到一本書。由于同事的推薦我也認真讀了一下試讀章節，一下就入迷了，于是直接買了一本（當時還不知道他參加試讀有獎活動）。上個月ITEYE又舉行這個活動，我也一起參加，當時寫下了這篇讀書筆記。
今天無意中看到，把自己寫的讀書筆記又仔細看了一遍，居然無法想像是出自自己的手中，心中有些感慨，于是轉到這里收藏之！
試讀活動頁面：http://webmaster.iteye.com/blog/2092746
==========實用主義===========
不知什么時候國內的技術人士開始流行大話技術了，不少《大話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筆業務。
之所以現在的目標分解比原來多了是因為我們每進行一步的時候發現了很多問題需要去解決，隨著測試的深入對于多線程的理解也更加深刻，每一個目標達成后我們都會討論下一個要解決什么問題，從而調整目標。
雖然我們沒有規范的文檔，甚至代碼都不規范，但是我們正一步一步向著更好的方向前進。
===================
重構的目的很簡單，就是為了讓產品更好，更強，但是具體下來怎么才算更好、更強，誰也說不出個標準。
只要能證明比以前好，就要用，無論是技術層面的規范、代碼、需求、過程，還是管理方面的績效考核、激勵方式、文檔、制度，都要遵循一個規律：世界上唯一不變的就是變化！
而敏捷開發就是應對變化最好的辦法：持續改進。而重構也是一樣，不變是等死，變也許死得更快，也許不一定死。借一句古話：千里之行始于足下，無論怎樣重構，都是一步一個腳印走出來，想要走的穩，每一步都要扎扎實實。
文章列表
留言列表
