简介：对于程序员而言，我始终认为代码是展示能力的要害。一个优良程序员写的代码，和一个一般程序员写的代码是很容易看出差异的，代码是展现程序员硬实力的名片。如何晋升写代码的能力，始终是一个要害的话题，不过很遗憾这篇文章其实也不是讲具体的步骤、银弹办法、文治秘籍什么的，这篇文章讲讲我本人印象中，对我写代码能力晋升比拟大的四段经验，兴许可供参考。

第一段：第一次感触每天亿级零碎的挑战

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 代码关上都不晓得从哪看起。

很侥幸，碰到了一个同样喜好 JVM 又比我强很多的同学，就是撒迦，圈内通常叫 R 大。我和撒迦好几个周末约着在公司一起看 JVM 代码，有撒迦的指导，我终于算是入门了，晓得大略怎么去看了，而且两个人一起看代码，相互分享和探讨，效率是十分高的。

有了这段经验，再加上持续解决着一些故障，基本上逐步对 JVM 的代码实现有了更多的了解。在起初做故障分享、问题解决什么的时候终于能更好地做到知其然知所以然。同样，这对解决故障的能力、写代码的能力也是十分有帮忙的，例如会更加明确以前认为的所谓的面向 GC 敌对的代码是几个意思。也有了更深的感触，就是其实 Java 的代码呢，通常不会写的太烂，因为 JVM 在运行期会做很多的尽可能的优化，拉到一个平均线，但要写得很好，难度是十分大的，因为须要懂 JVM，懂 JVM 上面的 OS。

总结

其实也总结不出什么，因为每个人所处的环境不一样，有不同的适宜各自晋升的办法。我看本人的经验总结下来，我感觉：

• 如果环境不具备，就给本人一个命题挑战。例如要学高并发的通信，能够尝试本人写一个和其余的做比照，做性能等的 PK，这个通常晋升还是会很大的。要学 GC，能够尝试给本人几个题目，来管制 GC 的行为等，如果环境具备的话，的确会更加无利。
• 多和优良的程序员一起学习。我本人从多隆、撒迦身上学习到了很多很多。从很多优良的开源代码，像 Netty、OpenJDK 外面也学习到了很多很多，所以多参加一些优良的开源我的项目也是一个很好的晋升办法，看优良的书（例如并发里的那本《Java 并发编程实战》，JVM 里的《Oracle JRockit: The Definitive Guide》，《深刻了解 Java 虚拟机》等），也一样是一种向优良程序员学习的好办法。
• 多多尝试解决问题 / 故障。这相对是晋升代码综合能力十分好的一个办法，本人工作里机会少的话，网上有大把的平台，像 Stack Overflow 之类的，都是很好的练习场。

最初的最初，我还是想说，代码能力作为程序员的硬名片，始终是最无效的辨别程序员能力的货色，”talk is cheap, show me the code”，这句话我感觉是永远成立的。

作者：开发者小助手_L
原文链接
本文为阿里云原创内容，未经容许不得转载