如何成为架构师？7 个关键的思考、习惯和经验！

工做了挺久，发现有个挺有意思的现象，从程序员、高级程序员，到如今挂着架构师、专家之类的头衔，伴随着技术和能力的提升，想不明白的事情反而愈来愈多了。这些疑问有些来自于跟小伙伴交流，有些是个人自问自答，有些到如今也想不清楚，这篇文章就来写一写这些问题。

如何更高效的学习？

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

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

大多数人天天能留给本身学习的时间有限，这个阶段如何提高学习效率就成了要解决的重点。

说说本身提高学习效率的心得，其实很是简单：体系化的学习。

我曾经很喜欢看一些博客或者是一些 “看起来” 比较通俗易懂的文章，天天在微博微信里刷到什么技术文章就 mark 下来，基本上几分钟就能读完。可一段时间下来，虽然读了很多东西，可是仍是有种在原地打转的状态，并无感觉到有什么实际的提升。

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

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

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

你是怎么知道这些的？

工做中老是会遇到各类各样的问题，有几回把问题处理过程总结了一下，发了出来，以后就像滚雪球同样，有愈来愈多的小伙伴来咨询问题，好比说：

前一阵帮忙排查一个性能问题，系统压力稍微一大就会频繁 Full GC，压力下降以后又恢复了。

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

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

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

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

并且幸运的是，在创建了本身的知识体系的基础上，学习新的知识一般都能很快的上手，解决一个问题每每只须要多了解一个知识点而已。

举个例子，频繁 Full GC 的问题，之前查过不少次 GC 的问题，大多数是 Java 程序或 JVM 内存泄露问题，而此次内存没有泄露，GC 吞吐量也正常，那么我只须要查一下如何查看一段时间内建立的最多的对象的方法就能够了。

回到刚才的问题，小伙伴们问我：“你是怎么学到这些的知识的？”

答案是：在你问我问题以后现学的。

架构师应不该该写代码？

彷佛隔三差五就能看到一些关于架构师应不该该写代码的文章。我是属于写代码派，由于我自己就喜欢写代码。可是，当工做职责发生变化以后，如何保持写代码和其它工做之间的平衡就成了问题。

从个体效率上来看，我本身亲自写代码，和不少人相比没有什么绝对优点，甚至有些人码代码的速度比我还快一些。

但做为架构师，参与写代码仍是会有一些不大不小的收益。

通常来讲合格的程序员对于明确分配的任务会完成的很好，可是大部分状况下“架构” 这个词意味着架构师并不会涉及太多细节，架构图和代码实现之间总仍是有些距离，你没法保证全部人都会正确的理解你的设计，或者是程序员写代码时遇到障碍时会马上想出足够优雅的解决方案。

以前写过一篇关于烂代码的文章，大部分烂代码并非架构师的设计问题，若是程序员没能很好的理解设计或者是经验不足，每每会作出一些很是匪夷所思的东西。好比我见过刚毕业的程序员为了防止模块耦合而将耦合的代码又拷贝了一份，或者为了 “优化性能” 而尽可能把全部逻辑写在一个函数里。

若是不能及时发现并改正这些问题，那么这些地方就会变成“正确的错误代码”，或者” 不是我写的 “代码，或者” 我靠我也看过那段代码 “之类足以被挂上耻辱柱的玩意。这种问题算是架构师的责任吗？做为一个视名声如命的架构师，我认为是的。

在我看来，写代码的架构师更像是在作后勤保障的工做：在代码中第一时间发现可能存在的问题，向其余人提出警告，或是给予其余人改进的意见，必要的时候或是给其余人演示一下正确的姿式。

大部分状况下我做为架构师并不须要揽下 “核心模块” 开发这种工做，毕竟我能调配的时间太零散了，效率难以保证，不少人在专一的状况下比我作的好不少，我只须要保持大局观须要适度参与就能够了。

