UNIX编程艺术笔记
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)題。
- 上一篇: ListView优化问题
- 下一篇: VB 程序设计参考