公司入職前安排了讀書環(huán)節(jié)，后臺開發(fā)類推薦了一下書籍：

• C++ Primer
• Unix 環(huán)境高級編程（APUE）
• Unix網(wǎng)絡(luò)編程 1/2卷（UNP）
• TCP/IP協(xié)議詳解
• 深入理解計算機系統(tǒng)
• Effective C++
• UNIX編程藝術(shù)
  以上書籍之前多多少少都接觸過一些，最近在做畢設(shè)方面的事情，想著看本輕松點的書籍，就從圖書館借了本《UNIX編程藝術(shù)》。花了一兩周的時間閱讀完此書，全書較多涉及UNIX編程的理念，而不是具體的技術(shù)。新手可以學(xué)到很多理論上的知識（非常適合拿來裝逼吹水），比如KISS原則、模塊化、透明性、機制與策略分離等，而老手在接觸到這些理論之后再結(jié)合自己做過的東西，仔細思考，應(yīng)該也會有自己一番的體會。所以不論是新手還是老手看此書都會有很多收獲。此書寫于2004年，到現(xiàn)在也有些年頭了，內(nèi)容舉例可能會有些陳舊，我們在閱讀的時候，也可以想想作者說的現(xiàn)在是否正確。
  下面的一些內(nèi)容是自己閱讀之后做的一些筆記，以供時常拿來翻閱。

I-場景

1. 哲學(xué)

• 機制而不是策略，自由放縱注意風(fēng)格，產(chǎn)生了多樣性。比如Unix應(yīng)用程序提供很多的行為選項，讓非技術(shù)的用戶暈頭轉(zhuǎn)向，而失去了很多用戶；但是策略相對短壽、機制才會長存，具有很大的靈活性。
• 趣味性是一個峰值效率的標志。對于程序員和開發(fā)人員來說，如果完成某項任務(wù)所需要付出的努力對他們是個挑戰(zhàn)又恰好還在力所能及的范圍，他們就會覺得很有樂趣。 而UNIX有Hack趣味。
• UNIX哲學(xué)是自下而上的，注重實效，鼓勵分清輕重緩急的感覺以及懷疑一切的態(tài)度，并鼓勵你以幽默達觀的態(tài)度對待這些。
• 簡潔是UNIX程序的核心風(fēng)格。 UNIX哲學(xué)的KISS原則：Keep it simple, stupid!
• 先制作原型，再精雕細琢。優(yōu)化之前，先確定能用。

2. 歷史–雙流記

本章主要回顧UNIX的歷史，來闡明如今的UNIX文化為什么呈現(xiàn)當前的狀態(tài)。 兩個歷史分別是UNIX的起源和歷史以及黑客的起源和歷史

UNIX的起源和歷史

• UNIX的祖輩是CTSS–兼容分時系統(tǒng)，父輩是頗具開拓性的Multics項目（試圖建立一個具備眾多功能的系統(tǒng)）；
• 創(chuàng)世紀：1969-1971年，UNIX誕生于貝爾實驗室；
  *出埃及記：1971-1980，C語言的加入，其表述方式帶來的可讀性、可改性和可移植性，給UNIX帶來了一定的成功。
• TCP/IP和UNIX內(nèi)戰(zhàn)：1980-1990， TCP/IP的引入，讓UNIX更加有活力。 然而微軟的興起和AT&T的拆分，讓UNIX進入了煉獄。UNIX的產(chǎn)業(yè)化，破壞了UNIX源碼的自由交流，而自由交流卻正是滋養(yǎng)UNIX系統(tǒng)早期的活力。
• 反擊帝國：1991-1995,Linus Torvalds宣布了Linux項目，依賴分布式開發(fā)和patch（補丁）工具，加入了Internet和圖形界面，實現(xiàn)了Unix的平價之夢，并拼裝了UNIX的傳統(tǒng)元素。 1995年之后，UNIX的故事就變成了開源運動的故事。

黑客的起源和歷史：1961-1995

