从菜鸟到Java架构师你还差多少距离
发布日期：2019-09-09 15:36:22点击次数：次
工作了挺久，发现有个挺有意思的现象，从程序员、高级程序员，到现在挂着架构师、专家之类的头衔，伴随着技术和能力的提高，想不明白的事情反而越来越多了。
这些疑问有些来自于跟小伙伴的交流，有些是我的自问自答，有些到现在也想不清楚，这篇文章就来写一写这些问题。
如何更高效的学习？
很多新人程序员一开始在学习上找不到方向，但我想在渡过了一段时间的新手期之后，这类问题大多都会变得不再那么明显，工作的方向也会逐渐变得清晰起来。
但是没过多久，能了解到的资料就开始超过每天学习的能力，像是买了没看的书、收藏没读的贴、Mark了之后再也没有关注过的文章越积越多，更别提每天面对各种技术分享或者微博里的新鲜玩意了
大多数人每天能留给自己学习的时间有限，这个阶段如何提升学习效率就成了要解决的重点。
说说自己提升学习效率的心得，非常简单：体系化的学习。
我曾经很喜欢看一些博客或者是一些“看起来”比较通俗易懂的文章，每天在微博微信里刷到什么技术文章就Mark下来，基本上几分钟就能读完。
可一段时间下来，虽然读了不少东西，但是还是有种在原地打转的状态，并没有感受到有什么实际的提高。
最后实在忍不住，抱着厚书硬啃了一遍，突然有种豁然开朗的感觉：读书时自己学到的是一张完整的知识网络，每个知识点和其它内容相互联系和区别。这种全方位的理解比起一篇篇独立的文章，不知要高到哪里去了。
而读了一段时间书之后，渐渐原本不在一个体系之内的知识也会慢慢联系起来，比如说后端服务的开发，简单梳理一下，就成了这样：
你是怎么知道这些的？
工作中总是会遇到各种各样的问题，有几次把问题处理过程总结了一下，发了出来，之后就像滚雪球一样，有越来越多的小伙伴来咨询问题。
比如说：前一阵帮忙排查一个性能问题，系统压力稍微一大就会频繁FullGC，压力降低之后又恢复了。
某个小伙伴接入代码质量检查系统之后发现每次构建会报一个莫名其妙的错误，打不了包。
某次代码有Bug，小伙伴跑来来问我git怎么才能回滚代码。
每次查完这种问题的时候，一些刚毕业没多久小伙伴们就会用一种崇拜的眼神看着我，然后大多会问：“你是怎么知道这些的?”
实际上，虽然我一直在不断的学习，但是面对工作中无穷无尽的新问题，大部分问题还是会命中我没有掌握的那部分区域。每次有人问到我不了解的知识时我都会非常开心：还有什么比带着问题学习更有效率的学习方法呢?
而且幸运的是，在建立了自己的知识体系的基础上，学习新的知识通常都能很快的上手，解决一个问题往往只需要多了解一个知识点而已。
举个例子，频繁FullGC的问题，以前查过很多次GC的问题，大多数是Java程序或JVM内存泄露问题，而这次内存没有泄露，GC吞吐量也正常，那么我只需要查一下如何查看一段时间内创建的最多的对象的方法就可以了。
回到刚才的问题，小伙伴们问我：“你是怎么学到这些的知识的?”
答案是：在你问我问题之后现学的。
似乎隔三差五就能看到一些关于架构师应不应该写代码的文章。我是属于写代码派，因为我本身就喜欢写代码。
但是，当工作职责发生变化之后，如何保持写代码和其它工作之间的平衡就成了问题。
从个体效率上来看，我自己亲自写代码，和很多人相比没有什么绝对优势，甚至有些人码代码的速度比我还快一些。
但作为架构师，参与写代码还是会有一些不大不小的收益。一般来说合格的程序员对于明确分配的任务会完成的很好，但是大部分情况下“架构”这个词意味着架构师并不会涉及太多细节。
架构图和代码实现之间总还是有些距离，你无法保证所有人都会正确的理解你的设计，或者是程序员写代码时遇到障碍时会立刻想出足够优雅的解决方案。
之前写过一篇关于烂代码的文章，大部分烂代码并不是架构师的设计问题，如果程序员没能很好的理解设计或者是经验不足，往往会做出一些非常匪夷所思的东西。
比如我见过刚毕业的程序员为了防止模块耦合而将耦合的代码又拷贝了一份，或者为了“优化性能”而尽量把所有逻辑写在一个函数里。
如果不能及时发现并改正这些问题，那么这些地方就会变成“正确的错误代码”，或者“不是我写的”代码，或者“我靠我也看过那段代码”之类足以被挂上耻辱柱的玩意。
这种问题算是架构师的责任吗？作为一个视名声如命的架构师，我认为是的。
在我看来，写代码的架构师更像是在做后勤保障的工作：在代码中第一时间发现可能存在的问题，向其他人提出警告；或是给予其他人改进的意见，必要的时候给其他人演示一下正确的姿势。
大部分情况下我作为架构师并不需要揽下“核心模块”开发这种工作，毕竟我能调配的时间太零散了，效率难以保证，很多人在专注的情况下比我做的好很多，我只需要保持大局观，需要时适度参与就可以了。
总的来说，架构师和程序员在某些方面上有点像产品经理和用户的关系，大部分程序员并不会主动告诉你他们想要什么、哪里需要优化，甚至自己也不知道这些。想要做出好的产品，捷径之一就是跟用户做同样的事情。
成为架构师最困难的门槛是什么？
跟一些程序员交流的过程中，有不少人问我要怎么成为一名牛逼的架构师。
我最近几年面试的人挺多，发现一个有意思的现象：很多自称架构师的人跟你讲一个架构时简直滔滔不绝，各种技术名词像是说相声一样从他嘴里说出来，三句话不离高并发、大数据。
但是稍微追问一下，就会发现很多基本概念的缺失，例如自称精通高并发的人说不清楚他所谓的高并发系统的瓶颈在哪里，自称精通架构设计的人说不明白他的系统怎么保证高可用，自称超大数据量的系统实际上只有不到100万条数据，等等。
架构师虽然听起来很高大上，但本质上仍然是工程师，不是科学家，也不是忽悠人的江湖骗子。学习再多，也需要实践落地。
设计架构方案更多的是在做一些抽象和权衡：把复杂的需求抽象成简单的模型，从功能、性能、可用性、研发成本等等方面规划如何构建一个系统，这些内容需要更多的实践练习。
很多人没有工作在类似微博平台这种天天需要接触架构设计的地方，而很多公司没有架构方面的工作可供他们练级，于是就想办法从理论上下功夫。
这类人的特征非常明显：在信息不足，甚至不了解实际场景的情况下就开始做架构设计，这种所谓的架构往往理解比较肤浅，经不住推敲。
每年招人之后我们都会做一些针对新人的架构方面的培训，课程材料基本上包括了高可用架构相关的主要方面，但是学完这些材料之后就能成为独当一面的架构师了吗？并没有。
相反，这仅仅是开始，新人真正做了几个并发量上万的系统之后才算是正式入门：面对压力时才会懂得权衡，走过弯路之后才会寻找捷径。
所以我认为在架构师(和其它很多)的工作中最重要的部分是实践，夸夸其谈很容易，与其拽一些技术名词，不如把你正在做的系统真正的做好。
| 029-88235527
| 867013167@qq.com
| 陕西省西安市雁塔区融鑫路3号自力集团院内2楼
029-88235527
企业QQ