我们最大的挑战：理解如何构造优秀的软件(转载)

我们真的知道如何开发优秀的软件吗？对大部分人来说，很显然是这样的。但是我们是否知道如何交流，以及不断改进我们开发软件的方式？我们真的了解交流和分享知识的最佳方式么？就我们在之前文章中的所见而言，显然没有！

我们站在流沙上还是巨人的肩膀上？

你是否曾经花时间研究新的方法或实践，最后却发现它只是你已经见过无数次的某种思想的改头换面？

你是否曾经烦恼过，每个软件开发新思路似乎都以过去的一切为代价，都与过去的一切水火不容？

在你看来，追逐最新的软件开发趋势是否已经变得比生产优秀的软件更重要？

你是否注意到，急着要取得进展的人们似乎丢弃了好的部分而留下坏的？他们没有从自己的经验中学习，在自己优秀的工作上更进一步，而选择将一切弃之不顾，重新开始他们认定的新事物。他们好像没有什么牢固的知识好依靠。

这种行为可以从很多地方看出来，很多团队草率地丢弃昂贵的过程和工具的投资，甚至在尝试它们之前。每个项目都采用新方法。每次工作发生变化，在手头真正的工作取得进展前，他们必须学习新方法。这是没有效率的，人们不能从经验中学习，因为他们永远从头开始。底线是，没有什么新事物能够被适当地固定下来 ——即使经过几种“现代”软件开发趋势，最流行的软件开发方法仍然是规范型的瀑布开发或自由hacking。作为一个行业，我们没有什么真正可以坚守的东西，而且一切似乎没有什么变化。

但现在我们能肯定敏捷会解决所有问题吗？

最新横扫行业的趋势是“敏捷”。现在，我们可以很明确地说，“敏捷”运动对软件产业做出了非常积极的 [1] 贡献。它提醒我们，软件开发中，人是第一位的，也是最重要的。事实上，这不是什么新观念，但这是重要的，而且这一点似乎被以前更加技术导向的趋势所忽视，比如说面向对象和Java编程。通过展现一系列优点，敏捷宣言创造了某种强健和适应力强的东西，可以抵挡下一次趋势带来的变革风浪。[2]许多声称支持敏捷哲学的敏捷方法，却没能做到这一点，这是非常让人遗憾的。对一项将人的价值放在过程和工具之上的运动来说，这确实带给了我们很多“新”的过程和工具。其中的大部分已经显示出效率，通过将团队带回到之前完成的开发软件工作。但在重新聚焦到这上面之前，许多人已经迷失或迷茫，因为将新术语引入旧事物后，让人觉得这一切似乎是全新的。这个对旧思想的不断重新包装和品牌重树让软件开发团队的工作方式剧烈摇摆。对他们的工作和产品任意命名，而不是让人们远离浪费时间的工作，将精力重新聚焦在对高质量软件的开发上。

即使有些方法能够像敏捷哲学一样正确、有益，但相关的信息可能会在摇摆和炒作中丢失。我们已经开始看到对敏捷的反弹，我们担心的是利益将会丢失，当早期使用者投入下一个趋势，而晚期大众则重新主张自己的权利，拒绝采纳这些显然不再流行的东西。

有可能会发生的事情是，我们增加更多时髦的词汇和相互冲突的名词，最终为这一切喧嚣所累！

应对挑战：发展基本理论，描述软件工程究竟是什么

很显然，我们需要停止对流行和永远令人失望的简单答案的追逐，同时不能阻碍创新和新想法。为了做到这一点，人们需要停止对旧思想不断重新包装和品牌重树。相反，他们应侧重于帮助人们了解如何建立优秀的软件。但我们如何才能重点推动这一变化？我们认为，这个理论就在眼前——我们要做的只是抓住它。首先，我们应该从所有流行的方法、过程和实践开始，并从中提炼出软件工程的“真理”。然后，我们可以描述和捕捉一个最小集合的基本概念，以最小独立过程的形式——我们将这个本质物的最小集合称之为内核。