• 游戲在校園的林間：1961-1980年，MIT的人工智能實驗室的程序員應(yīng)該是第一批自稱”hacker“的人；
• 互聯(lián)網(wǎng)大融合與自由軟件運動：1981-1991. 1983年，BSD植入了TCP/IP,UNIX文化和ARPANET文化開始融合。RMS創(chuàng)建了GNU項目，致力于編一個完全自由的操作系統(tǒng)。自由軟件術(shù)語的提出，讓黑客文化更加有自我意識。
• Linux和實用主義者的應(yīng)對：1991-1998. Linus Torvalds巧妙地跨越了GPL和反GPL的派別之爭。他利用GNU工具包搭建了自創(chuàng)的Linux內(nèi)核，用GPL的傳染性質(zhì)保護它。Torvalds明確的表示他認為自由軟件通常很好，但他偶爾也用專有軟件，他拒絕成為狂熱分子。

開源運動：1998年及之后

• 一個部落的零距離可能來自他們維護的代碼庫，或是一個或多個有著超凡影響力的領(lǐng)導(dǎo)者，或是一門語言，一個開發(fā)工具，或是一個特定的軟件許可，或是一種技術(shù)標準，或是基礎(chǔ)結(jié)構(gòu)某個部分的管理組織。 1995年之后，Linux扮演了一個特殊的角色：既是社區(qū)內(nèi)多數(shù)軟件的統(tǒng)一平臺，又是黑客中最被認可的品牌。整個黑客文化開始凝聚在一個共同目標：推動Linux和集市開發(fā)模式向前發(fā)展。
• ”開源“背后另一個意圖就是希望將黑客社區(qū)的方法以一種更親和市場、更少對抗性的方式介紹給外部世界。

Unix的歷史教訓(xùn)

• 距開源越近就越繁榮；
• 過度依賴任何一種技術(shù)或者商業(yè)模式都是錯誤的–相反，保持軟件及其設(shè)計傳統(tǒng)的靈活性才是生存之道；
• 別和低價而靈活的方案較勁；
• 真正的專業(yè)和奉獻精神，正是我們在屈服于世俗觀念的”合理商業(yè)做法“之前的所作所為。

3. 對比：Unix哲學(xué)同其他哲學(xué)的比較

操作系統(tǒng)的風(fēng)格元素

• 操作系統(tǒng)的統(tǒng)一性理念。比如UNIX系統(tǒng)的”一切皆文件“模型和由此基礎(chǔ)上建立的管道概念。
• 多任務(wù)能力。Unix系統(tǒng)擁有搶先式多任務(wù)的能力。 多任務(wù)和多用戶不是一回事。
• 協(xié)作進程：UNIX的IPC（進程間通信方式）很靈活。
• 內(nèi)部邊界： Unix是相信程序員的，但是程序員不能破壞其他人的數(shù)據(jù)，所以Unix設(shè)立了內(nèi)部邊界來防范惡意用戶或者有缺陷的程序。
• 開發(fā)的門坎： Unix將編譯器和腳本工具放在默認安裝中，支持了一種跨越眾多機器的玩家開發(fā)文化。

操作系統(tǒng)的比較

• 列舉了若干操作系統(tǒng)的優(yōu)缺點。

種什么籽，得什么果

• 競爭對手的一些缺點： 比如不可移植性、不具備良好的網(wǎng)絡(luò)支持能力。
• 而Windows在服務(wù)器上的缺陷（安全等原因），使得Linux取得了重大突破。
• 就像造房子一樣，在堅實的地基上修理上層建筑當然要比更換地基而不破壞上層建筑來得容易。

II–設(shè)計

4. 模塊化：保持清晰，保持簡潔。

