优秀架构师必备素质.pdf

合格架构师必备素质 究竟是什么让你在同一个位置上——例如程序员或技术负责人——工作了三 年、五年或者更久，而仍然得不到任何的发展空间？你 觉得自己已成为技术圈中的大牛，并信心满满地去拿明天就要颁发的 某某大奖，然而却仍然停留在同样的技术职位上，去年到今年涨的薪 水甚至填不平物价升幅？于是，你开始对老板不满，对员工不满，对 昨天升职的那个同事不满„„你开始计划明天就要跑单，或者准备考 虑提出加薪却又心怀忐忑。 如果技术人员有发展的轨迹，那么他要么 “看透工具的本质，把关注点转移到 ‘团队’的圈子里去”，要么 “顺着代码铺就的道路， 亦步亦趋地成为良匠大师”。仅以技术方向而言，你大概可以做到架 构师、总架构师甚至首席架构师；但问题是：你现在还只是一个程序 员。那要如何才能踏上通往架构师之路呢？本文为你解析一个架构师 的能力模型。 架构师不是界定一个技术高下的职位名称，而是一个职务。所谓 职务，包括职——职位，务——工作。前者决定了你具备哪些资源， 可以影响到怎样的范围，以及面向的机构，后者则简单地是你需要完 成的工作列表。 所以我说 “架构师”不是指 “一个能做架构的人”。前者是把架 构师当职能，后者是当工人。能做一份工作列表中的事，并不等于就 成为相应职位上的人。在管理体系里面，你的个人特性决定了你在哪 个位置，而技术技能只是做事实施的必需。架构师这个职务，同时要 求较高的个人素质和技术能力，因此它的进取之路总结起来就是：做 人、做事，做架构师。因此 “模型”由“个人特性”和 “技术技能” 两个方面构成，在第一张图中，我特别说明 “个人特性”既包括人际 关系的能力，也包括 （具体）业务能力； “技术技能”也是如此。所 以个人特性主要与 “做人”有关，部分地也包含 “做事”的要素。 图1 架构师能力模型 “有效沟通”以及 “学会谈判”与做具体的事无关，是个人能力 特性的公共方面。前者是过程，后者是知道如何定目标与求结果。而 “风险与防备”是做事过程控制的关键，与前面两项正好构成了一个 做事基本能力的完整体系。基本上，这三项个人特性都是一个 “普通 程序员”所不具备的，甚至在大多数情况下，普通程序员并不愿意去 具备这样的个人特性，因为在许多陷于技术泥淖的开发人员看来：沟 通总是会使事情变得更加麻烦，谈判则徒耗时间而无济于事。然而事 实上，在整个的架构决策过程中，架构师需要不停地沟通与谈判。将 “架构”变成 “决策”的过程，其实就是对各个技术角色 （及其思想） 兼容并包的过程，你需要不断地协调需求、实现之间的各种问题，也 需要面对各种投资者 （时间、资金、人才等方面的决策者）进行谈判， 以确定项目的规模——没有规模也就没有范围，没有范围如何展开设 计呢？ 一部分开发人员会认为上述过程是 “项目经理”的事情，但真的 如此吗？当你作为一个更高级别的架构师，以至于要影响到多个项目 的决策时，你就全然不会有这种感受了。因为这种情况下，你的决策 将先于项目的启动，或者说你已经不单单是一个技术角色了。 设计是架构能力的一部分，但架构师不是设计师——看清楚二者 之间的不同，你才真正迈出了架构师职业生涯的第一步。 个人特性中另一个非常重要的方面是 “抽象思维”，而这是与架 构师角色直接相关的一种能力。这种能力既有职业技能特征，又是普 遍性的能力。 所谓普遍性的能力，是指 “抽象”在我们——作为人这种个体的 ——生活中无处不在。例如我们说花、草，说桌、椅„„我们用语言 去指称任何一个既已存在的 （可以脱离我们的语言而自然存在的）事 物时，就用到了抽象。说 “桌子”的时候，既没有描述桌子的具体形 式，也没有说明它的规格，但我们用这个名词时，所有人都知道 “桌 子是什么”。所以，名词概念是整个抽象逻辑系统中的主体。如果失 去了这些名词定义，我们基本上不能说话，也不能描述任何东西—— 那便到了 “只可意会不可言传”的境地。 用现有的成熟语汇去描述你的系统时，大多数人会理解你所表达 的含义，例如我们说 “这个系统设计为一个三层结构”。然而架构师 面临的系统在许多细节上并不见得能够用成熟的语汇去描述，因此必 须自已构建一个抽象系统，这就需要概念抽象能力、概念表达能力和 基于概念的逻辑表达能力。 概念抽象能力是一种思维能力。简单地说，就是 “把目标分解或 概括清楚”：你要么概而言之 “它是什么”，要么详细地说明 “它包 括什么”。必须使用大量的语汇来陈述