什麼才是優秀的軟體架構？

代碼複用

無論是開發哪種軟體産品，成本和時間都是最重要的。較少的開發時間意味着可以比競争對手更早進入市場。較低的開發成本意味着能夠留出更多的營銷資金，覆寫更廣泛的潛在客戶。

其中，代碼複用是減少開發成本最常用的方式之一，其目的非常明顯，即：與其反複從頭開發，不如在新對象中重用已有的代碼。

這個想法表面看起來很棒，但實際上要讓已有的代碼在全新的代碼中工作，還是需要付出額外努力的。元件間緊密的耦合、對具體類而非接口的依賴和寫死的行為都會降低代碼的靈活性，使得複用這些代碼變得更加困難。

使用設計模式是增加軟體元件靈活性并使其易于複用的方式之一。但是，這可能也會讓元件變得更加複雜。

一般情況下，複用可以分為三個層次。在最底層，可以複用類、類庫、容器，也許還有一些類的“團體（例如容器和疊代器）”。

架構位于最高層。它們能幫助你精簡自己的設計，可以明确解決問題所需的抽象概念，然後用類來表示這些概念并定義其關系。例如，JUnit 是一個小型架構，也是架構的“Hello, world”，其中定義了 Test、TestCase 和 TestSuite 這幾個類及其關系。架構通常比單個類的顆粒度要大。你可以通過在某處建構子類來與架構建立聯系。這些子類信奉“别給我們打電話，我們會給你打電話的。”

還有一個中間層次。這是我覺得設計模式所處的位置。設計模式比架構更小且更抽象。它們實際上是對一組類的關系及其互動方式的描述。當你從類轉向模式，并最終到達架構的過程中，複用程度會不斷增加。

中間層次的優點在于模式提供的複用方式要比架構的風險小。建立架構是一項投入重大且風險很高的工作，模式則能讓你獨立于具體代碼來複用設計思想和理念。

擴充性

需求變化是程式員生命中唯一不變的事情。比如以下幾種場景：

• 你在 Windows 平台上釋出了一款遊戲，現在人們想要 Mac OS 的版本。
• 你建立了一個使用方形按鈕的 GUI 架構，但幾個月後開始流行原型按鈕。
• 你設計了一款優秀的電子商務網站，但僅僅幾個月後，客戶就要求新增電話訂單的功能。

每個軟體開發者都經曆過許多相似的故事，導緻它們發生的原因也不少。

首先，在完成了第一版的程式後，我們就應該做好了從頭開始優化重寫代碼的準備，因為現在你已經能在很多方面更好的了解問題了，同時在專業水準上也有所提高，是以之前的代碼現在看上去可能會顯得很糟糕。

其次，可能是在你掌控之外的某些事情發生了變化，這也是導緻許多開發團隊轉變最初想法的原因。比如，每位在網絡應用中使用 Flash 的開發者都必須重新開發或移植代碼，因為不斷地有浏覽器停止對 Flash 格式地支援。

最後，可能是需求的改變，之前你的客戶對目前版本的程式感到滿意，但是現在希望對程式進行 11 個“小小”的改動，使其可完成原始計劃階段中完全沒有提到的功能，新增或改變功能。

當然這也有好的一面，如果有人要求你對程式進行修改，至少說明還有人關心它。是以在設計程式架構時，有經驗的開發者都會盡量選擇支援未來任何可能變更的方式。

想學習更多 - - - 戳