总的来讲，架构师和程序员在某些方面上有点像产品经理和用户的关系，大部分程序员并不会主动告诉你他们想要什么、哪里须要优化，甚至本身也不知道这些。想要作出好的产品，捷径之一就是跟用户作一样的事情。

实践：开会是个技术活吗？

我以为应该没有人喜欢开会，身为一个程序员，没有几我的的志向是当什么职场交际花。

可是会议邀请就这么一个个的跳了出来：开发需求要跟产品开会、项目方案要跟技术开会、新人转正要去开评审会、别的公司来了几个大牛正在开分享会、出了故障要开总结会、小组有周会、部门有周会，大项目每周开两次碰头会不过度吧？小项目启动的时候开个会不过度吧？调试的时候发现有个坑你们赶忙讨论讨论吧？

有时候参加的会议整场下来跟我毛关系都没有，全程神游俩钟头，最后忽然有人一拍桌子：” 还有问题没？好，散了！“也有可能有个什么会没叫你，过了俩礼拜忽然收到封邮件催开发进度，” 当时那个会你没参加，你们都说应该是大家作……你没看会议纪要吗？“吐槽了这么多，但我仍是认为开会是个技术活，对于架构师来讲尤为如此。

大多数技术人员开会并非那种新闻里的工做汇报或者长者们的会议，他们真的须要经过开会讨论一个具体方案，或者解决什么具体问题。惋惜的是我参加过不少会议，大多数的会议都是在毫无心义的交流中浪费时间：几方人坐在一个屋里互相说一些对方理解不了的话，最后得出一个” 咱们会后再捋一捋 “之类的结论。

这并非会议才有的问题，在程序员平常的沟通中，也有不少人并不懂得如何交流，好比偶尔会收到一些写的很是认真的邮件，打开以后是密密麻麻的一屏幕文字，可是从第一句开始就不知道他在说什么，后面的东西连看的动力都没有了。

大多数时候，沟通的核心不是你说了什么，而是你想要让对方了解什么、让他作什么。良好的沟通能在工做中显著提高效率，但不少人忽略了这个事情。

想要恰到好处的进行沟通是一件不那么轻松的事情，可是简单来讲有几条原则：

1. 确保各方对背景的理解一致，好比开会以前先简单经过邮件交流一下，对新加入会议的人花个 30 秒钟作个前情提要，或者在讨论过程当中让对方说一下他的理解。
2. 去掉对方不能 / 不须要理解的内容，好比跟产品说 “这个队列在高并发下由于锁的实现有问题致使 CPU 性能瓶颈” 不如改为 “咱们发现了性能问题，持续 10 分钟了，10 万用户收不到运营发的无节操广告，大概 5 分钟后扩容解决”。
3. 确保在对方失去注意力前尽快说出重点，好比排查问题的总结邮件，若是第一段是这样：“某某框架内部使用的是 xxx 技术，这个技术的架构是这样：blabla”，那么对方可能彻底不知道你在讲什么。能够换成这样：“我发现了某某框架的 bug，须要尽快升级，不然在 xxx 状况下有可能会出现 yyy 问题，具体排查过程以下：blabla”。
4. 不要说没有意义的内容浪费其余人的时间，好比” 这需求作不了 “或者” 这里不可能出 bug “，没有人想听到这些废话。

为何别人的系统老是那么烂？

不少程序员解决问题的能力很强，说要解决一个什么问题，下午就能写出几百行代码把功能实现了。可是作出来的东西有种少考虑了什么东西的感受，我花了挺久去想一个词去形容 “这个东西”，最后想出了个勉强能够表达的词：程序的生命力。

大部分程序都能实现功能，可是若是把 “时间” 这个也做为一个考虑的维度的话，就会意识到一个合格的项目须要考虑更多的东西：更通用的使用方式、易于理解的文档、简单而易于扩展的设计，等等。而想要毁掉程序的生命力也很简单：作的更复杂，更定制化，让更少的人参与。