然后以这个内核为出发点，我们可以分析现有的过程和方法，并确定它们所包含的实践。从内核开始，我们可以找到一种描述实践的方式，使它们能够进行比较和结合。

现在所说的这种创造理论的方法本身并不是理论。这是我们已经做过的事情。通过研究一些方法，包括XP、Scrum和统一过程，我们的团队已经确定了 20多个内核元素，我们总是做的事情或产生的东西。从表面上看，在这些被研究的方法和我们的工作方式中，有可能会出现很大差异；但在实质上，它们有相同的 DNA。举例来说，你可以捕捉功能或用例或用户故事的条件，你可以在没有生命周期与统一过程的生命周期，甚至瀑布生命周期（就像有些人仍然在坚持的那样）的情况下使用这些条件。这些方法肯定有一个共同基础，能够以小的简单的内核要素集的形式被捕获。

现在，还不能冒失地声称，我们的内核提供了必要的理论。需要有比我们更多、更大的头脑来做到这一点。但是，我们会将它作为一项证据，证明它的能力和我们需要的理论就近在眼前。

但理论会带来什么影响呢？

它不仅会影响方法论、流程爱好者和学者，而且将会有利于软件开发涉及的每一个人。但是，它究竟会带来什么影响呢？

软件行业从中得到什么？

许多大公司都有自己的方法或过程，也就是一系列标准方法，搭配自己对更具体业务的想法。这些过程通常要用一本厚书或网站来介绍，大量资金被投入到归档工作中。有时，人们被训练使用这些过程，有时只是被简单告知它们在哪儿。在现实中，过程常常被忽视；仅有的被实际使用的部分是，组织中形成了“口头传统”的那些。这被解释成重新发现的自然法则：人们不看过程的书籍。新的思路引入到组织中，旧过程退出流行，而有关它们的书成为摆设。

在某些大公司甚至会出现多个过程。例如，大型系统集成商可能有十个或二十个不同的过程。有时它们很相似，但相似性背后隐藏着差异。

如果贵公司采用这种实践观，你就不需要因为一些新的性感的东西正成为流行，而抛弃整个工作方式。相反，你只需要对现有的工作方式进行改进，一次改进一个实践。你甚至可以采取那些被其他公司使用的实践，而不用丢掉似乎运作良好的现有实践。作为开始，你需要将现在的工作方式看作一个实践集合。然后寻找你的痛点，然后修补目前的工作方式，通过删除没用的实践，代之以解决这些薄弱环节的实践。一旦你理解了内核和它的使用，就很容易做到这一点。在具有多种不同工作方式的大型组织，你可以使用此方法先后改进每个工作方式，而不必强迫大家使用相同的方法或过程。

这种做法将使新实践更容易被采纳，而无须改变其他实践。想象一下，几年前，你已经引入了内核，并描述你的实践。然后，你将能够轻松引入Scrum，通过用Scrum取代项目管理中现有的实践，而无须对其他实践进行任何重大修改。展望未来，Scrum将很有可能被新的实践代替，你将能够很容易地做到这一点了。

学术和教育界从中得到什么？

如果我们的技术学院或大学教授学生软件工程基础知识，然后训练学生在一系列良好的实践中使用该基础，那将是非常棒的。教育将会更合乎逻辑，因为它着重以独特的想法，而不是特定的思想，来形成每个方法、过程或方法论。我相信学生们会喜欢的。这里也为相关研究留下了很多空间。记住Kurt Lewin的话：“没有什么比一个好的理论更实用了。”一个好的理论使得学习和开发你的知识更容易，而不会带来过分的崇拜。这将是聪明的。大多数大学教授们在学术生涯中，从来没有真正的机会来实践大规模的软件开发。但是他们仍然不得不教授软件工程，这当然是不容易或者只是依葫芦画瓢。他们只能这样做，因为这门课在课程表上，而不是因为他们确实有什么可教的。他们没有传授理论，只是一套想法或一个特定的方法。当被问及此事时，一名成功的计算机科学家、教授软件工程课程的教授说：“令人惊讶的是，学生们喜欢沐浴在我们交给他们的烂泥塘里”。我知道这么说并不严肃，但是可以肯定这位老师并不为他做的事情而感到自豪。

