1.6 UNIX原則

組合原則

簡(jiǎn)潔原則

透明性原則

經(jīng)濟(jì)原則

1.7 KISS原則

Keep It Simple，Stupid

1.9 態(tài)度也要緊

看到該做的就去做，短期來(lái)看似乎是多做了，但從長(zhǎng)期來(lái)看，這才是最佳捷徑

軟件設(shè)計(jì)和實(shí)現(xiàn)，應(yīng)該是一門充滿快樂(lè)的藝術(shù)，一種高水平的游戲

如果有足夠多眼睛的關(guān)注，所有bug都無(wú)處藏身

Unix要繁榮，就必須采用吸納低價(jià)而靈活的方案的訣竅，而不是去反對(duì)他們

318-327看完

4 模塊性

軟件有兩種設(shè)計(jì)方式，一種設(shè)計(jì)得極其簡(jiǎn)潔，沒(méi)有看得到的缺陷；一種設(shè)計(jì)得極其復(fù)雜，看不出缺陷，第一種難的多

要編寫(xiě)復(fù)雜軟件又不至于一敗涂地的唯一方法，就是用定義清晰的接口把若干簡(jiǎn)單模塊組合起來(lái)，這樣多數(shù)問(wèn)題只會(huì)出現(xiàn)在局部

4.1 最佳模塊大小

一些最有能力的開(kāi)發(fā)者，一開(kāi)始總是定義接口，然后編寫(xiě)簡(jiǎn)要注釋，對(duì)其進(jìn)行描述，最后才編寫(xiě)代碼，因?yàn)榫帉?xiě)注釋的過(guò)程，就闡明了代碼必須達(dá)到的目的

模塊之間通過(guò)API接口通信，bug最少的最佳物理行在400到800，關(guān)于邏輯行和物理行見(jiàn)下面代碼

a="我是一個(gè)物理行" a="""我是一個(gè)邏輯行 因?yàn)槲乙粭l語(yǔ)句便跨越了2個(gè)物理行"""

4.2 緊湊型和正交性

4.2.1 緊湊性

就是一個(gè)設(shè)計(jì)能否裝進(jìn)大腦的特性： 用經(jīng)驗(yàn)的用戶通常需要操作手冊(cè)嗎？如果不需要，那么這個(gè)設(shè)計(jì)就是緊湊的

經(jīng)驗(yàn)法則： 記憶的條目數(shù)大于七，則不太可能是緊湊的

4.2.2 正交性

任何操作均無(wú)副作用，只會(huì)改變一件事，而不會(huì)影響其他

體現(xiàn)了 單一職權(quán)原則? 只做好一件事

正交性代碼更容易復(fù)用

Don't repeat youself 當(dāng)你修改重復(fù)部分時(shí)，你可能只是修改了一部分而非全部，非常危險(xiǎn)

設(shè)計(jì)最好圍繞一個(gè)強(qiáng)核心算法，就比如，grep圍繞正則表達(dá)式

完美之道，不在無(wú)可增加，而在無(wú)可刪減

設(shè)計(jì)方法有自頂向下和自底向上，unix采用自底向上

為了中和自頂向下和自底向上，我們需要膠合層，類似于分層的api，service，common層

而且膠合層應(yīng)該盡量的薄，比如C語(yǔ)言，就是硬件和軟件的膠合層，而C語(yǔ)言的風(fēng)格就是盡量簡(jiǎn)潔，功能盡量少

API的入口點(diǎn)盡量不超過(guò)七個(gè)，簡(jiǎn)單的API比復(fù)雜API更好

5 文本化：好協(xié)議產(chǎn)生好實(shí)踐

5.1 文本化的重要性

文本文件/協(xié)議優(yōu)于二進(jìn)制流文件/協(xié)議，因?yàn)橥该餍?用戶易讀懂)

這一章就是一堆文本格式的介紹 RFC 822(電子郵件格式，包括 to，subject，cc等) 和XML

以及Unix文本格式的約定

看到 5.3 應(yīng)用協(xié)議設(shè)計(jì)。 有點(diǎn)看不下去，好無(wú)聊，也看不太懂

看到490頁(yè)，5.4應(yīng)用協(xié)議元格式，這章完全講協(xié)議啊，不看了

