另一方面，架构师的组织职责除了技术主管承担的之外，架构师还承担着在技术团队和非技术团队（例如：产品设计等团队）之间的接口作用，明确产品的边界，勾勒技术蓝图，协调不同技能的技术团队协作，完成最终的软件系统交付。这时架构师的角色就像服务化架构中的 API，定义了协作规范、交互协议和方式，但并不会聚焦在具体的实现上。

在更大规模的系统上，架构师似乎还要去涉猎更多的跨领域知识，否则很可能无法做出最适合的技术决策。但人终究是有局限的，你不可能学完所有领域，所以特定的领域又会涌现一些垂直领域的架构师。比如：数据架构师、网络架构师、业务架构师、安全架构师。因而某一个领域背景出身的架构师，他对其他领域也只能做个初步了解，当需要作出关于涉及其他领域的架构决策时，他就需要和其他领域的垂直架构师做深度的沟通交流，以辅助决策判断。

最后，我们还是总结下架构师的职责要求：

从一开始，我就提到技术主管和架构师是程序员自然成长路上的两条支路，始终停留在上面「出色程序员」能力模型域的程序员是无法很好的胜任技术主管和架构师这两个角色的。所以程序员在成长到一定阶段就需要去考虑是否真要往技术主管和架构师的方向发展。而从技术主管走到架构师相对而言更有延续性，但技术主管也会有另一条路，就是转型走上纯管理岗位，成为一名真正意义上的经理。

一旦选择走入架构师这条路，基本你就从一名出色的程序员这个领域走出，需要尽快去补充上面能力模型中指出的其他能力。这一点会让刚刚走上这条路的程序员很不适应，因为承担了更多其他职责，就必然要减少在编码实现的时间，慢慢就会怀疑自己的编码能力会退化，也跟不上一线最新的技术栈，各种酷酷的新工具。我曾有一段时间就产生过这样的茫然与惶恐，如今算是释然了。

舍得，舍得，没有舍就没有得。成为架构师会拥有一个更立体的知识、技能矩阵，这是你的得。获得了一个面，在某些点上必然面临被超越的结局。如果成为一名架构师好几年后，你居然还是团队里面编码最多，编程能力最强的人，其实这是一个失败的架构师，在教练和指导这个职责上已经完全的失败了。而有些谈论架构师的文章说：

架构师一定要负责整个系统中最核心和最难的地方的代码编写，如果一个团队里需要一个架构师，那他一定必须是团队里写代码能力最好的，而且要负责至少 40% 以上的核心开发工作。

上面的说法就是扯淡，这样的架构师就是这个团队最大的瓶颈。一个稍具规模的软件系统和团队中，承担 40% 以上的核心开发工作，基本上这样的架构师就是一个资深程序员，而架构师的其他职责我估计他都没时间和能力去考虑了。他会意识到这种方式无法持久，同时也夺走了其他开发者的创新能力和解决问题的乐趣，一个有经验的架构师能够更好地表达某些指导原则，并且了解什么时候该插手，什么时候该放手。

而架构师到底要不要编码，承担多少的编码工作，不是由某种定义和说法决定的。而是由架构师自己决定的，因为架构师承担了软件系统的最终交付和过程风险识别，如果架构师认为某些关键部分，团队里没有其他人能在交付日期前写出达到他认可的足够可靠的代码，他把这识别为一种风险，决定自己完成，那么他就去编码实现，否则就委托给他认为足够可靠的团队成员，这就是前面提到的「借助他人使之实现」的能力和自信。

当团队里的程序员都逐渐获得成长，成了高级或资深程序员之后，架构师实际还需要写代码的机会越来越少。这方面的能力必然面临退化，所以这方面对一线技术栈的决策会越来越交给一线资深程序员来判断。但我们担心时代、环境变化，有一天又需要回到一线技术栈时，那时技术栈已经发生了巨大变化，架构师还能很好的适应么。技术的理解和基础如内功，而重新学通一门技术栈如招数，我觉得也未必需要多少时间，数月、半年或一年也许又让你恢复到在新技术栈上感觉良好的编程状态。

...

有时候安安静静的做个程序员，也挺好的。

写点文字，画点画儿。
微信公众号「瞬息之间」，遇见了不妨就关注看看。

posted @