一个理论，将从根本上改变这种局面。学生将学习软件的基础知识。他们将得到一种语言，来沟通软件过程、实践、模式，等等。可以想象，他们将会得到一种以内核为语法的语言和描述过程构成成分的时间的语言结构。这样的语言需要是可执行的，这样实践才会变得生动。我说这些是为了表明这些实践不仅是规范，而且也可执行。当一个项目进行时，这些实践将开始运行，而且活动实例、工作产物，实例、技能角色将被真实物创造和填充。这些方面似乎能与实践模式很好地吻合，有非常有趣的语义规则需要确定和定义。向学生打开了一个全新的世界，可以帮助他们了解软件工程的基本原理。更不用说，为对实践和理论感兴趣的研究人员打开了一个全新的世界。

方法论从中得到什么？

回顾自己1987年后的职业生涯，许多人建议我写一本有关方法论的书。当时Objectory有一些新的想法，比如说用例、用例驱动的开发（这是一个测试驱动设计、合作、序列图、组件和基于组件的开发）。其余的大部分内容都没什么特别的。实施、单元测试、系统测试、性能测试、配置、规划都是相当传统的。当然，我有整个生命周期的经验，但我不是所有事情的世界级专家。然而，为了写书，我不得不包含整个生命周期的内容，即使其中很多不是我的专长。随着我们寻找的新理论，没有任何必要再说明不包含创新的内容。你不需要写一本书来发布新想法，然后把软件开发团队需要做的一切都放进去，而只需要描述你的新实践或新模式，也许第二天你就能向全世界发布了。全世界的任何好点子都可以贡献出来并获得成功。

软件开发团队从中得到什么？

终于，软件团队将能够摆脱亦步亦趋地追随潮流所造成的无休止的摇摆，成为严格意义上的软件工程团队。团队在坚实的基础上通过优秀的软件开发实践建设和扩展知识。这个基础不会频繁变化，不会强迫你一遍又一遍学习同样的事情。它可以让你通过自己的总结，而不是出席的课程来展示专业。它可以让你轻松和无缝地引进新思路和新队友，而不会造成性能骤降或精力浪费。团队最终能够不断改进和适应他们的工作方式，迎接他们每天面对的挑战。他们将能够开发自己的知识和技能，以一种能够让他们顺利地和来自不同背景、团队和组织的其他人合作的方式，而不必一遍又一遍地重复学习同样的事情了。

最后的话

我们对软件工程的了解缺乏一个基本理论。因此，我们不断用略有不同的词再造旧方法，掩盖了真正的创新，同时让抛弃旧的不好的部分，利用新的好的部分变得困难。该理论将帮助我们大大改进软件工程教育。这将帮助我们在面对身边涌现的新想法时的反应不那么天真。最后，它也将帮助我们更快地接受新的思想。这一理论的真正受益者将是软件行业，这一点已经在许多公司得到证明。我们将能够方便地教育我们的人员，让他们加快速度；改进我们生产产品的方式；系统地重新设计（比重构程度更强）我们的产品；不断改进我们的工作方式。其结果将是更好的软件、更快的速度和大幅降低的成本。正如上面提到的，我们需要齐心协力才能做到这一点。从Scott Ambler最近的一篇文章“理论需要战略”中可以看到这种势头已经开始，但仍有许多工作要做。

我们已经证明它的有效性，但我们仍然要做许多工作才能建立一个公认的标准，必须在一组专家和权威之间建立共识才能完成这点。我们期待着与这些专家的合作。

要了解更多参与的方式 ，请访问 www.ivarblog.com 或者在博客“软件工程需要一个理论” 上给我们留言或者发电子邮件到[e-mail]。

[1]如果你已经在世界各地的会议上看到我们最近的发言，你应该了解，我们是敏捷的狂热粉丝，是敏捷宣言的支持者。

[2] 新的趋势一定要跟随敏捷趋势，就像黑夜要跟随白天一样。