阿里毕玄：程序员应如何选择职业成长路线？

时间 2019-11-06

原文原文链接

做者：毕玄 阿里云开发者中心负责人 阿里系统软件、中间件、研发效能负责人程序员

阿里系统软件、中间件、研发效能负责人毕玄结合本身的经历跟你们讲述了他在各个角色上成长的感觉。在他的职业发展中，他经历了技术能力的成长、架构能力的成长，以及如今做为一个在修炼中的技术 Leader 的成长。其中技术能力和架构能力的成长是全部程序员都很须要的，值得全部正为职业发展而迷茫的技术同窗细细品味。编程

技术能力成长

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

技术能力的成长主要仍是在 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之类的，学的时候除了一些入门的书外，我很是建议去翻看源码，最后你会发现全部的书都不如源码），这样才能真正的理解和学会，不然其实很容易忘。分布式

架构能力成长

提及架构，在我刚工做的第三年负责工做流系统的时候也作过，但直到后来在阿里作 T四、异地多活，我才有了真正更强烈的感觉，对架构师也有更深的一些理解。架构呢，我如今的理解基本是一个结构图，固然有不一样视角的结构，但这个图里的部分呢是多个团队来作的，甚至是跨多个专业的团队。学习

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

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

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

技术Leader修炼

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

总结

总结来讲呢，我认为程序员可发展的路线仍是不少的，上面写的这三条其实都是可发展的路线，没有孰优孰劣，谁高一等之类的，兴趣、我的优点仍然是最重要的。

做为《OSGi原理与最佳实践》和《分布式Java应用：基础与实践》的做者，毕玄推荐了他的书单给到咱们：

《硅谷之谜》《智能时代：大数据与智能革命从新定义将来》