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

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

法則：

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次。然后，在其兇狠的眼神中，同伴很快掌握了快捷鍵。

總結：

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

總結

以上是生活随笔為你收集整理的程序员的共鸣 - 读《卓有成效的程序员》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。