按合約設計：感覺這個dbc限制太嚴格了，有點受不了。這樣做是否值得？代價是不是有點大？然後按照合約去進行設計。
死程式不說謊：早崩潰。發現問題，就要讓它在問題的現場崩潰，不要跑到呼叫的棧頂再告訴你發生了什麼。
怎樣配平資源:分配資源的例程要負責釋放它。以與資源分配的次序相反的次序解除資源的分配。因為先後2個資源可能會有依賴關係。相同的順序分配同一組資源。降低死鎖的機率。
要會用try finally要學會dispose()
使耦合減至最少得墨忒耳法則
某個物件的任何方法都應該只呼叫屬於以下情況的方法：
1）這個物件自己擁有的方法；
2）傳入該方法的引數的方法；
3）該方法建立的物件的方法；
4）該物件直接擁有的物件的方法；
黑板模式是一種常用的架構模式，應用中的多種不同資料處理邏輯相互影響和協同來完成資料分析處理。就好像多位不同的專家在同一黑板上交流思想，每個專家都可以獲得別的專家寫在黑板上的資訊，同時也可以用自己的分析去更新黑板上的資訊，從而影響其它專家。黑板模式的應用場景是要解決的任務可以分為多個子任務。
當我們在編碼的時候，考慮的編碼速率主要是用o（）表示，不需要我們去考慮；
現在的ide中的重構功能已經相當強大，真是太方便了。如果ide裡不支援重新命名的重構，我會瘋掉的。
如果發現了這些情況，說明需要重構了：重複、非正交的設計、過時的知識、效能。
1）不要試圖在重構的同時加入新功能。
2）在開始重構前，確保你擁有良好的測試。
3）採用短小、深思熟慮的步驟，每一步都執行一遍你的單元測試**。
11月從小工到專家的讀後感（一）
從小工到專家這本書以幽默風趣的語言向我們闡述其程式設計觀點，書中說到我們不應當因為害怕受到處罰，而沒有向上級匯報情況，更不要不好意思提出要求。只有積極的去解決問題才是最好的處理方法。但是匯報也不是一出問題就去匯報的，而是要在你已經嘗試了所有可能的方法，結果都沒有解決，在進行匯報的方式。其次就是提到了...
從小工到專家讀後感4
第四章注重時效的偏執 you can t write perfect software 你不可能寫出完美的 注重實效的程式設計師連自己也不信任。知道沒有人能編寫出完美的 包括自己，所以注重實效的程式設計師針對自己的錯誤進行防衛性的編碼。按合約設計 dbc軟體設計中為了確保軟體模組的權利與責任，以確保...
從小工到專家讀後感3
第三章為基本工具。除錯的第一準則 不要慌 如果你目睹bug或見到bug報告時的第一反應是 那不可能 你就完全錯了，乙個腦細胞都不要浪費在 但那不可能發生 起頭的思路上，因為很明顯，那不僅可能，而且已經發生了 在除錯時小心 近視 要抵制只修正你看到的症狀的迫切願望 更有可能的情況是，實際的故障離你正在...