整本書的一個基本出發點是開源。其中主要強調的觀點包括：

1.小即是美

作者持有的主要觀點是程式應該以小為美。小程式實現小功能，每個程式儘量保持單一職責，大的處理過程由多個小程式串聯組成，而不是建立一個大的程式包含所有功能。作者指出的一個軟體誤區如下：

“往往有這樣一類軟體工程師，為自己能編寫出規模巨集大的程式而深感驕傲，可除了他自己，沒有任何人能讀懂這些程式。他會認為只有這樣才具有“職業保障”。可以這麼說，就只剩他編寫的應用程式要大過其自負情結。在傳統軟體工程環境中，這樣的軟體工程師可以說是屢見不鮮。”

個人對作者觀點表示同意，個人以為，做軟體的目的在於通過軟體從一定程度上改變特定人群的行為方式，提高某方面的行為效率。軟體宜以簡潔為準，把握好出發點，而不是盲目的堆砌功能點。

2.快速建立原型

通過建立原型有效規避風險。對於軟體研發來說，我一直持有的觀點是儘早的建立原型，以減少不同角色人員在專案開展過程中對目標的理解偏差。我們曾出現過在沒有原型的情況下，根據文件進行討論，最後發現我們很多的甚至基本目標概念上出現偏差的問題，並且多次出現，極易導致專案初始版本出來以後又去回溯需求，重新定義目標，嚴重影響研發效率。

3.人類創造的三個系統

第一個系統：單槍匹馬或一小群開發人員在一定壓力下，以達成目標為目的，做出的具有基本功能的精簡、其貌不揚的計算系統。一般具有很高的開創性，顯示了一個能夠激發別人想象的概念，極具創意。

第二個系統：“專家”使用“第一個系統”驗證過的想法來建立“第二個系統”，通常是由委員會設計的，臃腫而緩慢，但在市場上大展巨集圖，被譽為偉大的成就的系統。

第三個系統：第三個系統通常是對第二個系統不滿，併力求精簡和實用，保持第一系統的概念，並融合第二系統中某些最佳特性的系統。

4.可移植性的優先權

作者強調，在可移植性與程式執行效率之間，應該偏向於可移植性。最高效的方法往往是針對特定環境做出了優化，其移植性比較低，不利於軟體的長期發展。而執行效率往往能夠隨著硬體的發展很快的提升。

作者提出，以純文字格式儲存資料是比較適合移植性的方法。出文本格式的資料相比二進位制檔案來說更加通用。同樣的，速度欠佳可以被新硬體所克服。

純文字格式儲存資料在跨平臺及跨命令傳輸之間具有很高的優勢，但在處理大量資料的時候，確實會存在某些問題。

5.充分利用軟體的槓桿效應

“良好的程式設計師編寫優秀程式碼，優秀的程式設計師借用優秀程式碼”。

軟體開源對於軟體的發展來說，具有極大的好處，可以在更高的數量級上對軟體進行優化。

6.互動式程式的高風險

良好的程式，應該避免使用強制性的使用者介面（CUI）。這裡的介面不只包含了我們通常的圖形使用者介面，也包含了命令列下的提示操作資訊等內容。以小即是美為原則，良好的程式應該是收到命令，處理資料，輸出資料，所有程式都是“過濾器”，將資料從一種形式轉換為另一種形式。CUI從一定程度上影響了資料在不同程式之間的傳輸，多餘的提示資訊往往導致多個程式命令之間不能夠以管道的形式進行資料傳輸。

“當你假設可能是另外一個程式而不是由人來接收程式的資料流時，就能消除我們固有的偏見，即試圖讓應用程式具有使用者友好性。你不會再侷限於思考選單的選擇項，而是開始研究資料最終可能會到達的地方。”

“把應用程式分解成更小的程式，每個程式只執行應用程式的一個功能”

7.在Unix下建立複雜應用程式的範例

8.內容為王

從作業系統的角度出發處理應用程式，對於作業系統而言，圖形介面沒有任何意義。Gnome和KDE只是操作系使用者之上的一個應用程式，只是面向使用者的，並不是面向作業系統的。

視訊、音訊、圖形影象也是如此，對於作業系統而言，這些內容是極不易檢索和識別的，是不具備真實意義的，只有文字才是高效的。

對於大資料處理來說，文字才是最實用的資源。

個人以為，在影象識別及語音識別技術成熟以後，視訊及圖形影象是一種發展趨勢，畢竟二維碼比一維碼能夠儲存的內容實在是多太多了。