編程大牛推薦，每個程序員都應該了解的學習資料、代碼技巧

接收程序員的技術早餐

作者｜陳皓

編輯｜小智

伸手黨福音。

在每個月月中，我會推薦一些有價值的內容，供你參考。這個月，我將為你推薦五篇閱讀文章，這五篇文章我覺得都是比較不錯的經驗總結，是我們每一個技術人員都需要知道的東西。它們分別是：

Stack Overflow 上開出來的一個經典書書單；

美國某大學教授給計算機專業學生的一些建議，其中有很多的資源；

LinkedIn 的高效代碼複查實踐，很不錯的方法，值得你一讀；

一份關於程序語言和 bug 數相關的有趣的報告，可以讓你對各種語言所有了解；

最後是一本 C++ 性能優化的非常有價值的電子書。

還有讀者留言表示對這個主題感興趣，希望我能推薦一些學習資料。這些內容基本都會在我的極客時間專欄《左耳聽風》中和大家分享。

每個程序員都應該讀的書

在 Stack Overflow 上有一個問題 What is the single most influential book every programmer should read，網址為：

https://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read

雖然這個問題被關閉了，但是這是一個非常熱門的問題。排在第一個的人給了一大串書的列表，看上去著實嚇人，不過都是一些相當經典相當有影響力的書，在這裡我重羅列一些我覺得你必需要看的。

《代碼大全》雖然這本書有點過時了，而且厚到可以墊顯示器，但是這是一本絕對經典的書。

《程序員修練之道》這本書也是相當的經典，我覺得就是你的指路明燈。

《計算機的構造和解釋》經典中的經典，必需讀的書。

《演算法導論》美國的本科生教材，這本書應該也是中國計算機學生的教材。

《設計模式》這本書是面向對象設計的經典書。

《重構》代碼壞味道和相應的代碼的最佳實踐。

《人月神話》這本書可能也有點過時了。但還是經典書。

《代碼整潔之道》細節之處的效率，完美和簡單。

《Effective C++》/《More Effective C++》C++ 中兩本經典得不能再經典的書。也許你覺得 C++ 複雜，但這兩本書中帶來對代碼穩定性的探索方式讓人非常受益，因為這種思維方式同樣可以用在其它地方。以至於各種模仿者，比如《Effective Java》也是一本經典書。

《Unix 編程藝術》、《Unix 高級環境編程》也是相關的經典。

還有好多，我就不在這裡一一列了。你可以看看其它的答案，我發現自己雖然讀過好多書，但也有好些書沒有讀過，這個問答對我也很有用。

計算機專業學生應有的知識

What every computer science major should know，每個搞計算機專業的學生應有的知識，網址為：

http://matt.might.net/articles/what-cs-majors-should-know/

本文作者馬修·邁特（Matthew Might）是美國猶他大學計算機學院的副教授，2007 年於喬治亞理工學院取得博士學位。計算機專業的課程繁多，而且隨著時代的變化，科目的課程組成也在不斷變化。如果不經過思考，直接套用現有的計算機專業課程列表，則有可能忽略一些將來可能變得重要的知識點。為此，馬修力求從四個方面來總結，得出這篇文章的內容。

要獲得一份好工作，學生需要知道什麼？

為了一輩子都有工作干，學生需要知道什麼？

學生需要知道什麼，才能考進研究生院？

學生需要知道什麼，才能對社會有益？

這篇文章不僅僅對剛畢業的學生有用，對有工作經驗的人同樣有用，這裡我把這篇文章的內容摘要如下。

首先，對於我們每個人來說，作品集（Portfolio）會比簡歷（Resume）更有參考意義。所以，在自己的簡歷中應該放上自己的一些項目經歷，或是一些開源軟體的貢獻，或是你完成的軟體的網址等。最好有一個自己的個人網址，上面有一些你做的事，自己的技能，經歷，以及你的一些文章和思考會比簡歷更好。

其次，計算機專業工作者也要學會與人交流的技巧，包括如何寫演示文稿，以及面對質疑時如何與人辯論的能力。

最後，他就各個方面展開計算機專業人士所需要的硬技能：工程類數學、Unix 哲學和實踐、系統管理、程序設計語言、離散數學、數據結構與演算法、計算機體系結構、操作系統、網路、安全、密碼學、軟體測試、用戶體驗、可視化、並行計算、軟體工程、形式化方法、圖形學、機器人、人工智慧、機器學習、資料庫，等等。詳讀本文可以了解計算機專業知識的全貌。

這篇文章的第三部分簡直就是一個知識資源嚮導庫，給出了各個技能的方向和關鍵知識點，你可以跟隨著這篇文章里的相關鏈接學到很多東西。

LinkedIn 高效的代碼複查技巧

LinkedIn"s Tips for Highly Effective Code Review，LinkedIn 的高效代碼複查技巧，網址為：

https://thenewstack.io/linkedin-code-review/

對於 Code Review，我有一篇文章 《從 Code Review 談如何做技術》，講述了為什麼 Code Review 是一件很重要事情。今天推薦的這篇文章是 LinkedIn 公司的相關實踐。

這篇文章介紹了 LinkedIn 公司內部實踐的 Code Review 形式。具體來說，LinkedIn 的代碼複查有以下幾個特點。

從 2011 年開始，強制要求在團隊成員之間做代碼複查。Code Review 帶來的反饋意見讓團隊成員能夠迅速提升自己的技能水平，這解決了 LinkedIn 各個團隊近年來因迅速擴張帶來的技能不足的問題。

