書評：卓有成效的程式設計師的45個習慣

這個書名看起來似乎有些莫名其妙，因為其實它包含了三本書：

    * Practices of an Agile Developer（中文名《高效程式設計師的45個習慣》，即將出版）
    * The Productive Programmer（中文名《卓有成效的程式設計師》，已出版）
    * The ThoughtWorks Anthology（中文名《軟體開發沉思錄：ThoughtWorks文集》，已出版）

雖然最後一本書的中文標題裡包含“沉思”字樣，但總體來說其實這三本都是實踐性的很強的書，基本上是會告訴你“怎麼做”——當然同樣也會告訴你為什麼。基本上這三本小於等於200頁的小冊子陪伴了我半個多月來的上下班，上廁所已經睡覺前的時間，也帶給了我不少體會和思考。

有人可能會說，大學教育應該加強培養學生的實踐能力，不過我的看法正好相反。我倒想說，在學校裡就別再生產實踐上投入了，這是教不出來的。學校的老師現在基本上都是100%的博士畢業，科研出身，本身工業實踐可能就不足，除了照本宣科（而這實踐性的“本”可能本身就不怎麼樣），又能指導學生什麼東西呢？記得有段時間我又重新混跡於學校的BBS了，在系版上和講授Web基礎課程的老師爭論“標準佈局方式”，老師堅持認為佈局就該使用table，而CSS只是用來填充樣式，而並非用來佈局的。但此時已經是2008年了，我想只要簡單關心一些業界發展，也不應該出現這個情況。但是對於老師來說，他們的目標是科研，就像那位老師，除了這堂課，又何必瞭解Web開發的發展動態？而大學裡應該為學生以後發展打下堅實的基礎，授以“漁”，授以“能力”，至於實踐性的內容，自有實踐來培養，學校就不要做這些本不擅長的事情了，幾乎不可能做好。

我大學讀的是軟體學院，比較注重“實踐”。記得當時大一結束後系裡組織專案組，由於我專業成績比較好於是“光榮入選”。於是近20個人的專案組分為了幾個小組，各由1個研究生作PM。還有一個需求分析組。然後我們使用標準的瀑布型開發方式，從需求分析開始，產品設計，用例圖，時序圖，類圖一個一個地畫。記得文件的頁數，UML的複雜程度（當時叫“專業”程度）都是值得自豪的事情。最後很顯然，專案失敗了。似乎這樣轟轟烈烈的專案開發行動也沒有出現過，大一的學生都早早進入各實驗室進行有針對性地科研性培養，這點還是讓我非常高興的。

不知道現在的大學教育還有沒有這樣的情況，不過在我現在看來，似乎在那時我積累了不少誤區，而這些誤區基本上都產生在“實際生產”方面。例如我被不斷教導“語言是沒有用的，思想是關鍵”，但我幾年下來我愈發認識到“語言影響思想”；例如我也被不斷教導“程式設計師是沒有前途的，要做PM”，導致我當時也總喜歡談“設計”談“專案管理”，而現在我堅持認為自己是“光榮的程式設計師”。還有例如“做作測試沒有意義”等等，諸如此類，不一一列舉了。總之，我當時學習了許多的“反模式”，這些東西在我接觸“敏捷”，接觸實際生產過程，接觸前人在實際生產過程中總結的經驗之後都被一個一個推翻了，幾乎一個不留。當時我也很痛苦，認為自己過去浪費了很多時間。但是現在想想，這也是我的積累，至少我知道了什麼是錯的，我知道某個東西為什麼是對的，而並不都是紙上談兵。還有既然已經經歷過一次思維轉變，我想我也已經可以坦然接受未來新一輪的革命。想著想著，我也就坦然了。

因此，如果您也有這樣的經歷，我想也沒有任何問題——看準之後，馬上改變。在思維改變的過程中我看了很多書，其中有一本值得在現在提起，那就是《The Pragmatic Programmer: From Journeyman to Master》（中文名《程式設計師修煉之道——從小工到專家》）。這本書完全是實際經驗的總結，一條條建議基本上都是精華，現在看來亦有常讀常新之感。不過這本書的最大問題就是，說的很多，資訊量很大，但相對比較簡單（條條擴充就變成另一本《程式碼大全》了），於是對於沒有一定經驗的初學者來說，難以引起共鳴。當時我在看這本書的時候的心態也是“好書，講的是真理，一定要接受”，而並沒有進行更多的反思和比較，在我現在看來這種讀書方式是很危險的，我的幸運之處也在於“盲從”對了人。

之所以提起這本書，是因為《Practices of an Agile Developer》（中文名《高效程式設計師的45個習慣》，即將出版）被看作是它的後續，雖然我認為這“後續”並沒有達到前輩的高度——不過也正因為如此，我看來它可能更適合初學者，或者說更加實踐一些，更貼近普通生產過程，更容易按部就班的幹——幾乎告訴您應該怎麼做，並且需要考慮哪些東西了。這本書關注的是如何敏捷地構建出成功的軟體專案，其中涉及到各個方面。如一上來講的並非如何進行“專案管理”（可能敏捷本身就是淡化傳統軟體開發的管理，講究的是“自我管理”），它講的是 “態度”，作為每個開發人員來說該如何在專案中把握自己的做事方法。後來又談了開發人員的自我發展，如何開發，如何除錯，如何交付，如何協作等各個話題。

