阐释设计质量

一个良好的设计是优雅而简练的——但优雅与否则是由观察者来决定的。在《 The Art of Agile Development（敏捷开发的艺术）》一书中，James Shore 否定了这个深奥的观点，他为设计质量下了一个非常具体的定义：“一个良好的软件设计在最小化软件的创建、修改和维护时间的同时，保证了运行性能。”

对于软件设计，这是一个相当非传统的观点——实际上，在我们讨论设计的时候，会马上映入我们脑海的系统内部组件的组织形式、类层级关系和其它所有传统观念，它都没有牵扯到。

为了深入阐述这个观点，Shore 考察了编程语言的演化和目前 Ruby 炙手可热的原因：

事实上，我们的电脑运行速度非常快，而现代编程语言实际上是在浪费计算资源。在优化编译器的帮助下，C 语言可以和汇编相媲美。而 C++ 则加入了虚方法表（Virtual Method Lookups）……每个方法四个字节，并引入一层额外的间接调用。Java 和 C#则引入了完全的中间语言，运行于常规机器之上的虚拟机上。而 Ruby，则在每次调用的时候解释整个程序！

太浪费了！

为什么 Ruby 在存在这样的性能损耗的情况下还能大行其道？为什么 Java 和 C#取得了如此的成功？它们在引入损耗之余还带来了什么，使损耗显得物有所值？我们为什么不都用 C 语言编程？

随后 Shore 主张，良好的设计（并非仅仅是软件设计）是“是折衷方案带来的效益最大化的一门艺术”。这也直接引出了上述对设计发人深省的阐释：“一个良好的软件设计在最小化软件的创建、修改和维护时间的同时，保证了运行性能。”

如果良好的设计依赖于软件的创建和修改，那么 _ 优秀 _ 的设计又是什么呢？

将良好的设计和维护的便捷等同起来并不是什么新鲜的说法，但用这种方式阐述则引出了以下有趣结论：

1. 设计质量是人群敏感（people-sensitive）的。

如果良好设计的目标是最小化软件的开发时间，那么一群熟悉 Java 的程序员很容易构建并维护的应用可以被视为一个良好的设计。但同一个应用在 C++ 程序员眼里就成了一个拙劣的设计了。对于使用不同语言编写并维护代码的程序员来说，同一个设计的质量是不同的。

2. 设计质量是和变更相关（change-specific）的。

设计质量和变更相关，这一说法也不外乎旧瓶装新酒。好在这个新的定义并没有颠覆我们已知的内容——它仅仅是在上面的一个补充。关于这个方面，有两种常见方法能使得设计具备更高质量：用诸如设计模式的工具来进行泛化，并运用测试和重构来辅助变更。谈到这个权衡问题，可以参考对 Eric Gamma 的一个采访，非常有启示意义。

3. 软件的修改和维护时间比创建时间更为重要。

这也是老生常谈的话题了。我们都知道，用在应用程序维护的时间远比其创建时间长得多。此外，在迭代式开发中，在程序初始创建过程内伴随着代码的修改，而对于这个问题我们有非常多的理由来关注它。

4. 设计质量是无法预测的。

按照以上的定义，质量和开发软件的团队是紧密相关的。随着团队发生改变和发展，设计的质量也相应改变。因此，它是无法预测的。实际上你只有在测试和修改的过程中才能了解一个设计的好坏。

那么，这又有多大用处呢？如果我们不能预测一个设计好坏与否，那么这个定义能给我们带来什么样的好处？Naur 提出了“像建立理论一样编程”的主张，认为代码中存在着一种“理论”。如果我们将这个主张和提出的定义联系起来，如果你理解这个理论，那么你可以轻而易举地更改代码。而理解了代码的“理论”也减少了第4 点提到的不可预测性。假如随着开发团队的发展，我们不断维持设计的理论，那么我们就可以维持设计的质量。

Shore这本书的草稿目前开放给公众审阅。通过将设计质量与构建和维护软件的人们联系起来，他给我们带来了一个发人深省的软件质量定义。