大棚解讀卓越程式設計師密碼

本原創文章屬於《Linux大棚》部落格。

部落格地址為http://roclinux.cn分上下兩篇

文章作者為roc

雨夜，北京，在家讀了《卓越程式設計師密碼》一書，覺得有一些內容值得回味，所以寫了這篇讀書筆記。

本書的封面：

卓越程式設計師密碼

本書的作者是Ka Wai Cheung，一看名字就知道是中國人，的確如此，作者名叫張家為，是一名程式設計師和設計師，同時也是美國芝加哥“We Are Mammoth”公司的聯合創始人，公司名稱翻譯成中文是“我們是猛獁”，很好玩的一個名字。

出於好奇，我看了We Are Mammoth的網站，網站設計的既有趣又有愛，可想而知，這是一家充滿活力的公司。如果大家有興趣，可以去那裡瀏覽他們的公司主頁。

這本《卓越程式設計師密碼》，並不厚，全書總共只有157頁，分為9個章節，分別是“引言”、“比喻”、“動力”、“生產力”、“複雜性”、“教學”、“客戶”、“程式碼”和“自豪感”。直到第8章才提到程式碼，足以說明這本書其實並不是教你如何程式設計的，而是教你如何高效的出色的完成任務的。

言歸正傳，我們來看看這本書裡哪些段落是值得回味和思考的。

【思想相通】

在程式設計的世界裡，我們會和各種各樣的“語言”打交道。雖然我主要的伺服器端開發語言是C#，但我的工作方法卻幾乎可以完全應用到Java、PHP、Ruby和Python上。程式語言雖然有不同，但核心的程式設計思想、方法和架構卻是高度類似的。我們只是用不同的方式來表達而已。

【普通人不瞭解程式設計】

大廚用不著琢磨烹飪要怎麼比喻，肉湯要是太鹹了，你一下就能嚐出來了；音樂家也不用這麼拐彎抹角地描述歌曲，一個調子聽起來太老套，是因為你早先就聽過一樣的節奏。別人一下就明白了。然而，程式設計可不大一樣。普通人看不出來什麼樣的程式碼優雅，什麼樣得程式碼一團糟。我們這個行業非常新。人類做飯、創作音樂、蓋房子都有幾千年了，可是考古學家還沒在巖壁上發現“人類坐在桌前打字”這種圖案。

【不要過度規劃】

在傳統的建築行業中，規劃是至關重要的。因為要建一個摩天大樓，撤銷（ctrl-z）、剪貼（ctrl-x）和拷貝（ctrl-c）都是行不通的。建築上沒法享受這些簡潔而強勁的案件，所以需要非常詳盡的說明書。日進斗金的房地產生意和災難性得頭條新聞之間就只有一步之遙。所以，要是打算建造一棟摩天大樓，把建築說明書寫得詳細到讓人想吐才是最合理的做法。

反過來，這些就是我們這個行業獨有得奢華享受了。軟體元件又不需要等著本地的工廠發運字母和數字。打字、編譯、測試，然後重複就行了。我們可以在實際產品上測試程式碼，而不用對著產品的某種模具測試。在開發過程中，我們可以看著懸索橋斷成千上萬次，在各種地方斷，在各種條件下斷，而不用擔心浪費材料或者鬧出人命。

在寫第一行程式碼之前做出非常詳細的說明書仍然有些好處，但這沒能充分利用到這種媒介的優勢。“規劃、規劃、規劃”過於強調要花大量時間計劃讓所有東西臻於完美，而忽視了可以用好實際寫程式碼的工夫。

【扔掉舊程式碼】

即使我確定要重新實現我前一陣子寫過的東西，早先註釋掉的東西一般來說也無論如何用不上。我可能把其他地方的邏輯動過了，舊程式碼裡面引用的物件或者方法可能也變了。比起重新干乾淨淨地把程式碼寫對，要把這舊程式碼救活，我得花上更多的時間在那兒東敲西補。