473~490

511~554

第六章

美在計(jì)算機(jī)科學(xué)中的地位，比在其他任何技術(shù)中心的地位都重要，因?yàn)檐浖珡?fù)雜了。美是低于復(fù)雜的終極武器。

可顯性，僅僅做到不晦澀是不夠的，還必須盡力做到有幫助，比如有意義的函數(shù)名稱，或者出現(xiàn)故障時(shí)有用的日志信息，比如gcc編譯時(shí)，打出來(lái)的一堆調(diào)試信息，易于幫助我們定位，哪里出了問(wèn)題

透明性，就是我們一眼就知道，這個(gè)機(jī)器(或者代碼)在干什么

編寫(xiě)透明、可顯得系統(tǒng)而節(jié)省的精力，將來(lái)完全可能就是自己的財(cái)富

Window注冊(cè)表，所有注冊(cè)記錄都儲(chǔ)存在一個(gè)大文件中，這是不好的，大文件應(yīng)該分為多個(gè)小文件

策略和機(jī)制應(yīng)該分離，策略，就好比你玩家在游戲中的裝備等數(shù)據(jù)，而服務(wù)器引擎則是機(jī)制

Freeciv這個(gè)游戲，其配置文件類似于windows注冊(cè)表，但是它的配置文件只能由游戲開(kāi)發(fā)者改動(dòng)，這就避免了用戶改動(dòng)注冊(cè)表，導(dǎo)致的注冊(cè)表過(guò)長(zhǎng)，運(yùn)行速率過(guò)慢。

6.2 為透明性和可顯性而設(shè)計(jì)

這個(gè)設(shè)計(jì)能行嗎？

別人能讀懂這個(gè)設(shè)計(jì)嗎？

這個(gè)設(shè)計(jì)優(yōu)雅嗎？

這三個(gè)問(wèn)題不是廢話，優(yōu)雅不是一種奢侈，這些品質(zhì)對(duì)于減少bug和提高軟件長(zhǎng)期維護(hù)性是最基本的

6.2.2 透明性之禪

最有效的方法很簡(jiǎn)單，就是不要再具體操作的代碼上疊放太多抽象層???? 這也是為什么要有薄膠合層

優(yōu)秀Unix代碼的簡(jiǎn)潔依賴于嚴(yán)格自律和高水平技藝

6.2.2 為透明性和可顯性

去欲望，少依戀，如實(shí)見(jiàn)

程序調(diào)用的最大靜態(tài)深度是多少，如果大于四，就要當(dāng)心

每個(gè)API的各個(gè)函數(shù)調(diào)用是否正交? 或者存在太多的特征標(biāo)志?

是否存在一些順手可用的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)或全局唯一的記錄器

代碼增加了特殊情況還是避免了特殊情況

透明性和避免過(guò)度保護(hù)

隱藏細(xì)節(jié)和無(wú)法訪問(wèn)細(xì)節(jié)有著重要區(qū)別(比如debug時(shí)能打出隱藏的日志)

良好程序應(yīng)該有調(diào)試和探測(cè)開(kāi)關(guān)

6.2.4 透明性和可編輯的表現(xiàn)形式

盡量實(shí)現(xiàn)可編輯的文本和二進(jìn)制格式來(lái)回?zé)o損轉(zhuǎn)換

CLI （comand line interface）命令行接口程序

6.2.5 透明性、故障診斷和故障恢復(fù)

透明的更容易恢復(fù)，也更健壯

6.3 可維護(hù)性

如果作者以外的其他人能順利理解和修改軟件，那么軟件就是可維護(hù)的

Unix哲學(xué)：寧愿拋棄、重建代碼也不愿修補(bǔ)哪些蹩腳的代碼

可維護(hù)的兩個(gè)重要實(shí)踐：

選擇簡(jiǎn)單的算法，“拿不準(zhǔn)就窮舉”，復(fù)雜的算法容易出bug，而且難以維護(hù)

還有就是，開(kāi)發(fā)者手冊(cè)，簡(jiǎn)略描述代碼的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)和算法

7 多道程序設(shè)計(jì)： 分離進(jìn)程為獨(dú)立的功能

Unix的藝術(shù)： 將大型程序分解成多個(gè)協(xié)作進(jìn)程

