Articles

谁需要架构师?

在公司封闭培训闲谈的时候,有人提到了这篇文章。当时我没有找到中文版,于是同事对我说,你要是有兴趣就把这篇文章翻译一下。我之前从未翻译过如此长的文章,所以一时兴起,就硬着头皮翻译了起来。

本文原文来自Martin Fowler的个人网站whoNeedsArchitect.pdf


不久前,我在走廊里溜达的时候遇到了我的同事Dave Rice,他当时看起来情绪有点不太好。我只问了一个很简单的问题,结果却引来了他暴跳如雷的答复:“我们再也不应该面试简历上写有‘架构师’的人了!”乍一听来,他这种想法有点奇怪,因为通常我们在介绍Dave的时候都说他是我们的首席架构师。

事实上他这种有点精神分裂似的想法是有原因的,因为在我们的行业标准中,“架构师”和“架构”两个词实在是被赋予了太多不同的含义了。在很多情况下,“软件架构师”一词是《黑客帝国:重装上阵》最后那段Matrix之父的真实写照。但即使是在最不重视软件架构师的公司里,也必然会有一个像Dave一样的架构师,起着重要的技术领导的作用。

什么是架构?

当我正在为《企业应用架构模式》一书的标题犯愁的时候,所有的评审人员都一致认为标题中应该有架构一词。然而我们却又都不知道该如何给这个词一个精确的定义。

为了避免对该词的解释模棱两可,我第一次尝试时完全凭借自己的直觉。我给“架构”一词做了如下定义:当我们谈论设计的时候,为了强调设计的重要性,我们就使用了“架构”一词。(同样,你可以想象一下,对于架构师一词也有类似的夸大的现象。)然而你会经常发现,就是这种完全评直觉的定义里,却埋藏着一丝真理。当我阅读了Ralph Johnson在极限编程邮件列表中的一篇文章后,我终于明白了。他写得实在是太好了,所以我决定引用全文。

较早的一个帖子里说:

RUP借鉴了IEEE标准中对于架构的定义,它将架构定义为:它是整个系统及其所在环境的最高层次的概念。在某一时刻,软件系统的架构就是这个系统中最重要模块的组织结构,以及这些模块间通过接口的交互。进一步,这些重要模块又是由更小的模块及其接口所组成。

Johnson回复到:

我曾经是IEEE标准的审阅者,IEEE标准曾经的确使用了上述定义。我也做过无力的争辩,我说这个定义本身明显存在缺陷。一个系统根本就不存在什么最高层次的概念。用户与开发人员对一个系统有着不同的理解。用户才不管什么架构和最重要的模块呢。所以,也许对于开发人员来说,架构是整个系统及其所在环境中最高层次的概念。我们暂时先不考虑那些对系统知之甚少的开发人员。对于专家级开发人员来说,架构是整个系统及其所在环境的最高层次的概念。那么那些重要模块为什么重要呢?因为这些专家级开发人员说它重要。

所以,一个更好的定义也许应该是这样的:在大多数成功的软件项目中,专家级开发人员们往往会对系统设计达成某种共识,这种共识就叫做“架构”。共识包括系统是被如何划分为模块的以及这些模块如何通过接口进行交互。这些模块是由更小一些的模块所组成,但架构只包括那些可以被所有开发人员所了解的模块和接口。

这是一个更好的定义,因为它明确的指出,架构是一个群体的共识。架构不仅仅依赖于软件本身,也同样依赖于这个群体对重要模块的看法。

另外,这还有一个对架构的定义,它大致是这么说的:“架构是项目早期就需要做的设计方面的决策”。我对于这个定义同样持怀疑态度,我认为,即使你希望你能在项目早期就做出正确的决策,但你真的就能比别人做出更正确的决策吗?

对于这第二种定义,大多数项目可能都需要把编程语言本身都算到架构里了,但是对于第一种定义这不是必须的。

到底应该把什么东西算到框架里,完全取决于开发人员认为系统哪部分更重要。对于开发企业级应用的人员来说,他们认为数据的持久化重要。当他们开始画架构图的时候,他们可能将架构分为三层。并且补充到:“我们使用Oracle数据库作为我们的数据持久层,以便将各种对象映射到这一层上”。但是对于医疗图像分析软件来说,他们可能同样使用了Oracle数据库,但却不会把它算到系统架构中。因为这类软件的难点在于对图像的分析,而不是存储。存取图像只是这类软件中一个很小的功能,大多数开发人员可能都会将这一功能忽略不计。

这样的话,我们到底应该如何向别人描述架构呢?“告诉我们那些最重要的吧!”架构就是那些最重要的东西,不管它是什么。

架构师角色

既然架构是那些最重要的东西,那么架构师就是那些需要整天关注这些最重要东西的人。接下来,我们看看架构师的本质。Dave Rice对比《黑客帝国:重装上阵》给我们举了个形象的例子。

