架構設計最佳實踐之DRY
在軟件過程中的自我重復，總的來說有五種類型：
(1) 一件事物，有多種的不同語言和方式來表達，不同的角色采用不同的語言去描述同一事物。在這些角色之間需要協同工作時造成的重復。
比如，架構設計師用一種語言和方式描述其架構設計，可為PPT、Word文檔、Visio、建模工具等。開發人員的工作語言則是程序代碼。兩種角色描述的是同一事物，只是描述語言不同而已，這樣造成架構設計師的架構輸出，不能作為開發人員的開發輸入，而不能被開發人員重用，導致一定的自我重復。這就像一個人用英文寫書，一個人用中文寫書，內容類似，那么中文作者要么重新整理內容并書寫書籍，要么就翻譯英文書籍，不管哪種，造成重復工作勞動是在所難免。
對于此類的自我重復，隨著模型驅動的成熟和廣泛應用將逐漸減少。模型驅動架構中業務建模、架構建模和程序編碼等之間，通過Unified Modeling Language(UML)、the Meta-Object Facility (MOF)、XML Metadata Interchange (XMI)和自動化代碼生成等語言、標準和技術進行互相轉換，達到Don't Repeat Yourself。如下圖所示：
傳統的開發過程中，需求、分析、設計、開發等各個階段，可能采用不同的描述語言和方式，互相之間也較難轉換，所以他們之間不能無縫的相互轉換，造成了重復溝通、理解和建模。
模型驅動開發，在開發過程的每個階段基于標準和轉換工具，所以每一個階段的成果，都可以被下一個階段復用，消除重復。這也是標準的魅力之一吧。
(2) 同一件事物，不同的人各描述了該事物的不同方面，造成他們之間所描述的事物既類似又不同，有重復的地方，又不完全一樣，導致自我重復。
比如，銀行中的用戶信息模塊，在"網上銀行"、"公積金貸款"，和"信用卡系統"中各自都可能有一個模塊，從數據庫、到邏輯、到界面都各自重復一套，他們之間既類似又有一些區別，如需要的信息不一樣。導致這些模塊之間的自我重復。
對于此類的自我重復，是由架構設計導致，在架構設計階段沒有按照"組件化"、"服務化"和"層次化"的架構設計，造成在一個事物不能符合不同模塊和系統的需求，并且無法擴展。
這種自我重復，在企業的遺留系統和新系統之間尤為明顯。因為大多企業的老系統在構建時由于技術、組織結構等原因，都是采用垂直的渠道架構，即存儲層、邏輯層、展現層完全重新實現，甚至連技術框架都和其他渠道相異。如某銀行業的多渠道應用中，不同渠道（如網上銀行和手機銀行）的邏輯類似，但在兩個系統中重用性不高，存在著大量的自我重復。如下圖左所示：
隨著SOA(Service Oriented Architecture)的廣泛使用，再輔助以層次化架構，能有效解決此類問題。
重復的組件要被重用，就需要是組件化的，并且能夠被訪問到。EJB、Web Service以及相應的組件化、基于服務的設計思想，一定程度解決了這些問題，緩和了在企業架構中的重用性問題。
而層次化的架構設計則既是解決架構重復的途徑，也是結果。層次化的架構演變過程，可以在人類社會發展過程中找到似曾相似的影子。在人類社會中，任何事情重復到一定程度，就會產生一個新的職業或階層，比如，找房子的人多了，就自然會產生中介。在架構設計中也是一樣。任何設計重復到一定程度，就應該抽象出新的層次。這個層次也許可以作為一個新的組件，也可能做出一個新的產品。
上圖2右邊的架構，是銀行多渠道整合的架構設計，是基于SOA架構的、多層次高度重用的架構設計，銀行在新增一個渠道（如增加ATM渠道）時，能夠重用大量的其他渠道的組件。
(3) 沒有自我重復，但重復別人。指一個功能有很好的免費開源框架或者標準可以依據，但設計開發時沒有采用，而重新發明輪子，導致不能重用已有的標準或開源框架的優勢。
記得幾年前參加的一個企業信息管理系統的產品開發，該產品從底層MVC框架開始開發，還開發了界面UI控件、自己的XML流程引擎實現等，然后才是在這個基礎上開發該企業的信息管理系統。最后結果如何可想而知：投入產出比失衡，以失敗告終。這是一個典型的"沒有重復自己，但重復標準或免費成熟框架"的例子。
在商業中的專業分工、競爭優勢理論和軟件架構思想有很多相通之處。一個開飯店的，不應該去種大米、白菜或養豬，而應該抓住自己的核心競爭優勢，開好飯店。相同的，種菜的、養豬的，也不應該無緣無故跑去開飯店。除非他們各自都想轉行，進入另外的專業化分工領域，同另外領域內公司競爭。
在軟件業中也是一樣的道理，每個產品都有其核心競爭力，每個產品都應該把握住本產品的核心競爭力，并投入最大的人力物力去經營。而對于其它的標準、輔助工具、框架或產品等，應該持開放的態度，復用已有的標準、成熟框架或產品。當然，除非你想重新定位你的產品。
這種類型的錯誤技術人員經常會犯，但作為產品的架構設計師，應該盡量杜絕這種錯誤的發生。
(4) 開發過程中信息重復，如軟件過程中用到的工具（項目管理系統、開發工具、測試計劃及用例、Build工具、版本管理工具等）之間的信息重復；還有軟件過程中各種角色的溝通重復，如開發人員報告進度給開發組長、開發組長又重新報告進度給項目經理等。如下圖所示：
對這一類型的自我重復，一個集成的協作平臺能解決問題?；谶@個協作平臺，軟件過程中所有角色、工具和流程都能無縫的協作，消除了信息重復和溝通重復，加快開發效率。如下圖所示：所有的工具無縫集成，消除了信息重復；所有的角色都基于一個協作平臺，能夠實施反映產品的狀態、信息、各種歷史記錄等，極大降低了溝通重復。
(5) 缺乏重構導致自我重復。這一種自我重復是最幼稚且低級的重復，但在很多產品的代碼和文檔也大量存在。一個功能在不同模塊中重復拷貝使用、對象繼承和組合關系混亂、文檔關系混亂等都屬于這一類的問題。
對于這一類型的自我重復，對軟件進行持續重構是唯一的好方法。代碼重構具體請參考《重構》這本書；至于文檔重復，大家不妨把《重構》的思想應用于文檔，也必有所得。
總結
Don't Repeat Yourself，是軟件開發的最佳實踐，良好的軟件開發應該是非自我重復的，同樣按照非自我重復思想設計開發的軟件，往往是好的軟件。
· DRY，消除軟件開發的各個階段之間的重復，以客戶和需求為中心，加快開發速度。
· DRY，遵循"組件化"、"服務化"、"層次化"的架構設計，使得架構清晰，層次分明，并易于重用。
· DRY，不自我重復，也不重復別人，特別是標準和成熟的開源框架，使得架構開放，穩定，并減少成本。
· DRY，不重復信息，不重復溝通，改進管理流程，加快開發速度，達到有效溝通。
· DRY，持續重構代碼，文檔等，保持軟件簡介、清晰，便于維護。
【編輯推薦】
