软件设计是一种抽象活动，设计所要实现的是产出代码。就这一点来说，任何人都会设计。但是，正如我们日常生活中所耳闻目睹或亲身经历，设计有优劣之分。
从项目管理的角度去理解，设计是为了满足涉众（Stakeholders）的需求。显然，一个设计应该满足客户对系统的功能及非功能需求。但单是满足了这一点，并不能称为一个好的设计。因为开发者同样属于涉众！而开发者的需求又是怎样的呢？至少，应该有以下几条吧：
- 老板希望软件交付后，不应该有很高的维护成本。如果开发人员为了维护而经常出差或者加班且久久不能投入新项目，显然，换了谁是老板都不愿意这种事情发生。
- 开发人员呢？谁愿意放弃和家人朋友而拼死拼活在单位加班，总是有这么多麻烦事缠着你，烦不烦哪！
- ……等等
所以，设计应该尽可能多地照顾到维护和变更。
为了兼顾各户满意和维护成本，设计应该不断挑战其终极目标——松耦合。不管是XP或UP，这个目标都不会改变。OO设计中的五大原则，其根本目的就是降低组件间的耦合度，避免牵一发则动全身的现象发生。降低耦合度不仅能够提高软件内在的质量，还能大大减少不必要的编译时间、减少向版本控制系统提交源码的网络开销……
如何鉴别设计的这一指标？软件工程中有专用的度量：CBO（Coupling Between Objects)，那是由公式计算出来的，也有很多工具支持，值得一试。（听过几次李维先生的讲座，他经常拿Together的度量功能炫耀^_^）
但是，作为一个开发人员，对手中的代码应该有适当的敏感性。毕竟，这些代码是你亲手创造的，谁不希望自己的作品得到众人的赞许？或许能换得一次加薪升职的机会^_^ 退一步，这可关系到宝贵的休息时间啊。所以，开发者应该对自己的产品有这样一种意识：及时修正设计中不合理的地方。
敏捷过程告诉我们：在代码“有味道”的时候进行重构。“有味道”是代码正在变质的标志，很遗憾，能够使代码保持原味的防腐剂还没发明。为了保证代码质量，及时重构是必要的。这就像在烧烤的时候为了防止烤焦，你得坐在炉子前经常翻动肉块一样。
如何闻出代码的味道？认真学习一下OO吧，别以为OO很简单，就是继承+封装+多态，谁都会。即使是书中记述的五大原则，想要运用自如，也得多感觉感觉才行。很多时候，我们不知不觉就把蛆虫放进了代码中……
好了，下一篇：OO五大原则