对于程序员而言，我始终认为代码是展现能力的关键，一个优秀程序员写的代码，和一个普通程序员写的代码是很容易看出差别的，代码作为程序员的硬实力和名片的展示，怎么提升写代码的能力始终是一个关键的话题，不过很遗憾这篇文章其实也不是讲具体的步骤、银弹方法、武功秘籍什么的，这篇文章讲讲我自己印象中对我写代码能力提升比较大的四段经历，也许可供参考。
2008年，HSF的第二个版本，在当时淘宝最重要的交易中心上线，上线当天造成淘宝网站访问巨慢，交易类的页面几乎打不开，最后靠下线HSF才恢复。下线后开始查问题，HSF的第二个版本基于的是jboss-remoting，jboss-remoting在当时的版本里远程同步调用的超时时间是写死在代码里的60s，而调用的服务确实会有一些超过10几秒的现象出现，导致了web应用处理web请求的线程池被这些慢请求给逐渐占据，请求堆积，最终呈现出了页面打开非常慢的现象。查清原因后，决定基于当时的Mina重写整个HSF的通信，重写的这两个月时间对我自己写代码的能力有很大的提升，无论是对网络IO方面处理的深入学习，还是在高并发系统上的深入学习，现在想想学习的方式也就是翻各类网络IO的科普资料，然后是读Mina的源码、Java网络IO的源码，并发这块的学习主要还是靠那本经典的《Java并发编程实战》，以及读Java J.U.C里的代码，这段时间的学习相比以往翻Think in Java之类的最大区别是，学习后付诸实践，随着HSF这个新的重写的版本的上线，基本算是逐渐真正掌握了这些部分的代码能力。
除了代码能力的提升外，得到了另外一个最大的教训就是，对于一个亿级且长时间运行的系统，很多看起来的小概率的问题都一定会成为严重的问题，这也是为什么写高并发系统的难度，要求了必须对自己写的代码，以及自己代码调用到的各种API里的实现都非常的清楚，这样才能真正确保最终代码的鲁棒性。第二段对我自己写代码能力提升特别大的经历是在民间"消防队"的那段日子，淘宝在2009年故障特别多，但处理故障还没有一个标准的体系和组织，导致很多时候会出现故障出了都没什么人处理，或者处理效率不高，于是当时有个运维团队的同学拉了一些人组建了一个群，群的名字叫淘宝消防队，用来处理淘宝出现的各种故障，我很凑巧的也加入了这个群，这个群里还有另外一个整个阿里公认的超级技术大神：多隆。一开始看到各种故障的时候，压根就不知道怎么下手，处理故障会需要的通常不仅仅是写代码的能力，还需要对一个系统全貌要有一定的掌握，例如前几年一篇特别火的文章，当点击搜索背后发生了什么这样的文章，其实就是要对一个系统的处理流程特别的熟悉，这在处理故障的时候是非常重要的，在有了故障大概在哪个环节后，很重要的就是对这个环节代码运行机制的细节掌控了，这个时候通常来说各种工具非常重要，可以有效的帮助你知道具体发生了什么，例如像系统层面的top -H之类的，java层面的btrace等等，都可以让你根据运行情况去定位问题的点。这段时间我觉得我的提升就是靠大量的练手，故障确实有点多，一开始就靠看人怎么处理，主要是从多隆这里学，然后是尝试自己解决一些故障，解决的越来越多后慢慢熟练度就上去了，除了解决故障能力的提升外，因为看了很多由于代码层面造成的故障，对自己在写代码时如何更好的保证鲁棒性，来避免故障，是非常有帮助的，例如，我看过很多滥用线程池造成创建了大量线程，最终导致线程创建不出来的case，就会明白自己在用线程池的场景里一定要非常清楚的控制最大的数量，包括堆积的策略等，又例如我看过N多的因为自增长容量的数据结构导致的OOM的case，就会明白在写代码的时候不能认为一定不会发生数据结构增长到超级大，所以不做任何保护的case，这个时间我明白到的就是写一段能运转，实现需求的代码不难，但要写一段在各种情况下都能长期稳定运行的代码是真心不容易，这我觉得是一个职业的写商业系统的程序员和只是写程序玩玩的最大差别。2010年，我从中间件团队离开，去做HBase，那个时候的HBase里面的通信还是用一个非常简单的写法实现的，我想着要么就把以前HSF里用的移植到HBase里用，这个时候刚好多隆在用c给各类c的应用写一个通用的通信框架libeasy，于是就有了一次测试，我记得第一次测试结果看到原来HSF里面的通信框架的高并发能力和libeasy比相差无比巨大，我和多隆便探讨他是怎么实现的，我看看能不能学习下在Java这边的版本里也改改，所以有了这段重写通信框架的经历。本来以为之前在写HSF的那几年应该算是对通信框架这块的代码相关的能力掌握的不错了，在和多隆一起重写的这段过程中，才发现差距还是很大的，多隆教会了很多细节的问题，基于NIO的通信框架的核心是用非常少的IO线程来处理IO事件（太多也没用，因为有些部分就只能串行），所以怎么高效的使用好这几个IO线程是非常关键的，要尽量减少这几个IO线程处理一些不相关的动作，另外一点就是尽量减少IO线程和业务处理线程的切换，例如后来常见的批量把一个流里的多个请求一次性丢给业务处理线程。这段经历对自己更加深入的掌握在代码逻辑整体的细节层面是非常有帮助的，这对于写要求很高的系统是非常重要的，毕竟对于一个超大规模的系统而言，1%的提升还是可观的。之前因为处理故障比较多，有段时间我开始给公司同事们分享如何处理故障，后来发现有些问题自己也讲不清楚，或者也不知道怎么处理，必须深入学习JVM才行，但其实一开始我完全摸不着门路，JVM代码打开都不知道从哪看起。很幸运，碰到了一个同样爱好又比我强很多的同学，就是撒迦，圈内通常叫R大，我和撒迦好几个周末约着在公司一起看JVM代码，有撒迦的指点，我终于是入门了，知道大概怎么去看了，而且两个人一起看代码，互相分享和探讨，效率是非常高的。有了这段经历，再加上继续处理着一些故障，基本上逐渐对JVM的代码实现有了更多的理解，在后来做故障分享、问题解决什么的时候终于能更好的做到知其然知所以然，同样，这对处理故障的能力，写代码的能力也是非常有帮助的，例如会更加明白以前认为的所谓的面向GC友好的代码是几个意思，也会有了更深的感受是其实Java的代码呢，通常不会写的太烂，因为JVM在运行期会做很多的尽可能的优化，拉到一个平均线，但要写的很好，难度是非常大的，因为需要懂JVM，懂JVM下面的OS。
其实也总结不出什么，因为每个人的环境什么的不太一样，也有适合各自提升的方法，我看自己的经历呢，我觉得：- 如果环境不具备，就给自己一个挑战的命题，例如要学高并发的通信，可以尝试自己写一个和其他的做对比，做性能等的pk，这个通常提升还是会很大的，要学GC，可以尝试给自己几个题目，来控制GC的行为等，如果环境具备的话，确实会更加有利；
- 多和优秀的程序员一起，我自己从多隆、撒迦身上学习到了很多很多，从很多优秀的开源代码，像Netty，OpenJDK里面也学习到了很多很多，所以多参与一些优秀的开源项目也是一个很好的提升方法，看优秀的书（例如并发里的那本Java并发编程实战，JVM里的Oracle JRockit: The Definitive Guide，深入理解Java虚拟机等），也一样是一种向优秀程序员学习的好方法；
- 多多尝试解决问题/故障，这绝对是提升代码综合能力非常好的一个方法，自己工作里机会少的话，网上有大把，像stackoverflow之类的，都是很好的练习场。
最后的最后，我还是想说，代码能力作为程序员的硬名片，始终是最有效的区分程序员能力的东西，talk is cheap, show me the code这句话我觉得是永远成立的。
/ 特别推荐老毕的专栏 /
这是与毕大师的一场长达 12 个小时的对话而产生的采访记录，也是一代大师由非专业到技术巨佬的成长故事集，但更多的是毕大师对自己 20 年程序人生的深度复盘，特别是他在淘宝的经历。内容包括并不限于：
面试，没写简历，也没答对几道题，他却进了淘宝？
写第一个系统HSF，刚转正就差点把系统搞挂了？
处理故障，充分锻炼了编程能力，他却说这对公司是个恶性循环？
做异地多活被广为人知，他却说做大项目，千万不要塑造一个神？
转到前景堪忧的运维团队，他表示团队价值问题自己也解决不了？
集团级项目统一调度做成了，他说可能是因为时机？
……
专栏共分为了四大模块。
具体详细内容，可以看看目录：
![]()
专栏里「高手锦囊」的部分最让我惊艳，这块算得上是把毕大师 20 年程序人生中最精华的部分都总结了出来，并通过与前三章真实项目经验、案例结合，分别在个人成事、方向选择、团队带领、做事文化、架构修炼这 5 大方面给出了他的指导，其中每一条都是能真正拿去借鉴的思考能力和实操方法论。
申请到了「粉丝专属」优惠：
原价 ¥99，早鸟特惠 ¥69
今日新用户仅 ¥59
![]()
👆识别二维码，免费试读👆
有句话说“以史为鉴，可以知兴替；以人为鉴，可以明得失”。毕大师在专栏中也提到过类似的话，“技术提升到了一定程度，其实就是混圈子，也就是见过猪跑很重要”。其实这都是在强调，不管做技术还是任何事情，找到有可以借鉴的经验，以及从前人的经验中深入挖掘自己的需求，这很重要。
而这份毕大师的职业生涯深度复盘，就是你技术职业生涯上认知提升的关键手册。
👇 点击「阅读原文」
免费试读，对话前阿里 P10 毕玄，提升你的技术洞察和认知。
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。