一个良好的设计是优雅而简练的——但优雅与否则是由观察者来决定的。在《 The Art of Agile Development(敏捷开发的艺术)》一书中,James Shore 否定了这个深奥的观点,他为设计质量下了一个非常具体的定义:“一个良好的软件设计在最小化软件的创建、修改和维护时间的同时,保证了运行性能。”
对于软件设计,这是一个相当非传统的观点——实际上,在我们讨论设计的时候,会马上映入我们脑海的系统内部组件的组织形式、类层级关系和其它所有传统观念,它都没有牵扯到。
为了深入阐述这个观点,Shore 考察了编程语言的演化和目前 Ruby 炙手可热的原因:
事实上,我们的电脑运行速度非常快,而现代编程语言实际上是在浪费计算资源。在优化编译器的帮助下,C 语言可以和汇编相媲美。而 C++ 则加入了虚方法表(Virtual Method Lookups)……每个方法四个字节,并引入一层额外的间接调用。Java 和 C#则引入了完全的中间语言,运行于常规机器之上的虚拟机上。而 Ruby,则在每次调用的时候解释整个程序!
太浪费了!
为什么 Ruby 在存在这样的性能损耗的情况下还能大行其道?为什么 Java 和 C#取得了如此的成功?它们在引入损耗之余还带来了什么,使损耗显得物有所值?我们为什么不都用 C 语言编程?
随后 Shore 主张,良好的设计(并非仅仅是软件设计)是“是折衷方案带来的效益最大化的一门艺术”。这也直接引出了上述对设计发人深省的阐释:“一个良好的软件设计在最小化软件的创建、修改和维护时间的同时,保证了运行性能。”
如果良好的设计依赖于软件的创建和修改,那么 _ 优秀 _ 的设计又是什么呢?
将良好的设计和维护的便捷等同起来并不是什么新鲜的说法,但用这种方式阐述则引出了以下有趣结论:
- 设计质量是人群敏感(people-sensitive)的。
如果良好设计的目标是最小化软件的开发时间,那么一群熟悉 Java 的程序员很容易构建并维护的应用可以被视为一个良好的设计。但同一个应用在 C++ 程序员眼里就成了一个拙劣的设计了。对于使用不同语言编写并维护代码的程序员来说,同一个设计的质量是不同的。
- 设计质量是和变更相关(change-specific)的。
设计质量和变更相关,这一说法也不外乎旧瓶装新酒。好在这个新的定义并没有颠覆我们已知的内容——它仅仅是在上面的一个补充。关于这个方面,有两种常见方法能使得设计具备更高质量:用诸如设计模式的工具来进行泛化,并运用测试和重构来辅助变更。谈到这个权衡问题,可以参考对 Eric Gamma 的一个采访,非常有启示意义。
- 软件的修改和维护时间比创建时间更为重要。
这也是老生常谈的话题了。我们都知道,用在应用程序维护的时间远比其创建时间长得多。此外,在迭代式开发中,在程序初始创建过程内伴随着代码的修改,而对于这个问题我们有非常多的理由来关注它。
- 设计质量是无法预测的。
按照以上的定义,质量和开发软件的团队是紧密相关的。随着团队发生改变和发展,设计的质量也相应改变。因此,它是无法预测的。实际上你只有在测试和修改的过程中才能了解一个设计的好坏。
那么,这又有多大用处呢?如果我们不能预测一个设计好坏与否,那么这个定义能给我们带来什么样的好处?Naur 提出了“像建立理论一样编程”的主张,认为代码中存在着一种“理论”。如果我们将这个主张和提出的定义联系起来,如果你理解这个理论,那么你可以轻而易举地更改代码。而理解了代码的“理论”也减少了第4 点提到的不可预测性。假如随着开发团队的发展,我们不断维持设计的理论,那么我们就可以维持设计的质量。
Shore这本书的草稿目前开放给公众审阅。通过将设计质量与构建和维护软件的人们联系起来,他给我们带来了一个发人深省的软件质量定义。
评论