程式猿，你如何能寫好程式？

剛領證的著名程式員狗叔（@googollee），前幾周提出了很好玩的問題：“把程式寫好的知識，是從哪裡學來的呢？”。

我和狗叔回憶，我們好像都沒有正經上過什麼“把程式寫好”的教育訓練班，也沒有《九陰真經》之類的寶典。但是我們又都看到，很多程式員寫的程式是不合格的，大量基礎規範都沒有遵循（更可怕的是這樣的程式很可能還在服務我們每天的生活）。那麼，優秀的程式員，是從哪裡學到把程式寫好的知識的呢？

這個問題我想了很久，有幾點結論可以分享給大家。

首先，必須要正視“寫代碼”這回事

有很多人雖然做着程式員的工作，其實内心是看不起寫程式的。對他們來說，寫代碼隻是不得不經曆的初級階段，等到職業生涯發展了，就可以脫離這種單調無聊的工作了。但是，這種想法是錯的，有這種想法隻能說明對計算機和程式的認知還相當膚淺。寫代碼絕不是簡單無聊的勞動，程式員首先必須了解計算機的運作原理，然後需要把現實問題模組化，并在計算機的世界裡精确地還原出問題的解決方案。既然代碼要交給功能強大的計算機去嚴格執行，程式員要擔負的責任就相當大，因為代碼的任何一點差異，都有可能影響程式最終的運作結果——因為程式的細小缺陷導緻航天任務失敗的例子已經有好幾次了。

反過來說，程式員能掌握的權力相當大，成為“合格程式員”的門檻也相當高，雖然這種門檻并不為許多人所知。前段時間有很多人叫嚷“我萬事俱備，隻差一個寫代碼的”，恰恰是因為他們把寫程式看成簡單機械的勞動，但以自己的聰明才智又學不會這種“簡單機械”的勞動。這種沖突，恰恰說明寫程式是有門檻、有要求的。是以，要想成為稱職的程式員，必須正視寫代碼。

其次，必須讀過一些基本的書籍

學校裡通常會安排程式設計語言的課程，但不會教“怎樣把程式寫好”的課程。許多人對計算機的了解還停留在“科學與理論”的角度，隻要程式能“對”，能輸出正确結果就可以；卻不知道如今與計算機相關的大量工作，其重心已經轉移到實踐和工程意識的方面了。這種錯誤的了解，導緻很多程式員在工作之後相當長的時間裡，學習的内容還局限于鑽研理論和算法，一直忽略了“把程式寫好”的補習。

其實市面上已經有一些教人“把程式寫好”的書籍，認真讀完這些書，認真落實其中的規範，至少能保證把程式寫“合格”，不會有明顯的缺陷，為将來把程式寫好奠定堅實的基礎。從我和身邊朋友的經驗出發，我覺得《代碼大全》、《重構》、《程式設計珠玑》、《程式員修煉之道》這幾本書都是很不錯的，如果能耐心讀完并認真思考，寫程式的水準會有相當的保證。

要保持好奇心，多借鑒其它項目的内部實作

我們時常開玩笑說，現在很多程式員的工作，就是從網上下載下傳一些開源項目，然後改改參數。其實這并非玩笑，而是很多程式員工作的真實寫照。充其量，他們還要做一些穿針引線的工作，把這些項目粘合組裝起來。

這看起來确實是簡單機械的勞動，也不會給人多少提升。但事實并非如此。很多好的程式員就在這個過程中學會了把代碼越寫越好。因為他們保持了好奇心，去探究這些開源項目的内部實作，把應用的過程當成了學習的途徑。在使用一個現成方案之前，先想想如果自己去解決要怎麼辦，再看看其他人的現成代碼，確定自己懂得了這些代碼蘊含的思維。甚至比較相類似的幾個開源項目的源代碼，分析其優劣，在自己的工作中注重借鑒其長處，避免其短處。久而久之，寫程式的水準自然會有大的提升。

在寫程式時，要懂得在工程與理論之間求得平衡

在談到寫程式時，經常有人引用奧卡姆剃刀原則，說“如無必要，勿增實體”；也有人引用愛因斯坦的話，“要足夠簡單，但不應該過于簡單”。由此證明，好的程式應當是足夠簡單而且非常優雅的。

