程序員修煉之道_從小工到專家_讀書分享

最近央視給我們連續分享了《大國工匠》，很是羨慕，嫉妒，恨。要知道我們程序員也是一名工匠，哈哈。最近用兩天多的時間讀了一本和工匠有關的書籍《程序員修煉之道-從小工到專家》這本書，現在分享給大家，因本人能力有限，拙劣之處請包涵。

從這本書的名字說起，這本書現在的名字體現不出來書中的主題內容，書的原名為《The Pragmatic Programmer》翻譯為《注重實效的程序員》，看到這個題目想必大家對書的主題有個大概印象。這本書在編碼問題，軟件架構和設計，項目管理等方面都有講解。

本書總共分八章：

1. 1.      注重實效的哲學

2. 2.      注重實效的途徑

3. 3.      基本工具

4. 4.      注重實效的偏執

5. 5.      彎曲，或折斷

6. 6.      當你編碼時

7. 7.      在項目編碼之前

8. 8.      注重實效的項目

這本書的章節設置和一般書籍章節設置有非常大的不同，各個章節之間做到了既獨立也相關，可以從頭閱讀，也可以隨意翻頁即讀。這難道是沒有明說的解耦思想，哈哈。

先說下第一章<<注重實效的哲學>>

首先大家不要被高大上的“哲學”二字迷惑，這里僅僅指的是一些基本思維方式方法。

1，             我的源碼被貓吃了

我舉個語境，要是哪天你的硬盤垮了，帶走了你的源碼，而你又沒有備份，你告訴你的老板“我的源碼被貓吃了”。這其實說的意思是，要對自己的工作負責。要提供選擇，而不是找借口。要說明通過什么能挽回局面。

2，             軟件的熵

想必程序員在維護槽糕的代碼都有這樣的經歷，現在的代碼都是垃圾，我照做就是了。

當我們發現自己所在的團隊的代碼非常優美時，我們會格外的保持干凈。聽起來是否似曾相識，其實這就是“破窗戶理論”。其實我現在還沒有弄清楚譯者為什么會用“軟件的熵”做標題。

3，             煮青蛙和石頭湯

溫水煮青蛙也可以用到項目管理當中，其實就是說，項目的腐爛都是從一次次脫離規范，一工時工時的拖延開始的。至于石頭湯的故事在這里不展開，留給有心的同學們，提前說一下，石頭湯的故事更有趣，參與的角色更多樣，理解的角度更多樣。

4，             足夠好的軟件

這一點引入一個書中的問題：

考察你使用的軟件工具和操作系統的制造商。你能否發現證據，表明這些公司安于發布他們知道不完美的軟件嗎？作為用戶，你是會（1）等著他們清除所有bug，（2）擁有復雜的軟件，并接受某些bug，還是會（3）選擇缺陷較少的更簡單的軟件？

這道題書中沒有給出答案及分析。從作者角度出發，選項（3）是符合作者的“足夠好的軟件”。

但是我認為這本書出版在2004年前后，到現在已12年之久，加上互聯網，移動互聯網發展，互聯網產品的涌現。作者對足夠好的軟件的定位還需商討。

5，             你的知識資產

這一點我就不按照書本上講解了，這里我從一個軟件開發角度講解一下知識。

第一類為基本理論類書籍，這些書籍的總量相對比較固定。基本上有140 左右。可以參考http://www.theithome.net/read-htm-tid-43460.html

第二類為技能書籍，包括各種流行技術，編程語言等。這種書籍廣泛，數量多。

我認為讀書的過程中最重要的就是要有批判精神。可以提高閱讀轉化率。

6，             交流

這部分我主要記住了兩句話，一句話是，被打量要比被忽視更好。第二句話說的意思是說一個好的想法，如果沒有有效的溝通就如同一個沒有人關心的孤兒。

注意，在這里給人力資源部打個廣告，人力資源部給員工的培養課程資料中的提供的《有效溝通技巧》講的交流溝通內容是很豐富的。

第二章《注重實效的途徑》

第一章講的內容更多的是無招內功九陽神功理念。第二章咱們就進入干貨，練習九陰白骨爪。

