阿里毕玄：从生物系学生，到技术团队 leader，他是如何完成自我蜕变的

新的技术层数不穷，困扰程序员的不仅有学不完的新技术，还有每个人在职业生涯中必然会面对的成长路线问题。这就像一个产品有了清晰的 roadmap，下一步走的才会更自信。本文整理自程序员毕玄的《程序员的成长路线（续）》，讲述了自己加入阿里后的技术成长历程。

技术能力成长

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

技术能力的成长主要是在 07 年加入阿里之后。在加入阿里前，我是一个连日均访问量 1w PV 都没见过的人，到了阿里，做的第一件事竟然是要写 HSF（阿里内部使用的 RPC 服务框架），并且要在客服的 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 需要有对技术趋势的感知和判断能力，这是非常综合的能力。同时，具备一到两个领域的技术深度，大的架构能力，以及对技术历程的理解、技术发展的思考能力。然后是其他的一些比较综合的能力，例如组织搭建、建设方面等。不过综合能力这块，对技术人来说，通常会欠缺的更多一些，这方面我也还在修炼和学习中，就不讲太多了。

总结

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

本文转载自技术琐话公众号。

原文链接：https://mp.weixin.qq.com/s/cHfmINIhJ71aZLj62ppO1Q