转型：产品团队与架构师——金山WPS架构师手记

By admin

June 26, 2010 - One minute read - 86 words

与国外大型软件公司相比，在金山，架构师的发展还处于一个学习阶段，我们也正在实践中摸索适合我们的方法。借此机会，我想和大家分享一下WPS项目中架构师的发展历程和经验教训，共同探讨适合中国软件业的架构师之路。

WPS项目架构师发展回顾

WPS项目架构师的发展是随着V6（内部代号，指WPS Office 2005即后续版本）开始的，在此之前，开发团队并没有明确的架构师角色，开发人员在自发的、简单的模块分工交流之后，即开始各自的编码。从2002年下半年开始，由包括许式伟在内的一个团队开始V6的前期工作。通过半年的原型开发，确定了模块划分和接口。我觉得，这是我们第一次实施由架构师主导的软件开发过程。

我是在表格组成为架构师的。在此之前，我在表格组作为核心程序员，负责关键模块的开发。大约一年后，随着软件规模不断扩大，项目组成员不断增多，依靠程序员自发协调的开发模式开始成为项目瓶颈。再加上我自己的兴趣，于是我开始向架构师方向发展。2004 年，系统架构组成立，正式确立了架构师岗位。大致上WPS的架构师与程序员的比例约为1:10，与管理人员相当。

架构师的定位和职能

虽然当前架构师岗位已经非常普遍，但对于架构师是什么，做什么，不同公司和不同人在理解上存在很大的分歧。在WPS，架构师负责主导项目组技术方向的工作。这个定义非常模糊，在各个项目组中的实际工作方式也各不相同。我曾经与一些同事和同行讨论过这个问题，得到的答案林林种种，大致归类如下：

架构设计：这是最直观的理解。
组间协调：在大型项目中，各项目组的架构师完成组间沟通工作，成为连接项目各个部分的桥梁。
设计评审：对其他人（不限于架构师）提出的设计方案进行评审。
框架与基础库的开发和维护。
技术攻关：一些项目组的架构师承担着核心模块或关键问题的攻关，虽然并不涉及整体架构，但是项目的其他部分都是围绕着架构师承担的这一块进行。
技术传播：一些项目经理希望架构师能够承担起培训、代码评审等工作。
技术管理：协助项目经理进行任务分解、人员分工和计划制定。
技术基础设施构建，例如代码管理、持续集成等。

还有其他一些不典型的未列出来。我认为这个现象表明了在现实情况下，不同性质的项目组对架构师角色的需求是不相同的。不过，从抽象角度而言，我觉得在目前的软件开发技术上，架构师应该是一个满足如下描述的角色。

架构师从高于代码的抽象角度进行对系统的整体或者部分的表达（Expression），通过适用的介质传达到相关人员，从而实施软件的构建和持续维护活动。

以我个人在表格项目中的工作为例：我不直接编写代码，而是通过设计文档和持续交流，让我的队友了解要做什么、怎么去做，以完成功能的开发和改进。后续我将对我的经历做一个具体的描述，请注意，它可能并不适用于你的组织。

架构师的产生

事实上，一个再小的团队，都会有部分成员，在一定程度上完成了架构师的工作内容。至于团队要到多大规模，才需要专门的架构师角色，并没有一个确定的标准。我的经验是，通用软件的代码行数超过5万时，架构师会对项目持续发展能力有明显影响。

架构师通常产生于核心开发人员，这源于以下两个理由：

对问题域有较深的了解，掌握已有实现（如果有）的大部分重要细节。
在项目组中得到信任，组员容易接受其做出的判断和决策。

即使不是内部培养，外部指派的架构师通常也具有这两个特征。在一个较好的体制下，当确定架构师人选后，首先需要对其进行必要的技能培训。根据项目需要的不同，架构师需要针对性地培养抽象思维能力、表达和沟通能力、协作能力、领域知识。在WPS，以下的技能被认为是对架构师较为基本的：

对问题域进行尽可能地细化和分解。我经常遇到面试系统架构师的朋友，当被要求设计一个应用软件或服务时，只能回答出MVC或三层架构就结束了，这明显不够。
使用一种建模语言描述设计。架构师的日常事务就是交流，一套事实标准的方言体系可以大幅度提高交流效率。UML 是一个较好选择，因为其推广和教育成本很低。
以别人能理解的方式解释你的设计。建模语言之于架构师相当于机械制图之于工程设计人员，虽然理想的状态是大家都有读图能力，但是如果没有，架构师需要有办法让他们弄懂你的意图。
理解他人用各种方式描述的设计方案。理由同上。
领域知识。架构师必须对问题域具有较深的理解，否则其设计结果很难真正适用。不过同时也不需要成为领域专家，因为过多关注领域细节会导致整体把握能力缺失。
一定的数学能力。

