云栖专辑| 阿里毕玄：程序员的成长路线

摘要：阿里基础设施负责人毕玄结合自己的经历跟大家讲述了他在各个角色上成长的感受，值得所有正为职业发展而迷茫的技术同学细细品味。

【编者按】2018年12月20日，云栖社区3周岁生日。阿里巴巴常说“晴天修屋顶”，所以我们特别策划了这个专辑——分享给开发者们20个阿里故事，50本书籍。第一位是林昊（毕玄）。

在这篇《程序员的成长路线》里，阿里基础设施负责人毕玄结合自己的经历跟大家讲述了他在各个角色上成长的感受。在他的职业经历中，在成长方面经历了技术能力的成长、架构能力的成长，以及现在作为一个在修炼中的技术 Leader 的成长。其中技术能力和架构能力的成长是所有程序员都很需要的，值得所有正为职业发展而迷茫的技术同学细细品味。

技术能力成长

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

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

回滚后开始仔细查问题，最后发现是当时 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 方面的比较综合的一些能力（例如组织搭建、建设方面的能力等，不过这些能力呢通常对技术的人来说确实会欠缺的更多一些），这个我自己还在修炼和学习中，就不讲太多了。