做單件事并做好

shell執(zhí)行，就是創(chuàng)建多個(gè)協(xié)作進(jìn)程，并由管道連接

IPC 進(jìn)程間通信

7.1

過(guò)早優(yōu)化是萬(wàn)惡之源

線程不是降低而是提高了全局復(fù)雜度，因此，除非萬(wàn)不得已，盡量避免使用線程

一個(gè)程序劃分為多個(gè)協(xié)程，也更利于安全性，只有較小的協(xié)程去執(zhí)行特權(quán)指令

最簡(jiǎn)的就是最好的

7.2 Unix IPC方法分類

7.2.1 把任務(wù)轉(zhuǎn)給專門程序

專門程序，其實(shí)就是不和其他進(jìn)程通信，只做自己的事情的程序

7.2.2 管道、重定向和過(guò)濾器

管道 就是 做單件事并做好

8 微型語(yǔ)言

8.1 理解語(yǔ)言分類法

結(jié)構(gòu)或用的數(shù)據(jù)格式文件(比如/etc/passwd) -> 微型語(yǔ)言(比如make) -> js -> Java

??

這些語(yǔ)言一定程度上是解釋器，解釋器范疇越大(即所需要的上下文越少)越通用(越靠右)，

8.2.1 sng

png沒(méi)有透明性，sng卻能夠?qū)ng以json字符串的樣式表現(xiàn)出來(lái)，所以具備了透明性

8.2.2 正則表達(dá)式

微語(yǔ)言的一種，極其簡(jiǎn)練卻很有用

8.2.3 Glade

透明性和簡(jiǎn)單性

8.2.4 m4

宏命令: define 'OS' 'operation system'

但是謹(jǐn)慎用宏

8.2.5

圖靈完備機(jī)

其實(shí)語(yǔ)言就是解釋器？

最小立異原則

必須謹(jǐn)慎使用語(yǔ)法糖，以免造成的晦澀多于幫助

8.2.8 awk

unix下輸入?info gawk，獲取在線文檔

9 生成：提升規(guī)格說(shuō)明的層次

程序員束手無(wú)策.... 只有跳脫代碼，直起腰，仔細(xì)思考數(shù)據(jù)才是最好的行動(dòng)，表達(dá)是編程的精髓(????表達(dá)力嗎)

人類其實(shí)更善于觀察數(shù)據(jù)，而不是推導(dǎo)控制流程(我覺(jué)得，人類是視覺(jué)動(dòng)物)

所以，盡可能的把設(shè)計(jì)的復(fù)雜度從程序代碼轉(zhuǎn)移到數(shù)據(jù)，是個(gè)好辦法

過(guò)程式語(yǔ)言 c，

說(shuō)明式語(yǔ)言 sql

相對(duì)來(lái)說(shuō)編譯時(shí)，c更難分分析，sql更容易分析(我覺(jué)得，透明性)，容易分析的語(yǔ)言，更容易找出錯(cuò)誤

進(jìn)行數(shù)據(jù)驅(qū)動(dòng)編程(和面向?qū)ο缶幊滩煌?時(shí)，需要把代碼和代碼作用的數(shù)據(jù)結(jié)構(gòu)劃分清除，這樣，在改變程序的邏輯時(shí)，只要編輯數(shù)據(jù)結(jié)構(gòu)而不是代碼，例子：ascii轉(zhuǎn)譯程序，只需要碼表和map邏輯

9.2 專用代碼的生成

9.2.1 ascii 代碼

assic 用法屏幕，就是作者自己手寫(xiě)一整個(gè)表，然后讓代碼去打印這個(gè)表，?這樣的話，要改輸出格式，只要對(duì)這個(gè)手寫(xiě)的表進(jìn)行操作就行啦，NB666

9.2.2 為列表生成HTML代碼

我草，這個(gè)真是屌爆了

?而我們可以先把數(shù)據(jù)按以下格式存儲(chǔ)在文檔中

?然后通過(guò)sed，生成對(duì)應(yīng)的html列表

我草，太吊了

所有這些例子的借鑒之處都是一樣的：

盡可能少干活；讓數(shù)據(jù)塑造代碼；依靠工具；把機(jī)制從策略中分離?

建設(shè)性的懶惰是大師級(jí)程序員的基本美德之一

