怎么提高写代码的能力

做者 | 毕玄 来源|阿里巴巴云原生公众号

对于程序员而言，我始终认为代码是展示能力的关键，一个优秀程序员写的代码，和一个普通程序员写的代码是很容易看出差异的，代码做为程序员的硬实力和名片的展现，怎么提高写代码的能力始终是一个关键的话题，不过很遗憾这篇文章其实也不是讲具体的步骤、银弹方法、武功秘籍什么的，这篇文章讲讲我本身印象中对我写代码能力提高比较大的四段经历，也许可供参考。

第一段：第一次感觉天天亿级系统的挑战

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 才行，但其实一开始我彻底摸不着门路，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" 这句话我以为是永远成立的。