簡簡單單幾條原則：
- 模塊的用戶永遠也不應(yīng)該被模塊的行為所迷惑
- 模塊要盡可能小准夷，但又不能太小
- 代碼應(yīng)該被重用，而不是被拷貝
- 模塊之間的依賴性應(yīng)該盡可能降到最小
- 錯誤應(yīng)該盡早被檢測出來，最好是在編譯時刻
重點講兩個。
模塊的用戶永遠也不應(yīng)該被模塊的行為所迷惑
最簡單的方式是寫下多且準確的注釋，不過我相信大部分很難做到“準確”忽舟。我習(xí)慣引用濤神的話，將該條規(guī)則表述為要求“代碼能夠自解釋”。
看起來簡單做起來難叮阅。對于Java程序猿刁品，有幾種必要的方式可以幫助你盡可能的做到這一點：
- 除了對外公布的API和部分重要模塊，要求自己不加任何注釋
- 使用清晰明確的命名浩姥，包括變量挑随、函數(shù)、類
- 被確定命名的類勒叠、函數(shù)兜挨、變量，其功能應(yīng)單一眯分、確定
- 使用的時候再聲明/創(chuàng)建拌汇，并盡可能進行顯示的初始化
- 嚴格明確對外保證的邊界，將精力放在保證公開接口弊决，而不是私有實現(xiàn)
- 恰當?shù)氖褂卯惓：腿罩?/strong>噪舀，不要用日志代替所有異常，但或許很多ERROR級別的日志都可以用異常來代替
- 雖然與原則2相悖飘诗，但如果合并模塊不會使系統(tǒng)變的難以理解与倡，為了簡化系統(tǒng)結(jié)構(gòu)我們建議合并部分模塊
- 除非對外發(fā)布后不可更改（比如java.util.Set接口），否則疚察，在能保持良好系統(tǒng)結(jié)構(gòu)的前提下蒸走，不要面向未來開發(fā)（這一點可能很難接受，不過想想什么時候才應(yīng)該應(yīng)用設(shè)計模式呢貌嫡？什么時候時候才應(yīng)該優(yōu)化性能呢？有需要的時候该溯。如果現(xiàn)在不需要岛抄，就不要面向未來開發(fā)。）
上述方式并不是充分的狈茉，我可能會在以后的開發(fā)中繼續(xù)補充重要的方式夫椭，也可能不會。因為你需要掌握的是如何思考氯庆，而不是記住這些死知識蹭秋。
上述原則部分參考自Google Java Style Guide，建議二者結(jié)合閱讀堤撵。
錯誤應(yīng)該盡早被檢測出來仁讨，最好是在編譯時刻
刷題的時候要時刻牢記：
如果可能，盡早的處理邊界條件实昨。
對于工程開發(fā)洞豁，可以改編如下：
如果可能，盡早的發(fā)現(xiàn)并處理錯誤。
這里的錯誤包括異常丈挟、邏輯錯誤等刁卜。分為兩個方面，發(fā)現(xiàn)曙咽、處理：
- 發(fā)現(xiàn)：要求我們盡早的發(fā)現(xiàn)錯誤蛔趴，最好是編譯期；如果在運行期例朱，就要在處理正常邏輯之前夺脾，盡早的檢測出錯誤。特別的茉继，在開發(fā)期間咧叭，編寫完備的測試用例，盡早發(fā)現(xiàn)邏輯錯誤烁竭。
- 處理：發(fā)現(xiàn)錯誤還不夠菲茬，我們要處理錯誤。如果是編譯或開發(fā)期間發(fā)生的錯誤派撕，修改代碼即可婉弹；如果是運行期發(fā)生的錯誤，記錄日志终吼、提前退出镀赌、拋出異常都是值得考慮的選擇，選擇當前保證和當前場景下最合適的际跪。
該原則要和原則1結(jié)合起來（任何原則都要和原則1結(jié)合）商佛，所以記得讓你發(fā)現(xiàn)、處理錯誤的代碼也是自解釋的姆打。
本文鏈接：程序猿應(yīng)該記住的幾條基本規(guī)則
作者：猴子007
出處：https://monkeysayhi.github.io
本文基于 知識共享署名-相同方式共享 4.0 國際許可協(xié)議發(fā)布良姆，歡迎轉(zhuǎn)載，演繹或用于商業(yè)目的幔戏，但是必須保留本文的署名及鏈接玛追。