不要把程式碼囤積在註釋裡，刪除程式碼可以讓程式碼庫精簡。眼前的頁面應該精確地反映出軟體現在的工作方式，一分不多，一分不少。現在就扔掉舊程式碼，在程式設計中間就不用跳過一堆不相干得垃圾位元組。我們以後也用不著去琢磨，這一大團已經註釋掉可看起來還很重要的程式碼，到底還是不是那麼重要。

【多元化勝於專業化】

在傳統的建築行業裡，讓電工兼任水泥澆築工，或者讓鋪磚工去裝管道都是不現實的事情。他們都各有專長，各司其職。但把同樣的理念移植到我們這個行業就不大站得住腳了。我們工作所用的工具無非就在眼前的這塊螢幕上。如果正在搞SQL，也用不著要換個地方才能寫HTML或者是在Photoshop裡面弄上一張圖，只要在計算機上切換程式就行了。程式設計的科目之間，沒有任何物理上的障礙。

【工作即福利】

在我們這個行業裡，長久的動力並不來自於福利。當然，高薪和免費午餐確實不錯，能隨時玩玩桌上足球機也不賴。但歸根結底，長久的動力來自於我們所做的工作。我所見到的每個有激情的程式設計師，在談論起經過長時間苦苦思索才為技術問題找到的優雅解決方案時，都異常興奮，這比說起在公司程式設計大會上贏得10%的加薪要興奮得多。

【福利可能是毀滅性的】

表面化的福利實際上會削弱人們工作的積極性。是的，在我們面前晃動的胡蘿蔔可能讓我們更加沒有工作的激情。

傳統的商業激勵因素，比如大筆獎金，可能會成功調動員工的積極性，但只能用於那些簡單瑣碎的工作，類似於把資料從一張表填到另一張表這樣的工作。

相反，那些需要批判性分析和創造性解決方案的工作，就像我們每天面對的這些，把金錢獎勵掛在員工眼前晃悠則沒什麼用處。在一些涉及高層次思考的實驗中，金錢激勵和業績之間是負相關：給一組特定研究物件的金錢獎勵越多，他們最後做的越糟。

【別在臥室裡工作】

正如帕金森定律所說：“工作會不斷膨脹，直到佔滿所有可用的時間之後才會完成。”由於我們可以在一天中的任何時間工作，所以可佔用的時間就多了去了。每週40個小時的工作突然就變成了168小時的工作+睡覺+吃喝娛樂。

在家辦公是一種奢侈，如果你有幸享受這一點的話，千萬不要在臥室辦公，最好搞出一個封閉的房間，這樣就可以在工作時間結束後從那裡離開，在門上掛上“打烊”的牌子，然後去享受生活中的其他樂趣，第二天再繼續工作。

這才是真正的生活。

【對閒散專案堅決說不】

我們每個人都有一堆閒散專案，可能是寫了一半但從來沒完成的軟體，也可能是開始寫時幹勁十足，但因出現更緊迫的事情而戛然而止的程式碼。可以怪其他工作佔用了時間，也可能是我們自己已然失去了興趣。

這類閒散專案本身沒有嚴格的時間限制，而且不成功也沒有什麼關係，因此註定要失敗。如果它的釋出日期不定，只是“未來某年某月某日”，很可能我們近期就不會去完成它。

三個月怎麼樣？

Jack Dorsey用三個月開發了一個鮮為人知的簡訊服務，他從構思到釋出第一版所花的時間還不到三個月，這個服務就是後來的Twitter。試想一下，如果他年復一年地開發，而不是一旦開始就閃電釋出，那麼結果可能就大不一樣了。

【設定一個最後期限，即使是隨便設的】

制定了最後期限，工作才能得以完成，否則產品永遠難見曙光。最後期限提升了工作的重要性。如果讓一個專案從幾個月拖到幾年，你的產品可能就失去了開始時所期待得價值了。

