网络文章

从“菜鸟”码农到“资深”架构师,我到底经历了什么?

工作了挺久,发现有个挺有意思的现象,从程序员、高级程序员,到现在挂着架构师、专家之类的头衔,伴随着技术和能力的提高,想不明白的事情反而越来越多了。

 

工作了挺久,发现有个挺有意思的现象,从程序员、高级程序员,到现在挂着架构师、专家之类的头衔,伴随着技术和能力的提高,想不明白的事情反而越来越多了。

这些疑问有些来自于跟小伙伴的交流,有些是我的自问自答,有些到现在也想不清楚,这篇文章就来写一写这些问题。

如何更高效的学习?

很多新人程序员一开始在学习上找不到方向,但我想在渡过了一段时间的新手期之后,这类问题大多都会变得不再那么明显,工作的方向也会逐渐变得清晰起来。

但是没过多久,能了解到的资料就开始超过每天学习的能力,像是买了没看的书、收藏没读的贴、Mark 了之后再也没有关注过的文章越积越多,更别提每天面对各种技术分享或者微博里的新鲜玩意了。

大多数人每天能留给自己学习的时间有限,这个阶段如何提升学习效率就成了要解决的重点。

说说自己提升学习效率的心得,非常简单:体系化的学习。

我曾经很喜欢看一些博客或者是一些“看起来”比较通俗易懂的文章,每天在微博微信里刷到什么技术文章就 Mark 下来,基本上几分钟就能读完。

可一段时间下来,虽然读了不少东西,但是还是有种在原地打转的状态,并没有感受到有什么实际的提高。

最后实在忍不住,抱着厚书硬啃了一遍,突然有种豁然开朗的感觉:读书时自己学到的是一张完整的知识网络,每个知识点和其它内容相互联系和区别。这种全方位的理解比起一篇篇独立的文章,不知要高到哪里去了。

而读了一段时间书之后,渐渐原本不在一个体系之内的知识也会慢慢联系起来,比如说后端服务的开发,简单梳理一下,就成了这样:

在重复了几次痛苦的学习-梳理过程后,再去看一些独立的文章或者资料往往会事半功倍,因为能在体系内找到相对应的知识,甚至有时候一本书里一页只需要看一句话,点破那层窗户纸,就可以掌握新的知识。

你是怎么知道这些的?

工作中总是会遇到各种各样的问题,有几次把问题处理过程总结了一下,发了出来,之后就像滚雪球一样,有越来越多的小伙伴来咨询问题。

比如说:前一阵帮忙排查一个性能问题,系统压力稍微一大就会频繁 FullGC,压力降低之后又恢复了。

某个小伙伴接入代码质量检查系统之后发现每次构建会报一个莫名其妙的错误,打不了包。

某次代码有 Bug,小伙伴跑来来问我 git 怎么才能回滚代码。

每次查完这种问题的时候,一些刚毕业没多久小伙伴们就会用一种崇拜的眼神看着我,然后大多会问:“你是怎么知道这些的?”

实际上,虽然我一直在不断的学习,但是面对工作中无穷无尽的新问题,大部分问题还是会命中我没有掌握的那部分区域。每次有人问到我不了解的知识时我都会非常开心:还有什么比带着问题学习更有效率的学习方法呢?

而且幸运的是,在建立了自己的知识体系的基础上,学习新的知识通常都能很快的上手,解决一个问题往往只需要多了解一个知识点而已。

举个例子,频繁 FullGC 的问题,以前查过很多次 GC 的问题,大多数是 Java 程序或 JVM 内存泄露问题,而这次内存没有泄露,GC 吞吐量也正常,那么我只需要查一下如何查看一段时间内创建的最多的对象的方法就可以了。

回到刚才的问题,小伙伴们问我:“你是怎么学到这些的知识的?”

答案是:在你问我问题之后现学的。

架构师应不应该写代码?

似乎隔三差五就能看到一些关于架构师应不应该写代码的文章。我是属于写代码派,因为我本身就喜欢写代码。

但是,当工作职责发生变化之后,如何保持写代码和其它工作之间的平衡就成了问题。

从个体效率上来看,我自己亲自写代码,和很多人相比没有什么绝对优势,甚至有些人码代码的速度比我还快一些。

但作为架构师,参与写代码还是会有一些不大不小的收益。一般来说合格的程序员对于明确分配的任务会完成的很好,但是大部分情况下“架构”这个词意味着架构师并不会涉及太多细节。

架构图和代码实现之间总还是有些距离,你无法保证所有人都会正确的理解你的设计,或者是程序员写代码时遇到障碍时会立刻想出足够优雅的解决方案。

原创不易,完成人机校验,阅读全文

相关推荐