最近讀了《卓有成效的程式設計師》，感覺收穫頗大。這是一本寫給程式設計師的難得的好書。書中大都是一些淺顯的道理，但作者將這些東西加以收集、歸納、總結，並最終成書。作者為了收集各種提高效率的工具和方法，東奔西走，可謂費了一番苦心。
我覺得此書第一部分總結的一些法則非常好，我提取了一下：
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次。然後，在其**的眼神中，同伴很快掌握了快捷鍵。
這本書很薄，蘊藏的道理卻不少，相信每個讀過它的人都會從中收穫。讀過之後，我們不應該侷限於書中提到的某些小技巧， 或是書中某乙個細節，畢竟，提供效率的方法有很多很多，法則也有很多很多，一本書很難將其窮舉完。我們應該從書中吸取其思想，並在實際工作和學習中不斷總結，做乙個真正的「卓有成效的程式設計師」！
程式設計師的共鳴 讀《卓有成效的程式設計師》
最近讀了 卓有成效的程式設計師 感覺收穫頗大。這是一本寫給程式設計師的難得的好書。書中大都是一些淺顯的道理，但作者將這些東西加以收集 歸納 總結，並最終成書。作者為了收集各種提高效率的工具和方法，東奔西走，可謂費了一番苦心。我覺得此書第一部分總結的一些法則非常好，我提取了一下 1.加速法則 關注本質...
《卓有成效的程式設計師》讀後感
以前看過 卓有成效的程式設計師 的幾頁，但只是看了前面的幾十頁，當時這本書給我的感覺只是一些工作中所用的指令碼的集合。當時我的結論是它的價值並不大。後 來又分別在不同的地方出現了這一本書，於是推斷我當初對這本書所下的結論應該是太武斷了。因為如果它是一本指令碼的集合的話，那它不可能有這麼大的價值讓無 ...
孟巖 之 卓有成效的程式設計師
對於程式設計師，過去我們一直習慣於用單純的技術水平，也就是實現程式功能的能力來衡量。然而這個時代其實已經過去了。雖然技術仍然很重要，但企業越來越多地認識到，對於程式設計師更全面的衡量標準，應當是生產率。只有能夠以較高的效率完成對專案 對企業有價值的工作，才是團隊和組織所真正需要的人才。反之，技術好，...