1、 簡介
在本篇中，我想先從全局方面介紹壹下論壇應用程序的總體目標。在本篇中，我將討論壹下避免代碼壞味道的重要性，還將討論如何利用軟件設計原則和模式來幫助妳編寫適合未來改變的富有彈性的代碼。最後，我還將論證壹下為什麽我選擇使用測試驅動開發方式構建本系列文章中的論壇應用程序。
2、 什麽樣的軟件是好的軟件
我不想僅僅為了構建論壇應用程序而任意構建此論壇應用程序。我的目標是盡可能構建最棒的論壇應用程序。
這個目標立即引發這樣壹個問題：什麽樣的軟件是好的軟件？是什麽導致壹個應用程序比另壹個應用程序更好壹些或更差壹些呢？在事先沒有壹個關於“好軟件”的定義之前，我無法聲明我構建了壹個完美的論壇應用程序。
因此，下面是我對於“好軟件”的定義。
3、 好軟件是設計得易於修改的軟件
存在多種原因可能需要妳改變
1)妳可能需要在壹個現有軟件上添加新的特征
2)妳可能需要修改壹個現有軟件中的錯誤
3)妳可能需要優化現有軟件
4)妳可能需要改進現有軟件的設計
壹般說來，設計糟糕的軟件是難於改變的。有些軟件設計得如此糟糕，以致於每個人都害怕碰壹碰它。我們大家應該都使用過設計得糟糕的軟件。當軟件不好時，妳很希望它幹脆走開；甚至如果有機會的話，妳可能想從頭開始重新編寫這款軟件。
4、 避免代碼壞味道
Robert和Micah Martin把糟糕的軟件部分描述為代碼壞味道。下列代碼壞味道意味著此軟件的書寫是相當糟糕的：
1)僵化性（Rigidity）—僵化的軟件是這樣的軟件，當妳在某個位置作壹改動時即要求對系統作出相應的壹系列的更改。
2)脆弱性（Fragility）—脆弱的軟件是這樣的軟件，妳在某個位置作壹改動時即打斷另外多處的正常運行。
3)不必要的復雜性—不必要的復雜軟件是指過度設計的軟件，其目的是為了處理任何可能的改變。
4)不必要的重復—不必要的重復軟件中包含大量的重復性代碼。
5)晦澀性—晦澀的軟件是指難於理解的軟件。
註意上述這些代碼味道在Micah和Robert Martin的著名《Agile Principles,Patterns,and Practices in C#》中得到充分的描述。在此，強烈建議讀者讀壹下這本書。
註意，上述這些代碼味道都與所有的代碼改變相關聯。每壹個這些代碼味道都將妨礙代碼的改變。
5、 軟件設計原則
遵循良好的軟件設計原則，將有助於編寫軟件易於適應未來更改的軟件。軟件設計原則有若幹，也不盡相同。例如，Cunningham和Cunningham Wiki描述面向對象設計的11個原則：
其中提到的面向對象設計的前五個原則與Robert Martin及他的兒子Micah Martin編著的《Agile Principles,Patterns,and Practices in C#》中所主張的軟件設計原則是壹致的。此外，Robert Martin還在Object Mentor開辟的博客上討論了這些原則：
此外，我還發現有另外兩本書中也提供了有關軟件設計原則的極其有用的信息。第壹本是Eric Freeman,Elisabeth Freeman, Kathy Sierra, Bert Bates編著的《Head First Design Patterns》；第二本是Brett McLaughlin,Gary Pollice和David West編著的《Head First Object-Oriented Analysis and Design》。盡管這些書所討論的原則與Robert Martin的提法並不十分相同，但是它們卻十分相近。
不過真實的情況是，上述所有這些針對軟件設計原則展開討論的資源都源自Robert Martin的工作。Robert Martin並不是所有原則的發明者，但是他的確是第壹個把這些原則收集到壹起的人。下面列出這些軟件設計原則：
SRP—單壹責任原則
OCP—開關原則
LSP—Liskov替換原則
ISP—接口隔離原則
DIP—依賴倒置原則
上述這個原則的集合正好對應於縮略詞SOLID。
下面的軟件設計原則列表來自於《Head First Design Patterns》壹書：
封裝變化
多用組合少用繼承
基於接口而不是基於實現編程
在交互的對象間努力實現松耦合
類應該為了擴展而開放，但是為了修改而關閉
依賴於抽象，而不要依賴於具體類
僅僅對妳的朋友交談
不調用我，我們會調用妳
壹個類應該僅有壹個改變的理由
當然，上述原則之間也存在許多的重疊之處。例如，“單壹責任”原則與後面的“壹個類應該僅有壹個改變的理由”這壹原則是相壹致的。然而，它們所強調的重點還是有所不同。更多的細節在此不便贅述。
所有這些設計原則的真正動機在於，努力構建出能夠適應變化的軟件。上述原則分別對於不同的原則進行相應的闡述，最終目的也不過是為了創建出可以經得起時間測試的軟件。
6、 軟件設計模式
軟件設計模式描述的是應用軟件設計原則所遵循的策略的問題。換句話說，壹個軟件設計原則是壹個好的思想，而壹個軟件設計模式是妳用於實現這種好的思想的工具。
軟件設計模式的思想最初源於書籍《Design Patterns: Elements of Reusable Object-Oriented Software》。正是這本書為其它許多描述軟件設計模式書的創作帶去靈感。
例如，另壹本書《The Head First Design Pattern》就以壹種更易於理解的方式向人們介紹了GOF所著的書（即上面的那本《Design Patterns: Elements of Reusable Object-Oriented Software》）中所引入的設計模式。這本書中總***詳細介紹了下列14種軟件設計模式：
Strategy
Observer
Decorator
Factory
Singleton
Command
Adaptor
Fa?ade
Template
Iterator
Composite
State
Proxy
Compound
另壹本在軟件設計模式方面較有影響的書是Martin Fowler的《Patterns of Enterprise Application Architecture》。這本書還擁有壹個公司網站，其中列舉了本書中所介紹的模式。此網站的網址是：。
軟件設計模式提供給妳按照模式的方式構建妳的代碼，從而使之更富於適應未來的彈性修改。例如，當構建本文中的論壇應用程序時，我們就使用了壹種名字為Repository的軟件設計模式進行設計。Eric Evans，在他的著作《Domain-Driven Design》中這樣描述Repository模式：
壹個REPOSITORY把某種類型的所有對象描述為壹個概念的集合(通常是模擬的)。其行為類似於壹個集合，但是具有更細致的支持查詢的能力。於是，符合相應類型的對象可以被添加或刪除，而位於此REPOSITORY背後的系統則可以從數據庫中添加或刪除它們。
根據Evans的解釋，Repository模式的壹個主要的優點是，它能夠幫助妳實現“應用程序和域設計與存儲技術，多種數據庫策略，甚至是多個數據源之間的解耦。”換句話說，Repository模式能夠使妳的應用程序免於因數據庫訪問方式的不同而重新加以改變。
為了使我們的論壇應用程序從某壹種特定的存儲技術中獨立出去，我們將在系統中引入上述Repository模式。因此，最終的此論壇應用程序的設計將能夠支持我們可以在不同的數據訪問技術（例如LINQ to SQL，Entity Framework或NHibernate）之間切換。
7、 測試驅動開發
我打算使用測試驅動開發原則構建本文中的MVC論壇應用程序。更具體地說是，在我編寫任何應用程序代碼之前，我將首先編寫壹個應用程序代碼的單元測試。
測試驅動開發將會基於下列原因為妳帶來更高質量的代碼：
(1)為妳的代碼編寫測試能夠提供給妳壹個適應於未來可能改變的安全網。
(2)為妳的代碼編寫測試迫使妳書寫松耦合的代碼。
(3)在正式書寫妳的代碼前為妳的代碼編寫測試將迫使妳從壹個用戶的角度來觀察自己書寫的代碼。
讓我們更細致地分析上述每種特征的優點。
首先，單元測試提供妳壹個適應於未來可能改變的安全網。這是Michael Feathers在他的著作《Working Effectively with Legacy Code》壹再強調的壹個觀點。事實上，他把遺留代碼定義為“簡單地編碼而不進行測試”。
當妳的應用程序代碼被單元測試所覆蓋時，妳可以修改該代碼而不必擔心此改動會妳的代碼既有的功能。單元測試有助於使妳的代碼進行更安全的重構。如果妳能夠重構，那麽，妳可以使用軟件設計模式修改妳的代碼，這將產生更好的適應未來修改的代碼。
其次，遵循測試驅動開發將迫使妳使用壹種特定的方式書寫代碼。可測試的代碼將趨於導致松耦合的代碼。單元測試能夠在各自孤立的代碼單元中執行壹個測試。為了構建妳的應用程序以便使之可測試，妳需要使用壹種可孤立的組件方式來構建應用程序。
壹個類與另壹個類之間是松耦合的是指，當妳改變第壹個類時不必改變另壹個類。測試驅動開發經常迫使妳編寫松耦合的代碼，因為松耦合代碼是經得起改變的。
最後，按照測試先行的方式書寫代碼將迫使妳從壹個用戶的角度來觀察自己書寫的代碼。通過首先編寫測試的方式書寫代碼，會使妳站在壹個未來的有可能使用妳的代碼的開發者的角度進行工作。既然編寫測試迫使妳考慮另壹個開發者(也許是未來的妳自己)如何使用妳的代碼，那麽，妳最終編寫的代碼應該是設計得更好的代碼。
8、 莫圖眼前之利益 更宜立足於長遠
使用測試驅動開發原則構建軟件在軟件開發之初要求開發者付出更多的努力。盡管編寫測試需要花費壹定的時間；然而，其思想是，最初構建單元測試所要求付出的努力將會在未來獲得豐厚的回報。
存在兩種方式可以使妳成為壹名開發者。妳可以成長為壹個牛仔，也有可能成長為壹個工匠。壹個牛仔能夠立即開始編碼。也就是說，壹個牛仔可以以很快的速度構建壹個軟件應用程序。然而，作為壹個牛仔，其問題在於軟件必須要進行長期的維護。
壹個工匠則是很有忍耐性的。壹個工匠總會精雕細琢地開發壹款軟件。壹個工匠總是非常仔細地構建單元測試，並使之涵蓋壹個應用程序中所有的代碼。因此，壹個工匠要花費更長的時間才能創建成功壹款應用程序。然而，此應用程序在創建後，卻是易於後期的維護—更易於修改錯誤且更易於把新特征添加到應用程序中。
9、 總結
總之，我們的最終目標是構建壹個MVC論壇應用程序，此程序能夠經得起長時間的測試。它應該是不僅現在良好地工作，還應該在未來繼續工作—即使是當有人需要對該應用程序進行更改之時。
我想利用微軟 MVC框架開發此論壇應用程序。原因在於，這個框架可以使我更容易地編寫程序的測試代碼。而另壹方面， MVC框架本身就從設計之初提供了對測試驅動開發的最忠誠的支持。