編碼盡量往上推以最小化常數(shù)缺陷密度效應(yīng)??????

10 配置: 邁出正確的第一步

積硅步，至千里

10.1 什么應(yīng)是可配置的

什么應(yīng)是可配置的?? 回答：全部

分離原則： 只要可能，就建立機(jī)制而把策略決定權(quán)交個(gè)用戶

盡量用自動(dòng)檢測(cè)來(lái)減少配置開(kāi)關(guān)的數(shù)量

讓程序經(jīng)濟(jì)運(yùn)行時(shí)設(shè)計(jì)者的任務(wù)，用戶不應(yīng)該看到優(yōu)化開(kāi)關(guān)

考慮一下問(wèn)題：

能省掉這個(gè)功能嗎

能否用無(wú)傷大雅的方式改變程序的常規(guī)行為，從而無(wú)需這個(gè)選項(xiàng)?

這個(gè)選項(xiàng)是否花哨沒(méi)用?

增加一個(gè)開(kāi)/關(guān)配置選項(xiàng)，就是使測(cè)試量加倍，既然在實(shí)踐中從來(lái)沒(méi)有人完成雙倍測(cè)試量，那么實(shí)際影響，就是減少了特定配置獲得的測(cè)試量

10.2 配置在哪里

1 /ect

2 系統(tǒng)環(huán)境變量

3 用戶主目錄(LINUX中的~)的運(yùn)行控制文件

4 用戶環(huán)境變量

5 命令行參數(shù)

后者覆蓋前者，越往后范圍越小

10.3 運(yùn)行控制文件

rc 后綴，代表'運(yùn)行控制(run control)'

其實(shí)運(yùn)行控制文件和點(diǎn)文件(比如.netrc文件, .profile文件)，我的理解就是配置文件，用來(lái)決定程序按照何種配置去運(yùn)行

10.3 命令行選項(xiàng)

-a -ab代表組合-a和-b

10.5.1 從-a到-z的命令行選項(xiàng)

-a -all所有

-b buffer或者batch

-c command 命令(帶參數(shù))

-d debug 調(diào)試，偶爾delete

-e execute

-f file 代表輸入文件，輸出文件

-i interactive

-k keep或者kill

-l list

-n number

-o output

-p port?

-q quite

-r recurse遞歸 reverse反向

-z zip啟用壓縮

看到881頁(yè)

10.6.1 實(shí)例分析fetchmail

提供了了太多的選項(xiàng)，以至于用戶手冊(cè)過(guò)于復(fù)雜

解決辦法就是提供-o選項(xiàng)，然后-o后面的參數(shù)視為配置文件的一行信息

10.6.2

11 接口: Unix環(huán)境下的用戶接口設(shè)計(jì)模式

我們所有的知識(shí)都來(lái)源于我們的感知

與其他程序通訊方式的前瞻性設(shè)計(jì)，這是什么鬼？？？？？

最小立異原則： 如果可能，盡量允許用戶將接口功能委派給熟悉的程序來(lái)完成，比如讓用戶選擇自己的文本編輯器

互助式的接口組合使用

共生和委派策略來(lái)提高代碼的復(fù)用度，并降低軟件復(fù)雜度： 讓用戶選擇自己的代理

如果不能委派，那么就效仿

11.3 接口設(shè)計(jì)評(píng)估

簡(jiǎn)潔、表現(xiàn)力、透明、易用、腳本化

簡(jiǎn)潔： 可以用操作時(shí)間來(lái)衡量，鍵盤拼寫(xiě)比鼠標(biāo)點(diǎn)擊屏幕字符要快得多

表現(xiàn)力：可以觸發(fā)相當(dāng)廣泛的行為，比如鍵盤可以單鍵，也可以組合鍵

易用性：和用戶要記憶的東西成反比

接口透明度：所見(jiàn)即所得，中間結(jié)果也很容易看出來(lái)

腳本化： 接口更容易為其他程序所用

自動(dòng)完成重復(fù)任務(wù)：

roguelike

更具表達(dá)力的語(yǔ)言意味著程序更短，bug更少。

