“外部质量”还是“内部质量”

这几天看了看《硝烟中的Scrum和XP》，其中作者将产品质量分为两种——“外部质量”和“内部质量”。作者认为，在项目工期紧的时候，外部质量是可以妥协的。而内部质量是不容妥协的。但是，哪些问题属于内部质量呢？ 
作者并没有详细的论述这个问题。下面，我列出了一些常见的场景和划分。 你怎么看待这个问题呢？

外部质量

• 可扩展性
  我一直认为，一个没有明确的目标的可扩展性设计往往会变成过度设计。因此，我觉得可扩展性相关的质量问题应该作为外部质量看待。敏捷中强调 做的刚够就好。
• 功能不完整的实现
  有些时候，对某个功能模块的实现中存在 明显的 功能不完整。这一点我认为也是外部质量。因为，我们采用迭代式开发的目的就是可以逐渐的完成这个功能。但是，我认为这种功能不完整应该是 显而易见 的。否则，我认为就属于内部质量中的“逻辑严整性”和“语义清晰性”的问题了。
• 性能
  性能优化往往会牺牲架构的简单性和代码的可维护性。而且，我个人认为从实际的产品角度来看，性能只有“能够接受”和“不能接受”的差别，而没有“好”和“不好”的差别。因此，我认为它是产品是否能够验收的一个重要指标。但不是一个我们应该时刻关注的质量问题。

内部质量

• 代码规范
  混乱的代码意味着更加难以维护。划分外部质量和内部质量的一个重要标准是：对产品的可维护性有很大影响的质量问题应该称之为内部质量。因此，我认为代码规范为“内部质量”。
• 设计和实现的逻辑严整性
  例如：你设计了一个集合类，就应该确保集合的基本增删改操作正确。你可以在集合的删除操作中抛出“NotSupportException”或断言错误以标示该集合是一个只增集合。但是，你不能通过忽略删除方法的实现来达到同样的目的。
  另外一个逻辑严整性问题的例子是：Equals方法和GetHashCode方法实现上。你可以同时不实现这两个方法。如果实现，就一定要实现正确。不能因为目前没有需求将该对象作为Hashtable的Key，而忽略GetHashCode的实现。
  一个逻辑上不严整的设计往往会对将来使用该模块的开发人员造成误导。 最终造成可维护性问题。因此参考上面的原则，我认为这一条应该归为“内部质量”。
• 语义清晰性
  这一条和“逻辑严整性”类似。不能在方法命名等地方出现语义上的不清晰。对将来的使用者造成误导。

关于划分原则的思考

• 对产品未来可维护性有影响的点应该归为内部质量
  正因为“可维护性”往往是一个不易被觉察的问题，我才觉得可维护性是团队最应该关注的质量问题。是不能够放弃的底线。相对而言，“可扩展性”和“可维护性”如此相似，却恰恰相反，它看起来如此美妙。但，过度设计往往都是因为对“可扩展性”的追求而导致的。它反而是我们程序员应该时刻警惕的东西。
• 内部质量往往比较虚，而那些清晰明确的问题或目标个人认为归为“外部质量”比较好。
  人的精力是有限的，正因为这种有限性，让我们需要建立一些简单的原则来帮助我们将精力放在更重要的问题上。尽可能减少我们关注的范围，会让我们在这个范围内做的更好。因此，我觉得应该尽可能的将那些显而易见的问题排除出“内部质量”问题之外。这样，我们才能够更好的控制“内部质量”。那些显而易见的问题，其实，往往都不是问题。
• 性能
  这一点我一直很犹豫，因为往往一个不好的架构会导致难以修复的性能问题。但是，就这个话题而言。我还是更加倾向于将性能看做是外部质量。因为它往往是显而易见的。产品的Master，Customer等等很多人会关注与这个问题上。很多时候，在产品前期准备的时候就已经提出了明确的性能要求。因此，它是一个重要的产品测量点，但是，不是“内部质量”