Bertrand Meyer谈软件质量需求

The Demand for Software Quality 软件质量需求

A Conversation with Bertrand Meyer, Part I Bertrand Meyer访谈之一

by Bill Venners 采访者：Bill Venners

October 27, 2003 时间：2003-10-27

Summary

提要

Bertrand Meyer talks with Bill Venners about the increasing importance of software quality, the commercial forces on quality, and the challenges of complexity.

Bertrand Meyer和Bill Venners讨论软件质量不断攀升的重要性、市场对软件质量的影响以及软件复杂性的挑战。

Bertrand Meyer is a software pioneer whose activities have spanned both the academic and business worlds. He is currently the Chair of Software Engineering at ETH, the Swiss Institute of Technology. He is the author of numerous papers and many books, including the classic Object Oriented Software Construction (Prentice Hall, 1994, 2000). In 1985, he founded Interactive Software Engineering, Inc., now called Eiffel Software, Inc., a company which offers Eiffel-based software tools, training, and consulting.

Bertrand Meyer是同时活跃于学术和商业二界的软件先驱。他目前担任瑞士理工学院的软件工程协会。他撰写了数量浩繁的论文和书籍，如经典的《面向对象软件构造》（Prentice出版社，1994，2000）。1985年，他创立了交互软件工程公司。公司目前已经更名为Eiffel软件公司，提供基于Eiffel语言的软件工具、培训和咨询业务。

On September 28, 2003, Bill Venners conducted a phone interview with Bertrand Meyer. In this interview, which will be published in multiple installments on Artima.com, Meyer gives insights into many software-related topics, including quality, complexity, design by contract, and test-driven development. In this initial installment, Meyer discusses the increasing importance of software quality, the commercial forces on quality, and the challenges of complexity.

2003年9月28日，Bill Venners对Bertrand Meyer做了电话访谈。在这次访谈（内容将在Artima.com分多次公布）中，Meyer对许多有关软件的问题作了鞭辟入里的论述，如软件质量、软件复杂性、契约设计以及测试驱动型开发等。在这个最开始的部分中，Meyer论述了软件质量不断攀升的重要性、市场对于软件质量的影响以及软件复杂性的挑战。

The Importance of Software Quality

软件质量的重要性

Bill Venners: In a 2001 interview with InformIT, you said, "The going has been so good that the software profession has been able to treat quality as one issue among many. Increasingly it will become the dominant issue." Why?

你在2001年InformIT对你的一次访谈中讲到：“当前的形势很好，以至在软件界，质量已经能成为很多人的话题。它将日益成为人们最主要的议题。”这是为什么呢？

Bertrand Meyer: As the use of computers pervades more and more of what society does, the effects of non-quality software just becomes unacceptable. Software is becoming more ambitious, and we rely on it more and more. Problems that could be dismissed quite easily before are now coming to the forefront.

计算机的应用已经遍及社会生活的方方面面，因此，质量低下的软件是不被接受的。软件业飞速发展，我们对软件的依赖性也日益增加。到了今天，我们必须面对一些由来已久但不被重视的问题。

There is a very revealing quote by Alan Perlis in his preface to the MIT book on Scheme, The Structure and Interpretation of Computer Programming, by Abelson and Sussman. Alan Perlis wrote:

I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customer got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house.

Alan Perlis在麻省理工学院的一本教材——Abelson和Sussman合著的《计算机编程的结构和解析》——的序言中有一段颇具启发性的话。他写到：

我认为计算机科学至关重要的是保持“计算”的趣味性。在它刚兴起的时候，它的确非常有趣。当然，用户也常常为之买单；过了一段时间，我们开始认真对待用户的抱怨。于是我们认为自己应该为计算机成功地、无错地完美运行负责。我却不这样看。我认为我们应该为之努力的是延伸计算机的功能，让它们有新的发展方向，让我们的屋子里充满趣味。

That is typical of the kind of attitude that says "Sure, we can do whatever we like. If there's a problem we'll fix it." But that's simply not true anymore. People depend on software far too fundamentally to accept this kind of attitude. In a way we had it even easier during the dot-com boom years, between 1996 and 2000, but this is not 1998 anymore. The kind of free ride that some people were getting in past years simply doesn't exist anymore.

