软件产品的“外部质量”和“内部质量”

　这几天看了看《硝烟中的Scrum和XP》，其中作者将产品质量分为两种——“外部质量”和“内部质量”。作者认为，在项目工期紧的时候，外部质量是可以妥协的。而内部质量是不容妥协的。但是，哪些问题属于内部质量呢？

　　作者并没有详细的论述这个问题。下面，我列出了一些常见的场景和划分。你怎么看待这个问题呢？

　　外部质量

　　● 可扩展性

　　我一直认为，一个没有明确的目标的可扩展性设计往往会变成过度设计。因此，我觉得可扩展性相关的质量问题应该作为外部质量看待。敏捷中强调 做的刚够就好。

　　● 功能不完整的实现

　　有些时候，对某个功能模块的实现中存在 明显的 功能不完整。这一点我认为也是外部质量。因为，我们采用迭代式开发的目的就是可以逐渐的完成这个功能。但是，我认为这种功能不完整应该是 显而易见 的。否则，我认为就属于内部质量中的“逻辑严整性”和“语义清晰性”的问题了。

　　● 性能

　　性能优化往往会牺牲架构的简单性和代码的可维护性。而且，我个人认为从实际的产品角度来看，性能只有“能够接受”和“不能接受”的差别，而没有“好”和“不好”的差别。因此，我认为它是产品是否能够验收的一个重要指标。但不是一个我们应该时刻关注的质量问题。

　　内部质量

　　● 代码规范

　　混乱的代码意味着更加难以维护。划分外部质量和内部质量的一个重要标准是：对产品的可维护性有很大影响的质量问题应该称之为内部质量。因此，我认为代码规范为“内部质量”。

　　● 设计和实现的逻辑严整性

　　例如：你设计了一个集合类，就应该确保集合的基本增删改操作正确。你可以在集合的删除操作中抛出“No