再谈《全栈架构师》

在SDCC2016的架构师进阶之路主题,我分享了《老曹眼中的全栈架构师》话题,会后在csdn博客发布了同名文字,在我的公众号(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)资源紧张,资源紧张更多存在于创业公司,我也在一些创业公司里做过事情。比如说我们想搭一个系统出来,没钱、没资源,这个时候,很多想法要诉诸实践,一定要有全栈。
肯定还有其他的需求存在的,只是我可能没有经历过,或者是大家没有关注过而已。

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

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

全栈架构师是不是一个伪命题呢,是一个上帝类吗? 我不知道,我只是想说那篇文字,试图明确:
什么是架构?什么是架构师?
什么是全栈?什么是全栈架构师?
为什么需要全栈/架构师? 如何可能成为一个全栈架构师?

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

欢迎关注本公众号:wireless_com


微信扫一扫关注该公众号

推荐阅读更多精彩内容