7，             重復的危害

   書中描述是這樣子的，當你在一個系統中兩處或者多處表達同一個事物，你要是改變其中一處，你必須記得改變其他各處。但是我要說這不是你能否記住的的問題，而是你何時忘記的問題。這就是重復危害的深刻表達。

   書中的作者在這一小節中對重復危害的產生原因講的很透徹全面。但是到最后沒有明確提煉出避免重復的措施，措施隱含分布在各處（難道是為了避免重復，這也是太快了吧），我整理如下:

1，             通過清晰的設計，強有力的技術領導，進而在設計中進行充分理解的責任區域劃分。可以規避一些問題

2，             但是模塊層重復更隱蔽。不能劃入明顯的責任區域。解決這個問題就要用到第一章的第六條交流。鼓勵開發者交換意見，進行提問，找到并復用已有的東西。

8，             正交性

這里的正交其實就是咱們熟悉的解耦。在這里你估計會想到標題為啥是正交，不是解耦。

我忘了告訴大家本書的作者同時也是一位木匠和音樂家。估計能在木匠和音樂領域找到答案。作者真的博學。

這里拋出去一道思考題：

C++支持多重繼承，而java允許類實現多重接口，使用這些設施對正交性有和影響？使用多重繼承和使用多重接口的影響是否有不同？。。。

9，             可撤銷性

可撤銷性我認為是對一個產品開發結果的一種度量。可撤銷性就是擁抱變化，通過之前的建議，避免重復，解耦等的使用，制作靈活，有適應能力的軟件。

舉個很常見的例子，如果正在項目開發的過程當中提出需要更換數據庫廠商，這時要是我們把數據庫的概念抽象出來（數據庫只是一種數據持久化），而不是把調用數據庫的代碼纏繞在各處。我們就可以說是soeasy。

10，        曳光彈

這個名詞我是第一次聽說，中間作者也花費了筆墨解釋曳光彈的出處。這個名字估計估計要另外一個作者喜歡玩飛機有關系吧。

簡單的說，曳光彈其實就是有可用代碼的原型設計。原型一旦用戶對界面同意，可以直接扔掉。但是曳光彈不同，他是一個能工作的東西。開發人員可以在里面添加新功能。

其實在這里追究曳光彈的概念邊界我覺得不重要，重要的是我們能在合適的場合使用。

11，        原型與便簽

這一節通篇再講原型設計。看完之后基本就忘記了。

12，        領域語言

這一小節的內容作者是站在計算機語言的高度描述講解的。現在這么多的語言，就是因為為了解決不同領域的問題產生的。例如咱們公司前一段事件招聘中提到的R語言，R語言我認為就是一種為了用于統計計算和統計制圖的優秀領域語言。

再往近的說，相信大部分公司開發人員都熟悉java，熟悉非常流行的spring框架。Spring中有一個常用的措施，就是許多特定功能都可以通過XML描述語言進行描述。可以屏蔽實現細節。很簡單的可以讓開發人員處理特定領域問題（比如事務控制，日志等）。我認為spring通過利用xml描述語言，及其自己寫的類似解釋XMl的解釋器來解決問題的思路從某種角度也有這個思想。

13，        估算

里面講到的估算，印象是最深的是一個例子,如果你的奶奶問你何時到達，她也許只是想知道該給你準備午餐還是晚餐，而一個困在水下，空氣就快用光的潛水員很可能需要你精確的回答。這告訴我們估算是有語境的。

這本書講到的估算比較粗略。想要系統學習估算要找相關專業書籍啦。

第三章《基本工具》

第三章作者從木匠切入，系統闡述了工具的作用，工具是如何產生工作效益，最終工具可以放大你的才干。其中包括14，純文本的威力，15，shell游戲，16，強力編輯，17，源碼控制，18，調試，19，文本操作，20，代碼生成器。

其中的shell游戲，純文本的威力小節如果你是一個類unix系統用戶會體會比較深刻，但是我不是。體會的不是很深刻。

對于調試書中有一句很難忘的話，如果你發現了他人的bug，請不用把精力放到職責肇事者。你應該修正問題。因為這現在是你的問題，責任。這或許可能當為工作環境中的一種文化引導。

代碼生成器的便利性在公司的開發平臺（在eclipse平臺之上做了插件開發）之上體現的很具體可感知。

第四章《注重實效的偏執》

這一章看完我沒有理解標題中的偏執。哎，畢竟是國外的東西拿來翻譯的。

這一章主要講的目的是如何編寫健壯的代碼，講解的內容有21，按照合約設計，22，死程序不說謊，23，斷言式編程，24，何時使用異常，25，怎么配平資源。

