如何成长为一名合格的架构师？

主要当然是跟架构相关的事情吧（好像是废话哎），具体一点就是架构设计，讲解推广，然后再做一些代码方面的工作。说起来，讲解推广可能是很多人不太重视的，但其实它的比重还是比较大的，基本能到三成。

而这三者的比例，5：3：2也是很经常的。也就是说，团队到达一定的规模，架构师可能80%的时间都不在编程而在思考上。想（设计）不好，团队就会走很多弯路。很多时候我们太忙，看起来是事情太多，但其实可能是想得太少。

会写代码么？会写，但是可能并不会是核心代码，这个其实看每个团队的成熟程度，比如早期我会写一些核心代码，但是后来因为团队比较厉害了，如果我不分配足够的精力在某个功能实现上，为了不拖累整体的进度，会倾向于写一些边缘的代码，主要是了解团队的代码质量和实现进度。现在可能更多的写一些试验性的代码，去玩一些新的技术。

这里面还有个很特殊也很重要的工作，就是故障处理。对于一个系统来说，实现出来只是第一步，真正做成高可用的系统，还有相当长的路要走。这个过程中，你会遇到各种各样的情况，遭遇系统宕机、服务崩溃等等。基于故障的改进是架构演化很重要的一种形式。我们经常说，故障是推动技术进步的重要动力，就是这个意思。在处理故障的过程中，才会更容易体会思考当前系统的缺陷，后续改进的方向也会更加明确清晰。

前面这些事情基本都是属于输出型的，是个人对团队的贡献。个人层面，我还是需要不断地输入，学习新的知识，保持对行业、领域内新技术的更新。这里也向大家推荐一下，看论文可以认为是架构修炼的一个捷径，因为很多论文写得比较严谨，也会比较系统，了解一个系统实现的细节甚至是思想都很方便。

再有点时间，可能就是写写文章，最近（一年前）写了一个公众号，大家有兴趣可以关注，名字是「一乐来了」，不过可能还是年更 :P

我第一反应感觉自己没走过多少坑，但是后来想想，其实这也许是在坑里的表现，因为一般在坑里的人是不知道自己在里面的。

话说回来，我觉得有一个坑是所有工作的人都很容易遇到的，就是要认识到研发类工作遇到的问题，在很多情况下，不仅仅是技术问题，这就意味着并不是解决了技术部分就能解决掉的。

拿我自己举例。刚开始做系统设计的时候，有一些架构改造的点子经常不被认可，跟同事跟领导说起来，大家虽然没有什么意见，却应者寥寥。当时有一种强烈怀才不遇的感觉，甚至一度对团队都产生了怀疑，非常苦恼。

后来忽然有一天想明白了，只要还在一个团队，还是得做些事情说服别人才有意义，保持清高却期待变化是不现实的。想说服大家还是得换个角度，先去思考别人为什么不接受。顺着这个方向，慢慢解开了这个结。一般这种你觉得自己不被人理解的情况，基本都是你因为对技术的兴奋，过低评估了风险，或者没有考虑人的因素（是否充足，投入产出比），或者没有考虑项目的因素（排期进度方面）。

多说一句投入产出比的事情。其实单纯的技术改进很多情况下都没有太大价值，除了个人能练练手以外。技术真正发挥价值的地方，一定是在对用户产生影响的时候。如果做不到这点，一遇到人力紧张的情况这样的技术改造就会被放弃。当然说起来应该也算好事。

至于如何做架构呢？我推荐一个工具iPad Pro，也给大家演示一下像Paper53、Notability这样的应用。这些都是我在平时给大家讲解时会用到的，比单纯的PPT要好很多。因为从一个架构图开始，给大家建立整体的概念，然后细化分析其中的组件，在这个过程中再不断提醒这个组件在整个系统中的位置，对于理解一个系统来讲帮助是非常显著的。

服务从本质上来讲就是数据的处理，而架构设计就是在定义数据流转方式而已。

最重要的当然是要像架构师一样思考。今天来看直播的有很多不同阶段的同学，我再说一些稍微具体的建议，当然也结合我看到的很多人容易走进的误区。

对于刚入门的同学，在听到一些新的热的技术时，一定不要只是看热闹，要去看门道。很多人都可以针对架构问题夸夸其谈，但其实对概念并没有了解清楚，表现出来就是好一点也只是知道某个东西是什么，却不知道它的优缺点，也不清楚为什么在一些情况下要用。

