私以為可以提高程式設計師技術檔次的書和部落格

為什麼中國的程式設計師總是在不斷學習新的開發工具、鑽研程式程式碼，而不逐步提升自己的視野、思維和經驗？

（注意：本文閱讀量在2016.08.26日正常的為150+左右，為了測試閱讀量的不合理計算方法，我寫了一個小程式將其刷到了2056。關於閱讀量的不合理計算方式的bug，已經提交到http://www.ituring.com.cn/article/17095 。正常的閱讀量 = 當前閱讀量 - 1900）

(已同步更新到專欄文章：私以為可以提高程式設計師技術檔次的書和部落格 - 杜小豆的程式設計小道 - 知乎專欄)

我大膽把程式設計師分為兩種——工人與藝人。

工人，類似於泥瓦匠，按部就班，可以做好本職工作，但不具備創造性，在程式設計時也沒有考慮系統的架構、各模組之間的分工等。這種人往往死守某一種語言或技術，不肯接納新思想，也拒絕接受新的技術。其最大的特點就是，寫出的程式碼能勉強能執行，但沒有經過任何重構，程式碼完全是一團錯綜曲折的雜醬麵。這種匠人有許多稱呼，如碼農、IT民工。

藝人，即是藝術家。我們常聽見有人說程式設計是一門藝術，他們口中所說的就是這類人。藝人級別的程式設計師，所寫的程式碼精煉簡潔，架構優良，各模組分工明確且結構清晰。他們選用某種語言，不是因為它流行，而是因為它適合，因此他們不會拘泥於語言，追求完美與極致。這種藝人也有許多稱呼，如黑客、極客。

侷限於某門程式語言，並實現工人到藝人的華麗轉變。按照這個標準，我推薦了以下書籍：

1.《程式碼的未來》：松本行弘，程式設計的本質是思考。

關於作者

Ruby之父

程式設計的本質是什麼？

程式設計的本質是思考。

什麼又是程式設計？

創造出一種人類和計算機都能夠理解的語言（程式語言），並通過這樣的語言將人類的意圖傳達給計算機，這樣的行為就叫做程式設計。

我是在大學在讀到這本書的，在此之前，我已有了3年多程式設計經歷。但不可避免的，在讀到這本書之前，我對程式設計的理解卻仍然淡薄。 我曾經在學習組合語言的過程中，得到了老師的善意提醒：“組合語言已經過時了，沒多少人用，現在主流的語言是JAVA，你應該學習JAVA。”

我非常困惑，因為在此之前，我同樣得到另一個人的提醒：“語言只是一種工具，真正的高手，不管用什麼程式語言都一樣。”

剛學的語言卻早已過時，剛進入正軌卻要重新開始......你很難想象當時的我有多麼低落。

這，還不是最可怕的。

可怕的是老師還告訴你：“現在都是視覺化程式設計，不用再寫那麼多程式碼，需要什麼直接用就好了，就像搭積木一樣。未來的話，可能只需要你把你的需求告訴程式設計軟體，它就自動為你生成程式碼了。”

恐懼！

我第一次感覺到學了程式設計沒有任何意義，因為我跟不上時代發展的潮流，世界每一天都在變化，並且，很快就會將我拋棄。

如果你對此沒有太多感觸，不以為然，那麼，你可以看看現在層出不窮的新語言、新技術、新思想，你覺得你曾經學的東西還能支撐多久？而智慧程式替換掉你的那一天，又會在什麼時候到來？

我的恐懼是在讀到這本書之後才煙消雲散，或許是隨著接觸的程式語言增多，我對程式設計有了更多的認識，又或者，是這本書給了我一個善意的謊言，讓我有了繼續堅持下去的勇氣。

程式設計的本質是思考。

這意味著，語句中是用for還是while，程式語言是採用程式導向還是物件導向，對話方塊是放置到左邊還是右邊......這一切一切的背後，都是思考。

換句話說，無論你用多麼高效的語言，多麼強大的框架，多麼牛逼的程式設計思想，該寫的程式碼還是要寫，該解決的問題還是要解決。最終，程式設計還是得靠你的大腦思考，思考，就是程式設計的本質。

至於仍在擔心的問題：未來的某一天，程式設計師這個職業會被更智慧的程式設計軟體（AI）替代，從此消亡。

這個不是放棄程式設計的理由，因為既然AI能夠替代程式設計師，那麼也就意味著它能替代掉更多是人。要擔心的不是我們程式設計師應該怎麼辦，而是，我們人類該怎麼辦？

2.《程式設計高手箴言》：樑肇新，做一個程式設計師一定要有耐心。

關於作者

豪傑超級解霸作者（過去的豪傑超級解霸 == 現在的暴風影音）

程式與軟體是一樣的麼？

程式不等於軟體。

程式與軟體的區別是什麼？

程式要變成軟體，這中間是一個商業化的過程。

在此之前，你可能從某些方面知道了它們的區別：軟體 = 程式 + 文件；規模小的是程式，規模大的是軟體；寫的差的是程式，寫的好的是軟體......

但是，這是第一本從商業的角度探討程式與軟體區別的書。不僅如此，這本書還在程式設計人員的程式設計習慣、學習態度、個人發展、產品商業化等方面都給出了可供參考的見解。

如果你需要的不是那種完全是講解技術的書籍，而是能夠擴充你的思維，那麼這本書或許能夠給你更多的思考。

（注意：本書涉及到的技術較為底層，且同其他程式設計書籍一樣，技術講解佔據很多）

3.《UNIX程式設計藝術》： Eric S. Raymond ，KISS。

關於作者

《大教堂與集市》的作者

UNIX的哲學是什麼？

一個程式只做一件事，並做好。

程式要能協作。

一個好的程式應該遵循哪些原則？

簡潔原則：設計要簡潔，複雜度能低則低 。 吝嗇原則：除非確無它法，不要編寫龐大的程式。 緘默原則：如果一個程式沒什麼好說的，就保持緘默。 優化原則：雕琢前先得有原型，跑之前先學會走。 擴充套件原則：設計著眼未來，未來總比預想快。 KISS原則：Keep It Simple, Stupid!