架构师的工作内容

关于架构师是否要编码的问题，从我的经验来看，如果架构师有繁重的编码任务，就很容易沉浸到代码细节而忽略了整体（特别是其他人开发的部分）。因此，我倾向于只负责少量的框架和基础库，大部分时间都应该在代码之上思考问题。

通常情况下，架构师的主要工作是分析需求，设计实现架构，并给出设计文档。然而，不同的设计粒度，会产生不同尺度的设计视图。最宏观的视图类似于技术选型，即选择合适的平台、工具、第三方组件；而最细粒度的设计则细化到每个函数的功能和行为（常见于日本软件公司）。在实践中，在静态视图上我一般细化到公开类（类和其引用者属于不同模块）级别，核心模块细化到类级别。对于动态视图，由于通用软件不同于业务系统，通常我只关注最关键的一部分，因此整体文档中活动视图不多。

与普遍做法不同，我的类图一般描述类之间的抽象关系，很少写类的具体方法。这样做有两个原因：1 我的同事都是非常优秀的软件工程师，这个尺度的视图已经可以提供对他们来说够用的信息；2 减少文档维护工作量，至今为止我输出的文档都是自己维护，没有配备文档专员。

当软件规模足够大之后，架构师本身也需要再次分工。此时需要所谓的首席架构师关注系统整体，其他架构师关注各个部分。这种分工不影响架构师的工作方式。

在不同类型项目中，具体工作方式会有很大不同。上述内容适用于客户端通用软件，如果是服务端，则服务的切分和服务间的接口应该是架构师关注的重点。而不同的软件规模，或者是业务性软件，都会有不同的做法。

架构师与其他角色

在业界，除了本文重点讨论的架构师之外，还有一些与之类似的角色。如系统分析师，他专注于问题域的分析、用户需求的提取，一般多见于业务性软件组织中。还有专注于领域的资深工程师，通常具有超常的领域问题分析和实现能力，例如操作系统平台、优化、用户交互等。我们称他们为领域专家，也有冠以架构师的，例如平台架构师、安全架构师。

前面提到，架构师属于跨领域的交叉学科，因此好的架构师应该成为这个活动的中心。他从系统分析师（如果有）和领域专家吸取各种信息，利用这些信息来构造整个系统视图，并传达给大家，使项目组成员能够各司其职，高效协作。

在我们的实践中，测试部也有类似架构师的角色，不过并没有明确命名。

如何从程序员转为架构师

在讨论这个话题之前，我想要和大家交流的是：架构师只是一个分工，他并不等同于职务和地位，也不是技术路线唯一的发展方向。大家可以首先了解同类软件团队中架构师的工作特点，结合自身的兴趣，来决定是否转型到架构师。

对于想成为架构师的朋友，我有一些经验想和大家分享。

首先是需要写过足够数量的代码（非工作任务的）。架构师在一定程度上有点像医生，经常依赖经验和直觉，坚实的代码基础有助于提高判断的正确率。

同时还应该不断回顾和重构自己的代码。架构师的职责是维持架构的持续发展，如果连自己的代码都没有持续改进的动力，何谈对系统的不断完善。

多做设计练习。给自己一个应用课题，尝试不断地分解、设计。如果有可能，请前辈评点你的设计方案。阅读他人的代码，尝试抽取其中的设计。对于架构师而言，从各种来源摄取信息的能力非常重要。另外，阅读设计优秀的代码，可以增加自己的经验。

这个过程中，比较艰难的部分就是应用设计练习和设计抽取练习。这是一个转变思维习惯的过程，大概需要一年的时间完成。这些练习有一些比较系统的方法，限于篇幅本次不再累述。

最后，祝希望成为架构师的各位朋友能顺利完成转型过程。

作者简介：

杨钢，2001年加入金山软件至今，参加了自WPS 2002以来历届版本的开发。现任WPS研发部技术总监兼首席架构师，负责开发部管理和技术框架工作。致力于将架构设计变成一个有理论基础，可复制的过程。

（本文来自《程序员》杂志0906期）