Philippe Kruchten谈论架构和技术债务

个人简介 Philippe是温哥华英属哥伦比亚大学软件工程学的教授。在他现在的工作之前，他为Rational软件（现在是IBM）工作了16年，在那里他是加拿大空中交通控制系统的首席架构师，后来领导了RUP的开发。

SDC 2010是一个关于商业分析和敏捷方法的重要活动。通过2天的会议，你会从全球著名的演讲者的实战经验中学到实践技巧并收获发人深省的想法。

   

1. 这里我们请到了英属哥伦比亚大学软件工程学的教授Philippe Kruchten。Philippe，你能不能向我们简单介绍一下你的背景以及你和软件工程的关系？

我本来并没有计划做一名软件工程师。事实上，当我涉足软件圈时，正在努力成为一名机械工程师。在我距离拿到机械工程本科学位还有几个月的时候，IBM雇佣了我，后来就那样了。现在我已经很难彻底脱离软件产业，毕竟，在70年代，那个行业是看起来最有钱的地方。我为IBM工作了很短暂的时间，然后在法国电信研究院做了一些研究，在那里学习了一些软件。我也去了阿尔卡特，在那里学到了很多东西，因为那正是开始使用计算机的时候，特别是使用大规模联网的微机，来使电话交换机精确转换，以及使其他很多电信相关的东西工作得更好。

那是一段用大量软件建造大型软件系统的重要学习经历，有很多关于“性能”的讲法，比如“可用性”“可靠性”等等。 之后，我来到Rational软件，主要以软件咨询师的身份在大型指挥控制系统中做软件架构师。我一开始在欧洲各国工作，然后在太平洋区的某个地方，最后作为加拿大交通控制系统的首席架构师在温哥华工作。当我5年后结束这份合同时，我开始了当时称为“Rational方法（Rational Approach）”的开发，但这之后被称为“Rational对象过程（Rational Objectory Process）”，最后改名为“Rational统一过程（Rational Unified Process）”。我在那里工作了5年，直到IBM并购了Rational我才离开。然后我达到了“彼得原理”（注【1】）中最终无以胜任的那一级—— 教导本科生。

   

2. 我肯定这不仅仅是教导本科生而已。Rational统一过程和敏捷的世界似乎被看做是直接对立的。你曾经在敏捷方法刚刚出现的时候写了一篇文章，把很多敏捷相关的东西和Rational统一过程联系起来。你是如何跨越这两者的鸿沟的？

我并不觉得它们两者是完全对立的。它们分别在不同的背景、不同的项目中产生，但是统一过程可以用很敏捷的方式使用，也可以用很愚蠢的方式使用。你甚至可以用完全荒谬的方式使用它。有个人又一次告诉我“哦，是的，初始（inception），这是我们写需求的时候。精化（elaboration），这是我们做设计的时候。构建（construction），这是我们写代码的时候。”是的，你可以以一种荒谬的方式使用它。

我觉得RUP包含了很多敏捷的原则。它虽然没有像敏捷方法一样有一些对人的关注，但是可以从迭代开发、开发流程中引入的纪律、运用于多种环境的流程等方面看出来，而这些也是人们没有注意到也没有做到的地方。他们试图用“开箱即用（out of the box）”的方式来使用RUP。“哦，天哪！定义了27个目标，但我们只有6个人！我们怎么办啊？”“定义了37个工作产品，我们怎么办？”我们开发 RUP的任何人，都没有想把它当做类似于你打开一个盒子，然后按照里面所写的全部东西来做的事物。它更像一些实践的目录，你可以选择特定项目所需要的实践。

我对一些敏捷方法有相似的感觉。它们在适合它们运作的环境下产生。所以当你在类型相似的项目，大小相同的团队中使用它们时，会很奏效。但如果你把它们延伸至完全不同的背景下时，你会开始碰到一些困难。它们会变成“有一些尚待解决问题”的工具。通常，人们希望通过采取作者定义的所有实践，无论是RUP还是XP还是Scrum，来解决他们项目中的所有问题。事实上，我认为你应该反过来做 ：问问自己我们遇到的困难是什么？我们可以从哪里得到一些改善？然后采取能解决问题的流程元素和实践。

   

3. 我听到你不止一次地提到“有纪律的敏捷”的概念。你能告诉我们那是什么吗？