聽說Unix/Linux不錯，作為一個合格的程式設計師應該去嘗試一下。

於是你下載安裝了Ubutu/RedHat，開啟了桌面環境，單擊雙擊，複製貼上。

呃，Unix/Linux相比Windows，沒什麼不同嘛！

Unix相對於Windows,其最大的特色，我覺得就是程式之間的協作，也就是管道。圍繞管道而設計出來的程式，便會順理成章的去遵循上面提出的幾個原則。

如果你認同Linux的設計哲學，那麼你可以看看這本書。

這本書在模組化、文字化、配置、介面、複雜度、優化、可移植性等方面，都提供了Unix/Linux世界所積累的寶貴經驗。

好的程式可以經受時間、平臺與使用者的考驗，好的程式設計思想可以經受實踐的檢驗。

附：

不懂UNIX的人註定最終還要重複發明一個蹩腳的Unix。 Those who do not understand Unix are condemned to reinvent it, pooly。 —— Usenet 簽名， Henry Spencer

4.《程式設計師修煉之道:從小工到專家》：Andrew Hunt / David Thomas， 死程式不說謊。

關於作者

本書作者

“拿來就用”主義應該受到鄙視嗎？

你不是在窺探，你是在向他們學習。而且要記住，訪問是互惠的——不要因為別人鑽研你的程式碼而苦惱。

怎樣看待抽象與細節？

將抽象放進程式碼，細節放進後設資料(put abstractions in code, details in matadata) 。

複用，俗稱Copy，文人稱之為拿來主義。在站在巨人的肩膀上與獨立自主的爭論中，複用與造輪子各自朝著不同的方向快速發展著。

有一種觀點認為一個好的程式設計師應該自己從底層做起，而不是去複製貼上別人的程式碼。但隨著開源運動的崛起，以及程式設計師所做的大量重複工作，迫使我們對複用有了更深的認識。

這本書可以看作是對《UNIX程式設計藝術》的補充，是對程式設計好程式所應遵循原則的進一步闡述。同時相比上一本書，本書更著重於實際的建議：如何劃分呼叫者與被呼叫者之間的職責範圍，如何處理傳遞給函式的引數，如何正確除錯等。