一种典型的态度是：“你完全可以相信，我们能做任何我们想做的事情。如果有什么问题，我们会修正它。”但这恰恰已不再可能。人们对软件的依赖性如此之大，以至他们根本不可能接受这样的态度。在.com时代（1996到2000年）的早些时候，这样的观念还勉强能站住脚，但到1998年已不可能。这种在过去可以让人们轻易接受的搭便车态度，如今已无立足之地。

The Harvard Business Review published an article in May 2003, "IT Doesn't Matter" by Nicholas Carr, that stated that IT hasn't delivered on its promises. It is a quite telling sign of how society at large is expecting much more seriousness and is holding us to our promises much more than used to be the case. Even though it may still seem like we do have a free ride, in fact that era is coming to a close. People are watching much more carefully what we're doing and whether they're getting any return for their money. And the heart of that is quality.

2003年5月，《哈佛商业评论》发表了Nicholas Carr的文章《IT麻木不仁》，文章指出：IT没有兑现它的承诺。这发出了一个明显的信号：整个社会要求我们对自己的承诺要有比过去高得多的严肃态度。尽管在目前看来，我们似乎还能（不负责任地）搭便车，但这样的时代将很快终结。人们越来越关心我们的所作所为，关心自己的支出是否可以得到回报。这一些的核心就是质量。

Commercial Forces on Software Quality

市场对软件质量的影响

Bill Venners: In your paper, The Grand Challenge of Trusted Components, you write "There is a quality incentive, but it only leads to the acceptability point: the stage at which remaining deficiencies do not endanger [the product's] usefulness to the market. Beyond that point, most managers consider that further quality enhancing measures yield a quickly diminishing return on investment." How do commercial pressures affect software quality?

你的论文《可信任组件的巨大挑战》中谈到：“质量提升的动机是存在的，但它仅仅被允许到达这样的水平：可以存在在市场上不会危机到产品有效性的缺陷。大多数管理者认为超出此范围的质量提升措施只能产生急剧下降的投资回报。”那么市场到底是怎么影响软件质量的？

Bertrand Meyer: Commercial pressures affect software quality partly positively and partly negatively. It is almost tempting to use as an analogy the Laffer Curve, which was popular for a while in so-called Reaganomics. I'm not an economist, and I hear that the theory has been by now discredited, so I really don't want to imply that the Laffer Cruve is fundamentally true in economics. Nevertheless, the Laffer Curve is the idea that if you tax people at zero percent, the state suffers because it doesn't get any revenue. If you tax people at 100%, it's in the end no better, because if people are not making any money, they will stop working, and the state will also not get any revenue. It's a rather simplistic argument. Although it is pretty clear the Laffer Curve has an element of truth, I'm not sure how precise or accurate it is in economics. But as an analogy, it describes well the commercial pressures on software quality.

市场力量对于软件质量的影响，既有正面的，也有负面的。这差不多和里根经济政策时期流行的拉弗曲线理论类似。我不是经济学家，也听说这个理论目前已不足信，因此我没有暗示拉弗曲线在经济学上根本正确的意思。不过，拉弗曲线告诉我们，如果你按0%水平对人们征税，那么国家会遭受灾难，因为它得不到任何收入；如果提高到100%（不能再高的水平），则人们不能获得任何收入，因此他们将拒绝工作，这样国家也得不到任何收入。这是一种相当单纯的讨论。尽管拉弗曲线在这一点上具有相当明显的合理性，但我无疑确定它在经济学上的正确性和精确性。不过作为一个类比，它可以很好地描述市场力量对于软件质量的影响力。

If you produce a software system that has terrible quality, you lose because no one will want to buy it. If on the other hand you spend infinite time, extremely large effort, and huge sums of money to build the absolutely perfect piece of software, then it's going to take so long to complete and it will be so expensive to produce that you'll be out of business anyway. Either you missed the market window, or you simply exhausted all your resources. So people in industry try to get to that magical middle ground where the product is good enough not to be rejected right away, such as during evaluation, but also not the object of so much perfectionism and so much work that it would take too long or cost too much to complete.