我在一个相对大型的复杂系统中学习软件，我们有庞大的团队，有些时候系统的安全性很关键。你必须要有一些纪律！想象一下，你不能只是跟别人说说话，做些结对编程，让设计随着沟通和重构渐进。你需要有一些预测性，你需要能够证明你达到了一些之前定义的质量标准。我觉得这和一些敏捷原则是完全兼容的，像交流、迭代、循环反馈、从自己的进展和错误中学习等等。你可以把这两者结合使用。我觉得Barry Boehm把书命名为“平衡敏捷和纪律（Balancing Agility and Discipline）”是件很遗憾的事情，这让他们看起来是对立的。我觉得你必须有一些相对的纪律性，才能使敏捷开发获得成功。

   

4. 关于敏捷和架构，很多敏捷方法暗示我们需要容许架构的渐进。

哦，是的，那是另外一个决定于上下文的问题。很多很多的项目，可能80% - 85%的软件项目，它们的架构是在第一天到位的。当你开始你的项目时，重大的问题已经决定了，像语言、平台、框架，以及你能想到的其他的。对于架构的疑虑可能只对一小部分软件开发项目适用。你要敏捷，以及你要重视架构可能又是一组虚假对立。你可以都做！

架构，是指做一些对于系统有长远影响的重要决定。如果你忽视架构，而只是赶快把可见的功能点开发出来，那你很快就会陷入技术债务。当然，你可能快到第一次发布的时间点了。但是如果你不重视架构，如果你总是以“哦，这是庞大的预先设计（BDUF）”，“你们不会需要它 (YAGNI)”，“让我们推迟到最后负责时刻（last responsible moment）再说”为理由拒绝架构设计，那你可能能够完成第一次发布，但之后你会受困于许多技术债务。

架构上的决定，或者以前做的决定，是很难在以后挽回的。团队中一些人，也许不是所有人，必须持续关注架构。大多数架构难点都和质量参数有关，而不是功能需求。这是我们实现安全性、可扩展性、可维护性、高可用性系统的方法，也是有很多艰难决定的地方。

仅仅是用Scrum来驱动项目，从backlog中拿一些东西出来做，在sprint结尾的时候演示，可能会过早地把你引入技术债务。当然这还是取决于背景和上下文。在有些背景中，对架构的关注是重要的，在其他的背景中，架构并无所谓，只要好到我们能做我们的事就可以了。

   

5. 你很强调上下文和选择的重要性。这是不是你今天想要传递的关键信息？

是的，这是我要传递的重要消息之一。北美的地产商说：房地产有3大重要因素：位置、位置和位置。我觉得我们应该注重上下文、上下文和上下文。有人认为我们会在某天找到某个绝顶聪明的软件开发者，他将勾画出能替代所有方法的终极方法 -- 我不相信！我们当今工作的软件产业中有太多种完全不同的软件开发类型，无论从商业领域、项目大小、难度或是质量参数、复杂度，都有着巨大的不同。我们找不到一种方法能适用于全部。我们必须从现有的方法和实践中学习，理解它们所能解决的问题。当我们开始一个新项目时，我们必须理解这些方法中的哪些部分是可以使用的。

也许我们要选一些RUP中的生命周期管理，也许我们要做一些结对编程，也许我们想要测试驱动开发，也许我们不需要架构；这都跟上下文有关。项目的范围很广。我们看到的基于网络的数据库、网络服务器、通过网络的连接等，它们都有一些共同的特征。这可能是一些敏捷实践能“尝甜头”的地方。我也很关心你的项目如果不能尝到那些甜头时会发生什么。非常庞大的项目（世界上还是有一些这样的项目）、嵌入式软件项目、对安全性有高要求的项目、有严格性能约束的项目——它们需要很多关注。它们不会随着每周的重构慢慢形成。

   

6. 我们现在的方向在哪里？软件产业将会走向哪里？Philippe Kruchten 又会走向哪里？

如果我知道就好了。如果哪里有个水晶球，也许会有帮助。如我之前所说，我们必须放弃那种有人会创建一种流程适用于全部软件产业的想法。我们必须学会什么是好的，什么适用于哪些上下文。我们也必须学会“人”才是软件开发中的关键重要因素，这是敏捷告诉我们的。这才是软件开发背后的“机制”。我们建造不出一个软件工厂，把需求推进去，把软件拿出来。虽然这仍然是很多人的梦想。如果你跟模型驱动（model driven）的人说这个，他们会试着抬高抽象的级别。就像我们已经摆脱了有一种终极编程语言的想法一样，像三、四十年前的PL 1或者ADAR，我们终会承认不同方向的软件流程能应对不同的问题。

