總結

本書主要介紹了Unix系統領域中的設計和開發哲學、思想文化體系、原則與經驗，由公認的Unix編程大師、開源運動領袖人物之一Eric S.Raymond傾力多年寫作而成

摘錄：

用錯誤的方式解決正確的問題總比用正確的方法解決錯誤的問題好。

Unix的這種自由放縱主義風格會讓它失去很多非技術型用戶。但從長遠考慮，最終你會發覺這個“錯誤”換來至關重要的優勢：策略相對短壽，而機制才會長存。

只提供機制不提供方針的哲學能使Unix長久保鮮

既然能夠改編、重用、再造，節省自己 90%的工作量，為什么還要從零開始編碼呢？

設計規則：程序得以形成嚴絲合縫的工具套裝，而不是應景的解決對策。

Unix哲學：
1. 原則 1：你無法斷定程序會在什么地方耗費運行時間。瓶頸經常出現在想不到的地方，所以別急于胡亂找個地方改代碼，除非你已經證實那兒就是瓶頸所在。
2. 原則 2：估量。在你沒對代碼進行估量，特別是沒找到最耗時的那部分之前，別去優化速度。
3. 原則3：花哨的算法在n 很小時通常很慢，而n通常很小。花哨算法的常數復雜度很大。除非你確定n總是很大，否則不要用花哨算法（即使n很大，也優先考慮原則2）。
4. 原則4：花哨的算法比簡單算法更容易出bug、更難實現。盡量使用簡單的算法配合簡單的數據結構。
5. 原則 5：數據壓倒一切。如果已經選擇了正確的數據結構并且把一切都組織得井井有條，正確的算法也就不言自明。編程的核心是數據結構，而不是算法[7]。
6. 原則6：沒有原則6。

Unix哲學中更多的內容不是這些先哲們口頭表述出來的，而是由他們所作的一切和Unix本身所作出的榜樣體現出來的。從整體上來說，可以概括為以下幾點：
1. 模塊原則：使用簡潔的接口拼合簡單的部件。
2. 清晰原則：清晰勝于機巧。
3. 組合原則：設計時考慮拼接組合。
4. 分離原則：策略同機制分離，接口同引擎分離。
5. 簡潔原則：設計要簡潔，復雜度能低則低。
6. 吝嗇原則：除非確無它法，不要編寫龐大的程序。
7. 透明性原則：設計要可見，以便審查和調試。
8. 健壯原則：健壯源于透明與簡潔。
9. 表示原則：把知識疊入數據以求邏輯質樸而健壯。
10. 通俗原則：接口設計避免標新立異。
11. 緘默原則：如果一個程序沒什么好說的，就沉默。
12. 補救原則：出現異常時，馬上退出并給出足夠錯誤信息。
13. 經濟原則：寧花機器一分，不花程序員一秒。
14. 生成原則：避免手工hack，盡量編寫程序去生成程序。
15. 優化原則：雕琢前先要有原型，跑之前先學會走。
16. 多樣原則：決不相信所謂“不二法門”的斷言。
17. 擴展原則：設計著眼未來，未來總比預想來得快。

軟件設計有兩種方式：一種是設計得極為簡潔，沒有看得到的缺陷；另一種是設計得極為復雜，有缺陷也看不出來。第一種方式的難度要大得多。

在Unix歷史中，最大的規律就是：距開源越近就越繁榮。

養成在編碼前為API編寫一段非正式書面描述的習慣，是一個非常好的辦法。實際上，一些最有能力的開發者，一開始總是定義接口，然后編寫簡要注釋，對其進行描述，最后才編寫代碼——因為編寫注釋的過程就闡明了代碼必須達到的目的。這種描述能夠幫助你組織思路，本身就是十分有用的模塊說明，而且，最終你可能還想把這些說明做成路標文檔（roadmap document），方便以后的人閱讀代碼。

Hatton 的經驗數據表明，假設其它所有因素（如程序員能力）都相同，200 到 400 之間邏輯行的代碼是“最佳點”，可能的缺陷密度達到最小。

Hatton 建議邏輯行與物理行之間為兩倍的折算率，即最佳物理行數建議應在400至800行之間。

無論何時，重復代碼都是危險信號。

程序員工具箱中最強大的優化技術就是不做優化。

最聰明、最便宜、常常也是最迅速的性能提升方法，就是等上幾個月，期望硬件性能更好。

如果有真憑實據證明應用程序運行緩慢，這時（僅當此時）才可以考慮優化代碼。但付諸實施前，要先估量。

最有效的代碼優化方法就是保持代碼短小簡單。

有時，按需計算出昂貴的結果，再緩存起來為以后使用，通過這種方法可以兼得魚和熊掌（低延遲和高吞吐量）—合理利用緩存

代碼多并不等于代碼好，至少在編寫低層次代碼和大量重復投入時是如此。

評估開源軟件包的方法是閱讀其文檔和快速瀏覽它的部分代碼。如果所見的代碼編寫恰當，文檔完備，那么鼓勵使用。如果能夠證明軟件包已經有些年頭并且存在實質具體的用戶反饋，就可以斷定它是相當可靠的（無論如何還是測測為佳）。

預測未來最好的方法就是去創造未來。1971年XEROX PARC會議上的發言—Alan Kay

總結

以上是生活随笔為你收集整理的UNIX编程艺术-艾瑞克.S.理曼德的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。