• 早期的Unix程序員擅長模塊化是因為他們被迫如此，如果沒有良好的架構(gòu)，操作系統(tǒng)就會崩潰。
• 封裝良好的模塊，不會過多向外部披露自身的細節(jié)，不會直接調(diào)用其他模塊的實現(xiàn)碼，也不會胡亂共享全局數(shù)據(jù)。
• 具有最佳尺寸的模塊并不意味著代碼有高質(zhì)量，還得考慮緊湊性和正交性。
• 緊湊性就是一個設(shè)計能否裝入人腦。比如一個設(shè)計有經(jīng)驗的用戶不需要操作手冊，這個設(shè)計就是緊湊的。
• 正交性是指任何操作均無副作用，每一個動作只改變一件事，不會影響其他。
• 不要重復(fù)自身（don’t repeat yourself)。
• 軟件的分層：自頂向下和自底向上。 當自頂向下和自底向上發(fā)生沖突時，頂層的應(yīng)用邏輯和底層的域原語集必須用膠合邏輯層來進行阻抗匹配。 膠合層是個挺討厭的東西，必須盡可能薄。
• OO語言使抽象變得容易，但是過多的層次破壞了透明性，我們很難看清層次，無法理清代碼的運行過程。
• 單個函數(shù)與其說是行數(shù)計算問題，不如說是內(nèi)部復(fù)雜度性的問題（比如說局部變量太多、代碼存在太多縮進）。

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

• 設(shè)計文件格式和應(yīng)用協(xié)議需要考慮的重要方面：互用性、透明性、可擴展性以及經(jīng)濟型。
• 使用二進制的唯一正當理由：處理大批量的數(shù)據(jù)集或者關(guān)心時間或指令開銷。
• 數(shù)據(jù)文件元格式有多重不同的元格式，比如DSV、RFC 822、Cookie-Jar、Record-Jar、XML、Windows INI等；
• 應(yīng)用協(xié)議如果是文本格式的，憑肉眼可以很容易地分析，很多事情變得容易。可以看看SMTP、POP3和IMAP三種經(jīng)典的應(yīng)用協(xié)議。
• 應(yīng)用協(xié)議元格式：盡管網(wǎng)絡(luò)帶寬比存儲昂貴許多，需要重視事物處理的經(jīng)濟性，但是文本格式的透明性和互用性優(yōu)勢還是十分顯著，大多數(shù)設(shè)計者還是選擇了采用可讀性更高的文本格式。比如HTTP協(xié)議、BEEP協(xié)議、XML-RPC/SOAP/Jabber協(xié)議。

6.透明性：來點光

在第五章中，討論了數(shù)據(jù)格式和應(yīng)用協(xié)議進行文本化的重要性，文本化讓透明性和可顯性的品質(zhì)得到了提升。
* 如果實際上能夠預(yù)測到程序行為的全部或大部分情況，這個程序就是透明的；
* 如果程序可以幫助人們建立“做什么、怎樣做”，這個軟件系統(tǒng)就是可顯的。比如對用戶來說，文檔有助于可顯性； 對程序員而言，好的命名規(guī)范有助于提高可顯性。
* 要追求代碼的透明，最有效的方法很簡單，就是不要在具體操作的代碼上疊放太多的抽象層。
* 透明的系統(tǒng)在bug發(fā)作時，更容易實施恢復(fù)措施；同時，透明的系統(tǒng)更容易讓人理解，從而更加方便維護。

7. 多道程序設(shè)計

• UNIX最具特點的程序模塊化方法就是將大型程序分解成多個協(xié)作進程。
• 多個并發(fā)進程除了帶來模塊化的好處之外，另一個原因是為了更強的安全性。
• UNIX IPC：把任務(wù)轉(zhuǎn)給專門程序（shell out)、管道/重定向（管道主要缺點是單向性，命名管道可以作為兩者間的配接器）、從進程、對等進程（臨時文件、信號、套接字、共享內(nèi)存）。

8. 微型語言：尋找歌唱的樂符

UNIX班有個長期傳統(tǒng)，存在小型的、為專門應(yīng)用領(lǐng)域特制、大量減少程序行數(shù)的語言。 比如無數(shù)Unix排版語言（troff/pic）、shell使用程序（awk/sed/dc/bc）和軟件開發(fā)工具（make/yacc/lex等）。 微型語言與腳本語言之間的界限都很模糊。
* 一切可計算的問題都可以計算，叫做圖靈完備。
* 明白微型語言在什么時候什么場景下使用。
* 某些情況下，需要我們我們?nèi)ピO(shè)計一個微型語言。 首先要盡可能保持微型語言的簡單（復(fù)雜度），思考能否通過擴展或者嵌入現(xiàn)有腳本語言來實現(xiàn)自己的微型語言（這是實現(xiàn)命令性語言的正確方法），慎用宏。

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

