這週我的閱讀書目是《程式設計匠藝》，像大多數有關書目一樣，該書從圍繞著如何編寫優美的**進行了討論，我著重看了書中關於防禦性程式設計和**優化兩個部分，這兩個部分也是我們在該課程中可以說是最主要的兩個方面。
1、關於防禦性程式設計：
用書中一句讓人覺得可笑卻又不得不認同的話引入，就是「所有你覺得有可能出錯的地方就一定會出錯」，雖然這句話有片面性，但是我們不得不承認作為乙個程式設計師或者即將成為程式設計師的人來說，簡直是至理名言。我理解防禦性程式設計，就是在編寫的過程中將犯錯誤的可能性消除，用老師的話說就是將bug扼殺在娘胎中。雖然編寫**時考慮太多會耽誤一點時間，但是這些都是為了節省debug的時間，這話是有道理的，但仔細一想卻又是模糊不清的，寫**時要考慮到什麼樣的程度，怎麼避免「太過謹慎」，比如寫一行無關緊要的**，卻仔仔細細看了十幾遍，這自然是划不來的。所以我感覺也並不是說作者強調的是**寫的時間越長，出錯的可能性就越低，作者的意思應當是寫**不要過於追求速度，應當保持平和的心態，在做任何新的**結構方面的構思時，應當深思熟慮，最少要三思而後碼。當做到這幾點時，再花更多的時間也就已經沒有太多意義了。
2、**優化的問題：
優化通常的意思就是讓**執行的更快，減少儲存的開銷，也即提高**的質量。但是書中也給出了某些專家關於優化的傳統觀點：對於一般程式設計師，不要做優化；對於專家，也還是不要做優化。雖然現在的計算機在運算能力上和記憶體管理上都已經有了極大的進步，我們的優化看起來就沒有什麼太大的價值了，起始我感覺不盡然，優化能力一方面是程式設計師技能的體現還有就是做好優化是一種習慣，可以使團隊工作的效益得到提公升。時間上的優化節約了團隊工作時間，記憶體上的優化也避免了以後工作中因為記憶體而產生的bug。但是那麼多人不建議進行優化就說明優化必定是存在一些負面影響的，比如降低了**的可讀性，使**變得更加難以維護，所以優化時還是要非常的慎重。
第九章 讀書筆記
這一章主要講的是硬體抽象層 hal hal hardware abstraction layer，硬體抽象層 是建立在 linux 驅動之上的一套程式庫。這套程式庫並不屬於 linux 核心，而是屬於 linux 核心層之上的應用層。google為 android 加入hal 主要目的如下 1 統一...
第九周學習筆記
主要內容 1.文章解決了什麼問題？svm訓練演算法在大規模問題上收斂很慢，且十分複雜 難以實現，運算過程中需要維持乙個n 2n 2 n2個元素的矩陣，當年 1998 問題規模超過4000個樣本時，就超過了當時的記憶體大小 128mb 曾經的訓練演算法之一的chunking使得演算法從維持n 2n 2...
effectiveC 讀書筆記（九）
9.雜項討論 miscellany 1.嚴肅對待編譯器發出的警告訊息。努力在你的編譯器的最高 最嚴苛 警告級別下爭取 無任何警告 的榮譽 2.不要過度倚賴編譯器的報警能力，因為不同的編譯器對待事情的態度並不相同。一旦移值到另乙個編譯器上，你原本倚賴的警告資訊有可能消失 1.c 標準程式庫主要機能由 ...