架构师一定要掌握技术细节吗?

Owen Jia 2021年03月16日 73次浏览

做程序员的就没有不想成为架构师的,如果有,那他一定是个有“想法”的程序员。

架构师已经是程序员中处在技术最顶尖的一群人,如果你说上面还有技术总监和CTO呢,那只能说你层次还太低了没看明白。

程序员的职业发展

程序员发展线路图(这线路中任何时候转管理都行):

  • CTO
  • 总监
  • 架构级
    • 专家级
      • 高级
        • 中级
            • 初级
public class Test {
  public static void main(String[] args){
    System.out.println("架构级程序员,统称为‘架构师’。");
  }
}

总监和CTO已经走向了管理和业务,脱离技术一线。如果发现你们公司总监或CTO还在写Code,那说明你们公司有点小,真的很小,有可能都算不上个公司。

首先,架构师一定是“掌握过”技术的。

这里的“掌握过”要理解一下,架构以下的程序员都是在一条赛道上跑,熟悉业务再深入技术底层。

比如一个刚毕业的IT,从事java开发,一开始就会个java语法,略微会个spring,这叫初级程序员。等他工作个1年,发现能在一个搭建好的project框架下熟练开发业务,不需要太多帮助了,这叫中级程序员了。在过个3年左右,在常规的业务code下已经不满足了,开始搞框架并能自己搭建和维护,新业务启动能copy个框架过来直接开始写业务,这个时候已经是高级程序员了。再有个3年左右,部分程序员已经不甘心写业务code了,开始专门搞框架维护,研究底层源码,还自己写个把框架,能提升各种性能瓶颈,这个时候已经专家程序员了。

有一天专家程序员突然对整个业务系统感兴趣,想设计一个完整的系统,从页面+后台+数据,还有包括人员资源,都整合起来把系统落地建设完成。这个时候这个专家发现自己的知识太过细分了,还有很多不会,如web开发,app开发,h5开发,数据库维护,项目管理,人员组建,人员管理等,这些能力都需要才能搞定一个完整的系统建设。

这个时候这个专家开始拼命的学,这个时候“学习能力”才是根本,因为学的东西太多太多,跨过去专家就成了架构程序员了。

其次,架构师不一定要“掌握”技术的。

凡是到达架构级别的程序员,有几个特征:超强学习能力、优秀的表达能力、丰富的技术广度、足够的技术深度、一定的领导能力、很好的组织协调力。

所以“技术”不是架构级程序员唯一的指标,只是他能力中的不可或缺一部分。往往越到后期,技术之外的能力越来越重要,是往后发展必须的条件。

但,架构师还是一位技术一线的程序员,往往有救火队员形象,又有点像个打杂的,他们穿插在各种级别程序员之中,也穿插在各种人员当中,如产品、运维、研发、市场、运营、PM、总监、还有其他等等人。

对于架构师的考察,很多面试官都搞成了考察“专家或者高级”程序员,去测试一下框架底层原理掌握的怎么样了,某个生命周期讲讲。这些是一个专家级程序员必须熟练掌握,并且随时能拿出来侃侃而谈的,但不是架构师的主要考察指标。

随着架构师的成长,“技术深度”会慢慢地遗忘丢失,不可避免。

从“初级、中级、高级”乃至“专家”成长起来,都只有一个核心指标“技术深度”,面试时只关注这个是没问题的。这个级别一般只在程序员圈子里沟通,外加些产品、测试,但还统一在“产研”中,是他们天天都会接触的。

架构师跨出了这个圈子,来到了更大的天地。

就好比小说修真世界,每一次突破都会发现更大的世界,同时也发现自己技能又不够用了,又开始低调做人练怪升级,只有到达这个世界圈最强时候(飞升前)才能横着走。

最后,生活最大

不做架构师,不是就做不好程序员的。

在职业发展中,有一个十分关键的因素就是“时间”,不管你是什么职业都跑不过它,时间表现在你的年龄上。程序员有个35岁的魔咒!有很多技术人员就凭一个两个能力吃一辈子饭,还不愁吃穿,只要把一个能力做到极致,到达这个领域顶尖,照样是具有跨级打架的能力。

顶尖,是凤毛麟角的人物了。

从一个人的一生来考虑,不要被一份工作和一个职业局限住自己,在一个阶段做适合自己的事情才最好,每个阶段都可以不同。日子才是人生的根本所在,生命只有一次,不要让自己后悔曾经。