60岁，我还想每天坚持编码！华为软件王是对待编码的……

有熟知的同事说我是软硬皆通的“万金油”，是某些领域硕果仅存的“活化石”。但在我看来，只是因为恰巧持续几年在同一个领域摸爬滚打，有更多机会钻得更深一点。

兴趣，从和网吧网管“斗法”开始

2005年我入职公司，从此开始了和传送网的缘分。其实，我大学的专业并不是软件，但自从在课上接触了代码，我就发现这玩意儿能做的事情太多了，简直让人欲罢不能。

为了在代码的世界里自由驰骋，图书馆和网吧成为了我学业之外的“常驻地”，从Pascal，到C/C++，Windows API/COM，再到Java，只要看下去，就停不下来。为了检验自己的技术，我还经常和网吧网管“斗法”，破解网管软件。记得有一次，我架设了个私有网站，在上面放了一段JavaScript脚本，激活了网管软件屏蔽的“运行”对话框，重新控制了整个系统。这一招躲过了好几个版本的网管软件升级，让我嘚瑟了好一阵子。

正是因为自己对软件的“痴恋”，让我对写代码这件事有着天然的向往。热爱什么，就选择什么。我一毕业就成为了一名程序员。

重构代码，就像在钢丝上跳舞

那时迭代还没流行起来，产品刚过TR5，在瀑布流程下这就代表着产品质量相当稳定。所以，每天除了学习产品知识外，我就是专心看代码。

谁知这一看，我就动了改代码的心思，因为我发现有些代码完全是大段落的复制粘贴，中间偶尔有几行差异点，修改问题时很难做到一次改全；另外还存在大篇幅的switch case，复杂度高的同时，处理流程也没有统一模式，新写的代码不管往哪加，都感觉很别扭。

我和导师商量：“能不能重构下代码？“导师一口答应了：“不过本地先改好了验证，下个版本再择机合入。”得到应许后，我一气呵成地抽取公共代码，统一接口参数，将switch case换成表驱动方式。

很快，下个版本就这么在期盼中来了，导师看我对代码这么上心，还交给了我一个新特性的开发任务，为此我复用了之前重构的成果，“玩”了下套路，很快就完成了开发。

当我满怀信心的将代码提交给测试时，原以为不会出现的低级问题冒出来好几个。咋回事？这不是打脸吗？为啥流程都梳理几遍了，转到测试还有漏网之鱼？堵住漏洞后，我仍然不安：到底用什么方法才能保证代码的基础质量？作为软件开发人员面对自测试，竟然是心有余而力不足。

后来公司引入了LLT（low level test）这个武器，专门解决代码的及时、轻量而又可持续的自验证，我们团队有幸作为试点团队，专门配了一个外籍专家手把手地教。于是，我操着一口蹩脚英语，向外籍专家“取经”。经过数十次的探讨，我发现外籍专家对被测代码边界的划分很有套路——用稳定的接口来作测试边界，基于测试边界来写用例，认为用例是测需求而不是测已经写好的代码。这种加上黑盒测试思路的白盒测试方法让我恍然大悟，既能享受白盒测试带来的方便构造任意异常场景的好处，又能享受黑盒测试带来的测试界面稳定、用例可继承的好处。理解这些后，我成了LLT坚定的拥护者。

后来，我在团队的支持下，先后主导开发出模型驱动的LLT用例自动生成的工具、自动打桩的工具。比如，在团队有意愿做LLT时，必须先搭建好LLT基础工程，常会遇到成千上万链接不过的情况，需要逐个打桩，动辄要专人花几周时间完成。于是，我们开发了自动打桩工具，半小时就可轻松搞定。

在我看来，重构代码就像在钢丝上跳舞。在享受重构带来快乐的同时，也需要用各种手段铺垫好防护网，避免掉入功能前后不一致及质量下滑的深渊。

不管角色怎么变，写代码这件事不能丢

2006年，数据业务开始大力开发分组特性，我也从NP驱动软件的骨干转身为L3VPN特性的PL。

一开始，我对PL也没啥概念，分配工作任务还好，最怕的就是管人，尤其怕给兄弟们打考评。幸运的是，当时我们团队技术氛围浓厚，我以平时的代码交付结果作为绩效考核的衡量标准，再辅以我在团队内的技术威望，打考评这件对我来讲最难的事算是勉强过关了。

