簡簡單單幾條原則：
- 模組的使用者永遠也不應該被模組的行為所迷惑
- 模組要儘可能小，但又不能太小
- 程式碼應該被重用，而不是被拷貝
- 模組之間的依賴性應該儘可能降到最小
- 錯誤應該儘早被檢測出來，最好是在編譯時刻
重點講兩個。
模組的使用者永遠也不應該被模組的行為所迷惑
最簡單的方式是寫下多且準確的註釋，不過我相信大部分很難做到“準確”。我習慣引用濤神的話，將該條規則表述為要求“程式碼能夠自解釋”。
看起來簡單做起來難。對於Java程式猿，有幾種必要的方式可以幫助你儘可能的做到這一點：
- 除了對外公佈的API和部分重要模組，要求自己不加任何註釋
- 使用清晰明確的命名，包括變數、函式、類
- 被確定命名的類、函式、變數，其功能應單一、確定
- 使用的時候再宣告/建立，並儘可能進行顯示的初始化
- 嚴格明確對外保證的邊界，將精力放在保證公開介面，而不是私有實現
- 恰當的使用異常和日誌，不要用日誌代替所有異常，但或許很多ERROR級別的日誌都可以用異常來代替
- 雖然與原則2相悖，但如果合併模組不會使系統變的難以理解，為了簡化系統結構我們建議合併部分模組
- 除非對外發布後不可更改（比如java.util.Set介面），否則，在能保持良好系統結構的前提下，不要面向未來開發（這一點可能很難接受，不過想想什麼時候才應該應用設計模式呢？什麼時候時候才應該優化效能呢？有需要的時候。如果現在不需要，就不要面向未來開發。）
上述方式並不是充分的，我可能會在以後的開發中繼續補充重要的方式，也可能不會。因為你需要掌握的是如何思考，而不是記住這些死知識。
上述原則部分參考自Google Java Style Guide，建議二者結合閱讀。
錯誤應該儘早被檢測出來，最好是在編譯時刻
刷題的時候要時刻牢記：
如果可能，儘早的處理邊界條件。
對於工程開發，可以改編如下：
如果可能，儘早的發現並處理錯誤。
這裡的錯誤包括異常、邏輯錯誤等。分為兩個方面，發現、處理：
- 發現：要求我們儘早的發現錯誤，最好是編譯期；如果在執行期，就要在處理正常邏輯之前，儘早的檢測出錯誤。特別的，在開發期間，編寫完備的測試用例，儘早發現邏輯錯誤。
- 處理：發現錯誤還不夠，我們要處理錯誤。如果是編譯或開發期間發生的錯誤，修改程式碼即可；如果是執行期發生的錯誤，記錄日誌、提前退出、丟擲異常都是值得考慮的選擇，選擇當前保證和當前場景下最合適的。
該原則要和原則1結合起來（任何原則都要和原則1結合），所以記得讓你發現、處理錯誤的程式碼也是自解釋的。
本文連結：程式猿應該記住的幾條基本規則
作者：猴子007
出處：monkeysayhi.github.io
本文基於 知識共享署名-相同方式共享 4.0 國際許可協議釋出，歡迎轉載，演繹或用於商業目的，但是必須保留本文的署名及連結。