Architectus Reloadus这类架构师需要做所有的重大决策。架构师需要做这种决策,因为我们需要有人来保证系统概念的完整性。或者也许是因为架构师认为组内其他成员的技术还达不到做出这种决策的要求。通常这种决策要提前做,以保证接下来组内每个人都有自己的任务计划。

Architectus Oryzus是另外一类架构师。这类架构师必须时刻关注项目中可能发生的各种问题,一旦发现任何严重的征兆就立即攻克,以免对项目产生重大影响。当我遇到这类架构师时,我发现他们工作中最值得注意的地方是紧密的团队合作。早上架构师与开发人员一起写代码,试图去帮助解决一些有问题的代码。下午架构师去参加需求会议,用非技术的语言,帮助提需求的人分析该需求可能带来的技术上的后果,例如研发成本。

Architectus Oryzus这类架构师还会尝试用不同的方法教导开发团队,以提升团队的整体能力,这样后续该团队就可以解决更复杂的问题。团队整体能力的提升给第二种架构师很大的优势。相反,对于第一种只做决策的架构师来说,团队能力很可能成为整个架构的瓶颈。从此我们可以大致推出一个令人满意的结论,架构师的价值与他所做出的决策数量成反比。

在一次近期ThoughtWorks的活动中,我和一些同事讨论有关架构师的话题。我发现一个有趣的结论,我们很快在什么是架构师的本职工作话题上达成共识。就像Architecus Oryzus一样,但是我们又不知道应该给这种类型的架构师取个什么恰当的名字合适。我们大多数人可能觉得架构师应该像Architectus Reloadus那样,但这种架构师却是建立在一个错误的比喻基础上的(http://martinfowler.com/bliki/BuildingArchitect.html)。Mike Two给出了一个我目前觉得最恰当的名字:向导,就像登山时候的领队一样。向导必须是一个既有经验又有技术的团队成员,他可以教会其他成员如何独立的照顾自己,当遇困难的时候,他会及时出现并解决困难。

摆脱软件架构

写文章的时候,我喜欢用一个醒目的标题,就像本文一样,并且有着比较深刻、不是一下子就能被理解的含义。还记得Johnson给出的架构的第二个定义吧?“架构是你希望能够尽量在项目早期就被确定的一些决策”。那么为什么人们希望能在项目早期就把这些决策做对呢?答案当然是人们察觉到这些决策一旦确定下来,后续就很难修改了。所以,我们也许最终可以这样对架构进行定义:“架构就是那些人们觉得后续很难进行修改的东西”。

在企业级应用开发过程中,人们普遍认为数据库的设计必须尽早明确,因为后续尤其是等系统上线后,就很难再对数据库设计进行修改。在我们的一个项目中,数据库管理员Pramod Sadalage发明了一种系统,可以让我们很容易的对数据库设计进行修改(http://martinfowler.com/articles/evodb.html)。这样的话,在我们的项目中,他就使得数据库的设计已经不再是架构的一部分了。我觉得这是一件非常好的事情,我们可以更好的应对变化。

在XP 2002大会上(http://martinfowler.com/articles/xp2002.html),有一个非常引人入胜的话题。 经济学家 Enrico Zaninotto对制造业和软件开发业敏捷思想更深层次的内容进行了分析和思考。我对其中的一个观点特别感兴趣,他说不可逆性是产生复杂度的最重要的因素之一。他发现在制造业和软件开发业的敏捷方法中,都会尝试减少不可逆性,来控制复杂度。我想这也就是说,架构师最重要的工作就是应该通过消除软件设计中的不可逆性,来彻底摆脱架构。

Johnson在给我回复的邮件中说:

建筑架构和软件架构的区别之一是,建筑架构的决策一旦确定了,后续就很难修改了。尽管不是说不可能,但地基一旦打好了,再想修改起来是非常困难的。

但却没有任何理论和证据表明软件修改是非常困难的。你可以通过对系统的设计,使得该系统对某一类问题修改起来非常容易。但想要对各种问题修改起来都很容易就比较困难了。因为想要使得对某一类问题修改起来容易,必然要使整个系统稍微复杂一点。而要使解决所有问题修改起来都容易,那系统就会变得非常复杂。复杂就会导致软件难以修改。这里我们好像陷入了一个怪圈。

我对Aspect-Oriented Programming持保留态度,因为我们已经有足够好的技术将程序的某一方面隔离,但是我们却没有使用这些技术。我不认为一个真正的问题,可以通过发明一种更好的隔离技术就能够被解决。因为我们根本不知道我们要隔离的是什么东西,也不知道某一方面的问题是否应该不应该被隔离。

软件并没有像建筑那样,受到物理上的限制。限制软件的是人们想象力、创造力,以及对问题整体的组织能力。简单来说,限制软件的是人们自身的属性,而不是这个世界的属性。“我们已经遇到了敌人,那就是我们自己。”