在使用者需求的看法上，本書不同於其他主流觀點，推崇挖掘需求——不要蒐集需求，挖掘它們。(don't gather requlrementsdig for them) 。

它不是字典般的程式碼大全，卻更像是百科全書般的程式設計指南。

5.《重構:改善既有程式碼的設計》： Martin Fowler， 事不過三，三則重構。

關於作者

協助創作了“敏捷軟體開發宣言”

什麼是重構？

重構，是這樣一個過程，在不改變程式碼外在行為的前提下，對程式碼做出修改，以改程式序的內部結構。

為什麼要重構？

任何一個傻瓜都能寫出計算機可以理解的程式碼，唯有寫出人類容易理解的程式碼，才是優秀的程式設計師。

我對大學程式設計類課程的一個感受時，大學老師不會講授軟體除錯。

除錯對軟體開發而言，無疑是非常重要的一個步驟，因為它能發現軟體中存在的很多語法問題與邏輯問題。 但就算如此重要的除錯，也只是發現了程式碼的表面問題，更深層次的架構設計之類，仍需要藉助與重構。

重構，通俗的稱修改程式碼，或者程式碼優化。

在多數程式設計師處於匠人級別，是因為他們所寫的程式碼僅僅是勉強能夠執行，沒有達到優化原則，在進階藝人的臺階上，止步不前。

開源軟體之所以在軟體質量上通常都遠高於閉源軟體，很重要的一個原因是開源軟體有更多的人蔘與軟體的重構工作，不斷修正軟體中不完美的設計或元件。

重構不是修復Bug，而是一個把“玩具”變為“可用產品”的優化過程，琢石成器！

重構也不是隨便看到哪裡不順眼就立即去修改，它有一些必須遵循的基本規範，其中最重要的一個就是“在不改變軟體可觀察行為的前提下改善其內部結構”。

這也意味著，使得在重構完成後，不會影響軟體的正常使用，同時儘量減少重構之後的程式碼除錯。

由於每次修改的幅度都很小，所以任何錯誤都很容易發現，你不必耗費大把時間除錯。

遵循合適的重構規範，重構之後的軟體，在使用者眼中它與重構前的軟體沒有任何差異，但在程式碼內部，軟體小麻雀卻早已“飛上枝頭變鳳凰”，變得更加強健、簡潔、易於維護等。

同時，重構也不是一個永無止境的過程，要懂得適可而止。在重構的過程中，要時刻謹重構的目的是為了解決軟體結構中的問題，而不是為了程式設計完美的程式碼。

單憑對完美的追求無法寫出實用的程式碼，而“實用”是軟體壓倒一切的要素。

附：

我不是個偉大的程式設計師，我只是個有著一些優秀習慣的好程式設計師。 —— Kent Beck

6.《人月神話》: 弗雷德裡克.布魯克斯， 向進度落後的專案中增加人手，只會使進度落後。

關於作者

主持開發OS/360

如何處理大型專案中的管理問題？

我相信由於人員的分工，大型程式設計專案碰到的管理問題和小專案碰到的管理問題區別很大；我相信關鍵需要的是維持產品自身和概念完整性。

為什麼我們時常陷入產品延期的僵局？

系統程式設計的進度安排背後的第一個錯誤的假設是：一切都將運作良好，每一項任務僅花費它所應該花費的時間。

這是一本被軟體開發人員（特別是專案管理人員）推崇的神書，能夠獲得如此尊稱的書並不多，除《人月神話》之外，《計算機程式設計藝術》也是其中之一。

我在多年前曾接觸到這本書，當時我並沒有任何團隊開發經驗，讀這本書只是它的名聲實在過於響亮。不幸的是第一次它給我的印象並不是很好，覺得百般無聊，如讀天書，很快我就將它擱置在一旁。

直到高三那年我和3位好友創業失敗，在創業過程中暴露出來的問題，以及自己在團隊開發過程中學到的種種經驗，才使得當我再次捧起這本書時，如若知己。

《人月神話》中的人代表參與開發工作的人員數量，月代表開發週期。在很多人眼中，人月是可以互換的，也即是安排更多的人員參與開發，那麼開發工作只需要更短的月就可以完成。

但正如作者在書中所言：

我們圍繞成本核算的估計技術，混淆了工作量和專案進展。人月是危險和帶有欺騙性的神話，因為它暗示了人員數量和時間是可以相互替換的。

專案的時間依賴於順序上的限制，人員的最大數量依賴於獨立子任務的數量。

最終，我們得到了著名的布魯克斯法則：

向進度落後的專案中增加人手，只會使進度落後。

這只是作者在實踐中總結出的眾多心得之一，除此之外，本書還涉及了其他軟體開發與專案管理中出現的各種問題，如功能的取捨、手冊編寫、制定開發週期等。

如果你沒有任何團隊開發經驗，我不建議你讀這本書。

如果你已經參與團隊開發，並且深陷專案管理的焦油坑，本書將帶給你更多有價值的思考。

附：

手中有個錘子，看到什麼都是釘子。

7.《黑客與畫家》：Paul Graham， 程式設計是一種藝術創作，黑客就是藝術家。

關於作者

創業投資公司Y Combinator創始人

程式語言對我們的思維有何影響？

你選擇什麼語言，決定了你能說什麼話。程式語言就是程式設計師的思維方式。

什麼才能成為一個優秀的黑客？

優秀的黑客養成了一種質疑一切的習慣。

一直以來，程式設計師總是給人一種呆子的錯覺。他們木訥、情商低下、不善言辭.......普通人很難理解這些呆子，因為在作者看來：

書呆子已經在思考的東西，正是真實世界看重的東西。

換而言之，他們不是呆，他們只是在專於他們著迷的問題。

這本書是一個程式設計師到藝術家的轉變之路，使得程式設計師不再執著於技術，而是對商業、設計等都有更深的認識。

對於很多人盲目追求新語言、新技術，或者其他流行的東西，本書的觀點是：

他們接受流行，不是因為想要與眾不同，而是因為害怕與眾不同。

對於那些被動跟著潮流而動，卻又想要看到潮流方向的人，這本書狠狠得打了他們一個耳光：

如果自己就是潮水的一部分，怎麼能看見潮流的方向呢？

附：

世界潮流，浩浩蕩蕩。順之則昌，逆之者亡！

8.《大教堂與集市》， Eric S. Raymond，只要眼睛多，Bug容易捉。

關於作者

《UNIX程式設計藝術》的作者

怎樣才能寫出好的軟體作品？

好的軟體作品，往往源自開發者的個人需要。

如何成為一個優秀的程式設計師？

優秀的程式設計師知道寫什麼，卓越的程式設計師知道改寫和重用什麼。

一直以來存在著兩種開發模式：大教堂與集市。 第一中模式中，軟體開發人員類似於大教堂中專門研究神學的神職人員，關在小黑屋裡，每日每夜的和其他人一起精雕細琢。通俗的講，這就是集中力量辦大事。要想進入此道，需有一個神職人員特許證。

第二個模式中，軟體開發人員就是集市中熙熙攘攘的商販。你可以隨意參與你感興趣的開發工作，而他人的成果也對你開放，不會被供奉在神探供他人景仰。如果你覺得某個軟體用起來不爽，或者有什麼問題，沒關係，自己修改一下，然後再將它奉獻給集市。通俗的講，這就是人多力量大。要想進入此道，需要一種拿來就用，不爽就改的開源精神。

這是一本可以引領你進入開源世界的書，你頑固不化且邪惡的靈魂若想得以解脫，需每日誠心誦讀全文，並按照大神指引的精神之路，參與開源事業。若你違反開源協議，將開源作品採用虛假手段作為個人的榮譽或公司產品，並給其披上邪惡的偽裝，你將被世代釘在開源世界的恥辱柱！遭受所有程式設計師的不屑！

附：

開源是第一生產力。

9.《失控》，凱文·凱利 ，量變引起質變。

關於作者

maverick（遊俠）

什麼是量變引起質變？

大量個體和少量個體的行為存在重大差異。群聚的個體孕育出必要的複雜性，足以產生湧現的事物。隨著成員數目的增加，兩個或更多成員之間可能的相互作用呈指數級增長。當連線度高且成員數目大時，就產生了群體行為的動態特性——量變引起質變。

如何看待資訊化所帶來的民主？

在任何社會中，只要交流和資訊連線的強度適中，民主就必然出現，在思想自由流動併產生新思想的地方，政治組織會最終走向民主這個必然的自組織的強大的吸引子。

剛進大學時，輔導員就強調一句話——量變引起質變。當然聽著，感覺還有些哲理，但一直苦於不知道其出處。後來終於在這本書裡看到了它。

本書作者是網際網路教父般的凱文·凱利，簡稱KK。《失控》一書寫作於1994年，其全稱是《失控：機器、社會與經濟的新生物學》。

這本書探討了可能在當下也依然熱門的很多問題，如蜂群思維、控制論、分散式計算、蝴蝶效應、人工智慧、混沌理論...... 很難想象，這樣一本對未來飽有遠見的書，卻寫於20多年前。而在20多年後，它仍被很多人推崇，其價值可見一斑。

近些年人工智慧領域突發猛進，也引發越來越多的人，開始擔憂人與機器的新生。對此，KK在書中是如何評論的：

在將生命的力量釋放到我們所創造的機器中的同時，我們就喪失了對他們的控制。

而隨著網路的快速發展，我們也有幸見證了微博反腐的變革，資訊化所推動的民主革新，不可避免。對此，KK在書中又是這樣論斷：

唯有龐大的網狀結構才能包容形態的真正多樣性。這就是為什麼網路差不多與民主和市場意義等同的原因。

而在社交網路，若你有幸是一箇中心結點，那麼你的價值也會隨著與他人直接或間接的連線而提高。對此，KK在書中又是這樣：

他們的聯絡越多，我的聯絡就變得越有價值。

這就是你要的思想著作，精神洗禮，靈魂深造！

附：

網路符號象徵著心智的迷茫，生命的糾結，以及追求個性的群氓。

10.**《哥德爾、艾舍爾、巴赫——集異璧之大成》：侯世達，**quaerendo invenietis（覓之，自有所獲）

關於作者

Douglas Richard Hofstadter，中文名為侯世達，本書獲普立茲獎。

什麼是侯世達定律？

做事所花費的時間總是比你預期的要長，即使你的預期中考慮了侯世達定律。

怎樣才能創造出靈活的智慧？

智慧的靈活性來自大量的不同規則和規則的層次。

《哥德爾、艾舍爾、巴赫——集異璧之大成》，分為《集異壁GEB》與《異集壁EGB》 上下兩篇。其英文原書名為《Godel, Escher, Bach--an Eternal Golden Braid》，其中braid一詞有2種含義：

1. 辮子，名詞
2. 編織，動詞

標題中的braid具有雙關的作用。

作為數學名詞暗示了正題和副題之間有“G，E，B”和“E，G，B”這種詞首字母在次序上的照應。

而對於中文標題中的“G、E、B”，分別對應著"Godel、Escher、Bach"，即是“哥德爾、埃舍爾、巴赫”。由此擴充套件下去，又代表著“哥德爾的哥德爾不完備定理、埃舍爾的畫、巴赫的音樂”。

好吧，之所以對一個書名都如此糾結，是因為這本書是一本跨度很大，且非常燒腦的書。

按照作者侯世達在”鳴謝“與“導言”中自述，本書在他的腦海中醞釀了幾乎有二十年之久，起初他打算寫一篇以哥德爾定理為核心的小冊子，後來想法像球面一樣擴充套件開來，不久就觸及了巴赫和艾舍爾，並涉及數理邏輯，可計算理論，人工智慧等諸多領域。

最後提醒：本書的中文譯本共計１０５３頁，涉及音樂，繪畫，宗教，哲學，人工智慧，數理邏輯......

這就是你想要的那本奇書！

附：

侯世達定律指做複雜任務需要花費的時間總是很難預計的。程式設計師經常會引用這一定律，特別是在進行有關提高效率的討論時（如《人月神話》和極限程式設計）。其自指的特徵反映了即便意識到任務的複雜性，預計花費的時間仍是困難的。

作者：杜小豆 連結：https://www.zhihu.com/question/23821125/answer/117538575 來源：知乎 著作權歸作者所有，轉載請聯絡作者獲得授權。

11.《演算法導論》：Thomas H. Cormen / Charles E. Leiserson / Ronald L. Rivest / Clifford Stein

關於作者 本書作者。

在處理器速度大幅提高和儲存器容量顯著增加，且價格趨於便宜的的今天，為什麼還要學演算法？

計算機可以做的很快，但還不能是無限快。儲存器可以做到很便宜，但不會是免費。

關於此書，我不用做太多的介紹。一方面是其大名早已被人所熟知，另一方面是我壓根就沒看多少。

我初次看這本書完全沒任何資料結構與演算法的知識，而書中的的例子都是用虛擬碼表示，看起來著實吃力。所以對於沒有任何資料結構與演算法基礎知識的人，我不推薦直接看這本書。

後來雖然學了資料機構的課程，但無奈老師雖把知識點背的滾瓜爛熟，我聽的卻也恍惚。把各種概念、知識點、公式一股腦的塞給我，卻未有任何思路的講解，最後的結果就是，我通過了期末考試，但老師所講，我都已忘記。

因為看書並記住書中的東西只是記憶，並沒有涉及推理，只有靠推理才能深入理解一個事物，看到別人看不到的地方。

我欠《演算法導論》一個約會。

附：

有深入看過此書的朋友，對本書的詳細介紹就靠你們了。請私信我更新。

12.《資料之巔：大資料革命，歷史、現實與未來》，塗子沛，把科技符號變成文化符號。

關於作者

科技作家，專治各種“差不多”。

少數服從多數一定是正確的麼？

多數人的意見雖然代表了多數人的利益，但“多數”恰恰可能是平庸的多數，精英永遠是少數，大眾民主並不能保證人類社會向正確的方向發展。

追求完全準確的正確態度是什麼？

在可能獲得一個大概的情況下，滿足於事物固有的精確度、停止追求完全準確，這是思維受過訓練的標誌。 ——亞里士多德

資料、資訊、知識、智慧，它們之間有何關係？

資料是對客觀世界的記錄，當我們賦予資料背景時，它就成為資訊；資訊是知識的來源，當把資訊提煉出規律的時候，它就上升為知識；知識的智慧的基礎......

毫無疑問，這本書是大資料方面的權威著作。但正如你所看到的那樣，它並不是一本講授用各種方法、演算法、軟體來獲取並分析大資料的工具書。

相反，這是一本嘗試從美國曆史發展來探討資料/大資料對社會影響的書，全書沒有繁亂的概念解釋，有的只是一個個鮮活震撼的歷史事件，關乎民主、科學，已經我們對待資料的應有態度。

或者，它又是一本關於大資料的科普小書。

隨著網際網路的發展，以及政府工作更多的採取資訊科技，我們似乎都相信，我們的社會正朝著更民主、公正的方向發展。

而以中國文化中所流淌的“大概、可能、也許、好像、顯著、明顯”等不嚴禁的思想，民主道路似乎任重道遠。

民主的質量依賴於大眾的理性思考水平。

於此，本書所推崇的，其實是一種“數字”精神，即是依照“資料”治國，按照“數字”行事。 或許我們所或缺的，不是吃苦耐勞的優秀品德，而是追求嚴禁的科學精神。

附：

公民，無數的公民，才是推動一個社會不斷進步的源源動力。

（我總是不由自主的想起熟悉的話：今年我國/省/市/縣/校/......人民的XXX，在去年的基礎上，明顯/顯著/極大/.......提高。）

13.《奇點臨近》，Ray Kurzweil ，我們正在創造我們自己的繼承者。

關於作者

人工智慧、機器人、深度學習等領域的奇才

我們的大腦與思想有何關係？

我們的大腦創造了思想，思想又反過來創造了大腦。

為什麼說人工智慧一直“沒有”進步？

一旦人工智慧的目標實現，便不再認為它屬於人工智慧的領域，而只是一個一般的有用技術。

21世紀剛剛開始，這是人類歷史上充滿變革、最激動人心的時代。它是這樣的一個時代：人類的本質意義將得到擴充何挑戰。隨著我們這個種族突破基因法則的掣肘，人類將達到前所未有的智慧水平、高度的物質文明，並突破壽命的極限。

1997年，IBM的深藍戰勝國際棋王卡斯帕羅夫；2016年，Google的AlphaGo戰勝世界圍棋冠軍李世石。 那些在歷史程式中具有劃時代意義的時刻，正是我們踏入新紀年的起點。

那些冰冷的機器，曾經只知道靠大量的重複性勞動來取勝，野蠻而愚笨，而今，它們卻變得聰慧過人，並且，正在或者已經取代其創造者的地位。

這是一本探討人工智慧（AI）的書，但同《資料之巔：大資料革命，歷史、現實與未來》一樣，它不是一本講授人工智慧各種演算法或底層技術的工具書，而是一本對人類社會發展有高明遠見的預言書。

奈米機器人進入體力消滅病變細胞，修復受損組織，機器成為我們身體的一部分；基因技術得到飛速發展，我透過那微小的分子鏈，望盡你的一生；你是通過機器獲得新生的人類？還是附加於人類卻開始覺醒的機器？

知識累積、加速回歸定律、摩爾定律、大腦逆向工程、基因技術、奈米技術、機器智慧......

這就是本書所探討的內容：一個我們正在跨入的、嶄新的新世界。

機器的新生，人類的永生。

附：

當你站在起點時，一切都是新的。

14.《深入理解計算機系統》：Randal E.Bryant, David R.O'Hallaron ，從程式設計師的角度看計算機系統。

關於作者

任教於卡內基-梅隆大學。

什麼是資訊？

資訊就是位+上下文。

計算機系統中抽象的重要性

抽象的使用時電腦科學中最為重要的概念之一。例如，為一組函式規定一個簡單的應用程式介面（API）就是一個很好的程式設計習慣，程式設計師無需瞭解內部的工作便可以使用這些程式碼。

這本書是從比較底層的角度講解計算機系統，涵蓋程式、資訊的表示和處理、處理器、儲存器、連結、IO、網路、併發程式設計等。

相比國內某些講解作業系統的書，本書最大的特點就是說人話，儘量用你聽得懂的語言，教授你所忽略或不在意的知識。

書中的很多內容，集精煉簡潔與通俗易懂為一體。例如，其中一個對抽象的理解上，就有這樣一段描述：

檔案是對I/O的抽象，虛擬儲存器是對程式儲存器的抽象，而程式是對正在執行的程式的抽象。

總而言之，這是我所看到的有關作業系統的書中，有足夠的深度與廣度，並讀完能讓我有“原來如此”或“恍然大悟”的感覺。

附：

世界上有10種人，懂二進位制的和不懂二進位制的。

15.《數學之美》：吳軍，資訊的作用在於消除不確定性。

關於作者

《浪潮之巔》作者

資訊的作用是什麼？

資訊的作用在於消除不確定性。

數學的精妙之處是什麼？

數學的精妙之處就在於簡單的模型可以幹大事。

這是一本關於數學知識的科普書，書中介紹瞭如下的數學知識：隱含馬爾可夫模型、布林代數、圖論、TF-IDF、有限狀態機和動態規劃、餘弦定理、非對稱加密演算法、最大熵模型、布隆過濾器、馬爾可夫鏈、貝葉斯網路、條件隨機場模型、維特比演算法、期望最大化演算法、邏輯迴歸模型、分治演算法。

作者吳軍博士曾擔任Google研究院資深研究員，具有工科背景。所以本書的特點是說人話 + 做實事。書中的數學知識大都可以和實際工作結合起來，並且與用計算機解決實際問題息息相關。

我印象中比較深刻的是利用餘弦定理判斷相似性，以及利用貝葉斯網路減少垃圾郵件。

同時，數學的簡潔與強大也被應用到了軟體開發中。如：

簡單性和模組化是軟體工程的基石；分散式和容錯性是網際網路的生命。

在工程上簡單實用的方法最好。

當然，本書也講解技術型知識的同時，也飽含人文的溫情：

先幫助使用者解決80﹪的問題，再慢慢解決剩下的20﹪問題。

如果你是一個足夠優秀的開發者，一個偉大產品的締造者，並不僅僅侷限於一個技術型工作者。或許上面的文字，可以給你更多思考。

最後，本文最初將程式設計師分為工人與藝人，也來自本書的延伸。

技術分為術和道兩種，具體的做事方法是術，做事的原理和原則是道。

附：

許多失敗並不是因為人不優秀，而是做事情的方法不對，一開始追求大而全的解決方案，之後長時間不能完成，最好不了了之。

16.《浪潮之巔》：吳軍， Stay Hongry, Stay Foolish。

關於作者

《數學之美》作者

如何理解浪潮？

在工業史上，新技術代替舊的技術是不以人的意志力為轉移的。人生最幸運之事，就是發現和順應這個潮流

。 對待創新的正確態度是什麼？

創新必須依靠技術實力。

這本書講述矽谷興盛發展的簡史。從IBM到微軟，從甲骨文到Facebook，從蘋果到谷歌。 談及矽谷，我會很自然的想到兩個地方：一個是中國的中關村，另一個是印度的班加羅爾。 在中國，若要發展某一產業，大多有政府主導，投入大量資金，在某地新建XXX產業園，集合頂尖人才，共創民族輝煌。

而與我們困境相似的印度，卻採取的另一種不同的方式。我們所看到的是印度對教育，特別是對IT教育的巨大投入與重視。

世界上大多數成功的投資和新產業的出現並不是靠政府的扶植，而不是商業發展的自然結果。

技術與行業的革新發展，其關鍵，不在硬體配置，而在軟實力；一個國家最寶貴的東西不是土地資金，而是知識人才；集權式的管理並不能讓行業迸發生機，自由才是它們進步的動力。

而今中關村與班加羅爾，兩者在國際上的地位，或許正是2種發展模式的真實寫照。

再談及矽谷，這個創新聖地，早在幾十年前，就以藉助於大學優質的人才與企業豐富的資源而快速發展。它的發展不是一蹴而就，但似乎卻有規律可循：

開放校園的真正含義在於像史丹佛大學那樣，讓大學融入社會。

對年輕的學生最有益的校園環境就是那種最貼近今後真實生活的社會環境。

雖然市場是可以買來，但是收入卻要靠真本事才能掙到。

夢想不是在象牙塔中鑄造的， 開放亦不是“你家大門常開啟”。 附：

矽谷過去是、今天是、明天還會是年輕人夢開始的地方。

17.《程式設計師的數學》：結城浩，簡單的數學思維。

關於作者

寫程式，寫書。

如何理解邏輯？

邏輯是消除歧義的工具。

如何理解完整性與排他性？

沒有“遺漏”，即具備完整性。 沒有“重複”，即具備排他性。

以我有限的閱讀日本IT書籍的經驗來看，日本IT書籍有一個顯著的特點：通俗易懂又不乏深度。

無論是關於編寫作業系統的《30天自制作業系統》，還是關於C語言的《征服C指標》，都是如此。

當然，讓我印象最深的，還是這本書。

數學的發展是有一定規律可循的，而且很多都是為了解決社會發展中所遇到的問題。但我所接受的數學教育，一般確是下面這種模式：

1. 老師講授XX定理的概念。
2. 學習XXX個公式，做習題，考試。
3. XXX定理/公式不夠好？沒關係，我們再介紹一個XXX定理/公式。
4. 轉至第1步。

What I cannot create, I do not understand." -- Richard Feynman

國內所盛行的滿堂灌式的教育，只給出了最後的結果，卻未給出得到這個結果的過程，儘管他們也一直宣稱“成功不重要，重要的是過程”。盲目給出結果而忽略過程，換一種說法就是科學精神所推崇的可重現被徹底忽略了，所以儘管我能做數學題，並用數學知識去解決問題，但是很多情況下我都是處於迷糊的狀態，“知其然而不知其所以然”。

本書可以讓你對數學有更為深刻的理解，“知其然且知其所以然”。如果你以前所接受的教育都是老師直接給你某個理論，那麼這本書所做的，就是給你那個發現理論的思想/腦袋。

從基本的0和10進位制之類的基礎知識，再到對計算機中所採用2進位制和遞迴深入理解，以及我最喜歡的圖靈機停機問題的證明......這是一場思想之旅。

（關於圖靈機停機問題，可參閱劉未鵬大神的 康托爾、哥德爾、圖靈——永恆的金色對角線(rev#2) 一文）

最後，愛上數學，《程式設計師的數學》和《數學之美》更配哦。

附：

認清模式，進行抽象化。

18.《松本行弘的程式世界》：松本行弘， 軟體開發的最大敵人是複雜性。  

關於作者

Ruby之父，《程式碼的未來》作者

如何看待程式設計的歷史？

從某種角度說，程式設計的歷史就因為想當然而失敗的歷史。

   物件導向程式設計的三原則？

多型性，資料抽象和繼承被稱為物件導向程式設計的三原則。

按照豆瓣圖書對此的介紹，作者從全域性的角度，利用大量的程式示例及圖表，深刻闡述了Ruby程式語言的設計理念，並以獨特的視角考察了與程式設計相關的各種技術。

重點是後面的內容。

松本行弘其Ruby之父的身份，並未使得本書將重點放在對Ruby的講解，儘管在很多地方不可避免的提及到了Ruby。

不少有一定程式設計經驗的人，特別是具有學習多種程式語言經歷的人，只要所學程式語言不是有程式導向/物件導向/函數語言程式設計/非同步程式設計......等的跨度較大的區別，一般都很容易上手。

這也意味著，不同程式語言之中存在著很多相同的東西，只不過它們在不同的程式語言被千奇百怪的語法糖給裹著。

If it walks like a duck and quacks like a duck,it must be a duck（走起來來想鴨子，叫起來也像鴨子，那麼它就是鴨子） 。

這就是著名的鴨子定理。

在本書，你可以看到很多這樣的鴨子。

迭代器就是迴圈的意思。

設計模式是個程式設計術語，它是指設計上經常反覆使用的模式。

非同步通訊是將處理細分成多個處理來交替執行。

最後，本書相比《程式碼的未來》，所涉及的技術細節更多且範圍更廣，可以看作是對《程式碼的未來》一書的補充。

19.《程式設計珠璣》：Jon Bentley，啊哈！演算法！

關於作者

曾在卡內基-梅隆大學擔任教授，電腦科學大家培養專業戶

為什麼要花費一定的時間在細節上？

仔細分析小問題有時可以帶來巨大的實際好處。

解決問題所應遵循的普遍原則有哪些？

恰當的問題 時間和空間之間的權衡，二者不可偏廢。 簡單的設計。

沒學走路之前想要跑，沒弄懂問題之前卻急著編碼。

年輕人你的問題就是想得太多而書讀得太少。----楊絳

珠璣，維基百科中文頁面對此無解釋，百科百科則將其解釋為有珠玉、珠寶之意。 說得太文縐縐了，通俗的說就是蚌殼裡的珍珠。

在國內很多資料結構與演算法書籍上，其基本的模式同我對《程式設計師的數學》中對數學的教授模式。而老師的具體教授模式可能是這樣：

1. 今天我們學習XXX資料結構，它的定義是什麼啊，可以運用到哪些地方啊。
2. 我們再學習與之與此有關的XXX演算法，分析一下其執行流程，看看黑板上的虛擬碼或程式碼片段。
3. 最後你們可以做做課後的習題，比如根據什麼畫出它的什麼。XXX題和XXX題很重要，考試可能要考哦。
4. 那個XXX，不要求掌握，考試也不考，有興趣的同學自己看一下吧。

正確解決一個問題的前提是要有一個正確的問題。國內資料結構與演算法書籍上有你做不完的習題。

個人覺得，程式設計師編寫程式，是用於解決實際問題，而各種層出不同的問題也是推動IT技術不斷進化發展的動力。作為支撐程式的位於低層的資料結構與演算法，也應該是來源於實際問題。

但與資料結構與演算法有關的很多書籍，卻陷於概念定義做習題的怪圈，忽略了其解決問題的本質。

這就是特立獨行的書，一本讓你可以解決實際問題的書。它有實際的問題，以及解決問題的思考過程。

《程式設計珠璣》，一本關於資料結構與演算法的書，說人話，做實事，卻不止於此。

附：

程式設計師你的問題就是程式碼寫得太多而對問題思考得太少。----某個人

20.《暗時間》：劉未鵬，脫離語言思考，使用語言實現。

關於作者

mindhacks 博主。

什麼是暗時間？

只有靠推理才能深入理解一個事物，看到別人看不到的地方，這部分推理的過程就是你的思維時間，也是人一生中佔據一個顯著比例的”暗時間”。

投入越多的時間，就越可能成功麼？

“投入時間”這個說法本身就是荒唐的，實際投入的是時間和效率的乘積。

最初接觸到劉未鵬大神，是源於我在搜尋有關圖靈機的資料中，意外發現了有個圖靈機停機問題的好文章——康托爾、哥德爾、圖靈——永恆的金色對角線(rev#2) 。

所以本書的書名雖然是《暗時間》，但卻並不是一本有關時間的什麼書籍，而是一本有關思維邏輯、心理學、計算機演算法.......的書。

我忘了告訴你，劉未鵬大神還是一個程式設計師。所以你在書中看到很多用程式設計師所容易理解的類比，也就不足為奇。

例如，在談及為什麼要專注於做某件事，而不是朝三暮四。作者的比喻就是：

如果一個系統不停地在多個任務之間來回倒騰，就會耗費大量的時間在上下文切換上，無形中浪費很多的時間。

當然本書著重的還是讓讀者認清思維的誤區。而程式設計師在此的顯著表現就是因長久熟悉某一語言/模式/工具，而不接納新的東西，最終形成的思維定勢。

設計模式是補丁，其出現往往意味著語言不夠強大，其使用意味著大量的、與所要達到的程式設計目的無關的樣板式程式碼。

不要覺得不用設計模式就不夠好不夠強大，以儘可能簡單的方式完成任務才是王道。

避免思維被一門語言束縛的最好辦法就是“學習其它語言”。

如果你是某某程式語言或某某模式之類的聖教徒，口頭禪是“XXX是世界上最好的語言“，那麼你需要接收本書的洗滌。

跳出思維觀察思維，這就是這本書所能帶給你的。

附：

不知道是不瞭解,沒有是瞭解之後得出的結論。

別把不知道當成沒有。

21.《瘋狂的程式設計師》，絕影，學技術先學做人。

關於作者

工作的時候，不因為賺多少錢快樂，而因為寫程式設計師快樂。

這是一本自傳性程式設計師小說，作者為絕影，最初在CSDN開博連載，後來寫得多了，變集結為冊，是為《瘋狂的程式設計師》。

這本書按照作者剛入大學接觸計算機，學習技術，參加工作，創業.......的順序，講述了一個計算機小白是如何成長為程式設計高手的故事。書中雖涉及部分技術性的知識，但未自成體系，其重點還是程式設計師的成長經歷以及感情經歷。

書中絕影為了能給女友和自己帶來更好的生活環境，加班加點努力工作，而忽視了對女友的關愛。及至後來女友與之分手，絕影不由得詢問自己：當初自己努力工作是為了自己所珍愛的東西，如今所珍愛的東西沒了，我當初那麼努力工作又是為了什麼？

好吧，這本小說離你想要的提高技術之類差得很遠。但是我想在此談談我推薦這本書的原因。

中國傳統文化一直強調“德”，一個人，若沒有“德”，能力越大，對這個社會的危害越大。不少人也都熟悉蜘蛛俠那句名言：

能力越大，責任越大。

而著名武俠小說作家金庸先生則強調：

俠之大者，為國為民。

在書中，絕影曾破解商業軟體，編寫外掛，後期創業失敗後，寫下了一本小說，就是這本《瘋狂的程式設計師》。

不得不承認，這是一本優秀的小說，因為它激勵我想要成為一個像絕影那樣很牛逼的人，書中的情節讓作為程式設計師的我感同深受。

於是讀完此書後，我準備去作者的部落格留言，以作紀念，但其部落格已被關閉，無法開啟。

後來從看雪論壇和其他站點得知，在現實中，《瘋狂的程式設計師》一書的作者絕影，因涉及編寫外掛程式而鋃鐺入獄。

附：

創造還是毀滅，這是一個問題。

22.《程式設計之道》，傑弗雷﹒詹姆斯 ，三日不程式設計，食肉無味。

關於作者

把最好的管理技術與最成功的高科技企業相結合。

什麼是程式設計之道？

寂靜的虛空裡誕生了神祕的東西，這種東西恆久存在永不消失，它是所有程式的根源所在，我不知道怎麼形容它，姑且稱它為程式設計之道。

為什麼要花費必要的時間在程式的設計上？

“程式被測試時再去改變它的設計已經太晚了。”

莊周夢中化蝶，醒來後卻不知是我莊周夢中化蝶，還是蝶在夢中化我莊周？

超級大師圖靈曾夢見自己是一臺機器，醒後他這樣回憶：“我不知道是圖靈夢見自己變成機器還是機器夢見自己變成圖靈。”

這本書被歸類於程式設計師的哲學書，如同《莊子》，包含智慧，並且有人評論此書大有借鑑《莊子》之意，書名也有一個極具東方色彩的“道”。

關於層出不同的程式語言，程式設計大師如是說：

道生機器語言，機器語言生彙編器。 彙編器生編譯器，最後產生上萬種高階語言。

關於軟體維護，程式設計大師如是說：

既使一個程式只有三行長，也總有一天需要去維護它。

最後一個飽含深意的故事是，有個人參加一個計算機展覽，並告訴門衛： “先警告你，我是偷盜高手，我入室偷盜的本領聞名遐邇。這次展覽會也再劫難逃。”

但每次警衛對程式設計大師搜身時，卻未能發現任何東西。於是在展覽會的最後一天，警衛按捺不住他的好奇心： “告訴我，先生，您到底偷了什麼？”

這個人笑了笑：

“我在偷想法。”

附：

風不動則草不動， 沒有軟體，硬體只是一堆發熱的電子器件

23.《夢斷程式碼》：Scott Rosenberg，你越懂軟體，就越不會去做軟體。

關於作者

暫未找到作者詳細資料

對於自己的軟體作品，應追求完美麼？

數字時代的新時間機制下，一切皆有可能發生，而且速度驚人。這意味著你沒時間做到盡善盡美——無須擔心，因為別人也一樣。

為何創造大型軟體產品困難重重？

創造並使用真正有用的軟體大型可複用元件，無關乎志向，亦無關乎技能。只因為難題源自軟體的多樣性，根深蒂固且難以解決。

《人月神話》一書中，作者將那些陷入開發僵局的大型軟體專案，類比為身陷焦油坑的史前巨獸。聽天由命，不掙扎，於是身體逐漸被埋沒，寂靜無聲；垂死掙扎，卻越陷越深，最終消亡；棄車保帥，如壁虎斷尾一般，終於求得一絲生機。

想要成為那隻陷入焦油坑卻又奇蹟般生還的史前巨獸，需要具備很多條件：要足夠輕巧，至少不要過於龐大，轉身的速度要足夠快；要夠明智，懂得捨棄某些東西換來整體的存在；要足夠警惕，以至於不會陷得太深才發現自己需要轉身。

這本書講授的，就是《人月神話》所提及到的，史前巨獸在焦油坑中垂死掙扎的情景。你會變成一個冷漠的旁觀者，看著那個叫做Chandler的軟體專案，是如何一步步陷入僵局，並最終趨於消亡。

向落後的專案加派人手？將一切推倒重來一次？還是其他？

需求變更，設計不合理，結構混亂，莫名其妙的Bug，進度緩慢.......

電腦當機，你可以按下Reset鍵重啟。軟體開發陷入僵局，你會不會又重頭做起？

附：

一切倒塌又得以重建，再造它們的人滿心歡喜。 —— William Butler Yeats

————————————————————————————

其他說明

1.關於本文

本專欄的名稱是“杜小豆的程式設計小道”，不是“XXX程式設計高手的程式設計大道”。

本文的標題是“私以為可以提高程式設計師技術檔次的書和部落格”，不是“提高程式設計師技術檔次必讀的書和部落格”，亦不是“XXX程式設計高手給菜鳥推薦的N大經典書和部落格”。標題中的“私”代表”杜小豆同學“，所以對本文的正確對待態度是：“杜小豆同學以為可以提高程式設計師技術檔次的書和部落格”。

另外，本文源自我關於問題“有哪些可以提高程式設計師技術檔次的書或部落格？”所做的回答。這類開放性問題相比“1+1=？”這種問題，其最大的特點就是沒有唯一的答案，允許不同觀點存在，並鼓勵思想交流。本文就是在這樣一種思想下誕生的。

最後，微信公眾號圖靈教育在2016年09月01日對本文的轉載已獲得授權，某小編將其以“讀書中的心得和體會”看待，這也是我希望讀者對本文所應秉持的態度。

2.關於書籍列表

既然本文是“杜小豆同學以為可以提高程式設計師技術檔次的書和部落格”，所以你讚賞的某本書沒有出現在書籍列表中，或者你認為某本書不應該出現在書籍列表中，都不會對已有的書籍列表造成影響。我不會因為照顧到每一個讀者的感受而修改書籍列表，有任何不同觀點，歡迎在問題下提供不同答案。

3.關於評論

評論區秉持開放，自由，平等的原則，未貶低或刪除任何評論。鼓勵對書籍列表中的書籍提出不同觀點或其他有價值的見解。

對於主觀性較強的評論，無論是“提高程式設計技術需要看合適的書籍”，還是“讀這些書沒有卵用”，亦或是“提高程式設計技術只能看原始碼”.......等，不做任何評論。

同時，建議在評論中適當加入修飾語，如“我認為”，“就我個人而言”，“我覺得”......等。

對於無明顯說服力的評論，無論是“讀書沒什麼用”，還是“埋著頭程式設計沒什麼用”等，我自動忽略。

同時，建議給出能增強你觀點說服力的具體參考資料，或是請在進行對比試驗後，再進行探討。

對於無顯著價值的評論，如“Mark”，“不錯”，“還好”，“垃圾”等，原諒我不能一一回復。

另外，涉及到辱罵他人或是進行人身攻擊的評論，會被我刪除，同時我會對此公開說明。

4.其他

自由是每個人都有選擇的權利，請自由的表達你的觀點/看法/心得等。

生命，宇宙，以及一切的答案。

讓我們的思想自由戀愛吧！

———————————————————————————— 本文源自我在知乎的一個回答【有哪些可以提高程式設計師技術檔次的書或部落格？ - 杜小豆的回答】，另外題目要求是提高程式設計師的技術檔次，我姑且把這個檔次理解為眼界、精神等，所以會推薦一些非技術型但對可能提高對認知與思維的書籍， 當然，技術類是重點介紹。計劃會介紹以下書籍：

《開放的智力》 《禪與摩托車維修藝術》 《天才在左，瘋子在右》 《你的燈亮著麼》 《窮爸爸，富爸爸》 《三體》 《計算機程式設計藝術》 《程式碼大全》 《世界因你而不同》 空閒時間更新 （2016年09月03日）