通過建立公司範圍的 Code Review 工具，這就可以做跨團隊的 Code Review。既有利於消除 bug，提升質量，也有利於大家對代碼的學習和技能的傳播。

Code Review 的經驗作為員工晉陞的參考因素之一。

Code Review 的一個難點是，Reviewer 可能不了解某個修改的背景和目的。所以 LinkedIn 要求代碼簽入版本管理系統前，就對其做清晰的說明，以便複查者了解其目的，促進 Review 的進行。

我認為，這個方法實在在太贊了。因為，我看到很多時候，Reviewer 都會說不了解對方代碼的背景或是代碼量比較大而無法做 Code Review，然而，卻沒有找到相應的方法解決這個問題。

LinkedIn 對提交代碼寫說明文檔這個方法是一個非常不錯的方法，因為代碼提交人寫文檔的過程其實也是重頭梳理的過程。我的個人經驗是，寫文檔的時候通常會發現自己把事兒干複雜了，應該把代碼再簡化一下，於是就會回頭去改代碼。是的，寫文檔就是在寫代碼。

有些 Code Review 工具所允許給出的反饋只是代碼怎樣修改以變得更好，但長此以往會讓人覺得複查提出的意見都表示原先的代碼不夠好。為了提高員工積極性，LinkedIn 的代碼複查工具允許提出「這段代碼很棒」之類的話語，以便讓好代碼的作者得到鼓勵。我認為，這個方法也很贊，正面鼓勵的價值也不可小看。

為 Code Review 的結果寫出有目的性的注釋。比如「消除重複代碼」，「增加了測試覆蓋率」，等等。長此以往也讓團隊的價值觀得以明確。

Code Review 中，不但要 Review 提交者的代碼，還要 Reivew 提交者做過的測試。除了一些單元測試，還有一些可能是手動的測試。提交者最好列出所有測試過的案例。這樣可以讓 Reviewer 可以做出更多的測試建議，從而可以提高質量。

對 Code Review 有明確的期望，不過分關注細枝末節，也不要炫技，而是對要 Review 的代碼有一個明確的目標。

編程語言和代碼質量的研究報告

A Large-Scale Study of Programming Languages and Code Quality in GitHub，編程語言和代碼質量的研究報告，網址為：

https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/

這是一項有趣的研究。有四個人從 Github 上分析了 728 個項目，6300 萬行代碼，近 3 萬個提交人，150 萬個 commits，以及 17 種編程語言（如下圖所示），然後，他們想找到編程語言對軟體質量的影響。

然後，他們還對編程語言做了一個分類，想找到不同類型的編程語言的 bug 問題。如下圖所示：

以及，他們還對這眾多的開源軟體做了個聚類，如下圖：

對 bug 的類型也做了一個聚類，如下圖：

其中分析的方法我不多說了。我們來看一下相關的結果。

首先，他們得出來的第一個結果是，從查看 bug fix 的 commits 的個數情況來看，C、C++、Objective-C、PHP 和 Python 中有很多很多的 commits 都是和 bug fix 相關的，而 Clojure、Haskell、Ruby、Scala 在 bug fix 的 commits 的數明顯要少很多。

下圖是各個語言出 bug 的情況。如果你看到是正數，說明高於平均水平，如果你看到是負數，則是低於平均水平。

第二個結論是，函數式編程語言的 bug 明顯比大多數其它語言的要好很多。有隱式類型轉換的語言明顯產生的 bug 數要比強類型的語言要少很多。函數式的靜態類型的語言要比函數式的動態類型語言的程序出 bug 的可能性要小很多。

第三，研究者想搞清是否 bug 數會和軟體的領域相關。比如，業務型的，中間件型、框架、lib，或是資料庫。研究表明，並沒有什麼相關性。下面這個圖是各個語言在不同領域的 bug 率。

第四，研究人員想搞清楚 bug 的類型是否會和語言有關係。的確如此，bug 的類型和語言是強相關性的。下圖是各個語言在不同的 bug 類型的情況。如果你看到的是正數，說明高於平均水平，如果你看到的是負數，則是低於平均水平。

也許，這份報告可以在你評估語言時有一定的借鑒作用。

電子書：《C++ 軟體性能優化》

Optimizing Software in C++ - Agner Fog - PDF，C++ 軟體性能優化，

http://agner.org/optimize/optimizing_cpp.pdf

這本書是所有 C++ 程序員都應該要讀的一本書。這本書從事無巨細地從語言層面，編譯器層面，內存訪問層面，多線程層面，CPU 層面……講述了如果對軟體性能的調優。實在是一本經典的電子書。

Agner Fog 還寫了其它幾本和性能調優相關的書，你可以到這個網址下載：

http://www.agner.org/optimize/

Optimizing subroutines in assembly language: An optimization guide for x86 platformsThe microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for assembly programmers and compiler makers

Instruction tables: Lists of instruction latencies, throughputs and micro-operation breakdowns for Intel, AMD and VIA CPUs

Calling conventions for different C++ compilers and operating systems

我今天推薦的內容比較干，需要慢慢吸收體會，最好能借鑒到實踐中用用，相信會有更多的感悟和收穫。你還對哪些方面的內容感興趣，歡迎留言給我。我後面收集推薦內容的時候，會有意識地關注整理。

還想收穫更多？

現在訂閱，立享福利：

福利一：原價￥199/ 年，極客時間新用戶註冊立減￥30

福利二：每邀請一位好友購買，你可獲得 24 元現金返現，您的好友也將獲得 ￥12 元現金返現。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！