如果你的软件产品质量非常糟糕，你将得不到任何收入，因为没人愿意买它。相反，如果你穷尽时日、耗尽人力、物力和财力去构造绝对完美的软件，那么其过长的开发周期和高昂的成本将决定你必然退出市场。你不是错过市场机遇就是最终耗尽所有资源。所以，置身软件行业的人们都要努力寻找一个难以把握的平衡点：产品要足够好，以至它不会在诸如评估等阶段就马上被否定；同时也不追求十全十美、精雕细琢，否则会囿于时间和金钱而无法达到目的。

The Challenge of Complexity

复杂性的挑战

Bill Venners: You said in your book, Object Oriented Software Construction, "The single biggest enemy of reliability and perhaps of software quality in general is complexity." Could you talk a bit about that?

你的大作《面向对象软件构造》中讲过：“可靠性，或许还有软件质量，的唯一最大敌人通常是复杂性。”对此你能展开谈谈么？

Bertrand Meyer: I think we build in software some of the most complex artifacts that have ever been envisioned by humankind, and in some cases they just overwhelm us. The only way we can build really big and satisfactory systems is to put a hold on complexity, to maintain a grasp on complexity. Something like Windows XP, which is 45 million lines of code or so, is really beyond any single person's ability to comprehend or even imagine. The only way to keep on top of things, the only way to have any hope for a modicum of reliability, is to get rid of unnecessary complexity and tame the remaining complexity through all means possible.

我认为我们的软件中存在一些到达人类想象极限的复杂部分，某些时候，这些部分让我们一败涂地。构建大型的、让人满意的系统的唯一办法是不要持续地复杂化，必须保持对复杂性的控制力。比如Windows XP系统包含大约4千5百万行代码，这完全不是单独某个人可以理解甚至想象的。如果要想保持对它们的控制，或者说还希望哪怕有一点点可靠性的话，唯一的办法就是剔除没必要复杂的部分，而想尽办法保持对其余部分的复杂性控制。

Taming complexity is really fundamental in the Eiffel approach. Eiffel is there really to help people build complex, difficult things. You can certainly build easy or moderately difficult systems using Eiffel better than using other approaches, but where Eiffel really starts to shine is when you have a problem that is more complex than you would like and you have to find some way of taming its complexity. This is where, for example, having some relatively strict rules of object modularity and information hiding is absolutely fundamental. The kinds of things that you find in just about every other approach to circumvent information hiding don't exist in Eiffel. Such strict rules sometimes irritate programmers at first, because they want to do things and they feel they can't, or they have to write a little more code to achieve the result. But the strictness is really a major guard against the catastrophes that start to come up when you're scaling up your design.

复杂性控制在Eiffel语言编程中是一个基本原则。Eiffel对人们作复杂、高难度开发大有帮助。当然，你可以用Eiffel语言构建简单的、困难适度的系统，甚至可以比使用其他工具做得更好，但当问题复杂到超过你的意愿，你没办法控制其复杂性的时候，Eiffel才会真正大放异彩。例如，它的基本原则之一就是对对象模块性和隐藏信息要有相应的严格规定。在很多别的语言中，你能找到取得隐藏信息的简单办法，但Eiffel中是不存在的。一开始，这些严格规则可能会激怒程序员，因为他们无法干自己想做的事情，或者要写更多的代码才能达到目的。但当你需要拓展你原来的设计时，这些规则就成了避免大祸的强大卫士。

For example, in just about every recent object-oriented language, you have the ability, with some restriction, of directly assigning to a field of an object: x.a = 1, where x is an object, a is a field. Everyone who has been exposed to the basics of modern methodology and object technology understands why this is wrong. And then almost everyone says, "Yes, but in many cases I don't care. I know exactly what I'm doing. They are my objects and my classes. I control all the accesses to them, so don't bother me. Don't force me to write a special routine to encapsulate the modification of field a." And on the surface, people are correct. In the short term, on a small scale, it's true. Who cares?

