標籤:
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)
相似的功能代碼應盡量放在一個部分。 High Cohesion, Low Coupling!
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)
這是Kent Beck一本書的標題,同時也被認為是極限編程和敏捷方法的宗旨。
許多其他原則都是基於這個概念的,即你應該積極面對變化。事實上,一些較老的編程原則如最小化耦合原則都是為了使代碼能夠容易變化。無論你是否是個極限編程者,基於這個原則去編寫代碼會讓你的工作變得更有意義。
作者簡介:Christopher Diggins是加拿大一位有25年編程經驗的資深技術人員,曾效力於Microsoft和AutoDesk,並創辦過兩家贏利的互連網公司。
優悅集團(深圳)有限公司
悅享科技 樂享生活
:YOJOYGROUP
微博: http://weibo.com/YOJOYGROUP
官網:http://www.yojoygroup.com/
聯絡&投稿:[email protected]
軟體設計原則