簡(jiǎn)簡(jiǎn)單單幾條原則：
- 模塊的用戶永遠(yuǎn)也不應(yīng)該被模塊的行為所迷惑
- 模塊要盡可能小，但又不能太小
- 代碼應(yīng)該被重用，而不是被拷貝
- 模塊之間的依賴性應(yīng)該盡可能降到最小
- 錯(cuò)誤應(yīng)該盡早被檢測(cè)出來，最好是在編譯時(shí)刻
重點(diǎn)講兩個(gè)。
模塊的用戶永遠(yuǎn)也不應(yīng)該被模塊的行為所迷惑
最簡(jiǎn)單的方式是寫下多且準(zhǔn)確的注釋，不過我相信大部分很難做到“準(zhǔn)確”。我習(xí)慣引用濤神的話，將該條規(guī)則表述為要求“代碼能夠自解釋”。
看起來簡(jiǎn)單做起來難。對(duì)于Java程序猿，有幾種必要的方式可以幫助你盡可能的做到這一點(diǎn)：
- 除了對(duì)外公布的API和部分重要模塊，要求自己不加任何注釋
- 使用清晰明確的命名，包括變量、函數(shù)、類
- 被確定命名的類、函數(shù)、變量，其功能應(yīng)單一、確定
- 使用的時(shí)候再聲明/創(chuàng)建，并盡可能進(jìn)行顯示的初始化
- 嚴(yán)格明確對(duì)外保證的邊界，將精力放在保證公開接口，而不是私有實(shí)現(xiàn)
- 恰當(dāng)?shù)氖褂卯惓：腿罩?/strong>，不要用日志代替所有異常，但或許很多ERROR級(jí)別的日志都可以用異常來代替
- 雖然與原則2相悖，但如果合并模塊不會(huì)使系統(tǒng)變的難以理解，為了簡(jiǎn)化系統(tǒng)結(jié)構(gòu)我們建議合并部分模塊
- 除非對(duì)外發(fā)布后不可更改（比如java.util.Set接口），否則，在能保持良好系統(tǒng)結(jié)構(gòu)的前提下，不要面向未來開發(fā)（這一點(diǎn)可能很難接受，不過想想什么時(shí)候才應(yīng)該應(yīng)用設(shè)計(jì)模式呢？什么時(shí)候時(shí)候才應(yīng)該優(yōu)化性能呢？有需要的時(shí)候。如果現(xiàn)在不需要，就不要面向未來開發(fā)。）
上述方式并不是充分的，我可能會(huì)在以后的開發(fā)中繼續(xù)補(bǔ)充重要的方式，也可能不會(huì)。因?yàn)?strong>你需要掌握的是如何思考，而不是記住這些死知識(shí)。
上述原則部分參考自Google Java Style Guide，建議二者結(jié)合閱讀。
錯(cuò)誤應(yīng)該盡早被檢測(cè)出來，最好是在編譯時(shí)刻
刷題的時(shí)候要時(shí)刻牢記：
如果可能，盡早的處理邊界條件。
對(duì)于工程開發(fā)，可以改編如下：
如果可能，盡早的發(fā)現(xiàn)并處理錯(cuò)誤。
這里的錯(cuò)誤包括異常、邏輯錯(cuò)誤等。分為兩個(gè)方面，發(fā)現(xiàn)、處理：
- 發(fā)現(xiàn)：要求我們盡早的發(fā)現(xiàn)錯(cuò)誤，最好是編譯期；如果在運(yùn)行期，就要在處理正常邏輯之前，盡早的檢測(cè)出錯(cuò)誤。特別的，在開發(fā)期間，編寫完備的測(cè)試用例，盡早發(fā)現(xiàn)邏輯錯(cuò)誤。
- 處理：發(fā)現(xiàn)錯(cuò)誤還不夠，我們要處理錯(cuò)誤。如果是編譯或開發(fā)期間發(fā)生的錯(cuò)誤，修改代碼即可；如果是運(yùn)行期發(fā)生的錯(cuò)誤，記錄日志、提前退出、拋出異常都是值得考慮的選擇，選擇當(dāng)前保證和當(dāng)前場(chǎng)景下最合適的。
該原則要和原則1結(jié)合起來（任何原則都要和原則1結(jié)合），所以記得讓你發(fā)現(xiàn)、處理錯(cuò)誤的代碼也是自解釋的。
本文鏈接：程序猿應(yīng)該記住的幾條基本規(guī)則
作者：猴子007
出處：https://monkeysayhi.github.io
本文基于 知識(shí)共享署名-相同方式共享 4.0 國(guó)際許可協(xié)議發(fā)布，歡迎轉(zhuǎn)載，演繹或用于商業(yè)目的，但是必須保留本文的署名及鏈接。
