為了能幫程式設計師如何正確高效書寫程序
減少bug，小千也是經過一番地毯式的搜索
總得出一下經驗
這既不是九陰真經
又不是葵花寶典
有的只是小對泥萌的一片苦心
閱讀本篇文章只要三分鐘喲！
▼
寫代碼絕不是簡單無聊的勞動，程式設計師首先必須了解計算機的運行原理，然後需要把現實問題建模，並在計算機的世界裡精確地還原出問題的解決方案。既然代碼要交給功能強大的計算機去嚴格執行，程式設計師要擔負的責任就相當大，因為代碼的任何一點差異，都有可能影響程序最終的運行結果——因為程序的細小缺陷導致航天任務失敗的例子已經有好幾次了。
反過來說，程式設計師能掌握的權力相當大，成為「合格程式設計師」的門檻也相當高，雖然這種門檻並不為許多人所知，所以，要想成為稱職的程式設計師，必須正視寫代碼。
學校裡通常會安排程式語言的課程，但不會教「怎樣把程序寫好」的課程。許多人對計算機的理解還停留在「科學與理論」的角度，只要程序能「對」，能輸出正確結果就可以；卻不知道如今與計算機相關的大量工作，其重心已經轉移到實踐和工程意識的方面了。這種錯誤的理解，導致很多程式設計師在工作之後相當長的時間裡，學習的內容還局限於鑽研理論和算法，一直忽略了「把程序寫好」的補習。
其實市面上已經有一些教人「把程序寫好」的書籍，認真讀完這些書，認真落實其中的規範，至少能保證把程序寫「合格」，不會有明顯的缺陷，為將來把程序寫好奠定堅實的基礎。從我和身邊朋友的經驗出發，我覺得《代碼大全》、《重構》、《編程珠璣》、《程式設計師修煉之道》這幾本書都是很不錯的，如果能耐心讀完並認真思考，寫程序的水平會有相當的保證。
我們時常開玩笑說，現在很多程式設計師的工作，就是從網上下載一些開源項目，然後改改參數。其實這並非玩笑，而是很多程式設計師工作的真實寫照。充其量，他們還要做一些穿針引線的工作，把這些項目粘合組裝起來。
這看起來確實是簡單機械的勞動，也不會給人多少提升。但事實並非如此。很多好的程式設計師就在這個過程中學會了把代碼越寫越好。因為他們保持了好奇心，去探究這些開源項目的內部實現，把應用的過程當成了學習的途徑。在使用一個現成方案之前，先想想如果自己去解決要怎麼辦，再看看其他人的現成代碼，確保自己懂得了這些代碼蘊含的思維。
在談到寫程序時，經常有人引用奧卡姆剃刀原則，說「如無必要，勿增實體」；也有人引用愛因斯坦的話，「要足夠簡單，但不應該過於簡單」。由此證明，好的程序應當是足夠簡單而且非常優雅的。
在大方向上，我認同這種說法。但在具體的問題上，它未必正確。因為編程是與工程密切相關的工作，與工程密切相關就意味著大量的權衡、取捨。無論奧卡姆剃刀原則還是愛因斯坦的話，原本的主題都是針對理論的，所以兩者並不能嚴格劃等號。
在實踐中我見到過很多過份迷戀簡單、美感的程式設計師，我稱之為「玩套路」——他們太在意程序的形式美感，為了刻意追求那種嚴謹整齊的感覺而忽略了現實，也不懂得針對現實做出取捨，最終把自己套了進去。結果，用戶明明需要的一畝菜地，他們交付的卻是一份盆景，還振振有辭地指責用戶不懂技術。這樣的人，往往既當不好程式設計師，也成不了軟體開發工程師。
Code Review是提高代碼質量的有效手段，這一點大家公認。但是在很多場合，Code Review很難推行起來，原因之一就是程式設計師內心難以接受其他人對自己代碼的批評。
這種現象倒也情有可原，因為寫程序這回事，大家多少認為是有絕對標準，可以分出高下的。對大多數人來說，潛意識裡也確實很難區分「對我的工作的批評」和「對我的批評」。所以面對其他人對自己代碼的批評，除非是來自上級，否則多少有些面子上掛不住，天然有爭辯的衝動。
我們需要明白，不經歷挑戰和批評，人是很難提高的。其他人的批評，只要不是惡意的，總是能提供不一樣的視角，幫助我們更深入或者更全面的認識問題，這是很好的成長機會。
另一方面，團隊領導也應當營造平等合理的協作氣氛，倡導「對事不對人」的價值觀。這樣，才能讓更多的成員坦然接受對自己代碼的批評。
歸根到底，「榮譽感」是驅動個人不斷追求更高境界的源動力。對沒有榮譽感的程式設計師來說，「把程序寫好」充其量是不得已背上的負擔；而對於具有榮譽感的程式設計師來說，「把程序寫好」是需要不斷追求的目標。
程式設計師應當屬於德魯克說的「知識工作者」。對於知識工作者，我們就不能像對待機器和工人那樣去嚴格約束工作的過程，只能要求結果，或者說「找到合適的人，提供合適的環境，期待美好的事情發生」，這也是很多程式設計師享受的方式。但是，如果程式設計師不在乎自我驅動和追求，把寫程序當作不需要任何想像力和創造力簡單重複勞動，那麼「血汗工廠」的工作方式可能更能保證生產效率。
想獲取更多精彩內容
請關注千鋒互聯喲！
▼
▼