再谈一文

  1. 云栖社区>
  2. 博客>
  3. 正文

再谈一文

abel_cao 2016-12-11 16:04:37 浏览470
展开阅读全文
版权声明:本文为半吊子子全栈工匠(wireless_com,同公众号)原创文章,未经允许不得转载。 https://blog.csdn.net/wireless_com/article/details/53573519

        在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)资源紧张,资源紧张更多存在于创业公司,我也在一些创业公司里做过事情。比如说我们想搭一个系统出来,没钱、没资源,这个时候,很多想法要诉诸实践,一定要有全栈。

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

        

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

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

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

什么是架构?什么是架构师?

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

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


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


微信扫一扫
关注该公众号

网友评论

登录后评论
0/500
评论
abel_cao
+ 关注