比如，在目前很多的面向对象语言中，尽管有一些限制，但你可以直接给一个对象的字段赋值：x.a = 1，其中x是一个对象，a是它的一个字段。任何一个有近代方法论和对象技术基础的人都明白为什么这是错误的。几乎每个人都会说：“的确是错误的，但大多数情况下我不会在意它。我当然知道我在干嘛。它们是我的对象和类，我应该控制它们所有的访问接口，所以你不要来烦我。不要强迫我额外写些代码去封装对字段a的修改过程。”表面看，他们是对的。短期内，小范围情况下，它没有问题。有谁会在意它呢？

But direct assignment is a typical kind of little problem that takes up a completely new dimension as you start having tens of thousands, hundreds of thousands, or millions of lines of code; thousands or tens of thousands of classes; many people working on the project; the project undergoing many changes, many revisions, and ports to different platforms. This kind of thing, direct assignment of object fields, completely messes up the architecture. So it's a small problem that becomes a huge one.

但直接赋值这样一个典型的小问题在你有上万、十万甚至百万行代码、有成千上万个类，很多人参与一个项目，项目经历很多变动、大量修改，并且需要面向不同平台的时候，会将事情带入一个完全不同的方向。像对象字段直接赋值这类问题，将彻底搅乱整个架构。最终，一个小问题要带来一个大麻烦。

The problem is small in the sense that fixing it is very easy in the source. You just prohibit, as in Eiffel, any direct access to fields and require that these things be encapsulated in simple procedures that perform the job—procedures which, of course, may then have contracts. So it's really a problem that is quite easy to kill in the bud. But if you don't kill it in the bud, then it grows to a proportion where it can kill you.

如此一个小问题，你完全可以很容易在源代码中修正它。你仅仅需要像Eiffel语言那样禁止对对象字段的直接存取，转而必须在对完成这项工作的简单过程的封装基础上进行——当然这样的过程可能还需要一些契约。这是一个很容易消灭在萌芽阶段的问题，但如果你不这样做，它将会茁壮成长，最后置你于死地。

Another example is overloading: giving the same name to different operations within the same class. I know this is controversial. People have been brainwashed so much that overloading is a good thing that it is kind of dangerous to go back to the basics and say that it's not a good thing. Again, every recent language has overloading. Their libraries tend to make an orgy of overloading, giving the same name to dozens of different operations. This kind of apparent short-term convenience buys a lot of long-term complexity, because you have to find out in each particular case what exactly is the signature of every variant of an operation. The mechanisms of dynamic binding as they exist in object technology and of course in Eiffel are much more effective than overloading to provide the kind of flexibility that people really want in the end.

另外一个例子是重载：在同一个类中定义相同名字（的方法）去实现不同的操作。我知道对于这个问题是有争议的。人们已经被洗脑，坚信重载是一个非常好的东西，但本质上，它是危险的，并不是个好东西。和对象字段直接赋值一样，现在的各种语言都支持重载。人们编写的各种库中，重载泛滥，用一个名字（的方法）去实现许多不同操作。表面上，它短期内有其便利性，但长远来看，则付出了复杂性上升的代价，因为你必须搞清楚不同操作中每个变量的确切含义。其实，对象技术（当然还包括Eiffel）中的动态绑定机制完全能提供人们想要的、比重载更好的灵活性。

So these are examples of cases in which being a little more careful in the language design can make a large contribution to the goal of taming complexity. It's also sometimes why people haven't believed our claims about Eiffel. The use of Eiffel is quite simple, but the examples that we publish are simple not necessarily because the underlying problems are simple, but because the solutions are. Eiffel is really a tool for removing artificial complexity and finding the essential simplicity that often lies below it. What we realize now is that sometimes people just don't believe it. They don't believe in simple solutions. They think we must be either hiding something or that the language and methods don't actually solve the real practical problems of software development, because they know there has to be more complexity there. As this horrible cliche goes, "if it looks too good to be true, then it must not be true," which is certainly the stupidest utterance ever proffered by humankind. This is the kind of cliche we hear from many people, and it's just wrong in the case of Eiffel. If you have the right tools for approaching problems, then you can get rid of unnecessary complexity and find the essential simplicity behind it.

