骗局|架构师一定要掌握技术细节吗?
做程序员的就没有不想成为架构师的,如果有,那他一定是个有“想法”的程序员。
架构师已经是程序员中处在技术最顶尖的一群人,如果你说上面还有技术总监和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岁的魔咒!有很多技术人员就凭一个两个能力吃一辈子饭,还不愁吃穿,只要把一个能力做到极致,到达这个领域顶尖,照样是具有跨级打架的能力。
顶尖,是凤毛麟角的人物了。
从一个人的一生来考虑,不要被一份工作和一个职业局限住自己,在一个阶段做适合自己的事情才最好,每个阶段都可以不同。日子才是人生的根本所在,生命只有一次,不要让自己后悔曾经。
作者:Owen Jia

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
App后台开发运维和架构实践学习总结(5)——App产品从需求到研发到开发到上线到产品迭代全过程
前言 如果没有做过开发,研发过产品的人,很难体会做产品的艰难,刚进公司的人,一般充当的是程序开发,我这里说的是开发,它与研发是有区别的. 一个需求下来,如果不能很好地理解产品需求,如果不能很好的驾驭需求实现的逻辑,肆意的根据理解去做技术方面的架构和编码,等到后来发现了不对了再去修改就特别麻烦。 所以我们在实现产品需求时,每一个功能需求,不管是大还是小,都要想商量清楚了,我们在采取编码. 言归正转,那么整个过程一款产品从想法-开发-上线-产品都经历了哪些? 希望能给大家一个好的借鉴作用,总结的不好的,希望给予指正,大家可以畅所欲言. 主要分为以下几步 第一步:需求梳理、分析 第二步:产品原型图绘制 第三步:UI设计 第四步:项目经理&技术负责人对接需求 第五步:技术方案 & 架构设计 第六步:项目排期 & 任务分解 第七步:产品研发阶段 第八步:交付测试阶段 第九步:产品发布上线 第十步:迭代 下面我们来看看具体操作: 第一步:需求梳理、分析 在此假设用户需求分析已经确定 , 接下来根据提炼的真实用户需求来确定产品需求。 产品经理将会根...
- 下一篇
微服务架构Day21-SpringCloud之分布式配置中心
SpringCloud Config SpringCloud整合了微服务中的整体解决方案:分布式配置中心,分布式锁,分布式任务调度平台,分布式事务,分布式日志收集 产生背景:在微服务中如果使用传统的方式管理配置文件,配置文件管理器将会非常复杂;在生产环境中,配置文件改变时,需要重新配置war包,重新读取配置文件信息到JVM中 SpringCloud Config分布式配置中心: 在微服务中使用同一个服务器管理所有服务配置文件信息 在服务器运行的过程中,如果配置文件发生改变,不需要重启服务器就可以实时更改配置文件信息 Config配置文件的实时刷新不等同于热部署 热部署的底层实现其实还是重启服务器,不适合于生产环境,只适合于本地的开发测试 Config架构 当一个系统中的配置文件发生改变的时候,需要重新启动该服务,才能使配置文件生效 SpringCloud Config可以实现微服务中所有系统的配置文件的统一管理,还可以实现当配置文件发生变化时,系统会自动更新获取新的配置 分布式配置中心框架 阿波罗: 携程的分布式配置中心框架,有图形界面可以管理配置文件信息,配置文件信息存放在数据库中 ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS关闭SELinux安全模块
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7设置SWAP分区,小内存服务器的救世主
- 设置Eclipse缩进为4个空格,增强代码规范