第四章注重時效的偏執
you can't write perfect software
你不可能寫出完美的**
注重實效的程式設計師連自己也不信任。知道沒有人能編寫出完美的**，包括自己，所以注重實效的程式設計師針對自己的錯誤進行防衛性的編碼。
按合約設計
dbc軟體設計中為了確保軟體模組的權利與責任，以確保程式的正確性，也引入了合約的概念，這就是dbc（design by contract）按合約設計。
dbc的流程：
1.前條件：為了呼叫例程，必須為真的條件
2.後條件：例程保證會做的事情
3.類不變項：類確保從呼叫者的視角來看，該條件總是為真
design with contracts
通過合約進行設計
實現dbc
1.斷言
支援斷言式程式設計的語言可以通過斷言部分實現dbc。
為什麼是部分實現？因為：
首先，斷言不支援繼承層次向下遺傳
其次，斷言不支援「老」值。（什麼是「老」值？）
最後，runtime和庫的設計不支援合約（什麼意思？）
2.語言支援
有些語言內建對dbc的支援（eiffel和sather）
c，c++的有些預處理器能處理作為特殊注釋嵌入在**中的dbc。預處理器可以把這些注釋展開為斷言**（nana）
j**a可以使用icontract
從小工到專家讀後感3
第三章為基本工具。除錯的第一準則 不要慌 如果你目睹bug或見到bug報告時的第一反應是 那不可能 你就完全錯了，乙個腦細胞都不要浪費在 但那不可能發生 起頭的思路上，因為很明顯，那不僅可能，而且已經發生了 在除錯時小心 近視 要抵制只修正你看到的症狀的迫切願望 更有可能的情況是，實際的故障離你正在...
11月從小工到專家讀後感（二）
按合約設計 感覺這個dbc限制太嚴格了，有點受不了。這樣做是否值得？代價是不是有點大？然後按照合約去進行設計。死程式不說謊 早崩潰。發現問題，就要讓它在問題的現場崩潰，不要跑到呼叫的棧頂再告訴你發生了什麼。怎樣配平資源 分配資源的例程要負責釋放它。以與資源分配的次序相反的次序解除資源的分配。因為先後...
11月從小工到專家的讀後感（一）
從小工到專家這本書以幽默風趣的語言向我們闡述其程式設計觀點，書中說到我們不應當因為害怕受到處罰，而沒有向上級匯報情況，更不要不好意思提出要求。只有積極的去解決問題才是最好的處理方法。但是匯報也不是一出問題就去匯報的，而是要在你已經嘗試了所有可能的方法，結果都沒有解決，在進行匯報的方式。其次就是提到了...