程式員的共鳴 – 讀《卓有成效的程式員》

文章目錄

• 總結：

最近讀了《卓有成效的程式員》，感覺收穫頗大。這是一本寫給程式員的難得的好書。書中大都是一些淺顯的道理，但作者將這些東西加以收集、歸納、總結，並最終成書。作者為了收集各種提高效率的工具和方法，東奔西走，可謂費了一番苦心。

我覺得此書第一部分總結的一些法則非常好，我提取了一下：

法則：
1.加速法則

    關注本質，而非形式

    一個應用程式列表的有用程度與它的長度成反比

    程式員的很多時間都浪費在找東西上

    華而不實的東西中看不中用

    鍵盤輸入總比導航快

    首選鍵盤而非滑鼠

    地址欄是Windows資源管理員介面中最高效的部分

    花點時間來學習你手邊的所有隱藏的快速鍵

    環境切換會消耗時間

    成批覆制粘貼要比反覆多次複製粘貼快

    忘記曆史就意味著你得再輸入一遍

    嵌入圖形化工具的命令提示字元讓你魚與熊掌兼得

    在上下文中學習IDE快速鍵，而不要去背長長的列表

    當你第二次輸入一個複雜結構時，將它做成模板

    如果要對多行文本做同樣的操作，就應該找出其中的模式，並把它記錄為一個宏

    不要總是重複輸入相同的命令

    每天花一點點時間來使每一天都更高效

2.專註法則

    精力越集中，思維越縝密

    排除幹擾：隔離策略，關掉不需要的提示，創造安靜時間 

    草堆越大，從中找到一根針就越難

    不要問檔案樹，要搜尋

    使用多顯示器

    虛擬桌面可以讓原本雜亂無章的一大堆視窗變得整潔

3.自動化法則

    不要重新發明輪子

    用Selenium瀏覽網頁

    不要浪費時間動手去做可以被自動化的事情

    用Windows Power Shell替代批次檔

    馴服Subversion命令列

    以創造性的方式解決問題，有助於在將來解決類似的問題

    是否應該自動化的關鍵在於投資報酬率和緩解風險

    研究性的工作應該放在時間盒裡做

    別給犛牛剪毛

4.規範性法則

    對於任何你不自己去構建的東西，只在版本控制中儲存一份副本

    使用標準的構建伺服器

    通過複製粘貼來複用是邪惡的，不論你複製粘貼的是什麼

    利用虛擬平台使項目依賴標準化

    不要讓對象 - 關係映射工具（O/R映射器）違反規範原則

    通過擴充。開放類（open class），或者部分類（partial class） 來為產生的程式碼增加行為

    始終保持代碼和資料結構的同步

    過時的文檔比沒有文檔更糟，因為它會主動誤導你

    任何需要費勁創造的東西，都讓它的創造者欲罷不能

    白板 + 數位相機強過任何CASE工具

    盡量產生所有技術文檔

    重複是軟體開發中最大的阻力

工具：

書中，還提到了大量的提高效率的工具，都是非常不錯的。相信很多人都有自己的一個列表，下面是我電腦中必不可少的幾款軟體：

    1. FireFox 及其各類外掛程式

    2. Launchy啟動加速器

    3. Total Commander

    4. ClipX多重剪下板

    5. EmEditor文字編輯器

    6. Vistual Studio的VA外掛程式

    7. Search And Replace

    8. Everything

    9. Miranda IM

    10. ....

感觸：
1. 憤怒的猴子

在書中的第二部分，提到了很多實踐相關的內容。讓我感觸最深的是“憤怒的猴子”的故事：

“早在20世紀60年代（那時候科學家們可以做任何瘋狂的事情），行為科學家們進行了一項實驗。他們把五隻猴子和一架活梯放在一間屋子裡，並在天花板上掛了一串香蕉。這些猴子很快就想到它們可以爬上梯子去吃香蕉，但每當它們靠近活梯的時候，科學家們就用冰水浸滿整個屋子。我想你能猜到會發生什麼：一群憤怒的猴子。很快，再沒有一隻猴子會去靠近那個梯子了。

之後，科學家們將其中一隻猴子替換成另一隻沒有忍受過冰水折磨的新猴子。這隻新猴子所做的第一件事就是直奔那架梯子，但當它這麼做時其他所有猴子都痛打它。它不明白為什麼，但很快就學乖了：不要去靠近那架梯子。科學家們逐漸將最初的那些猴子都替換成新猴子，直到這群猴子中誰都沒有被水浸泡過，然而它們還是會去攻擊任何靠近梯子的猴子。

這說明了什嗎？軟體項目中許多慣例之所以存在，就因為”我們一直是那樣做的“。換句話說，是因為憤怒的猴子。”

我們小組在制定C++相關的代碼規範時就遇到過無數類似的問題。比如，在制定變數的命名規範時，我們針對是否採用匈牙利命名法爭論了很久。有的人認為， 幾乎以前看到的所有C++代碼都採用了匈牙利命名法，甚至，微軟定義的所有API都使用了此類命名法。剛開始，我也是有同樣的疑惑。

後來，我們經過仔細分析C++匈牙利命名法由來，漸漸感覺我們就是那些憤怒的猴子，盲目跟從前人的方式，缺乏打破傳統的勇氣。C++有著其特殊的曆史原因，很多標準一直沉澱下來並很少改變。我們再看看後來新生的那些程式設計語言，C#, Python…… 都拋棄了匈牙利命名法，同時再看看現在C++前沿的C++ 0x以及現在出版的一些書中，也漸漸放棄了對匈牙利命名法的使用。因為類型的意義在物件模型中越來越弱化。因此，最後我們放棄了匈牙利命名法這個老古董。

2. 敏捷開發

這本書帶有強烈的ThoughtWorks色彩，敏捷的思想貫穿全書，包括測試驅動設計，白板，結對程式設計。這也讓我對敏捷產生了更加強烈的興趣。 其中有一段測試驅動開發TDD的一段故事：

“記得第一次和一些已經習慣於單元測試的開發人員一起動手開始修改代碼時，我也是非常緊張，因為大量的修改往往會破壞很多東西，但他們看起來絲毫沒有猶豫。逐漸地，我也放下心來，因為我慢慢地認識到：有了測試的保證，完全可以放心大膽地去修改代碼。”

3. 有趣的故事

書中還有一些有趣的故事，比如作者的一個朋友在和別人結對程式設計時，為了養成同伴使用快速鍵的習慣，每當同伴未使用快速鍵時，他都會要求將操作撤銷，然後要求使用快速鍵再重複操作3次。然後，在其兇狠的眼神中，同伴很快掌握了快速鍵。

總結：

這本書很薄，蘊藏的道理卻不少，相信每個讀過它的人都會從中收穫。讀過之後，我們不應該局限於書中提到的某些小技巧， 或是書中某一個細節，畢竟，提供效率的方法有很多很多，法則也有很多很多，一本書很難將其窮舉完。我們應該從書中吸取其思想，並在實際工作和學習中不斷總結，做一個真正的“卓有成效的程式員”！