慢慢的，当开始懂一些的时候，要找机会开始实践。读再多的文章，不如自己上手实现一次。这种实践不是说完成一个项目就行，而是那些有挑战的项目，因为架构问题只有在解决复杂问题的时候才会出现。说起来我们前几天搞过一次PCC性能挑战赛，目的也是这样。

实践之后，还要记得归纳总结。因为如果要实现一个系统，大多数人都会因为急于编码而疏于思考。通过归纳总结，可以反思遇到的问题，重新思考系统的设计缺陷，不仅有助于以后做同类系统时不再踩坑，也因为没有了实现系统的干扰压力，更有可能举一反三，发现更巧妙的系统设计。

最后对于有一定经验的同学的建议就是，要多到社区交流。这不止是个学习的问题，而是对于一般人来讲，到了这个阶段很容易骄傲甚至自满。这是一个很不好的情况，不仅自己不会再有提高，跟团队的配合都可能出现问题。但你很难避免，部分也是因为人性使然。但是与人交流，特别是参加顶级会议，你会遇到很多跟你一样优秀的人，甚至比你优秀更多的人。你跟他们交流，自然会发现技术领域的广阔无边，也就不会再有那样的情绪了。

这里也顺便做个广告，七月份深圳架构师峰会就要开了，感兴趣的同学可以多去看看。我虽然是架构师成长专题的出品人，但是其他专题也都非常优秀，绝对可以值回票价。

ArchSummit 深圳 2017 官网：http://sz2017.archsummit.com/

提出这个问题，还是因为某大厂特殊对待35岁以上员工的新闻。我必须声明的是我还不到35岁，所以并不能有35岁以上学习发展的经验。

我们有时候确实会在意年龄，你10岁没上小学，大家都说你晚了，你30岁还没有结婚，你就是晚婚了。但是在这学习发展的方面，年龄其实并不是问题，规划才是问题。

前几天聊到人生发财靠康波，说的是经济周期都比较长，规律可能在长波维度（六十年左右）才能看出来。但是考虑到行业发展速度和人生长度，个人规划还是比较适合短周期，比如我就一直在用五年规划。

如果有规划，一方面你可以有条不紊脚踏实地的在某一方面深耕，另一方面，也会帮助你尽早去掉一些没有用的烦恼。

书单就是一个很好的例子。很多人都喜欢跟别人要书单，自己也会买很多书「准备」看。注意是准备，因为大多数人并不会真正看完。我之前在微博上分享过一个自己09年的阅读相关的规划，当时我把自己要看的书，按照书的厚度和每天要看多少来进行分析，当时的几本书看完就要三百多天。也就是说一年不买书都看不完，而它们仅仅是案头的一部分。这也是我现在并不会给人推荐书单的原因，如果一个人没有规划，书单只是一个购物单而已。

但是如果你开始规划，你就会知道自己拼了命也只会看几本书的时候，你就更容易理智对待要看的书，把精力分配到更值得看的书上，而不是撒胡椒面式的随意阅读。值得精读又能做到精读的书还是有限的。

当然也一定要警惕，不要被你的思想所局限。之前我写过一篇文章「做业务系统也可以成为架构师」提过这个事情。人永远不知道自己不知道的东西，规划的时候也不能闭门造车，多找人寻些建议，看看别人眼里的一些事情。

介绍里跟大家说过一句，业余时间玩得还比较多。跑步、游（喝）泳（水）、登（爬）山、足球（也是跑步）、骑马（去年只玩了两次），最近拳击也开始玩了。

这些都很有意思，大家可以一起玩玩。但我觉得最值得推荐的，还是跑步。原因就在于程序员因为加班多，很容易得职业病。我个人曾经有严重的肩颈劳损问题，严重到每天工作九小时之后肯定会头疼，因为肌肉劳损影响了头部的血液循环。西医看不出问题来，中医针灸、艾灸、中药、按摩也是多管齐下也不管用，直到后来开始跑步，才解决了这个问题。（一秒化身传销了）

现在我每次基本都跑一万米。很多没跑步的人都觉得难，其实是很简单的事情，正常人不是可以过早放弃的话，都可以做到。我自己原来也不行，大学时候12分钟跑都跑不下来，但这其实是一个健康人很容易达到的程度，只要你坚持练习就行。当然运动到了这个量级，确实也会对身体产生不小的负荷，也很容易有运动损伤，要注意技巧方法的改进，装备该换就得换。

其他的就不多说了，有机会可以详细聊。最后祝大家都能有个运动的爱好，养成这样对人生有益的好习惯，毕竟好身体才是享受工作生活的基础。