最後期限創造了一種緊迫感，敦促你衝過終點線。即使沒有人再逼迫你，它也能給你你所需的鞭策。

【去掉時間表中的細節】

我搞軟體開發十二年，從來沒見過一個專案是完全按計劃走的。

功能會變，未預料到的障礙會出現。有時候，我們預計花一個星期的事情，最後花了三個星期。不過，最常見的事情是我們把專案時間制定得過於詳細，會讓我們成為時間的奴隸。所以，開始做計劃的時候，要少計劃些細節。一個八週的專案，找出八個每週要交付的成果，而不是四十個每天要交付的東西。

如果時間表太詳細，交付太頻繁，開發過程中就沒有做試驗伙食重新考慮細節的餘地。我們便只能嚴格遵守根據攝像出來的任務所設定的時間表，就好像被一個無知的“微觀經理”一直監督著一樣。一旦有幾個小任務沒按時完成，整個時間表就轟然坍塌了。這一點也不會激發我們的積極性，好的軟體不是這麼開發出來的。

【團隊是最寶貴的資產】

很多大公司都在兜售“人是我們最寶貴的資產”的陳詞濫調，聽起來就噁心。這些公司同時在用胸牌編號標識員工，用法購物卡的方式來挽救員工迅速消退的積極性，結果呢，還不是人員流動率居高不下。

說老實話，在我的小諮詢公司裡，人不是最寶貴的資產。而隨著時間建立起來的工作關係才是最重要的。我已經和幾乎同一批志趣相投的人一起工作了許多年，這種團隊內部的親密感意味著我們知道每個人喜歡的工作方式。

有些人喜歡細緻周到地工作，每一行程式碼都深思熟慮；有些人則粗枝大葉，再事後清理；有些人經常需要獨自工作，單槍匹馬解決問題；而有些人則一上來就需要協作。慢慢地，我們會以不同的方式互相彌補，我們會適應周圍的人。隨著時間的推移，我們開始凝聚在一起，真的是“凝”在一起。

【當心“知識魔咒”】

一旦你成為了某個領域的專家，就幾乎不可能明白對這個領域一無所知是什麼感覺。

想想你該如何向一個先天失明的人解釋是什麼顏色，或者向先天失聰的人解釋什麼是聲音。舉個不那麼極端的例子，想想律師吧，如果沒有各種抽象和限定，他就沒法準確回答法律問題。

這種現象就稱為“知識魔咒”。

【為簡化不妨說謊】

當你教一樣新東西的時候，不要認為你所說的每一句話都必須是百分之百正確的。要把一個概念從一開始就將得非常完美，既不現實，效果也不好。高階概念本來就難以理解，這也正是它成為高階概念的原因。

所以，在你成為專家之後，要先把你所在領域中那些錯綜複雜的細枝末節舍掉。不要講那些“除了”和“但是要…”之類的特殊情況，因為它們現在不那麼重要。稍微把事實扭曲一點沒什麼大不了的，講課時，善意的謊言並不見得是件壞事。

【專案管理主要是人的管理】

好的開發人員是軟體領域的專家，而好的專案經理是客戶領域的專家。他們和電話或郵件那頭的人形成了親密的工作關係。他們知道什麼時候可以拖延，或者什麼東西對於客戶來說是真正重要的。客戶工作對於專案經理來說可能是一場情緒上的掙扎。

【程式碼的迷人特質】

程式碼不會偷懶；

程式碼不會嫌煩；

程式碼很廉價；

程式碼不會遺忘；

程式碼執行很快；

可見，程式碼才是有史以來最偉大得初級程式設計師。

==

【結語】

這本書裡，包含了作者的很多感悟，其中一些思考和沉澱，不光對程式設計師有益，對於做很多事情都有指導作用。

如果有空，可以看看這本小書，再結合自己之前的工作體會，或許能有自己的一些理解和收穫！

謝謝！