我们会面对一些不同的挑战：比如多核系统很可能会改变现有模式。我们还不能确切知道如何充分利用大规模的并行。而且，我们开发的软件和我们对软件的大部分思维模式，都基于一些串行线程，虽然可能会在这里那里有一些调换。多核将会改变很多事情。我们看到越来越多的软件用现成的软件组成。SOA只是一个范型（paradigm）或者模式（pattern）来组合软件。会有越来越多的人用现成的模块组装软件，而不是真正在写C++或者Java代码。那我们现在使用的方法是不是适用于这种新的模式呢？我不知道，我们还没到那一步，我们会继续发展，也许会找到一种新的编程语言，也许是函数式语言、领域特定语言来应对不同的问题。

互联网也在改变很多事情。有所谓“信息超载”之说，我们需要找到其他办法，在一个复杂系统或一组协同工作的系统中组织信息，以减少终端用户方的信息超载。所以，我不知道，我没有水晶球，但是看着事情发生会很有趣。

从我个人来说，最感兴趣的是做决定的流程，人们是如何做决定的，以及背后的原因。我觉得我们已经离传统的工程模式很远了，在那个时候工程师列举问题和解决方案的标准，然后列举可选方案并评估确定最佳方案。这不是软件开发中的情况。很多决定是基于经验瞬间做出的。这是非常有趣的东西，也是软件开发背景中很少涉及到的。它有趣是因为在引出需求和理解需求所解决的问题之间有连续性。它在商业分析师和产品经理之间、产品负责人和架构师之间也有连续性。

我们倾向于把它们看得非常不同，使用不同的上下文和模式。但是我越看它越觉得人们在做同样的事情，做选择和做决定。他们以不同的方法表达，但是当你在需求层面或者架构层面做一个决定的时候，其实是一码事。当一个层面有了一个决定，它就成为另一个层面要解决的问题，而这个问题又需要做决定来解决，接着又会成为这条链子上下一个人的问题。整件事情对我来说都是连续的。这可以使软件开发中的不同方面和谐起来。我们的各个分支并不是相互独立的，并不是商业分析师用他们自己的语言和自己的概念模型做他们自己的事情，软件设计者也做自己的事情，等等。这两者可以通过某种渠道和谐起来。

   

7. 你在英属哥伦比亚大学的研究重点是什么？（也许你已经回答了这个问题）

现在很难找到资助，特别是政府对软件工程的资助，对我感兴趣的那部分软件工程的资助，因为它太软性了。如果你和资助方代理谈软件流程，他们会说：“我们资助了软件流程30年了，我们能得到什么好处？”我仍然对架构感兴趣，我正在观察架构的两个方面，第一是做决定的流程，把架构看成一系列决定的产物，而不是一组UML图表（这个应该解决得差不多了）。把架构看成一系列设计决定后，我们就可以深入研究“这些决定是如何做出的”，这些设计决定背后的道理是什么，这些道理之间有什么联系。我们更多地进入了软件设计者和商业分析师类似于心理的领域。

另一个和架构相关的方面是技术债务，技术债务是错误架构决定后的不幸阴暗面，我已经和软件工程学员有一个相关的合作小项目。人们是怎么看技术债务的？我们能对技术债务制定成本或定价么？有什么策略和行动可以让你摆脱技术债务？这是一个似乎未被开发的领域，除了Steve McConnel和Martin Fowler写了一些文章以外，还没有对技术债务真正的研究。

我另一个感兴趣的地方更偏向于技术，触摸屏的使用，特别在软件开发中的桌面屏幕，大屏幕的交互触摸使用。大型分布式团队在不同地点不同时区协同工作时如何使用触摸屏，我在研究这个方向，它提供了很多有意思的研究话题。我也很幸运地拿到了政府赞助，因为这个研究能直接扶持加拿大的本地经济。

   

8. 非常感谢你。最后一个问题，你现在在新西兰参加即将开始的SDC大会。能不能透露一下你将为我们讲什么？

今年SDC大会的主题有一点和我个人兴趣偏离：商业分析。我是被软件教育局、 Shane你、还有Martyn Jones所邀请，我会尽力把我的兴趣和大会的主题结合起来。我会做一个针对商业分析师的软件架构的讨论会，讨论我作为一个软件架构师，期望商业分析师了解多少软件架构。我也会说一些技术债务、发布计划、以及如何把好的事情和坏的事情结合起来，像架构和功能，解决现有缺陷和避免技术债务，还有我本人对发布计划和迭代计划（或者Scrum中的Sprint计划）的巧妙结合。

译者注：【1】彼得原理指在区分等级的组织中，员工如果胜任当前的职位，就会得到升职，直至他无法胜任当前的职位为止。

查看英文采访：http://www.infoq.com/interviews/philippe-kruchten-technical-debt