在大方向上，我認同這種說法。但在具體的問題上，它未必正确。因為程式設計是與工程密切相關的工作，與工程密切相關就意味着大量的權衡、取舍。無論奧卡姆剃刀原則還是愛因斯坦的話，原本的主題都是針對理論的，是以兩者并不能嚴格劃等号。

在實踐中我見到過很多過份迷戀簡單、美感的程式員，我稱之為“玩套路”——他們太在意程式的形式美感，為了刻意追求那種嚴謹整齊的感覺而忽略了現實，也不懂得針對現實做出取舍，最終把自己套了進去。結果，使用者明明需要的一畝菜地，他們傳遞的卻是一份盆景，還振振有辭地指責使用者不懂技術。這樣的人，往往既當不好程式員，也成不了軟體開發工程師。

坦然接受其他人對自己代碼的批評

code review是提高代碼品質的有效手段，這一點大家公認。但是在很多場合，code review很難推行起來，原因之一就是程式員内心難以接受其他人對自己代碼的批評。

這種現象倒也情有可原，因為寫程式這回事，大家多少認為是有絕對标準，可以分出高下的。對大多數人來說，潛意識裡也确實很難區分“對我的工作的批評”和“對我的批評”。是以面對其他人對自己代碼的批評，除非是來自上級，否則多少有些面子上挂不住，天然有争辯的沖動。我自己就遇到過好幾次這樣的情況，本來讨論理論和方案一切正常，隻要涉及到“看某人的代碼”，氣氛就随之大變。

我們需要明白，不經曆挑戰和批評，人是很難提高的。其他人的批評，隻要不是惡意的，總是能提供不一樣的視角，幫助我們更深入或者更全面的認識問題，這是很好的成長機會。相比起來，“丢面子”更多隻是一閃而過的，甚至根本隻是自己覺得很丢臉，其他人完全不在意的。為了怕“丢面子”而排斥其他人的批評，實在是得不償失。

另一方面，團隊上司也應當營造平等合理的協作氣氛，倡導“對事不對人”的價值觀。這樣，才能讓更多的成員坦然接受對自己代碼的批評。

程式員需要有對榮譽感的追求

歸根到底，“榮譽感”是驅動個人不斷追求更高境界的源動力。對沒有榮譽感的程式員來說，“把程式寫好”充其量是不得已背上的負擔；而對于具有榮譽感的程式員來說，“把程式寫好”是需要不斷追求的目标。

在我看來，程式員的榮譽感主要展現在兩個重要的方面。第一是對品質的追求，好的程式員一定會對自己傳遞的程式的品質負責，力求做到沒有缺陷，是以不會依賴code review來發現代碼的缺陷，也不會依賴測試來發現功能的缺陷…… 甚至要向上遊擴充了解問題的起因和目的，向下遊擴充了解程式運作的狀态和行為——這已經是“全棧工程師”的雛形了。

第二是對“用技術更好解決問題”的不斷思索和追求。程式與現實不完全相同，是以很多時候并不受現實的嚴格限制，程式能不能突破這些限制，如何突破這些限制，靠的就是程式員的榮譽感。現實中很多時候确實“魚與熊掌不可兼得”，但是在程式的世界裡，在某些情況下，魚與熊掌是可能兼得的。現實中“菜刀用來殺人”似乎是無解的，但在程式的世界裡，有些菜刀就可以做到不能用來殺人。普通人或許囿于現實生活經驗無法想想“魚與熊掌兼得”、“菜刀不能殺人”，但想把程式寫好的程式員，一定不能就此止步。

最後我想說的是，程式員應當屬于德魯克說的“知識工作者”。對于知識工作者，我們就不能像對待機器和勞工那樣去嚴格限制工作的過程，隻能要求結果，或者說“找到合适的人，提供合适的環境，期待美好的事情發生”，這也是很多程式員享受的方式。但是，如果程式員不在乎自我驅動和追求，把寫程式當作不需要任何想象力和創造力簡單重複勞動，那麼“血汗工廠”的工作方式可能更能保證生産效率。