本文作者余晟，來自其微信公眾號“余晟以為”，原文題目為《“把程序寫好”這回事》

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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