• 數(shù)據(jù)比程序邏輯更易駕馭，更加直觀，透明性和清晰性方面更勝一籌。
• 數(shù)據(jù)驅(qū)動編程，將代碼和數(shù)據(jù)結(jié)構(gòu)劃分清楚，在改變程序邏輯時，只要改變數(shù)據(jù)結(jié)構(gòu)而不用修改代碼。
• 專用代碼的生成，比如用工具生成HTML代碼。盡可能少干活，建設(shè)性的懶惰是大師級程序員的基本美德之一。

10.配置：邁出正確的第一步

• 配置在哪里？在下面這些地方，查詢通常按照下面的順序進行，后面的設(shè)置會覆蓋前面的設(shè)置。
• 運行控制文件，在/etc/目錄下。
• 環(huán)境變量，系統(tǒng)環(huán)境變量、用戶環(huán)境變量。
• 命令行選項
• 上述配置是從最不易改變到最易改變的順序排列的。

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

• 程序的接口就是程序同用戶或者其它程序通信的方法總和。
• 最小立異原則：少來標新立異，是所有接口設(shè)計中的通用原則，且并非僅局限于軟件設(shè)計。一心不能二用，應(yīng)該把中心放在接口所屬的任務(wù)上。而這個原則，也不應(yīng)被理解為機械的保守主義。 如有可能，盡量允許用戶將接口功能委派給熟悉的程序來完成，不能委派時就效仿。
• Unix程序中存在豐富的接口風(fēng)格：面向行的、面向屏幕字符陣列的和基于X的，不同的接口風(fēng)格，適用于不同的任務(wù)。
• 接口的幾種度量標準：簡潔、表現(xiàn)力、易用、透明性和腳本化能力。
• CLI和可視化接口之間的權(quán)衡。命令行更具表達力，尤其是針對復(fù)雜的任務(wù)，同時具有高度的腳本化能力，但是CLI需要費勁地記憶（易用性低），并且透明性也非常低。比如說數(shù)據(jù)庫的SQL語句和圖形界面操作來說，可以很明顯看出二者之間的差別，同樣命令行的計算器和圖形界面的計算器對比也比較明顯。
• Unix接口設(shè)計模式。根據(jù)輸入和輸出可以分為這些模式：過濾器模式（比如grep）、Cantrip模式（比如clear)、源模式（不需要輸入，比如ls）、接收器模式（只接收不輸出，例子較少，比如lpr）、編譯器模式（既無標準輸入也無標準輸出，將錯誤消息發(fā)送到標準錯誤端）、ed模式（比如ftp、sh）、Roguelike模式（字符陣列比如vi）、“引擎和接口分離”模式（MVC模式作為GUI原型的建議）、CLI服務(wù)器模式
• 網(wǎng)頁瀏覽器作為通用前端，無需編寫一個定制的GUI前端。

12. 優(yōu)化

• 過早優(yōu)化是萬惡之源
• 不到萬不得已，盡量別去優(yōu)化一個工作中的系統(tǒng)，而是等上幾個月，期待硬件性能更好。
• 先估量，再優(yōu)化。通過profiler，去明確瓶頸所在，而profiler本身也是存在工具誤差的。
• 最有效的代碼優(yōu)化方法是保持代碼短小簡單。目標機器是分層的，將核心的數(shù)據(jù)結(jié)構(gòu)和指令代碼放在快速緩存。
• 快速處理器的另一個效應(yīng)是性能經(jīng)常受限于I/O以及網(wǎng)絡(luò)事務(wù)的開銷，要盡量避免協(xié)議的往返。
• 有三種常規(guī)策略來減少延遲：批操作、重疊操作、緩存操作結(jié)果。

13. 復(fù)雜度：盡可能簡單，但別簡單過了頭

• “Keep it simple, stupid”, 對于簡單的理解其實是很復(fù)雜的。
• 復(fù)雜度的三個來源：程序員實現(xiàn)的復(fù)雜度、顧客和用戶使用的復(fù)雜度以及代碼量，關(guān)于怎么去折中，是沒有標準答案的。
• 通過五個編輯器的故事，了解編輯器在處理更復(fù)雜任務(wù)時產(chǎn)生的不同程度的選擇復(fù)雜度。
• 吝嗇原則：只有實證了其它方法不通時才寫龐大程序。