過(guò)濾器原則
Postel原則 寬進(jìn)嚴(yán)出
過(guò)濾時(shí)，不需要的信息也絕不丟棄
過(guò)濾時(shí)，絕不增加無(wú)用數(shù)據(jù) 比如不遵循格式的日期，空行

Cantrip模式
沒(méi)有輸入沒(méi)有輸出，啟動(dòng)時(shí)指定條件，具備很強(qiáng)的腳本能力

比如 clear rm命令

比較好的風(fēng)格，交互用腳本語(yǔ)言寫(xiě)，然后內(nèi)部調(diào)用cantrip程序

源模式
沒(méi)有輸入，輸出只能在啟動(dòng)條件中控制，比如 ls

類編譯器模式

沒(méi)有輸入也沒(méi)有輸出，但是報(bào)錯(cuò)時(shí)會(huì)發(fā)信息
，交互性較低，所以比較容易腳本化

引擎和接口分離模式

核心算法與接受用戶命令，顯示結(jié)果相分離

比如控制器，視圖，模型

驅(qū)動(dòng)/引擎組合

比如驅(qū)動(dòng)可以是不同的網(wǎng)卡驅(qū)動(dòng)，而網(wǎng)卡作為引擎，只有一個(gè)

客戶端/服務(wù)器模式

配置者/執(zhí)行者組合

比如fetchmail和fetchmailconf

fetchmailconf用于GUI?

假脫機(jī)和守護(hù)進(jìn)程

守護(hù)進(jìn)程，輪詢作業(yè)

CLI服務(wù)器模式

其實(shí)就是守護(hù)進(jìn)程負(fù)責(zé)監(jiān)聽(tīng)，然后fork進(jìn)程處理輸入，比如inetd

微語(yǔ)言模式

GUI前端，CLI微型語(yǔ)言后端比如數(shù)據(jù)庫(kù)軟件

11.4 應(yīng)用Unix接口設(shè)計(jì)模式

要促進(jìn)腳本化和管道線能力（參考第 7 章），最好就是盡可能地選擇最簡(jiǎn)單的接口設(shè)計(jì)模式——牽扯環(huán)境因素最少、交互最少的模式。

既有腳本方式的接口，又有GUI方式的接口

CGI 瀏覽器內(nèi)嵌程序，用來(lái)接受用戶請(qǐng)求，并處理

沉默原則！

喋喋不休的程序，其他程序很難理解，更難交互

程序每產(chǎn)生一行垃圾，用戶可見(jiàn)的信息就少了一行。

信息內(nèi)容應(yīng)該符合最大驚奇原則——僅僅對(duì)偏離通常期望的情況詳加說(shuō)明。

12 優(yōu)化

過(guò)早優(yōu)化乃萬(wàn)惡之源

Unix的經(jīng)驗(yàn)告訴我們最主要的就是如何知道何時(shí)不去優(yōu)化。其次，最有效的優(yōu)化往往是優(yōu)化之外的其它事情，如：清晰干凈的設(shè)計(jì)。

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

12.2 先估量，后優(yōu)化

如果有真憑實(shí)據(jù)證明應(yīng)用程序運(yùn)行緩慢，這時(shí)（僅當(dāng)此時(shí)）才可以考慮優(yōu)

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

永遠(yuǎn)不要將核心數(shù)據(jù)結(jié)構(gòu)和時(shí)間關(guān)鍵循環(huán)拋出緩存。

“小即是美”的建議比以往更有用，尤其是考慮到核心數(shù)據(jù)結(jié)構(gòu)必須留在最快的緩存里。

三種常規(guī)的策略來(lái)減少時(shí)延，（a）對(duì)可以共享啟動(dòng)開(kāi)銷的事務(wù)進(jìn)行批處理，（b）允許事務(wù)重疊，和（c）緩存。

一致性在簡(jiǎn)單情況下可以保障，所以我絕對(duì)不要用二進(jìn)制緩存，用map做緩存就行了

13 復(fù)雜度：盡可能簡(jiǎn)單，但別簡(jiǎn)單過(guò)了頭

13.1 談?wù)剰?fù)雜度

Unix程序員追求簡(jiǎn)單的激情，源自注重實(shí)效的事實(shí)：復(fù)雜度就是成本

更多行的代碼意味著更多的 bug，而調(diào)試常常是開(kāi)發(fā)中最昂貴、最耗時(shí)的部分。