我跟不少程序员提过程序的生命力，好比说要让本身写的工具的操做方式跟其它 Linux 命令相似，或者要用一些更容易理解但不是性能最优的设计方式，又或者要他去参考如今业界主流的作法，不少人认为提这种需求的意义不大，我以为这里仍是举个例子吧。

不少公司应该都会有一些遗留系统，它们庞大、笨重、难用、几乎没法维护，全部人都在抱怨这些系统，而且天天都在千方百计换掉那些遗留系统。可是一段时间过去以后，又会发现身边的新人又开始吐槽当时替代遗留系统的那个系统了。

“大多数系统当初都很好使，功能当时够用，扩展性看起来也能够，可是这些系统都是开发的人离职以后变坏的。”

还有更好的办法吗？

成为技术专家以后的工做能够说是痛并快乐着，会有不少人找你咨询问题，另外一方面，会有太多人找你咨询问题。

甚至有一段时间我天天的工做就是解答问题，小到工具使用中到疑难 bug，大到架构设计，从早上到晚上基本都是在给各类各样的小伙伴提供咨询服务。

我很快发现有些地方不对头：有些问题实在是太简单了，以致于我甚至都不用思考就能够给出答案，为何会有这种问题？

后来我在每次回答以前先问一句：

“你还有更好的办法吗？”

一小部分人马上能给出优化后的版本，甚至我连续问几回以后，他能给出好几个优化后的版本；另小一部分人会斩钉截铁的说优化不了了，就这样了。可是大部分人会犹犹豫豫的说出一些彻底不着调的回答。

后来我改为在每次回答以前先问两句：

“你要解决什么问题?”

“还有更好的办法吗？”

效果好了不少，不少小伙伴发现要解决的问题并不复杂，只是作法跑偏了。

再后来我改为了在每次回答以前先问三句：

“他们要你解决什么问题？”

“你解决的是什么问题？”

“还有更好的办法吗？”

如今第三句已经不多问到了。

成为架构师最困难的门槛是什么？

跟一些程序员交流的过程当中，有很多人问我要怎么成为一名牛逼的架构师。

我最近几年面试的人挺多，发现一个有意思的现象：不少人自称架构师的人跟你讲一个架构时简直口若悬河，各类技术名词像是说相声同样从他嘴里说出来，三句话不离高并发大数据，可是稍微追问一下，就会发现不少基本概念的缺失，例如自称精通高并发的人说不清楚他所谓的高并发系统的瓶颈在哪里，自称精通架构设计的人说不明白他的系统怎么保证高可用，自称超大数据量的系统实际上只有不到 100 万条数据，等等。

架构师虽然听起来很高大上，但本质上仍然是工程师，不是科学家，也不是忽悠人的江湖骗子。学习再多，也须要实践落地。设计架构方案更多的是在作一些抽象和权衡：把复杂的需求抽象成简单的模型，从功能、性能、可用性、研发成本等等方面规划如何构建一个系统，这些内容须要更多的实践练习。

不少人没有工做在相似微博平台这种每天须要接触架构设计的地方，而不少公司没有架构方面的工做可供他们练级，因而就想办法从理论上下功夫，这类人的特征很是明显：在信息不足，甚至不了解实际场景的状况下就开始作架构设计，这种所谓的架构每每理解比较肤浅，经不住推敲。

每一年招人以后咱们都会作一些针对新人的架构方面的培训，课程材料基本上包括了高可用架构相关的主要方面，可是学完这些材料以后就能成为独当一面的架构师了吗？并无。相反，这仅仅是开始，新人真正作了几个并发量上万的系统以后才算是正式入门：面对压力时才会懂得权衡，走过弯路以后才会寻找捷径。

因此我认为在架构师（和其它不少）的工做中最重要的部分是实践，夸夸其谈很容易，与其拽一些技术名词，不如把你正在作的系统真正的作好。

我和大牛之间有多少距离？

