第三章為基本工具。
除錯的第一準則：不要慌
如果你目睹bug或見到bug報告時的第一反應是「那不可能」你就完全錯了，乙個腦細胞都不要浪費在「但那不可能發生」起頭的思路上，因為很明顯，那不僅可能，而且已經發生了
在除錯時小心「近視」。要抵制只修正你看到的症狀的迫切願望：更有可能的情況是，實際的故障離你正在觀察的地方可能還有幾步遠，並且可能涉及許多其他的相關事物。要總是設法找出問題的根源，而不只是問題的特定表現。
從何處開始？
在開始檢視bug之前，要確保你是在能夠成功編譯的**上工作-沒有警告，把時間浪費在設法找出編譯器能夠為你找出的問題上沒有意義
你也許需要與報告bug的使用者面談，以蒐集比最初給你的資料更多的資料
人工合成的測試不能足夠地演練應用，你必須強硬地測試邊界條件，又測試現實中的終端使用者的使用模式。
從小工到專家讀後感4
第四章注重時效的偏執 you can t write perfect software 你不可能寫出完美的 注重實效的程式設計師連自己也不信任。知道沒有人能編寫出完美的 包括自己，所以注重實效的程式設計師針對自己的錯誤進行防衛性的編碼。按合約設計 dbc軟體設計中為了確保軟體模組的權利與責任，以確保...
11月從小工到專家讀後感（二）
按合約設計 感覺這個dbc限制太嚴格了，有點受不了。這樣做是否值得？代價是不是有點大？然後按照合約去進行設計。死程式不說謊 早崩潰。發現問題，就要讓它在問題的現場崩潰，不要跑到呼叫的棧頂再告訴你發生了什麼。怎樣配平資源 分配資源的例程要負責釋放它。以與資源分配的次序相反的次序解除資源的分配。因為先後...
11月從小工到專家的讀後感（一）
從小工到專家這本書以幽默風趣的語言向我們闡述其程式設計觀點，書中說到我們不應當因為害怕受到處罰，而沒有向上級匯報情況，更不要不好意思提出要求。只有積極的去解決問題才是最好的處理方法。但是匯報也不是一出問題就去匯報的，而是要在你已經嘗試了所有可能的方法，結果都沒有解決，在進行匯報的方式。其次就是提到了...