13.1.2 接口復(fù)雜度和實(shí)現(xiàn)復(fù)雜度的折中

Unix思想中的一個(gè)主題就是強(qiáng)調(diào)工具小巧銳利，設(shè)計(jì)從零開(kāi)始，接口簡(jiǎn)單一致。

如果目標(biāo)是抑制整體復(fù)雜度，最愿意犧牲的是什么地方？什么地方又最該被犧牲掉？

本章大多數(shù)的問(wèn)題，良好品味和工程判斷力要求，情況不同，則答案不同。

重要的是要培養(yǎng)斟酌每一個(gè)設(shè)計(jì)的習(xí)慣。

正如我們?cè)谟懻撥浖K性之前的建議一樣，復(fù)雜度的算盤必須打好。

偶然復(fù)雜度的產(chǎn)生是因?yàn)闆](méi)有找到實(shí)現(xiàn)規(guī)定功能集合的最簡(jiǎn)方法。偶然復(fù)雜度可以由良好的設(shè)計(jì)或重新設(shè)計(jì)來(lái)去除。另一方面，選擇復(fù)雜度，同某個(gè)期望的功能相關(guān)聯(lián)，只能由改變工程的目標(biāo)來(lái)去除。

計(jì)算資源以及人類的思考，同財(cái)富一樣，不是靠?jī)?chǔ)藏而是靠消費(fèi)來(lái)證明其價(jià)值的。

13.3.2 折中無(wú)用

要么簡(jiǎn)約主義，要么無(wú)所不能

程序要么小巧，要么龐大，中間道路行不通

所有真正有用的程序，都想變成瑞士軍刀

只有實(shí)證了其他方法行不通時(shí)，才寫(xiě)龐大程序

行程才是目的;頓悟在每日的實(shí)踐中

第15章

從而讓人心無(wú)旁騖地專注于開(kāi)發(fā)中最重要（也是最享受）的部分——設(shè)計(jì)。 所以設(shè)計(jì)，是讓人享受的對(duì)嗎？

攀爬學(xué)習(xí)曲線的一次性付出，得到的是更有效編寫(xiě)程序的能力；

精力也可以更多地放在設(shè)計(jì)層面而不是低層次的細(xì)節(jié)操作。

make用于文檔轉(zhuǎn)換，比如將html標(biāo)簽文件轉(zhuǎn)換成易讀的文本格式

看到1287

15.6 運(yùn)行期調(diào)試

困難的是，語(yǔ)法正確的程序并不如期望的那樣運(yùn)行，解決辦法是

透明設(shè)計(jì)性：內(nèi)部數(shù)據(jù)的流向容易被人眼和簡(jiǎn)單工具審視

透明設(shè)計(jì)有利于防止bug，以及減輕運(yùn)行期調(diào)試任務(wù)

牢記Unix哲學(xué)，將時(shí)間花費(fèi)在設(shè)計(jì)質(zhì)量上，而不是低層次的細(xì)節(jié)上，盡可能地自動(dòng)化一切---包括運(yùn)行期調(diào)試的細(xì)節(jié)工作

make比較出名的工具是autoconf

profiler用來(lái)工具，用來(lái)檢測(cè)性能

15章看完

第16章

不言之教，無(wú)為之益，天下希及之。

不愿做不必要的工作是程序員的一大美德

避免重新發(fā)明輪子的最有效方法是借用別人的設(shè)計(jì)和實(shí)現(xiàn)。換句話說(shuō)，重用代碼

Unix的經(jīng)驗(yàn)是，養(yǎng)成良好的習(xí)慣，嘗試通過(guò)最少的新發(fā)明，組合現(xiàn)有組件以形成原型，而非匆忙地編寫(xiě)?yīng)毩⒌摹⒅荒苁褂靡淮蔚拇a。

16.2?透明性是重用的關(guān)鍵

實(shí)際上，任何具有非平凡API的軟件，如果無(wú)法深入肌理，甚至無(wú)法正確使用。

所以，開(kāi)放源碼”具有更深遠(yuǎn)的意義

設(shè)計(jì)最好的實(shí)踐需要情感的投入，而不是冷漠無(wú)聊的過(guò)程。軟件開(kāi)發(fā)者，同其它任何類型的工匠和技師一樣；他們想要成為藝術(shù)家，這并不是什么私密。