当然，PL也是有很多便利的，可用的资源比单枪匹马时要多了，只要有想法就不怕干不成事。PTN第一个项目组级别的“HLT（high level test）自动化工厂”，就是我主导搭建的，一举解决了发版本需要所有组员留守搞自测试的困境。在组内高效工作的氛围下，我也解放时间承担起MDE（模块设计师）的角色。在这期间，我发现各特性都有自己的硬件资源管理算法，重复实现，接口不一致，且大多采用遍历算法，效率不高。于是，我总结了已有特性的所有资源管理需求，结合bitmap、栈、索引几种技巧，完成了接口统一的资源管理算法，还凭此斩获了网络举办的第一届“十大金码奖”。

2010年，由于业务的需要，我又做起了专职MDE的角色，加入了新的团队，心里偷着乐：不用管人，又能利用MDE的影响力在项目组推行各种改进措施。当时新团队正处于第一个版本，需要补齐大量特性，我们不得不频繁发布版本，而每一次版本构建的时间又很长。增加日志后，我发现时间主要消耗在编译阶段，就想解决这个问题。要不开源节流试一试？我一方面清理无效的编译过程，一方面在网上搜索能并行编译的工具。可前者节流仅缩短了10%的时间，距离期望还有很大差距。

所以我把更多精力投入在开源上。就在我找到网上的工具，以为可以拿来主义的时候，却发现工具过于“傻瓜”，需要手动构造并行任务。为了让工具更智能，我边学边做，经历了很多第一次：第一次深入研究makefile，第一次尝试预编译，第一次复杂的运用批处理……经过一周摸索后，我终于把自动化并行的脚本做出来了，版本效率提升了3倍。

俗话说，挑战和机会是对孪生兄弟，工作也是如此。在我看来，软件工程师本来就应该是与时俱进的，不管环境怎么变，角色怎么变，始终要摸清业务的需求和约束，确定输入和输出，然后用软件把它实现出来。

打开天窗，才能发现自身不足

2017年，我接任了传送网的首席程序员，成为传送DU的首席committer。

我有幸接手了D3A架构优化项目。项目整体分为两大块，一是实现软件上的抽象转发建模，做到修改硬件方案对主机软件“零感知”，另一个是让微码能够按功能块来拼装，具备被软件定义的能力。只要实现这些，更换硬件的工作量至少降低50%。

这个项目对于我们整个团队意义重大，能彻底解决软硬件解耦的难题。在这个过程中，我不仅体会到“开天窗”的美妙滋味，也有幸交到了美研所的业界顶级专家罗勇这样的朋友。

一开始，我根据已有的经验判断：微码咋可能做得这么灵活？转发性能是第一优先级，跳来跳去肯定性能不达标。我和美研所的专家各种PK，发现他总是先让我们讲清楚需求，然后他出解决方案，我们叠加需求，他就再出方案，反正总是难不倒他。

比如，我们提到分布式转发的时候，主机由于上下行单板的资源交互，需要管理差异化的资源，达不成主机软件零感知的目标，咋搞呢？专家一分析：“为了让主机看到一样的转发资源，微码可以帮忙加映射。”但是这就会多查一张表，影响性能咋办？“那就合表嘛，这里增加了开销不一定非得在原地想办法。我们面对的是整个系统，拆东墙补西墙有时候也会是个好方法。”总之，不管我们的问题是什么，美研所专家都能逢山开路、遇水搭桥，几个回合下来，我彻底服气了。

后来，我才发现这场景似曾相识，方法都是细化打散了再排列组合。这不是和我以前给别人出主意的场景一样的吗？虽然我在所属领域自认为还算有经验，也帮组织解决不少问题，但打开天窗一看，发现依然是井底之蛙。所以，老板讲要经常出来喝咖啡，吸收外面的能量，经过这事儿我是信了。

当然，问题是最好的老师，你在帮助别人的同时，也是帮自己提升经验值。

我的偶像安德斯·海尔斯伯格（Delphi、C#和TypeScript之父）曾说过，程序员是最好的职业。第一次看到这句话时，我就很受鼓舞。代码的千变万化带来了解决问题的无限能力，让我体会到不可言喻的美妙感觉。13年来，我每天都在和代码打交道，却总是乐此不疲。如今，在武汉，在波分，在公司软件服务化浪潮中，我依然利用代码的魔力，让更多人因写软件变得更快乐。

热爱是点燃激情的火把，写代码可以是一辈子的事业。对我来说，如果到了60岁，还能每天坚持编码，大概就是最大的幸福了吧！

来源：心声社区