這個是轉帖,也是本身想要表達的.程序員
良好的編程原則與良好的設計工程原則密切相關。本文總結的這些設計原則,幫助開發者更有效率的編寫代碼,並幫助成爲一名優秀的程序員。apache
編程的最基本原則是避免重複。在程序代碼中總會有不少結構體,如循環、函數、類等等。 一旦你重複某個語句或概念,就會很容易造成一個抽象體。 注意: 代碼的「抽象」和它的「可讀性」(直觀性),實際上是一對矛盾的關係。適度的抽象和避免重複是有好處的, 它甚至能夠提升代碼的可讀性,然而若是你盡「一切可能」從代碼裏提取模板, 甚至把一些微不足道的「共同點」也提出來進行「共享」,它就開始有害了
與DRY原則相關。要記住,程序代碼中每個重要的功能,只能出如今源代碼的一個位置。
簡單是軟件設計的目標,簡單的代碼佔用時間少,漏洞少,而且易於修改。
除非你須要它,不然別建立新功能。
儘量作可運行的最簡單的事。在編程中,必定要保持簡單原則。 做爲一名程序員不斷的反思「如何在工做中作到簡化呢?」這將有助於在設計中保持簡單的路徑。
這是Steve Krug一本書的標題,同時也和編程有關。所編寫的代碼必定要易於讀易於理解, 這樣別人纔會欣賞,也可以給你提出合理化的建議。相反,如果繁雜難解的程序,其餘人老是會避而遠之的。
你所編寫的軟件實體(類、模塊、函數等)最好是開源的,這樣別人能夠拓展開發。 不過,對於你的代碼,得限定別人不得修改。換句話說,別人能夠基於你的代碼進行拓展編寫,但卻不能修改你的代碼。
一個優秀的代碼,應當使本人或是他人在未來都可以對它繼續編寫或維護。 代碼維護時,或許本人會比較容易,但對他人卻比較麻煩。 所以你寫的代碼要儘量保證他人可以容易維護。 用書中原話說「若是一個維護者再也不繼續維護你的代碼,極可能他就有想殺了你的衝動。」
最小驚訝原則一般是在用戶界面方面引用,但一樣適用於編寫的代碼。代碼應該儘量減小讓讀者驚喜。 也就是說,你編寫的代碼只需按照項目的要求來編寫。其餘華麗的功能就沒必要了,以避免弄巧成拙。
某個代碼的功能,應該保證只有單一的明確的執行任務。
代碼的任何一個部分應該減小對其餘區域代碼的依賴關係。儘可能不要使用共享參數。 低耦合每每是完美結構系統和優秀設計的標誌。
類似的功能代碼應儘可能放在一個部分。
隱藏實現細節原則,當其餘功能部分發生變化時,可以儘量下降對其餘組件的影響。
該代碼只和與其有直接關係的部分鏈接。(好比:該部分繼承的類,包含的對象,參數傳遞的對象等)。
除非你的代碼運行的比你想像中的要慢,不然別去優化。假如你真的想優化,就必須先想好如何用數據證實,它的速度變快了。 「過早的優化是一切罪惡的根源」——Donald Knuth
重用代碼能提升代碼的可讀性,縮短開發時間。
不一樣領域的功能,應該由不一樣的代碼和最小重迭的模塊組成。
這是Kent Beck一本書的標題,同時也被認爲是極限編程和敏捷方法的宗旨。 許多其餘原則都是基於這個概念的,即你應該積極面對變化。 事實上,一些較老的編程原則如最小化耦合原則都是爲了使代碼可以容易