16.4?

在開(kāi)源世界的開(kāi)發(fā)者，從來(lái)不會(huì)受最終期限的壓迫，不會(huì)一閉眼、一拍腦門就發(fā)布軟件。

Unix下工作，最管用的技能之一就是熟練地掌握將代碼粘合在一起的各種方法，從而能夠應(yīng)用組合原則。

作為Unix開(kāi)發(fā)者，最有價(jià)值的時(shí)間投資方法之一就是，花時(shí)間在這些站點(diǎn)上去了解可以獲得什么東西來(lái)重用。節(jié)省下來(lái)的編碼時(shí)間就是自己的 有機(jī)會(huì)去看一看 1382頁(yè)面

更一般地，閱讀代碼是為未來(lái)而投資。可以從中學(xué)到甚多——新技術(shù)、分解問(wèn)題的新方法、不同的風(fēng)格和手段。使用代碼和學(xué)習(xí)代碼都能得到有價(jià)值的回報(bào)。

寫(xiě)之前先讀；培養(yǎng)閱讀代碼的習(xí)慣。

第17章
好處：無(wú)需重寫(xiě)工具

Unix標(biāo)準(zhǔn)，POSIX，主要是描述：系統(tǒng)調(diào)用，C函數(shù)庫(kù)，shell語(yǔ)義等

標(biāo)準(zhǔn)化，其實(shí)就是為了可移植

標(biāo)準(zhǔn)定義的IETF哲學(xué)：“我們反對(duì)國(guó)王、總統(tǒng)和投票。我們信任大致的共識(shí)和可運(yùn)行的代碼”

請(qǐng)求意見(jiàn)稿（英語(yǔ)：Request?for?Comments，縮寫(xiě)：RFC），又翻譯作意見(jiàn)征求，意見(jiàn)請(qǐng)求，請(qǐng)求評(píng)論[1]是由互聯(lián)網(wǎng)工程任務(wù)組（IETF）發(fā)布的一系列備忘錄。

我的理解，RFC也算是一種被提出來(lái)的規(guī)范，但是流行程度取決于廣大開(kāi)發(fā)者

17.4?

補(bǔ)救糟糕的代碼或設(shè)計(jì)，比起重新開(kāi)始嘗嘗更費(fèi)時(shí)費(fèi)事。

Unix文化主張干脆拆毀重來(lái)。

先原型然后循環(huán)不斷地測(cè)試和演進(jìn)才是更好的方法。

良好的規(guī)格說(shuō)明(我的理解是程序的說(shuō)明文檔)具有巨大的價(jià)值。

Unix開(kāi)發(fā)中，文檔常常在程序之前，或者至少同程序一起編寫(xiě)

規(guī)格說(shuō)明，就是一切？ 所以規(guī)格說(shuō)明是？需求文檔？

標(biāo)準(zhǔn)，是DNA，我們根據(jù)DNA生成RNA，RNA即是根據(jù)標(biāo)準(zhǔn)生成的系統(tǒng)，比如Linux

17.5 可移植性編程

可移植性，空間上，可移植到不同主機(jī)；時(shí)間上，幾十年后仍然能用；時(shí)間上的可移植性甚至更重要

通常可以用autoconf來(lái)探查本地配置，從而解決可移植性問(wèn)題

分離信息庫(kù)和代碼，我覺(jué)得和上面那個(gè)手工寫(xiě)的ASCII常量表有點(diǎn)類似

基于開(kāi)放源碼編程，而不是專用代碼，這樣能更好應(yīng)對(duì)，接口迭代導(dǎo)致的不兼容

18 文檔：向網(wǎng)絡(luò)世界闡述代碼

所見(jiàn)即所得(WYSIWYG)和 已標(biāo)記為中心的工具(比如xml，html，和latex?) ，標(biāo)記工具更容易設(shè)計(jì)格式，布局

unix手冊(cè)，一般都有個(gè)BUGS部分，事無(wú)巨細(xì)地揭露軟件的已知缺陷

文檔類型定義（DTD，Document Type Definition）是一種特殊文檔，和XML語(yǔ)法規(guī)則相關(guān)

看完

