再谈<全栈架构师> 一文

在SDCC2016的架构师进阶之路主题，我分享了《老曹眼中的全栈架构师》话题，会后在csdn博客（http://blog.csdn.net/wireless_com）发布了同名文字，在我的公众号（wireless_com）发了《全栈的技术栈设想》。然后，有幸得到了中生代技术（freshmanTechnology）和多人的转载，中生代技术还专门开通了全栈架构师深度讨论群,引起了很多的争论和争议。

主要分为以下三种观点：

1）根本没有意义，纯属忽悠

如网友回复：“鬼都知道说的什么 数据 缓存 业务 性能 消息队列 操作系统 产品 云存储 大数据这些高大上的名次，天天聊天就讨论这些高大上的名称， 然而并没有什么卵用。”

2）有可能，但参考意义不大

有网友回复：“个人觉得不值得推崇，很多程序员为了全栈，东一榔头西一棒子，结果啥都没搞好”

3）表示赞同，具体实践待推敲

如网友@张真Alex 的说法：“比较认同全栈架构师，从前ibm把架构师分为六大类，是六脉神剑各使一剑，而如今，不管是工程师还是架构师都应该有全栈的思维（不一定全栈的技能），特别是架构师的职能，需要从业务，技术体系，端到端都具备相当的战斗力才行”

如此多的争议并不意外，事情越辩越明，在此分享一下那篇文字的初衷和自己的重新思考。本着科学的态度，讨论的前提应该是对问题明确，基本概念的定义是一致的，对不同逻辑推理得到的结果进行讨论。针对全栈架构师这一命题，个人觉得先要明确几个概念。

什么是架构？什么是架构师？

架构的定义业界一般有三种方法，一个定义为决策过程，一个定义为体系结构，还有就是两者兼而有之。 Simon Brown 在《software architect for Developers》一书中尝试给出了架构一词作为名词和动词的定义，并尝试给出了架构的分类。好友@温昱在《一线架构师实践指南中》尝试给出了软件架构的方法论ADMEMS即所谓的5视图方法。然而，Len Bass 在《软件架构实践（第2版）》中谈到“软件架构在不断发展，但它仍然是一个尚不成熟的学科”。

历史是任人打扮的小姑娘，类似的， 每个人对架构和架构师都有着不同的理解。蚂蚁金服@右军（公众号：流浪部署我的初衷）有一篇文章《谈架构》有着自己对架构的看法： ''' 架构是一种思维模式。架构师是一个title。为什么说架构是一种思维模式呢，小到一个模块，大到一个平台，都是一样样的。 软件架构的作用包括:

• 软件架构能够满足系统的品质
• 架构设计使受益人达成一致的目标
• 架构设计能够支持计划编制过程
• 架构设计对系统开发的指导性
• 架构设计能够有效地管理复杂性
• 架构设计为复用奠定了基础
• 架构设计能够降低维护费用
• 架构设计能够支持冲突分析

...

'''

其中有很多有价值的观点，感兴趣可以参考这篇文章。

在前当当架构部总监@史海峰看来，架构师首先是一个工程师，就如同在一些传统行业里，有总工程师、总设计师的说法。他把架构师的定义总结为七句话：

NO.1 以工程思维全面理解业务需求

NO.2 基于模型和基础模式抽象简化

NO.3 提出恰当可行的整体解决方案

NO.4 在限定资源范围完成明确目标

NO.5 满足业务需求且保证系统质量

NO.6 在可预见的周期内具备扩展性

NO.7 并在系统生命周期内持续演进

在@史海峰看来，不同架构师擅长的技术领域或有不同，但大家有共通的拿手绝活，那就是“快速切入、解构拆分系统模块和代码、有技术话语权”。这些绝活并非一蹴而就，而是架构师们日常工作中，不断地去发现问题、思考解决、设计取舍、重构迭代、协作传道、响应支持，持续学习进步达成的。并非所有公司都需要招架构师，只有当系统复杂达到某个程度，几个高级工程师一起难以很快说清楚的时候，就需要架构师加入了。架构师有两忌两宜。两忌分别是不应过于追求高大上，否则可能会和现有团队脱节，难以落地；技术上不应过于求全面，以能解决当前问题为主。两宜则是团队协助沟通能力要好和适应性强。

对于架构师，不同公司有不同的定义和解读，我觉得我们是幸运的，因为我们在实践着一种动态且没有成熟的技术，可能创造着一个新的团队角色甚至工种。

什么是全栈工程师？什么是全栈架构师？

对于全栈工程师，引用一个不权威的说法，百度百科中对全栈的描述是这样的：

