优秀架构师必备素质

如何做一个合格架构师 究竟是什么让你在同一个位置上——例如程序员或技术负责人——工作了三年、五年或者更久，而仍然得不到任何的发展空间？你 觉得自己已成为技术圈中的大牛，并信心满满地去拿明天就要颁发的 某某大奖，然而却仍然停留在同样的技术职位上，去年到今年涨的薪 水甚至填不平物价升幅？于是，你开始对老板不满，对员工不满，对 昨天升职的那个同事不满„„你开始计划明天就要跑单，或者准备考 虑提出加薪却又心怀忐忑。 如果技术人员有发展的轨迹，那么他要么“看透工具的本质，把关注点转移到‘团队’的圈子里去”，要么“顺着代码铺就的道路， 亦步亦趋地成为良匠大师”。仅以技术方向而言，你大概可以做到架 构师、总架构师甚至首席架构师；但问题是：你现在还只是一个程序 员。那要如何才能踏上通往架构师之路呢？本文为你解析一个架构师 的能力模型。 架构师不是界定一个技术高下的职位名称，而是一个职务。所谓 职务，包括职——职位，务——工作。前者决定了你具备哪些资源， 可以影响到怎样的范围，以及面向的机构，后者则简单地是你需要完 成的工作列表。 所以我说“架构师”不是指“一个能做架构的人”。前者是把架 构师当职能，后者是当工人。能做一份工作列表中的事，并不等于就 成为相应职位上的人。在管理体系里面，你的个人特性决定了你在哪 个位置，而技术技能只是做事实施的必需。架构师这个职务，同时要 求较高的个人素质和技术能力，因此它的进取之路总结起来就是：做 人、做事，做架构师。因此“模型”由“个人特性”和“技术技能” 两个方面构成，在第一张图中，我特别说明“个人特性”既包括人际 关系的能力，也包括（具体）业务能力；“技术技能”也是如此。所 以个人特性主要与“做人”有关，部分地也包含“做事”的要素。 图1 架构师能力模型 “有效沟通”以及“学会谈判”与做具体的事无关，是个人能力 特性的公共方面。前者是过程，后者是知道如何定目标与求结果。而 “风险与防备”是做事过程控制的关键，与前面两项正好构成了一个 做事基本能力的完整体系。基本上，这三项个人特性都是一个“普通 程序员”所不具备的，甚至在大多数情况下，普通程序员并不愿意去 具备这样的个人特性，因为在许多陷于技术泥淖的开发人员看来：沟 通总是会使事情变得更加麻烦，谈判则徒耗时间而无济于事。然而事 实上，在整个的架构决策过程中，架构师需要不停地沟通与谈判。将 “架构”变成“决策”的过程，其实就是对各个技术角色（及其思想） 兼容并包的过程，你需要不断地协调需求、实现之间的各种问题，也 需要面对各种投资者（时间、资金、人才等方面的决策者）进行谈判， 以确定项目的规模——没有规模也就没有范围，没有范围如何展开设 计呢？ 一部分开发人员会认为上述过程是“项目经理”的事情，但真的 如此吗？当你作为一个更高级别的架构师，以至于要影响到多个项目 的决策时，你就全然不会有这种感受了。因为这种情况下，你的决策 将先于项目的启动，或者说你已经不单单是一个技术角色了。 设计是架构能力的一部分，但架构师不是设计师——看清楚二者 之间的不同，你才真正迈出了架构师职业生涯的第一步。 个人特性中另一个非常重要的方面是“抽象思维”，而这是与架 构师角色直接相关的一种能力。这种能力既有职业技能特征，又是普 遍性的能力。 所谓普遍性的能力，是指“抽象”在我们——作为人这种个体的 ——生活中无处不在。例如我们说花、草，说桌、椅„„我们用语言 去指称任何一个既已存在的（可以脱离我们的语言而自然存在的）事 物时，就用到了抽象。说“桌子”的时候，既没有描述桌子的具体形 式，也没有说明它的规格，但我们用这个名词时，所有人都知道“桌 子是什么”。所以，名词概念是整个抽象逻辑系统中的主体。如果失 去了这些名词定义，我们基本上不能说话，也不能描述任何东西—— 那便到了“只可意会不可言传”的境地。 用现有的成熟语汇去描述你的系统时，大多数人会理解你所表达 的含义，例如我们说“这个系统设计为一个三层结构”。然而架构师 面临的系统在许多细节上并不见得能够用成熟的语汇去描述，因此必 须自已构建一个抽象系统，这就需要概念抽象能力、概念表达能力和 基于概念的逻辑表达能力。 概念抽象能力是一种思维能力。简单地说，就是“把目标分解或 概括清楚”：你要么概而言之“它是什么”，要么详细地说明“它包 括什么”。必须使用大量的语汇来陈述这个“什么”，这不单单是表 达为文字，也表达为你在思想过程中的一个完整系统。通常用的方法 是“映射系统”。例如你可以用数学中的“数轴”来映射“实数 域”。将目标系统形式化为一个概念化的、可讨论的结构系统后，你 的抽象过程就基本结束了。 图2 能力模型中的个人特性 然而这个“抽象系统”可能只构建在你的思维意识里，还必须把 它描绘出来。因为不能只是你自己思考清楚，系统就能设计完成。这 个“描绘”就依赖于后面两种表达能力，一种是描绘概念实体，一种 是描绘实体上的逻辑——有趣的是，这似乎又回到了“程序＝结构＋ 算法”。 现在大家回过头来看看UML，或者更多种类的ML（建模语言），他们就用于表达这两个方面的东西：要么是概念实体（例如用一个框 表明系统边界），要么是实体上的逻辑（例如用箭头表明逻辑时序）。 所以大家应该清楚，我们再如何称赞UML，它也只是一种对模型 化系统的“表达能力”，你只能把它当一种辅助表达的工具去使用， 它本身既不能帮助思考，也不见得能作为抽象过程中的或抽象思维环 境中的参考。 任何一个优秀的架构师都有自己独特的思考方式，这决定了他如 何抽象系统，以及如何“创造性地”设计与构画这个系统。这种“独 特的思考方式”贯彻他从孩童开始的整个成长过程，直至他形成独立 的社会观、人生观与世界观。他认识世界的方式和接受世界的能力决 定于他如何思考，也反映了他这种思考方式的“独特性”。但这并不 表明他有特立独行的行为特性（我们这里只说他的思考方式），我们 不应介意他是否用某种语言（例如UML或者形式化编程语言）来表达 他的思考结果。 架构师首先是把问题的真正目标确定下来，然后变成系统设计、 平台设计或架构设计。而在此之后设计输出将会有两个方向的发展， 一是被忠实地贯彻下来，二是被变形地发展下去。两个方向都存在致 命的危险：架构最终能否被完整实现。对前者来说，可能是架构设计 过度，或设计本身出现了错误；后者则是对架构直接的伤害。 所以架构师必须参与实施的全程——尤其是在架构被映射为目 标系统的前期。在这个阶段中，架构师的任务就是推动架构实施，以 保证在项目全程的设计／架构／体系的一致性。除了直接跟设计师或 设计团队沟通，以保证他们的设计在你可以控制的范围之内以外，架 构师还必须有阶段化设计的能力。这种能力用于将一个原本规模宏大 的架构设计，变成较小的、易于实施的、对开发团队来说可控的关键 点。例如在体系层次的规划上，设计可能是独立、异质的、可迁移的 存储框架来实现数据层，但在（前期的）实施上，这里可能被表达为 本地数据库，并要求前端开发人员必须通过一个清晰的数据交互层来 访问——例如一组数据存取接口，或一个独立数据服务组件。开发人 员可能在这里遇到障碍：因为要通过这些中间层来访问本地数据库， 纯粹是多余的。然而，正是这“多余的工作”提供了系统弹性，为并 行团队开发公共存储服务争取了周期，也为将来的灵活部署与数据迁 移提供了可能。 这里的关键就在于，无论原始系统设定有多大，实施时总是在 “做小”。每一个局部的实施块都是可控的，并为它在整个体系空间 中留下了位置和接口，这样才可能由“小的部分”做大。一个大系统 的架构师可能同时在考虑许多个项目中的、不同位置的架构，并且清 楚这些项目最终的总体规模。而这，就是平台架构师和体系架构师所 涉的领域。 图3 架构师模型图中的“实现能力” 架构真的是“好不好”的问题吗？如同我对工程的理解一样，架 构问题的根本，也并不在于它是否完美或漂亮，而是在于是否合用。 因此架构师必须对实施架构的团队以及实施过程有充分了解，知道他 们的能力缺陷，知道实现过程要消耗的资源，清楚每个环节可能的故 障以及先兆。只有这样，架构师才能设计一个让这个团队能实现，而 且在实现过程中能受控的架构。 要知道，你作为架构师被请来，不是画几张图纸交给项目经理， 说：你们去做吧，做不出来是你们不会做。即使你可以身体力行，在 这个团队中教大家、培养大家，那么公司的开销呢？风险呢？这些东 西难道就不考虑了？项目的周期因为实现的复杂程度而无法控制时， 项目就死掉了。那么，追根究底来说，是不是架构师的问题？是啊， 你为什么会做了一份“不合用”的架构呢？——你都不知道项目如 何开发、由谁实施、如何管理等等，又如何能面对这些实际环境去设 计架构呢？ 所以这一部分能力，是要在你的开发经验、团队经验以及用人识 人的经验中去找的。参考模型图的“实现能力”下的“设计能力?了 解你的主要沟通对象”和“架构推行”等分支，对你或有一些可用的 提示。 架构是一个从全局到局部的过程，而实施正好反过来，是从局部 到全局。这也正是“设计做大，实施做小”的另一个层面的含义。设 计大才可以见到全局，才知道此全局对彼全局的影响；实施小才可能 关注细节，才谈得上品质与控制。 事实上，大多数情况下架构是在为“当前项目之外”去考虑，这 可以看成全局关注的一个组成部分。因此我们需要界定所谓“全局” 的范围：超出公司或整个产品系列、产品线或规划的范围才是多余的。 所以当架构决策谈及“全局”时，其目标并不见得是“保障当前 项目”，而又必须由当前项目去完成。 一个经常被用到的例子是：如果仅为当前项目考虑，那么只需要 做成DLL模块；如果为产品线考虑，可能会是“管道＋插件”的结构 形式。而“管道＋插件”的形式显然比做成DLL模块更费时，这个时间成本（以及其它成本）就变成了当前项目的无谓开销。 这种全局策略对局部计划的影响是大多数公司不能忍受的，也被 很多团队所垢病。然而这却是架构师角色对体系的“近乎必然”的影 响——如果你试图在体系中引用架构师这个角色的话。一些情况下， 体系能够容纳这种影响，例如“技术架构师”试图推动某种插件框 架，而正好开发人员对这项技术感兴趣，那就顺其自然地花点工夫去 实现了。但如果不是这样，实施者或实施团队看不到“多余的部分” 对他们的价值时，来自局部的抵触就产生了。 这种情况下，平衡这些抵触就成了架构推行的实务之一。在我看 来，“平衡”是全局的艺术和局部的技术。也就是说，一方面架构师 要学会游说，另一方面也要寻求更为简洁的、成本更小的实现技术。 只有当整个体系都意识到（你所推行的）架构的重要性，而且实施成 本在他们可以接受的范围之内时，他们才会积极行动起来。 所以所谓平衡，其实也是折衷的过程。构架师只有眼中见大， 才知道哪些折衷可以做，而哪些不能。所谓设计评估（模型图中的实 现能力->设计能力->设计评估分支）并不是去分析一个设计结果好或 不好，而是从中看到原始的需求，看到体系全局的意图，然后知道在 将设计变得更为“适当”时可以做哪些折衷。同样的原因，架构师也 必须知道自己的决策会产生的影响，才能控制它们，以防它们变成团 队的灾难。有些时候，架构师甚至需要抛弃一些特性，以使得项目能 够持续下去。因为产品的阶段性产出只是整个战略中的一个环节，而 不是全部。 “怎么做一个架构师”这个问题得分成两个部分来看，一个是“做到”，一个是“做好”。由于架构师本身不过是一个技术职位， 所以时机成熟了自然会做得到。但问题是，真有一天你被放在这个位 置上了，你能做得好吗？ 我浏览过几套所谓培训机构的有关