19章?

軟件和性一樣，越自由越好

數(shù)量多不會(huì)被認(rèn)為是質(zhì)量高。尤其是，決不要因?yàn)楹ε聞e人看不懂而省略功能細(xì)節(jié)，決不要為了面子而不對(duì)存在的問(wèn)題提出警示。不愿坦露問(wèn)題才會(huì)損害信譽(yù)和用戶，坦白了的問(wèn)題則不會(huì)。

開(kāi)源開(kāi)發(fā)利用了這樣的事實(shí)，甄別和修改 bug 的任務(wù)適合分解成多個(gè)并行的子任務(wù)——這和實(shí)現(xiàn)某個(gè)特殊算法不一樣

盡早發(fā)布，經(jīng)常發(fā)布

因此，精工細(xì)作，等一切完美了才發(fā)布的想法是要不得的。

努力選擇唯一且容易鍵入的名稱前綴

使用GNU自動(dòng)工具

先測(cè)試再發(fā)布代碼

發(fā)布前對(duì)代碼進(jìn)行健全檢查
“健全檢查（sanity check）”的意思是：使用可以獲得的每一款工具來(lái)檢查每個(gè)人類易犯的錯(cuò)誤。使用工具捕捉到的錯(cuò)誤越多，用戶和自己需要對(duì)付的就越少。

比如，使用查找內(nèi)存泄漏和運(yùn)行期錯(cuò)誤的軟件；Electric Fence和Valgrind

擁有FAQ文件可以讓你省很多力氣。當(dāng)關(guān)于項(xiàng)目的某個(gè)問(wèn)題經(jīng)常出現(xiàn)時(shí)，就加到FAQ文件中

發(fā)展良好的FAQ可以減少項(xiàng)目維護(hù)者一個(gè)數(shù)量級(jí)的負(fù)擔(dān)，甚至更多。

看完了

20 未來(lái)：危機(jī)與機(jī)遇(看完)

預(yù)測(cè)未來(lái)的最好方法就是去創(chuàng)造未來(lái)?

Unix 程序員在 30年風(fēng)雨中學(xué)到最有經(jīng)驗(yàn)的回應(yīng)，就是回到最初的準(zhǔn)則——優(yōu)先從流、命名空間、進(jìn)程等Unix基本抽象中得到更多效用，而不是增加新的東西。

更優(yōu)秀解決方案的最危險(xiǎn)敵人，就是一個(gè)現(xiàn)存的、足夠優(yōu)秀的代碼庫(kù)。

C語(yǔ)言缺乏拋出附帶數(shù)據(jù)的命名異常的機(jī)制。因此，Unix API中的C函數(shù)用與眾不同的的返回值（通常是-1或NULL）并設(shè)置全局變量errno來(lái)報(bào)告錯(cuò)誤。[7]

交互設(shè)計(jì)也包含了大量堅(jiān)實(shí)的真理，需要為每個(gè)Unix程序員所知道。

ioctl和fnctl比較尷尬

通過(guò)fcntl設(shè)置的都是當(dāng)前進(jìn)程如何訪問(wèn)設(shè)備或文件的訪問(wèn)控制屬性，例如讀、寫(xiě)、追加、非阻塞、加鎖等，但并不設(shè)置文件或設(shè)備本身的屬性，例如文件的讀寫(xiě)權(quán)限、串口波特率等。

ioctl函數(shù)用于設(shè)置某些設(shè)備本身的屬性，例如串口波特率、終端窗口大小，注意區(qū)分這兩個(gè)函數(shù)的作用。

波特率即指一個(gè)單位時(shí)間內(nèi)傳輸符號(hào)的個(gè)數(shù)。

無(wú)名師的Unix心轉(zhuǎn)

現(xiàn)在得到的90%，比等不來(lái)的100%更有價(jià)值，他強(qiáng)調(diào)實(shí)現(xiàn)的健壯性和簡(jiǎn)單性

Unix傳統(tǒng)是簡(jiǎn)單和空

讀者評(píng)論

一個(gè)人所擁有的的理念和素質(zhì)，遠(yuǎn)比他所表現(xiàn)出來(lái)的專業(yè)技能重要的多？？？？？? 我不贊成，有一說(shuō)一

總結(jié)

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

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