解讀卓越程序員密碼
雨夜，北京，在家讀了《卓越程序員密碼》一書，覺得有一些內容值得回味，所以寫了這篇讀書筆記。
卓越程序員密碼
本書的作者是Ka Wai Cheung，一看名字就知道是中國人，的確如此，作者名叫張家為，是一名程序員和設計師，同時也是美國芝加哥“We Are Mammoth”公司的聯合創始人，公司名稱翻譯成中文是“我們是猛犸”，很好玩的一個名字。
出于好奇，我看了We Are Mammoth的網站，網站設計的既有趣又有愛，可想而知，這是一家充滿活力的公司。如果大家有興趣，可以去那里瀏覽他們的公司主頁。
這本《卓越程序員密碼》，并不厚，全書總共只有157頁，分為9個章節，分別是“引言”、“比喻”、“動力”、“生產力”、“復雜性”、“教學”、 “客戶”、“代碼”和“自豪感”。直到第8章才提到代碼，足以說明這本書其實并不是教你如何編程的，而是教你如何高效的出色的完成任務的。
言歸正傳，我們來看看這本書里哪些段落是值得回味和思考的。
本書的封面：
【思想相通】
在編程的世界里，我們會和各種各樣的“語言”打交道。雖然我主要的服務器端開發語言是C#，但我的工作方法卻幾乎可以完全應用到Java、PHP、 Ruby和Python上。編程語言雖然有不同，但核心的編程思想、方法和架構卻是高度類似的。我們只是用不同的方式來表達而已。
【普通人不了解編程】
大廚用不著琢磨烹飪要怎么比喻，肉湯要是太咸了，你一下就能嘗出來了；音樂家也不用這么拐彎抹角地描述歌曲，一個調子聽起來太老套，是因為你早先就 聽過一樣的節奏。別人一下就明白了。然而，編程可不大一樣。普通人看不出來什么樣的代碼優雅，什么樣得代碼一團糟。我們這個行業非常新。人類做飯、創作音 樂、蓋房子都有幾千年了，可是考古學家還沒在巖壁上發現“人類坐在桌前打字”這種圖案。
【不要過度規劃】
在傳統的建筑行業中，規劃是至關重要的。因為要建一個摩天大樓，撤銷（ctrl-z）、剪貼（ctrl-x）和拷貝（ctrl-c）都是行不通的。 建筑上沒法享受這些簡潔而強勁的案件，所以需要非常詳盡的說明書。日進斗金的房地產生意和災難性得頭條新聞之間就只有一步之遙。所以，要是打算建造一棟摩 天大樓，把建筑說明書寫得詳細到讓人想吐才是最合理的做法。
反過來，這些就是我們這個行業獨有得奢華享受了。軟件組件又不需要等著本地的工廠發運字母和數字。打字、編譯、測試，然后重復就行了。我們可以在實 際產品上測試代碼，而不用對著產品的某種模具測試。在開發過程中，我們可以看著懸索橋斷成千上萬次，在各種地方斷，在各種條件下斷，而不用擔心浪費材料或 者鬧出人命。
在寫第一行代碼之前做出非常詳細的說明書仍然有些好處，但這沒能充分利用到這種媒介的優勢。“規劃、規劃、規劃”過于強調要花大量時間計劃讓所有東西臻于完美，而忽視了可以用好實際寫代碼的工夫。
【扔掉舊代碼】
即使我確定要重新實現我前一陣子寫過的東西，早先注釋掉的東西一般來說也無論如何用不上。我可能把其他地方的邏輯動過了，舊代碼里面引用的對象或者方法可能也變了。比起重新干干凈凈地把代碼寫對，要把這舊代碼救活，我得花上更多的時間在那兒東敲西補。
不要把代碼囤積在注釋里，刪除代碼可以讓代碼庫精簡。眼前的頁面應該精確地反映出軟件現在的工作方式，一分不多，一分不少?，F在就扔掉舊代碼，在編 程中間就不用跳過一堆不相干得垃圾字節。我們以后也用不著去琢磨，這一大團已經注釋掉可看起來還很重要的代碼，到底還是不是那么重要。
【多元化勝于專業化】
在傳統的建筑行業里，讓電工兼任水泥澆筑工，或者讓鋪磚工去裝管道都是不現實的事情。他們都各有專長，各司其職。但把同樣的理念移植到我們這個行業 就不大站得住腳了。我們工作所用的工具無非就在眼前的這塊屏幕上。如果正在搞SQL，也用不著要換個地方才能寫HTML或者是在Photoshop里面弄 上一張圖，只要在計算機上切換程序就行了。編程的科目之間，沒有任何物理上的障礙。
【工作即福利】
在我們這個行業里，長久的動力并不來自于福利。當然，高薪和免費午餐確實不錯，能隨時玩玩桌上足球機也不賴。但歸根結底，長久的動力來自于我們所做 的工作。我所見到的每個有激情的程序員，在談論起經過長時間苦苦思索才為技術問題找到的優雅解決方案時，都異常興奮，這比說起在公司編程大會上贏得10% 的加薪要興奮得多。
【福利可能是毀滅性的】
表面化的福利實際上會削弱人們工作的積極性。是的，在我們面前晃動的胡蘿卜可能讓我們更加沒有工作的激情。
傳統的商業激勵因素，比如大筆獎金，可能會成功調動員工的積極性，但只能用于那些簡單瑣碎的工作，類似于把數據從一張表填到另一張表這樣的工作。
相反，那些需要批判性分析和創造性解決方案的工作，就像我們每天面對的這些，把金錢獎勵掛在員工眼前晃悠則沒什么用處。在一些涉及高層次思考的實驗中，金錢激勵和業績之間是負相關：給一組特定研究對象的金錢獎勵越多，他們最后做的越糟。
#p#
【別在臥室里工作】
正如帕金森定律所說：“工作會不斷膨脹，直到占滿所有可用的時間之后才會完成。”由于我們可以在一天中的任何時間工作，所以可占用的時間就多了去了。每周40個小時的工作突然就變成了168小時的工作+睡覺+吃喝娛樂。
在家辦公是一種奢侈，如果你有幸享受這一點的話，千萬不要在臥室辦公，最好搞出一個封閉的房間，這樣就可以在工作時間結束后從那里離開，在門上掛上“打烊”的牌子，然后去享受生活中的其他樂趣，第二天再繼續工作。
這才是真正的生活。
【對閑散項目堅決說不】
我們每個人都有一堆閑散項目，可能是寫了一半但從來沒完成的軟件，也可能是開始寫時干勁十足，但因出現更緊迫的事情而戛然而止的代碼?？梢怨制渌ぷ髡加昧藭r間，也可能是我們自己已然失去了興趣。
這類閑散項目本身沒有嚴格的時間限制，而且不成功也沒有什么關系，因此注定要失敗。如果它的發布日期不定，只是“未來某年某月某日”，很可能我們近期就不會去完成它。
三個月怎么樣？
Jack Dorsey用三個月開發了一個鮮為人知的短信服務，他從構思到發布第一版所花的時間還不到三個月，這個服務就是后來的Twitter。試想一下，如果他年復一年地開發，而不是一旦開始就閃電發布，那么結果可能就大不一樣了。
【設定一個最后期限，即使是隨便設的】
制定了最后期限，工作才能得以完成，否則產品永遠難見曙光。最后期限提升了工作的重要性。如果讓一個項目從幾個月拖到幾年，你的產品可能就失去了開始時所期待得價值了。
最后期限創造了一種緊迫感，敦促你沖過終點線。即使沒有人再逼迫你，它也能給你你所需的鞭策。
【去掉時間表中的細節】
我搞軟件開發十二年，從來沒見過一個項目是完全按計劃走的。
功能會變，未預料到的障礙會出現。有時候，我們預計花一個星期的事情，最后花了三個星期。不過，最常見的事情是我們把項目時間制定得過于詳細，會讓 我們成為時間的奴隸。所以，開始做計劃的時候，要少計劃些細節。一個八周的項目，找出八個每周要交付的成果，而不是四十個每天要交付的東西。
如果時間表太詳細，交付太頻繁，開發過程中就沒有做試驗伙食重新考慮細節的余地。我們便只能嚴格遵守根據攝像出來的任務所設定的時間表，就好像被一 個無知的“微觀經理”一直監督著一樣。一旦有幾個小任務沒按時完成，整個時間表就轟然坍塌了。這一點也不會激發我們的積極性，好的軟件不是這么開發出來 的。
【團隊是最寶貴的資產】
很多大公司都在兜售“人是我們最寶貴的資產”的陳詞濫調，聽起來就惡心。這些公司同時在用胸牌編號標識員工，用法購物卡的方式來挽救員工迅速消退的積極性，結果呢，還不是人員流動率居高不下。
說老實話，在我的小咨詢公司里，人不是最寶貴的資產。而隨著時間建立起來的工作關系才是最重要的。我已經和幾乎同一批志趣相投的人一起工作了許多年，這種團隊內部的親密感意味著我們知道每個人喜歡的工作方式。
有些人喜歡細致周到地工作，每一行代碼都深思熟慮；有些人則粗枝大葉，再事后清理；有些人經常需要獨自工作，單槍匹馬解決問題；而有些人則一上來就 需要協作。慢慢地，我們會以不同的方式互相彌補，我們會適應周圍的人。隨著時間的推移，我們開始凝聚在一起，真的是“凝”在一起。
【當心“知識魔咒”】
一旦你成為了某個領域的專家，就幾乎不可能明白對這個領域一無所知是什么感覺。
想想你該如何向一個先天失明的人解釋是什么顏色，或者向先天失聰的人解釋什么是聲音。舉個不那么極端的例子，想想律師吧，如果沒有各種抽象和限定，他就沒法準確回答法律問題。
這種現象就稱為“知識魔咒”。
【為簡化不妨說謊】
當你教一樣新東西的時候，不要認為你所說的每一句話都必須是百分之百正確的。要把一個概念從一開始就將得非常完美，既不現實，效果也不好。高級概念本來就難以理解，這也正是它成為高級概念的原因。
所以，在你成為專家之后，要先把你所在領域中那些錯綜復雜的細枝末節舍掉。不要講那些“除了”和“但是要…”之類的特殊情況，因為它們現在不那么重要。稍微把事實扭曲一點沒什么大不了的，講課時，善意的謊言并不見得是件壞事。
【項目管理主要是人的管理】
好的開發人員是軟件領域的專家，而好的項目經理是客戶領域的專家。他們和電話或郵件那頭的人形成了親密的工作關系。他們知道什么時候可以拖延，或者什么東西對于客戶來說是真正重要的。客戶工作對于項目經理來說可能是一場情緒上的掙扎。
【代碼的迷人特質】
代碼不會偷懶；
代碼不會嫌煩；
代碼很廉價；
代碼不會遺忘；
代碼運行很快；
可見，代碼才是有史以來最偉大得初級程序員。
==
【結語】
這本書里，包含了作者的很多感悟，其中一些思考和沉淀，不光對程序員有益，對于做很多事情都有指導作用。
如果有空，可以看看這本小書，再結合自己之前的工作體會，或許能有自己的一些理解和收獲！
謝謝！
