軟體編寫和設計中的18大原則

標籤：

軟體編寫和設計中的18大原則寫在這裡，自己經常看一看。作者Diggins是加拿大一位有25年編程經驗的資深技術人員，曾效力於Microsoft和Autodesk，並創辦過兩家贏利的互連網公司。

下面的13和14合起來也被稱作Shy原則。

　　1.避免重複原則(DRY - Don’t repeat yourself)

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

　　2.抽象原則(Abstraction Principle )

　　與DRY原則相關。要記住，程式碼中每一個重要的功能，只能出現在原始碼的一個位置。

　　3.簡單原則(Keep It Simple and Stupid )

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

　　4.避免建立你不要的代碼 Avoid Creating a YAGNI (You aren’t going to need it)

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

　　5.儘可能做可啟動並執行最簡單的事(Do the simplest thing that could possibly work)

　　儘可能做可啟動並執行最簡單的事。在編程中，一定要保持簡單原則。作為一名程式員不斷的反思“如何在工作中做到簡化呢?”這將有助於在設計中保持簡單的路徑。

　　6.別讓我思考(Don’t make me think )

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

　　7.開閉原則(Open/Closed Principle)

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

　　8.代碼維護(Write Code for the Maintainer)

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

　　9.最小驚訝原則(Principle of least astonishment)

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

　　10.單一責任原則(Single Responsibility Principle)

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

　　11.低耦合原則(Minimize Coupling)

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

　　12.最大限度凝聚原則(Maximize Cohesion)

　　相似的功能代碼應盡量放在一個部分。

　　13.隱藏實現細節(Hide Implementation Details)

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

　　14.迪米特法則又叫作最少知識原則(Law of Demeter)

　　該代碼只和與其有直接關係的部分串連。(比如：該部分繼承的類，包含的對象，參數傳遞的對象等)。

　　15.避免過早最佳化(Avoid Premature Optimization)

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

　　“過早的最佳化是一切罪惡的根源”——Donald Knuth

　　16.代碼重用原則(Code Reuse is Good)

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

　　17.關注點分離(Separation of Concerns)

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

　　18.擁抱改變(Embrace Change)

軟體編寫和設計中的18大原則