程序員修煉之道-從小工到專家讀後感3

　　　　閱讀了第四章和第五章的一部分，其中有關異常讓我印象深入，特別是本身也剛學到java異常處理部分，有關自定義異常類等。

　　　　在編程的時候，若是他不可能發生，用斷言確保他不會發生，只要最後結果不出來，那麼你所認爲的不必定就是徹底正確的，而你所要作的就是，增長代碼來檢驗他，最容易的辦法就是使用斷言，固然，絕對不要把必須的代碼放在斷言裏面，由於斷言可能會在編譯時被關閉，而且斷言不等於真正的錯誤的處理，所以不能用斷言來代替真正的錯誤處理，斷言檢查的是毫不應該發生的事情。

　　　　讓斷言一直開着，就像書中的那個說法同樣，斷言給代碼增長了一些開銷，由於他們檢查的是毫不應該發生的事情，，因此只會有代碼中的bug出發，一旦代碼通過了測試儀而且發佈出去，他們就再也不須要存在，應該被關閉，以使代碼運行的更快，斷言只是一種調試設施，這樣的說法誤導了人們對於斷言的見解，並且自己也存在重大的錯誤，在複雜的程序中，你不會那麼輕易的找到你的bug所在，其次，你的程序在運行的時候還會發生一些不可預料的事情，你的第一條防線是檢查任何可能的錯誤，第二條防線是使用斷言設法監測你疏漏的錯誤。

　　　　異常應該保留給意外事件，例如在文件讀取的時候是否有文件，刪除文件的時候是否存在，建立新文件的時候是否已經存在文件等，錯誤處理器是檢測到錯誤時調用的例程。在配平資源的時候要善始善終，在Java中，當try塊含有finally子句時，若是try塊中有任何語句被執行，該子句中的代碼就保證會被執行，是否有異常拋出沒有影響。但你沒法配平資源的時候，在動態數據結構的程序中，一個例程將分配一塊內存區，並把它鏈接進某個更大的數據庫中，這塊內存可能會在那裏呆上一段時間。注重實效的程序員誰都不信任，包括咱們本身，因此咱們以爲，構建代碼，對資源倒是獲得了適當釋放進行實際檢查，這老是一個好主意，對於大多數應用，這一般意味着爲美中資源類型編寫包裝，並使用這些包裝追蹤全部的分配和解除分配在你代碼中的釘釘地方，程序邏輯將要求資源處在特定的狀態中：使用包裝對此進行檢查。

　　　　生活不會停步不前，一樣，咱們編寫的代碼也不會，爲了讓咱們遇上今天近乎瘋狂的變化步伐，咱們必需要盡一切努力編寫儘量狂送靈活的代碼，不然，咱們會發現咱們的代碼變得過期，或者是太脆弱，以致於難以修理，而且最終可能會在想着將來瘋狂的突進中掉隊。要儘可能的下降代碼的耦合度（代碼模塊間的依賴關係），讓分離的概念保持分離，一種辦法是少寫代碼，改動代碼會讓你引入bug的可能性增大，把各類細節移除代碼，那樣就能夠更安全，更容易的改動他們，你應該注意你與多少其餘模塊交互，並且更重要的是，你怎樣開始與他們交互的，當咱們要求某個對象完成特定任務時，咱們想要愛軟件中遵循一樣的模型，咱們不但願這個對象給咱們一個第三方對象，咱們必須對其加一處理才能得到所需的服務。

　　　　再多的天才也沒法賽過對細節的專一，細節會弄亂咱們整潔的代碼，特別是他們常常變化，沒當咱們必須去改動代碼，以適應商業邏輯，法律，或管理員我的一時的口味的某種變化時，咱們有破壞系統，引入新bug 的危險。不要讓你的項目或者你的職業生涯走上渡渡鳥的道路，他們不能適應人類和他們的家畜的出現，好久就滅絕了，是人類記載的第一塊兒物種的滅絕。時間是軟甲架構的一個經常被忽略的方面，吸引咱們的只是進度表上的時間，相反咱們談論的是做爲軟件自身的一種設計要素的時間的角色，時間有兩個方面對咱們很重要，併發和次序。咱們在編程的時候，每每是線性的，老是先這個，再這個，這樣會帶來時間的耦合：在時間上的耦合，方法a必須老是在方法b以前調用；同時只能運行一個報告；再接受到按鈕點擊以前，你必須等待屏幕重畫滴必須在嗒以前發生。