跟不少人同样，刚毕业时我以为做为程序员，只要努力，加上少量天赋即可以得到一些成绩。

工做一段时间后，对本身和其余人的认识也愈来愈清晰，逐渐的发现程序员之间的差距或许比人和猴子之间的差距还大，接受这个事实这让我郁闷了好久。

再过一段时间，发现本身已经可以客观的评价本身的能力，也意识到了距离并非那么重要，只要想办法跑的更快，就足够了。

成为架构师必不可缺的技能

你们都知道，性能一直是让程序员比较头疼的问题。当系统架构变得复杂而庞大以后，性能方面就会降低，若是想成为一名优秀的架构师，性能优化就是你必须思考的问题。
因此性能优化专题从JVM底层原理到内存优化再到各个中间件的性能调优，好比Tomcat调优，MySQL调优等，让你洞悉性能本质，全面认识性能优化，再也不只是旁观者。有了大牛的代码功底以后，接下来能够更好地学习分布式架构技术。
透彻理解分布式架构的好处和优势必然性，适应市场需求，可以去找一些更大的平台发展，提高本身的综合技术能力和薪资。
了解从传统架构到分布式架构演变过程所带来的技术变革，将理论和实战相结合，透彻理解分布式架构及其解决方案。
从分布式架构原理，到分布式架构策略，再到分布式架构中间件，最后在加上分布式架构实战，让程序员能够在技术深度和技术广度上获得飞跃的提高，成为互联网行业所须要的T型人才。这张图详细介绍了源码中所用到的经典设计思想及经常使用设计模式，先打好内功基础，了解大牛是如何写代码的，从而吸取大牛的代码功力。

结合Spring5和MyBatis源码，带你理解做者框架思惟，帮助你们寻找分析源码的切入点，在思想上来一次巨大的升华。随着业务的发展，代码量的膨胀和团队成员的增长，传统单体式架构的弊端愈来愈凸显，严重制约了业务的快速创新和敏捷交付。为了解决传统单体架构面临的挑战，前后演进出了SOA服务化架构、RPC框架、分布式服务框架，最后就是当今很是流行的微服务架构。微服务化架构并不是银弹，它的实施自己就会面临不少陷阱和挑战，涉及到设计、开发、测试、部署、运行和运维等各个方面，一旦使用不当，则会致使整个微服务架构改造的效果大打折扣，甚至失败。
一名优秀的架构师必须有适合本身的兵器，也就是工欲善其事必先利其器，无论是小白，仍是资深开发，都须要先选择好的工具。工程化专题的学习能帮助你和团队提高开发效率，让本身有更多时间来思考。
Git：能够更好地管理你和你团队的代码。
Maven：能够更好地管理jar包和项目的构建等。
Jenkins：能够更好地持续编译，集成，发布你的项目。
Sonar：一个开源的代码质量分析平台，便于管理代码的质量，可检查出项目代码的漏洞和潜在的逻辑问题(提高代码的质量，更加高效地提高开发效率)。电商项目目的是把所学的分布式，微服务，性能调优等知识运用起来，只有在项目中你才能巩固知识，提高本身。实践电商项目会利用云服务器搭建真实的开发和部署环境，让你从零到项目实战，体验真实的企业级项目开发过程，让你具有独立开发和搭建分布架构系统的能力。

---

总结

其实要轻松掌握很简单，要点就两个：

• 1. 找到一套好的视频资料，紧跟大牛梳理好的知识框架进行学习。
• 1. 多练。 （视频优点是互动感强，容易集中注意力）

**你不须要是天才，也不须要具有强悍的天赋，只要作到这两点，短时间内成功的几率是很是高的。
对于不少初级Java工程师而言，想要提高技能，每每是本身摸索成长，不成体系的学习效果低效漫长且无助。下面资料部分截图，诚意满满：特别适合有1-5年开发经验的Java程序员们学习。**

资料获取方式： QQ群搜索“708-701-457”便可免费领取