转载

程序员的成长路线（续）

上周我几年前写的那篇《程序员的成长路线》的贴被翻出来，貌似还挺受欢迎的，自己看了下，觉得还可以写的更细节一些，在这篇里我更希望以自己的经历来讲讲在一些角色上成长的感受，我回顾了下自己的职业经历，在成长方面差不多经历了技术能力的成长、架构能力的成长，以及现在作为一个在修炼中的技术Leader的成长，这里面我想至少技术能力和架构能力的成长是所有程序员都很需要的，希望我自己的经历能更对你的成长或多或少有那么点帮助。

技术能力成长

我大学读的是生物系，缺少了专业的训练，这个使得我在技术能力上其实欠缺的更多，回头想想，在工作的前5年，更多的都是在拓宽技术面，刚毕业的时候只会asp，工作前两年学会了vb、delphi这些神器，到工作的第三、四年比较专注的做了工作流领域。

技术能力的成长主要还是在07年加入阿里以后，在加入阿里前，我是一个连日均访问量1w pv都没见过的人，到了阿里后，做的第一件事竟然就是写HSF，并且在客服的CRM系统上线，访问量大概是每天上百万的服务调用，无知者无畏，当时也就那么上线了，更神奇的是竟然没出现什么问题，于是继续把HSF上线到当时的交易中心，当时交易中心每天的服务调用量大概是1亿左右，结果上线当天就回滚了，而且还不知道到底是什么原因，这次的回滚是对我触动最大的一次（当然，触动大也有可能是后面要是解决不了，就该从淘宝滚蛋了）。

回滚后开始仔细查问题，最后发现是当时HSF所使用的jboss-remoting默认的超时参数60s的问题，自从这个问题后，才明白要支撑好到了一定量级的系统，最重要的是对整个技术栈的精通，否则出问题都不知道该怎么解决或临时查，于是才开始仔细学习Java的BIO/NIO，Mina，反射，并发编程等，尽管这些东西很多在加入阿里前也看过一些书、资料学过，但到了这个时候才发现自己其实不怎么懂，那段时间密集的开始更细致的看书，翻看用到的Mina、甚至是Java的各种API背后的源码，是自己的Java技能提升最快的一段时间，在回滚的两个月后，基于Mina完全重写了HSF，再次上线终于一切顺利。

在那之后，随着HSF应用的场景越来越多，以及加上后来自己在淘宝消防队查比较多的问题，Java方面的技能也得到了不少成长，而同时也发现了很多的Java问题还得对JVM、操作系统层面有一定掌握才行，尤其是JVM，于是当时和还在阿里的撒迦经常一起周末跑到公司来结对看JVM代码，:)，在撒迦的帮助下对JVM的掌握终于也越来越好，那段时光会让自己明白很多东西只有看了代码，并且有相应的使用机会才能真正的掌握。

在HSF之后，去做HBase，学习了很多在存储方面的技能，这也是我之前完全不懂的领域，在HBase之后，开始做T4，进入彻底不懂的领域，虚拟化、Cgroup等等都是那个时候才开始学习，但因为没详细研究过代码，并自己去做改造，其实到今天也就是点皮毛而已。

对于程序员而言，技术能力的成长显然是最重要的（程序员行当里最赞的一句就是：Talk is cheap, show me the code!），我自己其实很多都属于被逼的成长，当然这样通常反而也是最快的，很多同学会觉得自己没碰到这样的机会，所以成长就比较慢，我会非常建议的是可以尝试自己去创造一些场景（当然，如果本来就是工作需要就更好了），来学相应的技术能力（例如学Java的通讯框架，可以尝试自己基于BIO/NIO写一个，然后对比Mina/Netty这些成熟的，看看为什么写的不太一样，又例如学Java的内存管理，可以尝试自己写程序去控制GC的行为，例如先来一次ygc，再来两次fgc，再来5次ygc，再来一次fgc之类的，学的时候除了一些入门的书外，我非常建议去翻看源码，最后你会发现所有的书都不如源码），这样才能真正的理解和学会，否则其实很容易忘。

架构能力成长

架构这玩意，说起来我在刚工作的第三年负责工作流系统的时候，好像也做过，但直到后来在阿里做T4、异地多活我才有了真正更强烈的感受，以及对架构师的一些理解，架构呢，我现在的理解基本是一个结构图，当然有不同视角的结构，但这个图里的部分呢是多个团队来做的，甚至是跨多个专业的团队。

在做T4的时候，由于T4涉及到了标准的一个Java WebConsole，一堆的运维体系，容器技术等，这是一个至少要跨三个团队的结构，无论是从研发视角还是部署视角都是如此，因此作为T4的架构师，怎么设计好整个的结构，各自的边界、接口是我当时最大的感受，让跨专业的多个团队能更好的协作，在这个阶段中最重要的要考虑的是怎么根据整个项目的优先级来调整每个部分，以及作为一个不是全懂的架构师怎么更好的确保结果，我自己的感受是T4让我学会了从一个只做自己专业系统的架构师成长为了能做跨专业的系统的架构师。

在做异地多活的时候，感受就更加强烈，因为这个跨的专业数、整个参与的人数完全是上升到了一个非常大的程度，各个专业、系统的人都需要看整个架构才能知道自己应该做什么，扮演的角色，在做异地多活整个项目过程中，作为总的架构师，我自己感觉的是最重要的职责是怎么控制项目的风险，或者说作为架构师，你觉得一个项目中最重要的要掌控住的是，并且从架构上怎么设计这个部分，这也是后来我在问很多架构师时最喜欢问的问题，一份架构文档不是说按照模板写就可以（很多的架构设计文档都是千篇一律，通常看到的都是什么都考虑，但从架构设计上并没体现这些考虑的地方是怎么做的），而是要根据实际的项目/产品情况来突出重点，确保最重要的几个问题是从架构设计上就去掌控的，尤其是跨多个专业团队的大型项目，这种项目准确的说是大架构师带着一堆的专业领域的架构师来做的，例如异地多活项目从架构设计上来说除了正常的结构、边界以外，最重要的是数据正确性的设计，我自己最强的感受就是异地多活才让我明白了一个大型系统的架构师是怎么样的。

所以就我自己的感受而言，架构师对知识的宽要求非常广，并且要能非常好的进行抽象，来做结构、边界的设计，分析出当前阶段系统的重点，并从架构层面做好设计来确保重点的实现，这个相对技术能力的成长而言我觉得更需要机会，但同样在机会前需要有足够的积累（例如写一个系统的时候，是不是主动的去了解过上下游的系统设计，是不是了解过具体的部署结构，对相应的知识点有没有简单的了解等，我自己在做T4前，LVS、机房/网络结构等完全搞不懂是怎么回事）。

技术Leader修炼

技术Leader我比较倾向于有前面两步积累的同学，技术Leader非常重要的一点是对技术趋势的感知和判断能力，这其实是个非常综合的能力，一到两个领域的技术深度，大的架构能力，对技术历程的理解、技术发展的思考能力，作为技术Leader是很需要的，然后是其他的一些作为Leader方面的比较综合的一些能力（例如组织搭建、建设方面的能力等，不过这些能力呢通常对技术的人来说确实会欠缺的更多一些），这个我自己还在修炼和学习中，就不讲太多了。

总结

总结来说呢，我觉得和在之前文章里写的一样，我认为程序员可发展的路线还是很多的，上面写的这三条其实都是可发展的路线，没有孰优孰劣，谁高一等之类的，兴趣、个人优势仍然是最重要的。

原文 https://mp.weixin.qq.com/s/Y1Otzp43lQRqUKlGToMMAQ

正文到此结束