軟件設計哲學

Philosophy

模塊原則:使用簡潔的接口拼合簡單的部件

“計算機編程的本質就是控制複雜度”。

要編制複雜軟件而又不至於一敗塗地的唯一的方法就是降低其整體複雜度——用清晰的接口把若干個簡單的模塊組合成一個複雜的軟件。如此一來,多數問題就只會侷限於某個局部,那麼還有希望對局部進行改進而不至於牽動全身。

清晰原則:清晰勝於機巧

程序是給人看的,而不是機器。

這個原則不僅僅是指可讀性,同時也指在選擇算法和實現時就應該考慮到未來的可擴展性。不要爲了提升一丁點的程序的性能就增加技術的複雜性和晦澀性——因爲複雜的代碼更容易滋生bug,也因爲它會使日後的閱讀和維護工作更加艱難。

優雅而清晰的代碼不僅不容易崩潰——而且更利於後來的修改者立刻理解。

組合原則:設計時考慮拼接組合

要想讓程序具有組合性,就必須是程序彼此獨立。在文本流這一端的程序應該儘可能不要考慮文本流另一端的程序。將一端的程序替換爲一個截然不同的程序,而完全不驚擾另一端的程序應該很容易做到。

對於協議的設計,儘量採用簡單的文本數據格式。

分離原則:策略同機制分離,接口同引擎分離

要想讓程序具有組合性,就必須是程序彼此獨立。在文本流這一端的程序應該儘可能不要考慮文本流另一端的程序。將一端的程序替換爲一個截然不同的程序,而完全不驚擾另一端的程序應該很容易做到。

對於協議的設計,儘量採用簡單的文本數據格式。

簡潔原則:設計要簡潔,複雜度能低則低

簡潔總是難以保持的

吝嗇原則:除非確無他法,不要編寫龐大的程序

避免編寫龐大程序的方法的分割程序。一個程序只做好一件事情。

透明性原則:設計要可見,以便審查和調試

一眼就能看出軟件在做什麼以及怎麼做的

健壯原則:健壯源於透明與簡潔

健壯性是指軟件不僅在正常的情況下運行良好,而且在超出設計者設想的意外條件下也能夠運行良好。模塊性(代碼簡樸,接口簡潔)是組織程序以達到更簡潔目的的一個方法。

表示原則:把知識疊入數據以求邏輯質樸而健壯

用簡單的邏輯和負責

補救原則:出現異常時,馬上退出並給出足夠錯誤信息

生成原則:避免手工hack,儘量編寫程序去生成程序

也就是教會機器去做更多低層次的編程工作。

一個方向就是DSL。

優化原則:雕琢前先得有原型,跑前先學會走

過早優化是萬惡之源,他會損害設計。

先給你的設計做個未優化的,運行緩慢的,很耗內存但是正確的實現,然後向進行系統調整,尋找那些可以犧牲最小的局部的簡潔性而獲得較大的性能提升的地方。

多樣原則:決不相信所謂的“不二法門”的斷言

即使最出色的軟件也常常會受限於設計者的想象力。一個好的應用廣泛採用多種語言、開放的可擴展機制和用戶定製機制。

擴展原則:設計着眼未來,未來總比預想快

設計協議或者文本格式時,應使其具有充分的自描述性以便擴展。

設計代碼時,要有很好的組織,讓將來的開發者增加新功能時無需拆毀或重建整個架構。

單一職責:不做兩件事情

開閉原則

接口隔離原則

1、客戶端不應該依賴它不需要的接口。
2、類間的依賴關係應該建立在最小的接口上。

依賴倒置原則

1、上層模塊不應該依賴底層模塊,它們都應該依賴於抽象。
2、抽象不應該依賴於細節,細節應該依賴於抽象。

通俗原則:最小立異

最易用的程序就是用戶學習新東西最少的程序。
另一個方面是避免表象相同而實際卻略有不同,這會及其危險。最好讓不同事物有明顯區別,而不要看起來幾乎一模一樣。
命名、接口設計、參數設計要遵循一個習慣和常識,不要嘗試違背常識和習慣。

參考:

Unix哲學之編程原則

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章