主要內容
前言
很多年前，我曾經給一些有經驗的軟體開發者上課，教他們學習新的技術（例如Java之類的）。這些學生之間生產效率的差異一直讓我感到驚訝：有些人的效率能比另一些人高出幾個數量級──而且這還不是指他們使用工具的過程，而是他們與計算機之間的一般互動。我曾經跟同事開玩笑說，這個班上有些人的電腦壓根不是在跑，簡直就是在散步。順理成章地，這讓我開始反思自己的生產效率：我有沒有讓跑在（或者走在）我手邊的這台電腦物盡其用？
那以後又過了幾年，David Bock和我談論起這件事。很多比較年輕的同事從來就沒有認真用過命令行工具，自然也就無法理解為何這些工具能比時下這些漂亮的IDE還要高效。正如 David在序言裡說的，我們討論這個問題，並決定要寫一本關於“高效使用命令行”的書。我們聯繫了出版商，然後開始從朋友、同事那裡蒐集各種各樣的命令行巫術。
隨後又發生了幾件事：David創辦了他自己的諮詢公司，他的孩子也呱呱墜地──三胞胎！所以，顯然已經有足夠多的事情讓David焦頭爛額了。與此同時，我也明白了一件事：一本單純講述命令行技巧的書很可能會成為有史以來最乏味的書。差不多就在那個時候，我在班加羅爾的一個項目里工作，和我結對編程的搭檔Mujir和我聊起代碼中的模式、以及如何識別這些模式。如同醍醐灌頂一般，我突然意識到在自己蒐集的所有技巧中都可以看到模式的蹤影。我真正想要介紹的不是一堆命令行技巧，而是那些使得軟體開發者們高產的模式。於是，就有了你手中的這本書。
序
在我們這個行業里，不同程式設計師的個人生產效率可謂判若雲泥──大多數人也許要花一周時間才能幹完的活，有些人一天之內就搞定了。這是為什麼？簡單來說，這些程式設計師比他們的大多數同行掌握了更多趁手的工具。說得更明白一點，他們真正了解各種工具的功用，並且掌握了使用這些工具所需的思維方式。這些“高產程式設計師”的秘密是某種方法學與哲學的混合體，而Neal在他的書中準確地捕捉到了這種神秘的東西。
時間回到2005年，在去機場的車上Neal問我：“你認為這個世界會需要再多一本關於正則表達式的書嗎？”然後話題就變成了“我們希望有什麼樣的書”，並從此種下了你手上這本書的種子。回望自己的職業生涯中從“好程式設計師”躍升為“高產程式設計師”的那個階段，思索當時的情景和前因後果，我這樣說道：“書名我還沒想好，不過副標題應該叫‘用命令行作為集成開發環境’。”那時我把自己的生產效率提升歸功於使用bash shell帶來的加速，但這並不是全部──更重要的是我對這些工具更加熟悉，我無須思索怎么完成一些日常工作，而是自然而然地就把它們做好。我們還花了一些時間討論過度生產*以及控制這種情況的辦法。幾年以後，在經過無數的私下討論，以及圍繞這個主題做了一系列演講之後，Neal的大作終於得以付梓了。
在《Programming Perl》（O'Reilly出版）一書中，Larry Wall說到“懶惰，傲慢，缺乏耐性”是程式設計師的三大缺點：懶惰，因為你一直致力於減少需要完成的工作總量；缺乏耐性，因為一旦讓你浪費時間去做本該計算機做的事，你就會怒不可遏；還有傲慢，因為被榮譽感沖昏頭的你會把程式寫得讓誰都挑不出毛病來。這本書不會使用這幾個字眼（我已經用grep檢查過了），但你會發現同樣的理念在本書的內容中得到了繼承和發揚。
曾經有那么幾本書，它們影響了我的職業生涯，甚至改變了我看待這個世界的方式。說實話，我真的希望早10年看到這本書，因為我確信它會對它的讀者造成極其深遠的影響。 <!--[if !supportFootnotes]--> David Bock 首席諮詢師
CodeSherpas
<!--[endif]--> * 譯者註：“過度生產”（hyperproductivity）是指在高效的工具和工作流程之下工作的工人得不到休息而過度疲勞、壓力過大的情況。
目錄
譯者序
序
前言
第1章 簡介 9
為什麼要寫一本關於程式設計師生產力的書？ 9
本書包含哪些內容？ 10
如何讀此書？ 12
第2章 加速
啟動面板 14
加速器 18
宏 24
小結 26
第3章 專注 27
排除干擾 27
搜尋優於導航 29
找出難找的目標 30
使用有根視圖 31
設好“粘性屬性” 32
使用基於項目的捷徑 33
使用多顯示器 33
用虛擬桌面拆分工作空間 33
小結 34
第36章 自動化 36
不要重新發明輪子 37
建立本地快取 37
自動訪問網站
與RSS源互動
在構建之外使用Ant
用Rake執行常見任務
用Selenium瀏覽網頁
用bash統計異常數
用Windows Power Shell替代批處理檔案
用Mac OS X的Automator來刪除過時的下載檔案
馴服Subversion命令行
用Ruby編寫SQL拆分工具
我應該把它自動化嗎？
別給氂牛剪毛
小結
第5章 規範性 54
DRY 版本控制 54
使用標準的構建伺服器 55
間接機制 56
利用虛擬平台
DRY 阻抗失配 60
DRY 文檔 65
小結 68
第6章 測試驅動設計
不斷演化的測試 70
代碼覆蓋率 76
第7章靜態分析 78
位元組碼分析
源碼分析
用 Panopticode生成統計數據
動態語言的分析
第8章當個好公民 82
破壞封裝 82
構造函式
靜態方法
犯罪行為
第9章YAGNI
第10章 古代哲人
亞里斯多德的“事物的本質和附屬性質”理論
奧卡姆剃刀原理
笛米特法則
“古老的”軟體學說
第11章. 質疑權威 100
憤怒的猴子 100
連貫接口 101
反目標（Anti-Objects） 102
第12章 元編程 104
Java和反射 104
用Groovy測試Java 105
編寫連貫接口 106
元編程的歸處 107
第13章 組合方法和SLAP
組合方法實踐 109
SLAP 114
第14章 多語言編程 119
歷史與現狀 119
路在何方？ 121
Ola的金字塔 123
第15章 尋找完美工具 125
尋找完美編輯器 125
編輯器參考列表 127
為你的工作選擇正確的工具 128
丟棄錯誤的工具 132
第16章. 尾聲：繼續對話
附錄 Building Blocks 135
出版背景
目標讀者
這不是一本幫助最終用戶更有效使用計算機的書。這是一本寫給程式設計師的、關於如何提高生產效率的書，這也就意味著我可以對讀者做很多假設，很多基本概念也不需要浪費很多時間去解釋，因為軟體開發者是極其強大的計算機用戶。當然，沒有技術背景的用戶也應該能夠從本書（尤其是它的第一部分）中學到一些東西，但我的目標讀者只是軟體開發者。
本書沒有明確指定的閱讀順序，所以儘管隨性翻閱吧──當然如果你喜歡從頭讀到尾也沒有問題。書中的各個主題之間只有少許出人意表的關聯，所以儘管從頭讀到尾的方式會略有優勢，但還不足以認為這就是閱讀本書的不二法門。
創作原因
我是ThoughtWorks的一名員工。作為一家跨國諮詢公司，ThoughtWorks擁有大約1000名雇員，分公司遍布全球六個國家。因為諮詢工作需要長時間的旅行（特別是在美國），我們公司的員工整體而言相對年輕。記得有一次，在一次公司組織的郊遊活動（當然還有免費的飲料）中，我和一個人力資源部的同事閒談起來。她問我有多大年紀，我告訴了她，她立即“恭維”地對我說道：“哇，你已經老到足夠可以豐富我們公司的多樣性了！” 這激起了我的一些思考：原來我已經在軟體開發領域幹了很多年了（莫名的傷感…在我的那個年代，計算機甚至還是由煤油驅動的呢）。這些年來，我觀察到一個有趣的現象：軟體開發人員正在變得越來越低效，而不是更加高效。在古老的時代（對於計算機的時代而言，那是20年之前），讓計算機跑起來都是一件非常困難的事情，更不要說編寫程式這些事了。你得是一個足夠聰明的開發人員，才能讓那難以駕馭的機器變得對你有用。如此殘酷的現實，逼迫當時一些非常聰明的人開發出了各種各樣的方法來和“難搞”的計算機互動。
正是因為這些程式設計師的努力，計算機慢慢地開始變得易用。層出不窮的創新讓計算機用戶的抱怨也不再那么多。這些聰明的傢伙開始為他們所取得的成就慶祝（就像所有其他能讓用戶“閉嘴”的程式設計師一樣）。然後，一件有趣的事情發生了：對於整整一代程式設計師來說，他們不再需要“奇技淫巧”，計算機就會乖乖地滿足他們的要求，他們也和普通的計算機用戶一樣，習慣了如今易用的計算機。那這有什麼問題呢？畢竟，你不會拒絕提高生產力，對不對？
其實問題的關鍵在於，那些對普通用戶而言能提高其工作效率的東西（比如漂亮的圖形界面，滑鼠，下拉選單等等），對於其他一些人（程式開發者們）來說卻是他們獲得計算機最佳性能的障礙。“易用”和“高效”在很多時候其實是不相關的。那些在使用圖形界面（好吧，直截了當地說，就是Windows）的過程中長大的程式開發者們，對那些老一代“聰明人”所使用的不僅酷而且高效的技巧一無所知。他們的計算機在大部分時間裡根本不是在”跑“，簡直就是在”散步“。我寫此書，就是為了解決這個問題。
