總結(jié)

本書主要介紹了Unix系統(tǒng)領(lǐng)域中的設(shè)計(jì)和開發(fā)哲學(xué)、思想文化體系、原則與經(jīng)驗(yàn)，由公認(rèn)的Unix編程大師、開源運(yùn)動(dòng)領(lǐng)袖人物之一Eric S.Raymond傾力多年寫作而成

摘錄：

用錯(cuò)誤的方式解決正確的問(wèn)題總比用正確的方法解決錯(cuò)誤的問(wèn)題好。

Unix的這種自由放縱主義風(fēng)格會(huì)讓它失去很多非技術(shù)型用戶。但從長(zhǎng)遠(yuǎn)考慮，最終你會(huì)發(fā)覺(jué)這個(gè)“錯(cuò)誤”換來(lái)至關(guān)重要的優(yōu)勢(shì)：策略相對(duì)短壽，而機(jī)制才會(huì)長(zhǎng)存。

只提供機(jī)制不提供方針的哲學(xué)能使Unix長(zhǎng)久保鮮

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

設(shè)計(jì)規(guī)則：程序得以形成嚴(yán)絲合縫的工具套裝，而不是應(yīng)景的解決對(duì)策。

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

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

軟件設(shè)計(jì)有兩種方式：一種是設(shè)計(jì)得極為簡(jiǎn)潔，沒(méi)有看得到的缺陷；另一種是設(shè)計(jì)得極為復(fù)雜，有缺陷也看不出來(lái)。第一種方式的難度要大得多。

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

養(yǎng)成在編碼前為API編寫一段非正式書面描述的習(xí)慣，是一個(gè)非常好的辦法。實(shí)際上，一些最有能力的開發(fā)者，一開始總是定義接口，然后編寫簡(jiǎn)要注釋，對(duì)其進(jìn)行描述，最后才編寫代碼——因?yàn)榫帉懽⑨尩倪^(guò)程就闡明了代碼必須達(dá)到的目的。這種描述能夠幫助你組織思路，本身就是十分有用的模塊說(shuō)明，而且，最終你可能還想把這些說(shuō)明做成路標(biāo)文檔（roadmap document），方便以后的人閱讀代碼。

Hatton 的經(jīng)驗(yàn)數(shù)據(jù)表明，假設(shè)其它所有因素（如程序員能力）都相同，200 到 400 之間邏輯行的代碼是“最佳點(diǎn)”，可能的缺陷密度達(dá)到最小。

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

無(wú)論何時(shí)，重復(fù)代碼都是危險(xiǎn)信號(hào)。

程序員工具箱中最強(qiáng)大的優(yōu)化技術(shù)就是不做優(yōu)化。

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

如果有真憑實(shí)據(jù)證明應(yīng)用程序運(yùn)行緩慢，這時(shí)（僅當(dāng)此時(shí)）才可以考慮優(yōu)化代碼。但付諸實(shí)施前，要先估量。

最有效的代碼優(yōu)化方法就是保持代碼短小簡(jiǎn)單。

有時(shí)，按需計(jì)算出昂貴的結(jié)果，再緩存起來(lái)為以后使用，通過(guò)這種方法可以兼得魚和熊掌（低延遲和高吞吐量）—合理利用緩存

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

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

預(yù)測(cè)未來(lái)最好的方法就是去創(chuàng)造未來(lái)。1971年XEROX PARC會(huì)議上的發(fā)言—Alan Kay

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。