軟體設計原則

程式設計的最基本原則是避免重複。在程式**中總會有很多結構體，如迴圈、函式、類等等。一旦你重複某個語句或概念，就會很容易形成乙個抽象體。

與dry原則相關。要記住，程式**中每乙個重要的功能，只能出現在源**的乙個位置。

簡單是軟體設計的目標，簡單的**占用時間少，漏洞少，並且易於修改。

除非你需要它，否則別建立新功能。

盡可能做可執行的最簡單的事。在程式設計中，一定要保持簡單原則。作為一名程式設計師不斷的反思「如何在工作中做到簡化呢？」這將有助於在設計中保持簡單的路徑。

這是steve krug一本書的標題，同時也和程式設計有關。所編寫的**一定要易於讀易於理解，這樣別人才會欣賞，也能夠給你提出合理化的建議。相反，若是繁雜難解的程式，其他人總是會避而遠之的。

你所編寫的軟體實體（類、模組、函式等）最好是開放的，這樣別人可以拓展開發。不過，對於你的**，得限定別人不得修改。換句話說，別人可以基於你的**進行拓展編寫，但卻不能修改你的**。

乙個優秀的**，應當使本人或是他人在將來都能夠對它繼續編寫或維護。**維護時，或許本人會比較容易，但對他人卻比較麻煩。因此你寫的**要盡可能保證他人能夠容易維護。用書中原話說「如果乙個維護者不再繼續維護你的**，很可能他就有想殺了你的衝動。」

最小驚訝原則通常是在使用者介面方面引用，但同樣適用於編寫的**。**應該盡可能減少讓讀者驚喜。也就是說，你編寫的**只需按照專案的要求來編寫。其他華麗的功能就不必了，以免弄巧成拙。

某個**的功能，應該保證只有單一的明確的執行任務。

**的任何乙個部分應該減少對其他區域**的依賴關係。盡量不要使用共享引數。低耦合往往是完美結構系統和優秀設計的標誌。

相似的功能**應盡量放在乙個部分。high cohesion，

low coupling！

隱藏實現細節原則，當其他功能部分發生變化時，能夠盡可能降低對其他元件的影響。

該**只和與其有直接關係的部分連線。（比如：該部分繼承的類，包含的物件，引數傳遞的物件等）。

除非你的**執行的比你想像中的要慢，否則別去優化。假如你真的想優化，就必須先想好如何用資料證明，它的速度變快了。

「過早的優化是一切罪惡的根源」——donald knuth

重用**能提高**的可讀性，縮短開發時間。

不同領域的功能，應該由不同的**和最小重迭的模組組成。

這是kent beck一本書的標題，同時也被認為是極限程式設計和敏捷方法的宗旨。

許多其他原則都是基於這個概念的，即你應該積極面對變化。事實上，一些較老的程式設計原則如最小化耦合原則都是為了使**能夠容易變化。無論你是否是個極限程式設計者，基於這個原則去編寫**會讓你的工作變得更有意義。

作者簡介：christopher diggins是加拿大一位有25年程式設計經驗的資深技術人員，曾效力於microsoft和autodesk，並創辦過兩家贏利的網際網路公司。