创建成功的工程 作者：Bruce Eckel，翻译：UMLChina.Hairui? Bruce Eckel，著名的计算机语言和工程专家，著有《C++编程思想》（Thinking in C++）、《Java 编程思想》（Thinking in Java）等书籍 相关网站：http://www.bruceeckel.com --译者注? 以下工程开发指导是我对决定一项使用任何语言的软件工程成功与否的决定因素的一些认识。? 1．记住往往事与愿违? 纯粹的“轶事工程”（原文为：anecdotal project，其含义不好理解，暂译为"轶事工程"，盼指正--译者）的失败几率总是存在，一些低至百分之五十而另一些高达百分之八十，但是所有的这些都表明：你失败的机会大于你成功的机会。为什么我要从这个令人丧气的预测开始我的话题呢？因为每一天开始时，我都想“今天将会不同，我今天能够完成四倍数量的事情”，尽管（在此之前）有过一系列不间断的例外。对于软件工程来说，过度的狂热往往被那些（只）关心结果人所夸大——“这一次，我们将解决以前从来没有人解决过的问题，只需付出更少的时间和更小的代价”，尽管他们知道，真正的规则是：“你只能从此三者中选择一个”。? 记住你身后高高堆积的纸牌[i]非常重要。你手中有一根包含时代力量的魔术手杖或者是挂在悬崖上，会让你做出完全不同的两个决定。如果你懂得你的处境属于后者，你将会说：“是的，这很好。但首先让我们看看我们是否能够在现有的进度和预算情况下完成这一切。”? 一个将不稳定形势和对失败的认识放到显著位置的方法是研究过去的失败。一份很好的资料是Roberts Glass（一位爱好研究崩溃的专家）的著作：《软件失控》(Software Runaways,出版信息：Prentice Hall 1998)，以及他其它的著作。此外可以阅读Tom Demarco和Tim Lister的经典之作《人件——生产性工程和团队》 (Peopleware: Productive Projects and Team,出版信息：第二版，Dorset House,1999)。? 2．切合实际地安排时间? 时间安排的“魔法”经常受到非开发人员为满足软件开发实践之外的愿望和期待而产生的想法所驱使。最近我校正了自己的时间安排策略。我先将整个工程显示脑海中，然后闭上眼睛，清理自己的大脑并让它判断这个工程大概需要多少时间。如果不考虑奇怪的技术问题、各种会议和其他分心的事物的影响，得出的这个时间居然非常合理。但我建议将这个合理的时间乘以3，或许可能是4，并且加上百分之十。如果这个估计出来的时间将让你失去市场机遇，那么考虑不要进行这个工程。如果你认为像这样计划时间不合理，那么首先请注意，大多数工程将遵循这个规律。其次，试想一下，如果你所在公司的所有工程都很成功进行会带来局面：你将拥有更多的收入；更少的程序员会因为愚昧的工程时间安排筋疲力尽而退出。? 你也许还会争论说这个时间评估技术非常没有科学性，这一点我同意。然而，所有的软件评估技术都含有臆测和直觉的成分在内，甚至连功能点（原文为：function point，若有其他正规译法，请指正）分析都需要对功能点进行猜测。我的“信封背面”技术将所有臆测结合到了一起，而不试图假装没有猜测。用更少的时间，也许产生更好的结果。但是，我的猜测是建立在我自己的经验之上的。? 3．首先让它运作起来? 当我试图进行一些无意义的事情时，我最大的创造性成功来临了。铭记最重要技巧——当你开始一个工程时，你好比已经用手指将自己挂在一个悬崖之上；然后你考虑一下能够做什么疯狂的事情简单地让你的工程运作起来。这并不意味着你需要马上投入进去并用通常的方式开始撰写代码，你只需要尽早尽快找到一个转换周期非常短的工具，用来判断你是否可以做该项工作以及你的工程可行性如何。我在后面将要提到的Python语言就是这样一种工具。? 将你的计划运作起来有很多好处。凭你的经验，你应该知道，用户只有能够开始使用你开发的东西的时候才能理解你开发的是什么，然后他们会突然产生各种念头并对该软件应该做些什么真正提出要求。一份系统说明书往往只是一份文档，人们往往不会认真地阅读，但是如果你让他们体验一个可运行的程序之后，他们就会确切地明白你的意思。更早地了解用户们真正想要什么岂不是更好？? 事情往往会比你想象出来的要复杂四倍以上，所以对你能够完成的东西要尽可能地保守一些。无论何时，一些不可知的因素都在伴随着你的工作（这一点你可以从产品描述中一些“最”中察觉到：“最快”、“最大”、“最新”），原型的价值不能进行夸大。如果在此之前你没有做过类似的工程，那么最重要的事情是尽快地判明该工程是否可以实现，开发一个根本不能发挥作用的程序将会以浪费你的大量金钱而收场。? 最后一点，优化。要能够在这个阶段抵抗得了诱惑。牢记Donald Knuth说过的话（其中略有一点开玩笑的意思）：“不成熟的优化是所有麻烦的根源”。虽然优化是一些工程的关键因素，但是在确认程序切实可行之前一切优化都是盲目的。在最后建造系统之前浏览一遍所有的问题。每个工程都有一些你没有接触过的东西，你应该首先将注意力放到这个领域，创建一个测试程序或者原型来寻找解决问题的方法。在你知道你是否可以做到并且知道做到的难度有多大之前，你没有其他办法能够得知工程是否能够成功、如何为它安排时间以及它需要多少付出等等。? 4．使用恰当的工具? 一个工程的早期部分应该是高度探索性和实验性的，因为那个阶段是发现自己不会做什么以及如何去建造程序的阶段。寻找最适合工具的最好方法是去体验一下他们，然后摈弃其中工作效率低下的那些。例如，你可能开始的时候用的是Rational Rose，后来决定使用Visio Professional来创建视图，因为你需要Visio（或者通过Versa）提供的一些特性。? 用来做工程的恰当工具并不一定就必须是你已经了解的编程语言。当使用一种语言时，你就被局限在该语言所能表示的范围之中了。如果你是一个C++程序员，你很自然可能想用C++创建所有的工程管理和工具。但当你需要更加灵活的工具时，Perl是一种更快速的选择（甚至将考虑学习需要的时间在内）。在你的实际工程开发中，使用Python来快速造型或者甚至交付一个内嵌Python语言的应用程序将给你带来更好的局面。首先，它是免费的，所以不需要支付任何许可授权费用；同时它对C 和Java有完全兼容的接口，你可以使用Python解决所有Perl能够解决的问题，所以它是C++和Java的一种完美的辅助语言。? 5．接口的设计? 在C++中，接口是一个包含所有虚函数的类；而在Java中接口技术被直接支持；在COM和COBRA中，你没有其他选择，你和所有的抽象打交道——所有的都是接口，没有实现。接口提供了一个更加整洁的设计方式。要想让程序员们确信这一点有些困难，但是它对将COM或者COBRA指定为构件模型非常有帮助的（COBRA技术也是与操作系统无关的技术）。它不仅仅提供了工程实现语言的灵活性，并让你能够完全地将工程切割开来。如果你打算在你的开发组或者公司之外实现你的工程的一部分，整洁的接口可以阻止任何与工程其它部分不适当的连接，同时你可以用任何语言来进行开发。你可以采取快速造型来实现所有的接口，稍后才对其中比较特别的部分进行优化。? 6．设计时充分考虑异常情况? 在C++中，异常控制并不像在Java中那样得到有力支持——这是Java在工程管理方面成功之处。在设计、代码编写和模块使用的时候往往会有一些错误，除非软件自身能够通过抛出一个异常来声明这些错误，否则你将会花费许多小时或月的时间来捕获这些问题。只有通过严谨的异常使用，你才能保证这些问题不会出其不意地让你的工程陷入困境。? 7．简洁往往付出代价? 虽然很难说服管理部门，但是“简洁”这个词是可维护性和复用性的同义词。不仅如此，一个简洁的程序让人感觉很好。但是因为我们确信软件工程是一种商业行为，目的是为了赚钱，而不是为了感觉，因此很难说简洁的程序比其他非简洁的程序更加有灵气地结合在一起。但是由于软件是一种能够赚钱的艺术实体，在美学和实用性之间必然会一场争论。? 8．人与人之间的交流是一个瓶颈? 这就是为什么小型的组队往往更加有生产力的原因。当一个工程像火焰一样失去控制的时候，将更多的程序员扔进火焰将使情况变得更糟。这也是为什么简短的小会议往往可以发挥作用而冗长的大型会议却做不到，还有为什么太深的管理机制会导致生疏的原因。参阅《人件》（早些时候提及过）一书了解更多的细节。? 解决交流问题的最好办法是免费的：在一台废弃的计算机上安装一个Linux服务器，你可以在几分钟内完成这项工作，自动安装将包括一个Apache网页服务器。然后将你们所有的文档，从测试分析到用户文档，拷贝到服务器上，以便每个人都能够访问到最新的信息。你可以轻松地加入Java Servlets或者Perl脚本（http://www.perl.com/）或者Python(http://www.python.org/)来收集每一页的内容，然后用一个List服务器来向所有的成员发送公告。如果你想用camera-ready格式来提供文档，你可以用Adobe Acrobat格式来代替HTML格式。如果你的工程足够大的话，指定一名成员专门负责维护服务器是值得的。? 9．制定一份计划（可以是任何类型的）? 我曾经见过许多工程在没有签订任何合同（更别说一份计划）时已经有大量资金流动。哪怕是对于一个很小的工程，你也需要某种计划，甚至它可能只是被写在一个信封的背面或者只存在于主程序员的脑海中。当工程逐渐变大，你需要一个回顾的过程。一个典型的计划包括：分析阶段（包括你打算用程序解决什么问题以及程序将完成什么）、设计阶段（程序如何完成它的任务、程序实现的组成、分析阶段预定目标是否达到的测试使用信息以及发布、安装和培训等事项）。当新的信息被收集时，这些阶段将被重复。根据工程的大小，这些步骤将被缩小或者放大，但你必须像熟悉你的编程语言一样熟悉它们。? 10．考虑外部帮助? 一种放弃：我的公司提供培训和咨询服务，因此当然我感觉这是一个好主意。然而，如果你的公司内部有经验丰富的人可以担任你的工程的顾问，你可以不必向公司之外寻求帮助。这是一种以知识为基础的商业行为，生产力最低和最高的软件工人之间的生产力差别是很大的。如果你无法雇用那些最有生产力的工人，你可以通过培训提高他们的生产力，通过咨询和代码预排来改进你的工程的分析、设计和实现。对于顾问和客户来说，有一本优秀的书籍是Weinberg的《咨询的秘密》（出版信息：Dorset House,1986）? 另一方面，我曾经见过一些工程中，使用外部的开发组队剥夺了内部的队伍的权利，该项目最后以花费更多的时间和资金收场。这将我们带到我的最后一个提示:? 11.了解永远没有银弹（原文为：silver bullets,此处直译为银弹，估计引申含义和free lunch接近）的道理? 这句谚语是由Fred Brooks发明的，对于今天仍然适用——尽管有许多“银弹”已经被发明出来了。统一建模语言（UML）就是这样一个例子：它当然是一个很好的通用词汇表和设计符号集，但是UML仅仅轻微地减少了方法学家之间的争论而已。永远不会有不劳而获的事情。你必须艰辛地计划你的对象、它们的接口和结构，然后跨越一道道障碍将工程变成成果。你必须清楚没有任何可以保证成功的方案可以依赖，同时牢记工程的失败的几率让自己更好的瞄准成功。