出版時間:2009-3 出版社:機械工業(yè)出版社 作者:Neal Ford 頁數(shù):216 譯者:ThoughtWorks公司(中國)
Tag標(biāo)簽:無
前言
譯者序消除浪費,始于細節(jié)在一次關(guān)于敏捷的討論中,我說了一句令很多人不解的話:我不要敏捷。和很多話一樣,斷章取義的理解很容易造成誤會。我當(dāng)時說的整句話是:我不要敏捷,我要致力于消除軟件開發(fā)中的一切浪費。當(dāng)“敏捷”漸漸變成一個人見人愛的“大詞”,越來越多的人開始發(fā)現(xiàn),其實自己要的不是“be agile”,而是切實地消除浪費、提高效率。所以,作為ThoughtWorks員工的Neal Ford在他的這本書里閉口不談“敏捷”。
內(nèi)容概要
本書講述如何在開發(fā)軟件的過程中變得更加高效。同時,本書的講述將會跨語言和操作系統(tǒng):很多技巧的講述都會伴隨多種程序語言的例子,并且會跨越三種主要的操作系統(tǒng),Windows(多個版本),Mac OS X以及 *-nix(Unix或者Linux)。 本書討論的是程序員個體的生產(chǎn)力,而不是團隊的生產(chǎn)力問題,所以它不會涉及方法論(好吧,可能總會在這里或那里談?wù)摰揭恍?,但肯定不會深入討論)。同時,本書也不會討論生產(chǎn)力對整個團隊的影響。我的使命,是讓作為個體的程序員通過掌握恰當(dāng)?shù)墓ぞ吆退枷胱兊酶痈咝А?/pre>作者簡介
Neal Ford是ThoughtWorks的軟件架構(gòu)師。他曾在美國和其他國家進行現(xiàn)場授課,客戶包括軍方和很多《財富》500強的企業(yè)。書籍目錄
譯者序序前言第1章 簡介 為什么要寫一本關(guān)于程序員生產(chǎn)力的書? 本書包含哪些內(nèi)容? 如何讀此書? 第一部分 機制 第2章 加速 啟動面板 加速器 宏 小結(jié) 第3章 專注 排除干擾 搜索優(yōu)于導(dǎo)航 找出難找的目標(biāo) 使用有根視圖 設(shè)好“粘性屬性” 使用基于項目的快捷方式 使用多顯示器 用虛擬桌面拆分工作空間 小結(jié) 第4章 自動化 不要重新發(fā)明輪子 建立本地緩存 自動訪問網(wǎng)站 與RSS源交互 在構(gòu)建之外使用Ant 用Rake執(zhí)行常見任務(wù) 用Selenium瀏覽網(wǎng)頁 用bash統(tǒng)計異常數(shù) 用Windows Power Shell替代批處理文件 用Mac OS X的Automator來刪除過時的下載文件 馴服Subversion命令行 用Ruby編寫SQL拆分工具 我應(yīng)該把它自動化嗎? 別給牦牛剪毛 小結(jié) 第5章 規(guī)范性 DRY 版本控制 使用標(biāo)準(zhǔn)的構(gòu)建服務(wù)器 間接機制 利用虛擬平臺 DRY 阻抗失配 DRY 文檔 小結(jié) 第二部分 實踐 第6章 測試驅(qū)動設(shè)計 不斷演化的測試 代碼覆蓋率 第7章 靜態(tài)分析 字節(jié)碼分析 源碼分析 用 Panopticode生成統(tǒng)計數(shù)據(jù) 動態(tài)語言的分析 第8章 當(dāng)個好公民 破壞封裝 構(gòu)造函數(shù) 靜態(tài)方法 犯罪行為 第9章 YAGNI 第10章 古代哲人 亞里斯多德的“事物的本質(zhì)和附屬性質(zhì)”理論 奧卡姆剃刀原理 笛米特法則 “古老的”軟件學(xué)說 第11章 質(zhì)疑權(quán)威 憤怒的猴子 連貫接口 反目標(biāo)(Anti-Objects) 第12章 元編程 Java和反射 用Groovy測試Java 編寫連貫接口 元編程的歸處 第13章 組合方法和SLAP 組合方法實踐 SLAP 第14章 多語言編程 歷史與現(xiàn)狀 路在何方? Ola的金字塔 第15章 尋找完美工具 尋找完美編輯器 編輯器參考列表 為你的工作選擇正確的工具 丟棄錯誤的工具 第16章 尾聲:繼續(xù)對話附錄 Building Blocks章節(jié)摘錄
奧卡姆剃刀原理奧卡姆 的威廉爵士是一個厭惡華美裝飾以及復(fù)雜解釋的修士。他對哲學(xué)和科學(xué)的貢獻是奧卡姆剃刀原理:如果對于一個現(xiàn)象有好幾種解釋,那么最簡單的解釋往往是最正確的。顯然,這跟我們討論的事物本質(zhì)和附屬性質(zhì)理論緊密關(guān)聯(lián)。這個原理對于軟件的影響度也是出乎我們意料的。作為軟件工業(yè)中的一員,過去十年我們一直在進行著某項實驗。這個實驗始于上世紀(jì)90年代中期,主要是由于開發(fā)人員發(fā)現(xiàn)其開發(fā)進度遠遠跟不上軟件需求的增長而引發(fā)的(其實在那時這已經(jīng)不是一個新問題,這個問題自商業(yè)軟件的想法出現(xiàn)之后就一直存在)。實驗的目的是:創(chuàng)造一些工具和環(huán)境來提高那些普通開發(fā)人員的生產(chǎn)率,即使一些人比如Fred Brooks(去看他的《人月神話》)已經(jīng)告訴我們軟件開發(fā)中的一些混亂事實。此實驗試圖驗證:我們是否可以創(chuàng)造一種能限制程序員破壞力的語言而使人擺脫麻煩;我們是否可以無需支付荒唐的大量金錢給那些令人生厭的軟件技工(即使在那時候你可能還為找不到足夠的軟件技工而發(fā)愁),而同樣生產(chǎn)出軟件呢?這些思考讓我們創(chuàng)造出了如dBase, PowerBuilder, Clipper和Access這樣的工具,并促成了工具和語言相結(jié)合的4GL(第四代語言)的崛起,比如FoxPro和Access。但問題是,即使有這樣的工具和環(huán)境你也不能完成所有的工作。我同事Terry Dietzler為Access創(chuàng)建了一個叫做"80-10-10"的準(zhǔn)則(而我喜歡把它稱之為Dietzler定律)。這個定律說的是:80%的客戶需求可以很快完成;下一個10%需要花很大的努力才能完成;而最后的10%卻幾乎是不可能完成的,因為你不能把所有的工具和框架都"招致麾下"。而用戶卻希望能滿足一切需求,所以作為通用目的語言的4GL(Visual BASIC、Java、Delphi以及C#)應(yīng)運而生。Java和C#的出現(xiàn)主要是由于C++的復(fù)雜性和易錯性,語言開發(fā)者們?yōu)榱俗屢话愠绦騿T擺脫這些麻煩而在其內(nèi)建了一些相當(dāng)嚴(yán)格的限制。在此之后"80-10-10準(zhǔn)則"才發(fā)生了改變,無法完成的工作已經(jīng)微乎其微。這些語言都是通用目的語言,只要付出足夠的努力,大多數(shù)工作都可以完成。但Java雖然比較易用卻常常需要大量編碼,所以框架出現(xiàn)了,Aspects出現(xiàn)了,大量其它框架蜂擁而至。下面有一個例子。這段Java代碼是從一個廣泛使用的開源框架中提取出來的,試著找出它的用途吧(關(guān)于它的名字我只會提示你一點點):public static boolean xxXxxxx(String str) {int strLen;if (str == null || (strLen = str.length()) == 0) {return true;}for (int i = 0; i < strLen; i++) {if ((Character.isWhitespace(str.charAt(i)) == false)) {return false;}}return true;} 花了多少時間?這實際上是一個從Jakarta Commons框架(它提供了一些或許本該內(nèi)置于Java的幫助類和方法)中提取出來的isBlank方法。一個字符串是否為"空白"由兩個條件決定:這個字符串是空字符串,或者它只由空格組成。這段代碼的計算公式非常復(fù)雜,因為要考慮參數(shù)是null的情況,而且還要迭代所有的字符。當(dāng)然,你還要把字符包裝成Character類型以確定它是否空白字符(空格、制表符、換行符等)??傊?,太麻煩了!媒體關(guān)注與評論
對于程序員,過去我們一直習(xí)慣于用單純的技術(shù)水平,也就是實現(xiàn)程序功能的能力來衡量。然而這個時代其實已經(jīng)過去了。雖然技術(shù)仍然很重要,但企業(yè)越來越多地認識到,對于程序員更全面的衡量標(biāo)準(zhǔn),應(yīng)當(dāng)是生產(chǎn)率。只有能夠以較高的效率完成對項目、對企業(yè)有價值的工作,才是團隊和組織所真正需要的人才。反之,技術(shù)好,但不能真正促進整體價值,甚至其反作用,這樣的“技術(shù)牛人”已經(jīng)沒有生存空間了。 —— 孟巖 《程序員》雜志總編&ldq編輯推薦
《卓有成效的程序員》是一本揭示高效程序員的思考模式,一本告訴你如何縮短你與優(yōu)秀程序員的差距。以下媒體、專家、社區(qū)聯(lián)合推薦:媒體:《程序員》雜志、《電腦編程技巧與維護》雜志專家:韓磊、孟巖、馮大輝、李劍、黃晶、溫昱、周愛民名人推薦
《卓有成效的程序員》這本書,個人覺得單獨針對“程序員”可能還有點窄,其實《卓有成效的程序員》的大部分內(nèi)容對所有技術(shù)人員也是適用的。但愿看了《卓有成效的程序員》之后,能有更多的技術(shù)人員真正的行動起來,利用這本書提升自己,也去積極影響他人,形成更良性的互動,不要讓“持續(xù)改進”成為一句空話。另外,必須要補充的是,如果技術(shù)人員持續(xù)從事低效率的工作,極有可能逐漸厭煩技術(shù),疏遠技術(shù),乃至對技術(shù)絕望,而一個高效的技術(shù)人才能從技術(shù)中獲得真正的快樂。圖書封面
圖書標(biāo)簽Tags
無評論、評分、閱讀與下載