每位开发人员都应该成为架构师

架构师开发人员| 2016-02-03

要想交付最出色的成果，每位开发人员都应当身兼架构师与问题解决者这两大角色。

有时候我的脑袋里会突然出现像“微决议”这样的念头。基本上，微决议所要探讨的是我应该开始做，但在重要性方面还达不到人生高度的事物。

而在审视过程当中，我发现了一位读者朋友提出的问题。

您提到您自己实际并不喜欢“架构师”这样的头衔。我对此表示赞同，因为架构师这样的词汇在不同企业当中有着不同的意义。

根据我的个人经历，架构师可能需要编写代码、设计 UML 图表或者单纯只是撰写 Word 文档。

您难道不觉得开发人员本身就应该是一位身兼架构师与问题解决者两类角色的程序员吗？

就我的职业生活来讲，我担任过这里提到的全部工作岗位，因此我的观点可能在一定程度上存在偏差。不过换个角度来看，我们不妨将问题整理成另外的形式，即“是不是每位开发人员都应当拥有架构师头衔”或者说“是不是每位架构师都应该承担开发者职能”？

在对问题做出这样的简化之后，我给出的答案是肯定的。

是的，每位开发人员都应当是一位身兼架构师与问题解决者两类角色的程序员。另外，每一位开发人员都应当冠有架构师头衔。是的，每位开发人员都应当身负“架构师”职责。说到这里，我不禁想对架构师与开发人员之间的差异进行探讨。

下面来看程序员/软件工程师与架构师之间的区别所在：

关注范围：程序员专注于具体细节，而架构师专注于“宏观视角”。
领导关系：程序员处于被领导地位，架构师则扮演领导角色。
资历背景：架构师的从业时间一般比程序员更长。
气质特性：架构师是重要的梦想家，而程序员则是面向繁琐任务的实干者。
技术取向：架构师做出选择，而程序员提供选项。
技能：架构师的技能水平高于程序员。
代码：架构师需要编写之代码平均少于开发人员。
组织互动：架构师所参与之“业务”会议数量远多于程序员。
薪酬：架构师薪酬水平高于程序员。
自身价值：架构师的价值要高于程序员。

这些就是整个行业对于两者之间区别的看待方式。架构师从业经历更丰富、重要性更高、技术价值更为可观，因此拥有更迫切的市场需求; 而正因为他们太过关键，因此主要精力往往被用于其它事务——而非编写代码——身上。这显然是种混乱的定义方式，甚至自相矛盾，而角色的内在定位模糊性也让我们很难通过一刀切方式作为其评判标准。也正因为如此，某些企业中的架构师会负责构建 UML 图表，而另一些架构师则干着跟开发人员完全一样的工作。

问题在于，我们往往倾向于用一种笼统的定义来概括实际上极为复杂的概念，而对细微差异的关注缺失则导致定义与实质间存在巨大错位。

事实上，我们的生活稳步前行，每个人都经历过年轻、缺乏经验的起步阶段，并随着时间的推移而逐渐提高、成熟且最终获得源自努力的回报。我们的工作环境认可这种逐步完善的趋势，并立足于唯才是举的制度奖励这种成长。在这条道路上，我们会慢慢迎来属于自己的“资深”以及“首席”等花环，而领导能力则体现为“架构师”、“经理”以及“主管”等头衔当中。头衔等级越高，我们身上肩负的职责与期许就越是重要。另外，在这一推进过程中，我们会不可避免地在领导及业务层面步步上升，并由原本“注重细节”及“勤奋”的青年转型为“着眼于宏观”且“有远见”的管理者。到这时，我们已经不再执行具体的任务，而更多成为“思维领袖”。

在这样的背景之下，“架构师”角色以及“架构师”头衔都有着确切的意义。二者皆是对大家任务执行效果的一种表彰，意味着各位已经成长为较原先更重要、更有价值且更出色的职能角色。这也意味着我们接下来要从事的是不同于以往的工作内容、扮演不同于以往的角色并承担不同于以往的责任。

但如果我们暂时抛开这些价值判断，那么这两种角色之间还有哪些其它差别？

我们可以将这种差异进一步加以具象化，那么此类差异往往广泛存在于各行业及学科当中。一类角色负责制定决策，即着眼于“宏观”而较少“亲自上阵”，而另一类角色则执行更具针对性的任务，负责“亲手”解决问题。说到这里，我们可以将其比作律师事务所中的工作。事务所合伙人负责案件中的重要决策，而其它更具体、更简单的任务则由助理完成。

但需要强调的是，炙手可热的合伙人与看似平凡的助理所负责的工作在本质上并无区别——他们都只是整套业务体系中的运行点之一，负责完成被委以的任务。考虑到这一点，我们可以将同样的道理引入到编程世界当中：经验丰富的开发人员负责制定技术决策（并建立以其为核心的实现体系），编写难度最高以及/或者最为关键的代码片段，同时运营团队并为新晋开发人员们分配他们力所能及的任务。

响应文章开头，每一位开发人员都应当在一定程度成为架构师，或者说每位开发人员都应当同时着眼于软件的宏观定位与具体细节。有些开发者技能水平更高及经验更为丰富（自然也拥有更理想的薪酬待遇），而他们同时也了解应当如何制定技术层面的重要决策并将任务分配给谁来完成。不过从根本角度讲，其角色定义与普通开发人员并无区别——只是其信任层级更高，或者说达到了每位开发者都应达到的信任水平。

如果我构建一支队伍以构建软件解决方案，那么绝对不会刻意寻求两种截然不同的成员：一部分专门作为思维领袖执行广义规划与技术决策，而另一部分负责日常任务与细节工作。最理想的场景是团队里的每位成员都知道该如何解决问题，并通过这两种有所区别的立场与眼光审视问题的定义与细节走向。从另一个角度讲，同时拥有这两种审视能力的开发人员也必将成为企业中的 IT 摇滚巨星。

本文文字及图片出自博客园