我個人不認為斷言式編程能提高工作效率，至少現在，調試的設施很多。

對于書中的“在生產代碼中可以讓重要的斷言開啟”這個觀點同時有待商討。

25小節中提到的配平資源其實就是如何管理資源（內存等），這里的原則就是誰分配的，誰就負責解除其分配。對于java而言，垃圾回收機制已經幫我們做了大部分的工作。

第五章《彎曲，或折斷》

這一章主要介紹了如何創建可以擁抱變化的代碼，講解的內容有26，解耦與得默忒耳法則，27，元程序設計，28，時間耦合，29，它只是試圖，30，黑板

其中的元程序設計，它只是試圖（主要是對MVC做了擴展），時間耦合的運用都是為了達到解耦，解耦的目的就是穿件可以擁抱變化的代碼。

這里重點說明一下時間耦合，時間耦合中的時間有兩個方面對我們很重要：并發（事情在同一時間發生），次序（事情在時間中的相對位置）。對于可以同時進行的任務我們可以并發進行，利用一個任務的可能等待去執行另一個任務，這樣就可以在時間上進行解耦。對于有約束的并發，就是并發中次序。就需要有具體分析來改進并發。不知道是譯者的問題，還是我理解的問題，在時間耦合這塊我感覺我沒有很清晰的把握中原作者的所有意圖。

第六章《當你編碼時》

這一章主要介紹了當你編碼時應該思考的問題。講解的內容有: 31，靠巧合編程，32，算法速率，33，重構，34，易于測試的代碼，35，邪惡的向導。

如何避免靠巧合編程書中提到了很多條，其中不要依靠假定寫代碼，不但要測試你的代碼，同時也要測試你的假定。

算法速率的估算書中主要是把時間復雜度，空間復雜度的具體計算方法，同時也對時間和空間取舍做了說明。

重構需要記住的是，不要說開發時間不夠，記住上面的破窗戶理論。早重構，長重構。

在測試這塊我想說下，開發人員要重視自測，因為某一類問題（邏輯情況比較多）單靠測試人員有可能會遺漏。

邪惡的向導說法有點太過了，向導本省是好的，就是我們要對代碼生成器或者向導產生的代碼要保留百分之一的懷疑。

第七章《在項目開始之前》

這一章主要講述的對象從個體的哲學和編碼問題轉換為了項目。講解的內容有: 36，需求之坑，37，解開不可能解開的謎題，38，等你準備好，39，規范陷阱，40，圓圈與箭頭。

其中主要澄清一下需求之坑，這里的坑不是需求人員故意埋的坑，這里的坑指的是隱藏在坑底的需求，不是簡單搜索，而是深層次的挖掘。當開發人員發現了需求的坑，請不要抱怨需求人員，這不是需求人員造的坑，反而需求人員在我們不知道的情況下已幫助我們填補了許多坑，感謝需求人員。

這一章同時也講述了解決問題的意思思路，還有項目之前有限準備，防止錯失良機，適度規范，不要陷入規范陷阱。最后也講述了項目中的工具。我重點提醒不要被工具束縛住。

第八章《注重實效的項目》

這一章主要討論使項目失敗和成功的關鍵區域。講解的內容有：41，注重實效的團隊，42，無處不在的自動化，43，無情的測試，44，全部都是寫，45，極大的期望，46，傲慢與偏見。

在團隊的論述當中，印象最深刻的是杜絕一個老鼠害了一鍋湯，不要讓一個消極，一個不完美的東西存在，相信這個東西會蔓延開來，惡化整個團隊。這也和前文提到的“破窗戶理論”呼應。努力提高自動化程度，因為有人參與就有產生錯誤的機會。無情的測試里面講到了很大范圍的測試方法。當你交付的產品能稍微超出客戶的預期時相信你的商業信譽就提高了。最后提到傲慢與偏見其實就指的一件事，就是對你的代碼簽名，對于隊友可以方便的找到你。

讀書分享總結:
這本書中整體內容前后邏輯相關性不強，但是不能說這是缺點。這本書更多講的是一些觀點，方法，原則，建議，大概有46個。在這46個當中，我們要辯證統一地認識，在具體工作當中根據具體情況要有取有舍，避免一個人同時帶了多塊不同時間的手表，讓人忙亂于原則教條本身，無形之中忽視了項目，忽視了提高生產力這一重要目的。