III– 工具

14. 語言：C還是非C

• Unix下面存在非常多的語言種類。一是因為Unix廣泛應(yīng)用于研究和教學(xué)平臺，二是因為應(yīng)用設(shè)計和實現(xiàn)語言的合理搭配對生產(chǎn)力有極大促進。
• C語言很厲害、很經(jīng)濟。但是要求程序員自己完成內(nèi)存管理，很復(fù)雜，并且隨著硬件設(shè)備的性能提升，主要瓶頸集中在I/O事件等待、網(wǎng)絡(luò)延遲以及緩存列填充等限制上，所以Python、Java等語言慢慢興起。

15. 工具：開發(fā)的藝術(shù)

本章將介紹Unix下的開發(fā)策略–編譯代碼、管理代碼配置、性能分析、調(diào)試以及自動完成各種臟活累活。 這一套工具比起IDE更加靈活。
* 編輯器選擇：vi和Emacs
* 專用代碼生成器：yacc、lex
* 自動化編譯：make。 一個笑話：輸入”make love”，輸出是“Don’t know how to make love”。
* 版本控制系統(tǒng)
* 性能分析：gprof

16. 重用：論不要重新發(fā)明輪子

• 很多人喜歡自己造輪子，因為庫可能不是透明的、充滿bug，還不如自己來的痛快。
• 隨著開源的提出，我們應(yīng)當選擇好的輪子，這樣可以節(jié)省時間，提高效率。
• 很多開源的網(wǎng)站，如github等。
• 注意一些許可證的問題。

IV–社區(qū)

17. 可移植性：軟件可移植性與遵循標準

• 移植性一直是Unix的主要優(yōu)勢，可移植的戒律往往在架構(gòu)、接口和實現(xiàn)上施加了一種簡單化的影響，提高了項目成功的幾率也降低了生命周期的維護成本。
• C語言、Unix標準，IETF、RFC標準，一系列的標準和草案讓接口更加規(guī)范，從而更方便移植。
• 編程語言的可移植：Java和Python具備良好的可移植性。
• 可移植工具：autoconf來處理移植問題，configure/make/make install來干凈利落的編譯。
• 可移植性需要標準，而開放源代碼同樣給標準化的過程帶來了重要的影響。

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

• 文檔一般分為兩類，所見即所得（word）和標記為中心（XML、markdown），各有優(yōu)缺點；
• 編寫Unix文檔最佳實踐：信息密度適中、不要過于龐大、也不要省略功能細節(jié)和存在的問題、將文檔放在網(wǎng)上。

19. 開放源碼：在Unix新社區(qū)中編程

• 開源開發(fā)的規(guī)則很簡單：源碼公開、盡早發(fā)布-經(jīng)常發(fā)布、給貢獻以表揚（物質(zhì)獎勵或者精神獎勵）
• 與開源工作者協(xié)同工作的最佳實踐：版本控制系統(tǒng)（Git、svn等）、良好的代碼注釋、良好的代碼規(guī)范和文件命名規(guī)范、測試好再發(fā)布大媽、良好的交流實踐（郵件列表、網(wǎng)站等）。
• 許可證的邏輯，挑選合適的許可證。

20. 未來：危機與機遇

• 回顧過去，網(wǎng)絡(luò)互聯(lián)、位圖圖形顯示以及個人計算機這三個特殊的技術(shù)變化驅(qū)動了Unix設(shè)計風(fēng)格的重大變革。
• 盡管伴隨著許多創(chuàng)新，但所有對這三個技術(shù)的響應(yīng)都保持著Unix的設(shè)計準則–模塊化、透明性、機制同策略分離以及之前提到的品質(zhì)。
• Unix對GUI的支持較弱。Unix的API沒有使用異常（C語言缺乏拋出異常的機制）。
• 從歷史來看，我們只要能夠從錯誤中汲取教訓(xùn)，文化薪火相傳，Unix是不會輸?shù)摹?/li>

如果覺得文章不錯，可以打賞點~

總結(jié)

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

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