通往架构师路上的经验总结
转自：https://segmentfault.com/a/1190000015592691
前言：
我先介绍一下我的新同事，据说他是美国篮球运动员詹姆斯的死忠粉，公司好多同事都这么叫他James，有8年开发经验的架构师，之前在AL待过，我一听说是AL的，啧啧啧........，就有种莫名的种亲切感，就立马找新同事聊了起来。我们在空余的时间聊了很久，也聊了好多。毕竟之前都在AL待过，感觉话题还是有的。
在聊天过程中，我们也聊到了他为什么离开AL，也聊到了他在成为架构师的道路上的辛酸历程，聊过后，才发现，离开AL的原因和他的架构师之路和我的很是相似。都是经历不知多少个日夜磨砺出来的辛酸历程。现在回想过去，在看现在的自己，感觉之前的辛酸都是值得的。
好了，我在这里就不跟大家扯这么多了，今天的这篇文章，主要是我们两在聊天讨论的过程中，产生了很多在成为架构师的过程中的一些共鸣点，既然我们所经历的点有共鸣，那么我相信跟大家的也相差不大，所以，这篇文章仅供大家参考学习以及在成为架构师的道路上应该掌握的知识点和经验。相信你在看完这篇文章后，你有一个明确的目标以及一个通往架构师路上正确的方向。
困扰架构师日常问题
- 架构师应不应该写代码
- 为什么别人的系统总是那么烂
- 成为架构师最困难的门槛是什么？
- 如何更高效的学习？
- 面对目前流行的技术不知如何下手？
- 一家公司待久了，过得很安逸，但跳槽时面试碰壁？
- 觉得现在的技术基础感觉到很扎实，但就是自己的技术提升不上？
- 觉得自己很牛B，一般需求都能搞定，但是所学的知识点没有系统化，很难在技术领域继续突破？
- 现在觉得自己技术还可以，但就是薪资涨不上去？
以上这几点，做为开发人员的你们，有遇到过么？有为自己想过么？有细心仔细的去解决过这些问题么？有深刻的想过么？虽然这几个问题很简单，但对于我们在开发路上，是有非常重要的帮助的。
1：架构师应不应该写代码
合格的程序员对于明确分配的任务会完成的很好，但是大部分情况下“架构”这个词意味着架构师并不会涉及太多细节，架构图和代码实现之间总还是有些距离，你无法保证所有人都会正确的理解你的设计，或者是程序员写代码时遇到障碍时会立刻想出足够优雅的解决方案。
在我看来，写代码的架构师更像是在做后勤保障的工作：在代码中第一时间发现可能存在的问题，向其他人提出警告，或是给予其他人改进的意见，必要的时候或是给其他人演示一下正确的姿势。
大部分情况下我作为架构师并不需要揽下“核心模块”开发这种工作，毕竟我能调配的时间太零散了，效率难以保证，很多人在专注的情况下比我做的好很多，我只需要保持大局观需要适度参与就可以了。
总的来说，架构师和程序员在某些方面上有点像产品经理和用户的关系，大部分程序员并不会主动告诉你他们想要什么、哪里需要优化，甚至自己也不知道这些。想要做出好的产品，捷径之一就是跟用户做同样的事情。
2：为什么别人的系统总是那么烂
很多程序员解决问题的能力很强，说要解决一个什么问题，下午就能写出几百行代码把功能实现了。但是做出来的东西有种少考虑了什么东西的感觉。大部分程序都能实现功能，但是如果把“时间”这个也作为一个考虑的维度的话，就会意识到一个合格的项目需要考虑更多的东西：更通用的使用方式、易于理解的文档、简单而易于扩展的设计，等等。
很多公司应该都会有一些遗留系统，它们庞大、笨重、难用、几乎无法维护，所有人都在抱怨这些系统，并且每天都在想方设法换掉那些遗留系统。但是一段时间过去之后，又会发现身边的新人又开始吐槽当时替代遗留系统的那个系统了。
3：成为架构师最困难的门槛是什么？
很多人自称架构师的人跟你讲一个架构时简直滔滔不绝，各种技术名词像是说相声一样从他嘴里说出来，三句话不离高并发大数据，但是稍微追问一下，就会发现很多基本概念的缺失，例如自称精通高并发的人说不清楚他所谓的高并发系统的瓶颈在哪里，自称精通架构设计的人说不明白他的系统怎么保证高可用，自称超大数据量的系统实际上只有不到100万条数据，等等。
架构师虽然听起来很高大上，但本质上仍然是工程师，不是科学家，也不是忽悠人的江湖骗子。学习再多，也需要实践落地。设计架构方案更多的是在做一些抽象和权衡：把复杂的需求抽象成简单的模型，从功能、性能、可用性、研发成本等等方面规划如何构建一个系统，这些内容需要更多的实践练习。
4：如何更高效的学习？
大多数人每天能留给自己学习的时间有限，这个阶段如何提升学习效率就成了要解决的重点。
说说自己提升学习效率的心得，其实非常简单：体系化的学习。
在重复了几次痛苦的学习-梳理过程后，再去看一些独立的文章或者资料往往会事半功倍，因为能在体系内找到相对应的知识，甚至有时候一本书里一页只需要看一句话，点破那层窗户纸，就可以掌握新的知识。
跟很多人一样，刚毕业时我觉得作为程序员，只要努力，加上少许天赋便可以获得一些成绩。
工作一段时间后，对自己和其他人的认识也越来越清晰，逐渐的发现程序员之间的差距或许比人和猴子之间的差距还大，接受这个事实这让我郁闷了很久。
再过一段时间，发现自己已经能够客观的评价自己的能力，也意识到了距离并不是那么重要，只要想办法跑的更快，就足够了。
5：面对目前流行的技术不知如何下手？
第一，根据自己目前工作中所用到的技术，有目的性的学习；
第二，可以根据各大互联网公司的招聘要求，有选择性地进行规划学习；
第三，可以参照文章尾部Java架构师所具备知识点，上面有从源码到分布式到微服务到并发等，是十多年的一群有经验的老师整理出来的。
6：一家公司待久了，过得很安逸，但跳槽时面试碰壁？
很多程序员有这样的情况，因为一直处于自己的舒适区，每天写的是自己熟悉的业务代码，更多的做的是crud的工作，技术上没有挑战性，觉得生活也还可以。但是一旦跳出这个舒适区，就会很难适应，不知所措，因为外面新的技术太多，自己完全跟不上技术的步伐，这时候需要梳理一下自己目前所欠缺的点，有针对性地进行提高。
7：觉得现在的技术基础感觉到很扎实，但就是自己的技术提升不上？
这种技术扎实更多的是基础，比如javase，javaee等，并不能适应一线互联网公司的技术体系，比如分布式，微服务这块。技术提升不上是因为自己没有接触过相关的项目，以前那种基础知识网上还一大篇，但是越往上走资料越少，好的资料就越少，而且越往上如果没有引路人更加举步维艰。
8：觉得自己很牛B，一般需求都能搞定，但是所学的知识点没有系统化，很难在技术领域继续突破？
这里的一般需求，更多的应该是在单机环境之下的crud操作，项目没有太多难度，顶多是业务上的分析复杂一些，技术用到了一些主流的技术，比如dubbo，也仅仅停留在api的使用层面，不了解其原理，而且与dubbo相关的其他技术分支并没有很好的拓展，所以感觉很难突破。
9：现在觉得自己技术还可以，但就是薪资涨不上去？
需要弄清楚薪资由什么决定，是由你的价值决定，而你的价值取决于你的技术能力，如果你的技术能力一直停留在crud的层面，肯定会上不去，你需要做的是突破技术瓶颈。（我相信这一点，是大多数开发人员会首先考虑到的问题）。
经过以上的几个问题的总结，你们有一点点理解了么？有什么感触没？没有？那么你们继续往下看。
程序员应有的几个阶段
- 第一阶段----三年
我认为三年对于程序员来说是第一个门槛，这个阶段将会淘汰掉一批不适合写代码的人。这一阶段，我们走出校园，迈入社会，成为一名程序员，正式从书本上的内容迈向真正的企业级开发。我们知道如何团队协作、如何使用项目管理工具、项目版本如何控制、我们写的代码如何测试如何在线上运行等等，积累了一定的开发经验，也对代码有了一定深入的认识，是一个比较纯粹的Coder的阶段。
- 第二阶段----五年
五年又是区分程序员的第二个门槛。有些人在三年里，除了完成工作，在空余时间基本不会研究别的东西，这些人永远就是个Coder，年纪大一些势必被更年轻的人给顶替；有些人在三年里，除了写代码之外，还热衷于研究各种技术实现细节、看了N多好书、写一些博客、在Github上分享技术，这些人在五年后必然具备在技术上独当一面的能力并且清楚自己未来的发展方向，从一个Coder逐步走向系统分析师或是架构师，成为项目组中不可或缺的人物。
- 第三阶段----十年
十年又是另一个门槛了，转行或是继续做一名程序员就在这个节点上。如果在前几年就抱定不转行的思路并且为之努力的话，那么在十年的这个节点上，有些人必然成长为一名对行业有着深入认识、对技术有着深入认识、能从零开始对一个产品进行分析的程序员，这样的人在公司基本担任的都是CTO、技术专家、首席架构师等最关键的职位，这对于自己绝对是一件荣耀的事，当然老板在经济上也绝不会亏待你。
我认为，随着你工作年限的增长、对生活对生命认识的深入，应当不断思考三个问题：
- 我到底适不适合当一名程序员？
- 我到底应不应该一辈子以程序员为职业？
- 我对编程到底持有的是一种什么样的态度，是够用就好呢还是不断研究？
最终，明确自己的职业规划，对自己的规划负责并为之努力。