全栈工程师，也叫全端工程师(同时具备前端和后台能力)，英文Full Stack developer。是指掌握多种技能，并能利用多种技能独立完成产品的人。

根据自己的经验体会，全栈工程师在很多时候， 是为了梦想的苦命码农的无奈选择。其实，大公司也需要全栈的。我最早了解这个词，是从一个facebook那里的朋友知道的。

全栈，不是全能，和所选择的技术栈甚至业务栈相关。例如以LNMP（Linux ＋ Nignx ＋ MySQl＋ PHP），那么掌握了这四种技能，算不算一个全栈工程师呢？个人觉得可以的。但是随着技术栈的变化，例如引入了缓存Memcache乃至其他分布式缓存，那原来的全栈工程师还是全栈么？全栈是否要随之变化呢？

随着业务和技术栈选择的动态性变化，能否在团队中有一角色能够相对系统地对架构有个动态的设计，使我想到了“全栈架构师”这个词，这就是我引入全栈架构师的一个原因。同架构师和全栈一样，全栈架构师更不好定义，甚至可能错误地导致全栈就是全能的说法。

网友@张真Alex 认为全栈架构师最好是T型人才。

一竖的部分包括：

• 专业知识（应用，系统，安全，运维等），
• 战略分解（抽象，分类，算法），
• 调研选型（目标识别，快速学习，调查方法，可行研究）
• hands on（精通1-2语言，大量代码实践，设计方法等）

一横的部分包括：

• leadership（号召力，决断力，mentorship）
• 项目管理（项目计划，风险控制，取舍权衡）
• 领域知识（行业知识，行业生态）
• 创新思维（应用创新，跨界思维）
• 突破能力（经验沉淀，觉一反三）
• 沟通协调（主动沟通，灵活协调）

这一横一竖才构成了架构师（技术专家）的能力图谱，他认为可算全栈架构师。

我觉得这是非常有益的探讨，很遗憾，我还没有能力给出全栈架构师的完整而又清晰的定义，边界也不好界定，但是，我觉得我们都在探索的路上。

为什么需要全栈架构师？

大家普遍认为，团队需要深入业务，理解业务的发展，搭建核心架构，理清技术架构的细节和门槛，实现架构的迭代资源，扫清技术疑点和难点的人；需要把握好非功能需求的6种类型(功能性、可靠性、易用性、效率、维护性、可移植性)的人；....

那么，全栈架构师能够满足我们的哪些需求呢？我在《老曹眼中的全栈架构师》中谈到了4个自己认为的典型场景：

1） 性能瓶颈，业务系统是很复杂的，不管是什么量级的业务系统，当出现性能瓶颈的时候可能一个人解决不了，如果你能够贯穿所有被使用的技术栈，就能相对很容易地知道哪一点出现了问题。

2）沟通，前后端工程师，尤其是、各个跨语言前后端工程师之间的沟通是存在障碍的，全栈能够做好沟通的桥梁。

3）救火，比如突然间夜里给你一个短信告诉你系统出问题，你可能当时找不到那个开发此模块的工程师，怎么办？系统还能不能运行？业务会不会崩溃？如果崩溃，公司会遭受什么损失？这个时候就需要有全栈，他能够在要在第一时间解决系统中的问题。

4）资源紧张，资源紧张更多存在于创业公司，我也在一些创业公司里做过事情。比如说我们想搭一个系统出来，没钱、没资源，这个时候，很多想法要诉诸实践，一定要有全栈。

肯定还有其他的需求存在的，只是我可能没有经历过，或者是大家没有关注过而已。

如果对全栈架构师的需求是存在，那么，如何才有可能成为一名全栈架构师呢？我试图从技术栈，性能栈，和效率栈三个方面进行了探讨，在《老曹眼中的全栈架构师》中有所描述，这里不再赘述。

我说过全栈架构师可能是自己的杜撰， 但是，全栈思维优先还是被大多数朋友认可的，实际上是一种大局观，一个功能既可以前端又可以后端实现，利弊和方案的选择是需要有全栈架构师的，至少要有全栈的思维。全栈的思维，简单地可以理解成系统的思维方式。

全栈架构师是不是一个伪命题呢，是一个上帝类吗？ 我不知道，我只是想说那篇文字，试图明确：

什么是架构？什么是架构师？

什么是全栈？什么是全栈架构师？

为什么需要全栈／架构师？ 如何可能成为一个全栈架构师？

如果问题分为：已知的已知，已知的未知，未知的未知 的话，即便是将全栈架构师这一角色，从未知的未知变成已知的未知，我想也是一件好事情，能力所限，随笔如上。