軟件設計是一種抽象活動，設計所要實現的是產出代碼。就這一點來說，任何人都會設計。但是，正如我們日常生活中所耳聞目睹或親身經歷，設計有優劣之分。
從項目管理的角度去理解，設計是為了滿足涉眾（Stakeholders）的需求。顯然，一個設計應該滿足客戶對系統的功能及非功能需求。但單是滿足了這一點，并不能稱為一個好的設計。因為開發者同樣屬于涉眾！而開發者的需求又是怎樣的呢？至少，應該有以下幾條吧：
- 老板希望軟件交付后，不應該有很高的維護成本。如果開發人員為了維護而經常出差或者加班且久久不能投入新項目，顯然，換了誰是老板都不愿意這種事情發生。
- 開發人員呢？誰愿意放棄和家人朋友而拼死拼活在單位加班，總是有這么多麻煩事纏著你，煩不煩哪！
- ……等等
所以，設計應該盡可能多地照顧到維護和變更。
為了兼顧各戶滿意和維護成本，設計應該不斷挑戰其終極目標——松耦合。不管是XP或UP，這個目標都不會改變。OO設計中的五大原則，其根本目的就是降低組件間的耦合度，避免牽一發則動全身的現象發生。降低耦合度不僅能夠提高軟件內在的質量，還能大大減少不必要的編譯時間、減少向版本控制系統提交源碼的網絡開銷……
如何鑒別設計的這一指標？軟件工程中有專用的度量：CBO（Coupling Between Objects)，那是由公式計算出來的，也有很多工具支持，值得一試。（聽過幾次李維先生的講座，他經常拿Together的度量功能炫耀^_^）
但是，作為一個開發人員，對手中的代碼應該有適當的敏感性。畢竟，這些代碼是你親手創造的，誰不希望自己的作品得到眾人的贊許？或許能換得一次加薪升職的機會^_^ 退一步，這可關系到寶貴的休息時間啊。所以，開發者應該對自己的產品有這樣一種意識：及時修正設計中不合理的地方。
敏捷過程告訴我們：在代碼“有味道”的時候進行重構。“有味道”是代碼正在變質的標志，很遺憾，能夠使代碼保持原味的防腐劑還沒發明。為了保證代碼質量，及時重構是必要的。這就像在燒烤的時候為了防止烤焦，你得坐在爐子前經常翻動肉塊一樣。
如何聞出代碼的味道？認真學習一下OO吧，別以為OO很簡單，就是繼承+封裝+多態，誰都會。即使是書中記述的五大原則，想要運用自如，也得多感覺感覺才行。很多時候，我們不知不覺就把蛆蟲放進了代碼中……
好了，下一篇：OO五大原則