所以说，有很多例子证明，如果在编程语言设计时谨慎一些，就可以大大趋近复杂性控制的目标。这可能有时候也人们为什么不相信我们有关Eiffel的承诺的原因。Eiffel的使用是非常简单的；我们公布的例子也很简单，但其原因并不在于问题本身简单，而是我们的解决方案简单。Eiffel其实是一个剥离人为的复杂并找到常常隐藏起来的、本质上的简单性的工具。但我们现在发现人们有时候并不相信这一点，不相信有简单的解决方案。他们认为不是我们隐藏了某些东西，就是这种语言和这些方法并不能真正解决软件开发中的实际问题，因为他们相信就是应该更复杂些。有如此一种可恶的陈词滥调：“如果它好得不像是真的，那么就必然不是真的。”这可能是人类有史以来最愚蠢的说法。很多人都有这种论调，但在Eiffel面前，它恰恰就错了。只要你使用正确的工具去解决问题，你就可以去除不必要的复杂并找到隐藏的、本质的简单。

This is the key issue that anyone building a significant system is facing day in and day out: how to organize complexity both by removing unnecessary, artificial, self-imposed complexity, and by organizing what remains of inevitable complexity. This is where the concepts of inheritance, contracts, genericity, object-oriented development in general, and Eiffel in particular, can play a role.

任何一个正在构建大型系统的人，天天面对的中心议题就是：如何剔除不必要的、人为的、自找的复杂部分，并控制好剩下的、无可逃避的复杂性。在这个问题上，继承、契约、泛型以及面向对象开发等思想一般都可以——特别是Eiffel——发挥重要作用。

Bill Venners: It sounds to me that you're talking about two things: getting rid of unnecessary complexity and dealing with inherent complexity. I can see that tools, such as object-oriented techniques and languages, can help us deal with inherent complexity. But how can tools help us get rid of self-imposed complexity? What did you mean by "getting at the simplicity behind the complexity?"

根据我的理解，你应该是在论述两件事情：去除不必要的复杂性和处理必然的复杂性。我可以找到一些工具，如面向对象技术和语言，帮助我们处理必然的复杂性。但是工具如何帮助我们去除自找的复杂性呢？你所说“找出复杂背后的简单”是什么意思？

Bertrand Meyer: Look at modern operating systems. People bash the complexity of Windows, for example, but I'm not sure the competition is that much better. There's no need for any bashing of any particular vendor, but it's clear that some of these systems are just too messy. A clean, fresh look at some of the issues would result in much better architecture. On the other hand, it's also true that an operating system—be it Windows XP, RedHat Linux, or Solaris—has to deal with Unicode, with providing a user interface in 100 different languages. Especially in the case of Windows, it has to deal with hundreds of thousands of different devices from lots of different manufacturers. This is not a kind of self-inflicted complexity that academics like to criticize. In the real world, we have to deal with requirements that are imposed on us from the outside. So there are two kinds of complexity: inherent complexity, which we have to find ways to deal with through organization, through information hiding, through modularization; and artificial complexity, which we should just get rid of by simplifying the problem.

我们来看现在的一些操作系统。例如，人们猛烈抨击Windows的复杂性，但我并不认为其他竞争者做得更好。人们并没有攻击任何厂商的需要，但是很明显，有些系统的确显得过于混乱。如果重新彻底地审视人们提到的某些问题，的确可以设计出更好的架构。但是从另一方面来说，一个操作系统的复杂性又是无法避免的。Windows XP、RedHat Linux和Solaris都必须处理Unicode，必须为上百种语言提供用户接口。特别是Windows，它必须兼容大量厂商生产的难以计数的不同设备。这就不是学术界批判的那种自找的复杂性。在现实世界中，我们不得不面对外界强加给我们的各种要求。因此，复杂性可以分为两类：必然的复杂性，它要求我们必须通过优化组织、分析隐藏信息和模块化等手段找到办法来处理；另一类是人为的复杂性，我们应该通过简化要解决的问题来消除之。