在軟件的設計當中前人已經總結了許多的設計原則和設計模式。例如SOLID,GRASP設計原則,這些原則都是基於面向對象設計總結而來的。而GOF23是基於許多常見的場景總結出了一套設計模式,在咱們遇到相似的場景,均可以套用設計模式。而今天所講到的軟件三原則是適用於在軟件設計的各個層面的。它不只適用於面向對象的設計,也適用於面向過程的程序設計;不只適用於類的設計,也適用於模塊、子系統的設計。就連在項目架構運維部署中也適用於這一套簡單的法則。html
第一條準則是千萬不要重複你自身。儘可能在項目中減小重複的代碼行,重複的方法,重複的模塊。其實許多設計原則和模式最本質的思想都是在消除重複。咱們常常提起的重用性和可維護性實際上是基於減小重複這一簡單的思想。爲何如今微服務盛行呢?正是由於將系統中的服務進行抽取的話,便減小了重複。重複冗餘在維護代碼的時候將是很是困難的。DRY意味着系統內的每個部件都應該是惟一的而且是不模糊的。咱們能夠經過應用單一職責接口隔離等原則儘可能拆分系統,模塊,類,方法·。使其每個部件都是職責明確的而且可重用的。程序員
第二條準則是保持簡單易懂。從小到幾行代碼的寫法大到整個系統的架構咱們都應該保持簡單易懂。高手高就高在能夠將複雜的東西「簡單」的實現出來。剛入行的時候,我總喜歡用三目運算符將複雜的邏輯用一句冗長的代碼行寫出來。後面才發現這是很是愚蠢的。到了重構或者需求變動的時候,連我本身寫的代碼我都看着很是費勁難如下手。因此咱們應該致力於代碼的可理解性。下降複雜度也意味着維護變得簡單。Martin Flower在《重構》中有一句經典的話:"任何一個傻瓜都能寫出計算機能夠理解的程序,只有寫出人類容易理解的程序纔是優秀的程序員。其實不光是程序,這個原則也能夠延伸到產品的設計,業務的設計,項目結構的設計上。設計模式
第三條準則是你將不會須要它。千萬不要進行過分設計。咱們常常會在開發當中儘量的迎合將來可能的需求。而爲了迎合某些產生機率極低的需求而設計的成本是很是高的,這種過分設計的收益很是低。可能你深思熟慮的設計花了很多時間成本,卻在將來的兩三年內這個設計卻徹底沒有派上用場。一些設計是否必要,更多的應該基於當前的狀況。而不是爲了應對將來的各類變化,多此一舉的設計。若是淘寶一開始就往日均交易上億的狀況進行設計的話,那麼可能就不會有今天的淘寶了。由於創業公司的時間是很是寶貴的,比其餘公司早一步退出新的服務就能搶佔先機。並非說淘寶不須要考慮之後交易量暴增的狀況,而是不該該以當前日均交易才幾萬的狀況下去設計編碼日均交易上億的項目。過分設計每每會延緩開發迭代的速度。架構