這本書把一個實踐分為三個部分：“魔鬼（錯誤的做法）”，“天使（正確的做法）”以及“平衡的藝術”。有趣的事，至少我從自己身上或身邊，也可能是工作上，或是社群裡發現了幾乎一一對應的“魔鬼現象”。例如書中一開始講的“態度”中提到“對事不對人”，這難道不正是最近部落格園的“熱點問題”嗎？此外，這本書吸引我的另一個原因是書中的許多說法讓我非常贊同，或者說“有共鳴”。例如書中說到“持續學習”，“架構師必須寫程式碼”，“用寫部落格等方式進行總結”，對我來說真可謂“正中下懷”。

這本書最大的問題並非是書中哪裡寫的不對，而是有些“成功學”的意味——許多“道理”的確都是正確的，但是關鍵還是要靠“執行”。說到底，不執行，知道再多正確的做法也沒有用。而且，在我平時看來，大家不是不知道該怎麼做，而是“不願意去做”。例如誰都知道要對專案負責，但是在別人都不負責的時候，你還願意負責嗎？書中說要交流要分享，但是各位也一定聽到過許多聲音，例如說“要有保留，否則你就失去了價值”—— 咋聽上去真很有道理，有些更直接就是書中所列舉的“魔鬼的誘惑”。書裡也談到一些“平衡的藝術”，但和現在流行的一些“辦公室政治”方面來看，算是小巫見大巫了。我是理想主義者，有人說我幼稚，所以您也要對我的說法進行獨立思考。:)

《The Productive Programmer》（中文名《卓有成效的程式設計師》，已出版）一書與前者不同，它的目標是“個人效率”，而不是“專案開發”。

這本書分為兩個部分，第一部分主要講的是工具的使用，其中提到了許多提高開發效率的方式，例如如何使用虛擬桌面，如何使用巨集、命令列和快捷鍵等等——裡面的確提到了許多我原本不知道的使用方式（例如把資源管理器的“根目錄”固定住）。對於Windows程式設計師來說，還有相當部分可以幫助我們瞭解其他平臺，如 Unix上的一些開發文化（如PowerShell和cygwin的使用。Unix平臺是面向程式設計師的平臺，其中總結出了許多開發經驗同樣可以運用在 Windows平臺上——即便有些*nix程式設計師不太相信這點，但是我對此深有體會。而書中的第二部分是“實踐”，通俗地說便是“如何寫出更好的程式”，其中談到了單元測試，談到了設計方式，談到了程式碼檢查工具等等——說實話，我認為與第一部分相比它並不怎麼出彩，有些老生常談的味道，隨便找本講敏捷程式設計的書就會談到這些內容——就好比那《45個習慣》。

既然是在進行“個人效率”的修煉，這更加涉及到“執行”問題了，例如誰都知道快捷鍵能提高效率，但是你願意努力去背快捷鍵，而不是繼續自己點選單的習慣嗎？還有便是，這本小冊子講的還是簡單了，當您看過了這本書之後，不妨再多關注一下它的提綱（好吧，其實就是“目錄”），然後針對其中的每一點再作進一步的挖掘。

最後便是《The ThoughtWorks Anthology》了。這本書是一群樂於思考，善於總結和分享的人的心得體會。其實每個公司都有許多專案，但為什麼ThoughtWorks總是給人一種“盛產思想領袖”的感覺呢？我認為這關鍵還是以Martin Fowler為首的“思想家”們的作用吧。他們在不斷地進行“思考”和“總結”，更重要的是不斷的分享“分享”——我並不是在誇他們nb，我的目的是想說 “其實你我也可以這麼做”。當然，我更不是在輕視他們，我也樂於和他們這樣的人一起工作。

刨開前言，這本書收錄了13篇文章（外國人咋不忌諱這個數字了？），有專案管理方面的：如何走好從“開發完畢”到“交付成功”這最後幾步路，如何使用“迭代經理”這個角色等等；也有專案實踐方面的內容：如何使用Ant構建專案，如何進行自動化的“一鍵釋出”，如何進行效能測試等等。也有一些程式設計方面的實踐，如DSL構建，多語言開發，物件“健身操”等等。基本上，可以認為是精華，值得一讀吧。這本書有些部分的確讓我開了眼界，讓我瞭解了不少我原本不太知道的內容（尤其是專案管理方面），這感覺好像我在大學裡第一次看到一些專案管理書一樣：“原來，這才是專業的做法啊”。但是，現在我比當年要謹慎了許多，很多東西我還是在專案開發過程中嘗試一下再發表意見吧。至於其他方面也大都不錯，可能這種型別的“總結”還是挺吸引我的。

總之，這三本書都值得一讀。但是這有個前提，首先您得主動思考而不是一味地機械吸收，但更重要的可能還是需要有效地“執行”——而這點可能只能靠您自己的，別人很難給予有效的幫助吧

忘說了，這三本書我看得都是中文版，翻譯地挺通順的，沒啥讀不明白的地方。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15783504/viewspace-624701/，如需轉載，請註明出處，否則將追究法律責任。