华为24年，49岁，他一直在编码

/***

学习前辈的成功事迹，找到自己发展的方向，今天和大家分享华为程序员的故事

***/

“阮师傅，你准备啥时候退休啊？”这是很多同事见面常问我的一句话。也有不少人问我，为什么能在一个领域的研发坚持这么久？我每次都回答：“路由器我还没干够呢。”

可能有人会觉得这个回答很官方，但对我来说，是真心话。
　　

在路由器领域，可能有很多人都认识我，因为我在这块工作20多年了，而且一直在研发一线。与其说是适应或者习惯了华为的研发文化，倒不如说，这些年华为路由器业务从最初的一无所有到如今高速发展，我们经历了一个又一个软件技术的挑战。这些挑战，让我可以发挥自己的特长和优势，更引领我一路向前，不断发现不足，缩小差距，我更期望有生之年能尽绵薄之力和公司同仁一起推动华为路由器软件做到世界第一。

1996年，在某国企学校当了两年老师的我，正在苦恼学校所学的专业知识得不到发挥，一次周末和在华为北研所的同学聚会，同学说，华为的技术氛围好，给的薪酬也不错，可以考虑看看。当时华为还不是很有名气，北研所也仅成立一年，只有二三十号人，IP（数据通信）业务刚起步，但路由器技术在业界相当于现在的AI，机会难得，让一心想做技术的我心动了。面试过后北研领导问我能不能来上班，说转正后月薪XXXX元，当时我的月工资不过几百块，中关村平均月工资也不过一千五。无论是技术前景还是薪酬对一个单身汉都充满了吸引力，我果断辞职加入，从此一头扎根路由器领域。
　　

当时北研所不到10%的人懂数据通信，我对网络协议和网络架构也是一知半解，只记得读书时网络课程讲过网络分7层，就在一张白纸中开始了数据通信设备的开发。导师给我拿来三本IP“红宝书”和业界的一些代码比如协议栈，一个月的时间，我70%的时间都在通读代码，如饥似渴地学习，其余时间就是和同事们切磋。那会两人一张桌子，像高中时的课桌，遇到不懂的，抬头就能相互交流。我发现周围的同事也和我相似，年轻、有活力、开放、好学，每天除了看红宝书，就是编码，常常回去时已是半夜，两个礼拜就能看完四五万行代码，总算是入门了。
       

在研发这个大熔炉中，当时的我们每个人都投入了百分百的热情。在你追我赶的氛围中，除了个人技术能力快速提升之外，年轻的我思想受华为文化熏陶也变得开阔和成熟。至今记得有一篇你是搬石头还是盖教堂的文章，讲述人与人之间的区别，也许只是干活时内心是否有一个“教堂”。当我工作中遇到挫折时，我就经常问自己当初的目标是什么，为什么要做这项工作，不会因为暂时的挫折感到迷茫。

从1996年到2002年近7年间，我做过小路由器，做过VRP协议平台，下一代IP预研等，如果说预研是让我眼界更开阔，小路由器还只是“小打小闹”的话，从2003年开始参与高端路由器平台开发，就是扛着枪打大仗了。
　　

路由器软件开发分为两部分，一部分是通用的VRP协议平台，一部分是要落地到产品中，通过转发平台实现通用软件和具体的硬件产品适配。2003年，8090路由器第一个版本开始开发，这是公司第一个10G平台。从3月开始，四五十人集中在深圳封闭研发，我和北研团队六七人负责其中的“转发”业务。当时“转发”业务是用微码做的，由于对微码开发方式的不熟悉，加上通用平台和微码也没有对接过，新的业务场景、新的开发模式，不同于以往的编程语言，经验的不足，让我在进度上严重拖延了第一个版本的过点时间。测试每天发现各种各样的问题，比如端口反压被阻塞了，转发线程死锁了，转发性能不达标等等。我只好不停回溯方案，重新讨论设计落地新的方案，部分模块重写代码，花两三周才彻底解决。从3月到9月，几乎每天泡在实验室到凌晨，总算和大队伍合力做出了第一个版本。
　　

我自认为，虽然版本做出来了，但过程十分煎熬，这是我在华为经历的第一次比较大的挫折。当我对大型路由器软件熟悉之后，回看犯的错，都是很低级的错误，经验不足所致。也是走过弯路才更让人自省，代码可以重写，但方案如果错了，影响的将是版本的方向。若不能及时修正，只会花费更多的时间和精力在错误的路上越走越远。
 

一直以来，我都知道自己是一个情商和智商都非常普通的人，放在人群中平平无奇，对于技术，也没什么诀窍，就是“勤能补拙，熟能生巧”，不断地学习，不断地积累，不断地在挫折中总结分析，重新找到正确的方向，并沿着这一方向前进。
　　

从2003到2013的十年间，我经历过落地十几个关键新特性、帮助CPU性能优化从以往的100%降至5%的成功实践，也品尝过架构设计没有被选用的沮丧，还曾远离过开发去做技术规划，从系统、协议、产品转发到预研，除了硬件外，基本涉猎了路由器的所有模块。这期间也有机会成为管理者，但我认为只要能为公司做贡献，管理和技术都一样，相反我更喜欢技术想法能实现，开发落地到产品中的那份踏实感。
　　

可能也是因为这份“傻气”，2013年，V8平台准备落地路由器的BRAS产品，主管对我说，路由器还有技术要开发，问我愿不愿意从预研回开发。路由器软件平台凝聚了我司IP领域顶级专家们的经验和智慧，是路由器产品核心竞争力的关键武器，经过多年的耕耘，业务已经非常成熟，但由于其规模大和复杂度高，在产品的应用中，也面临着开发效率和开发成本的挑战。这感觉就像是“大象在跳舞”，我自认为可发挥空间并不大，但心中对开发的执念还是占了上风，于是我选择了回来。
　　

后来的事情也证明，我当初的想法是错的。只要你愿意，在成熟领域依然能发现很多创新机会点。

2015年9月，产品线DU组建了系统支撑组，我作为3名研发场景师之一，专门负责效率提升和架构优化工作。
　　

我们发现，FES（转发适配）模块成为版本商用的一个高风险点。由于海量的数据洪流冲击，一旦链路出现中断，网络拓扑发生变化，FES模块没有办法做到快速切换转发路径，导致网络业务和协议中断。这个问题不解决，产品将无法商用。但FES是一个公共模块，有七八年历史了，随着业务的不断增加，该模块功能越来越复杂，任何一个小改动都要小心翼翼，稍有不慎就有可能引起已有的业务不可用。因此，当我们提出架构整改动议之初，就因为风险巨大被否了。部门还有一个思路，保留现有的功能不变，重新开发一个类似的模块形成旁路。这样的“另辟蹊径”，意味着以后要维护两套方案，维护成本和难度都成倍增加。
　　

基于开发成本和效率考虑，我建议在原有架构基础上进行优化和改进。很多人认为风险太高，但我认为只有痛下决心优化，才能“一劳永逸”最高效地解决这个问题。讨论来来回回，谁也说服不了谁。后来，DU领导拍板，成立红蓝军设计小组，并行开展两种方案的设计，最后PK。
　　

作为蓝军，我们提出了部分重构的方案，既不是推倒重来，也不是一个个小点改进。在相同的时间内，我们团队将原来5万行的代码重构了一万行，新增一万行代码，在性能、易用性、可服务性和可扩展性方面更胜一筹，最终方案被采纳。版本上网后，也经受住了现网的考验，没有出现严重问题。

有人曾问我成为专家有什么经验，我说，“关注产品全局，敢于担当”。除了现网痛点，作为一名研发老兵，我常常关注软件工程技术和产品工程管理，站在开发角度，对软件架构和软件工程效率进行诊断和改进，主动伸出手去，提前识别问题，帮助大家提升研发效率。
　　

我们的版本是C语言，内存访问异常和内存泄漏问题让人非常头疼。内存问题在测试阶段很难被发现，而一旦漏到现网，就会导致严重的后果。为了解决这个问题，我们引入并适配了ASAN工具，将这个工具集成到持续构建工程，通过部门的网络质量监控系统“鹰眼”实现自动告警，让内存问题在开发阶段、测试阶段无处遁形，解决了上百个内存问题，形成了坚固的内存问题防护网，使得路由器开发效率得到很大提升。
　　

路由器软件平台架构是封闭的，我提出，“能分能合”的系统才是一个好系统，打破路由器软件单一的完整大包开发调测方法，开发了增量构建和增量替换等特性，这样避免每次调试都需要构建和加载整个大包（这个过程非常耗时），为开发人员调试时节省了大量的等待时间，提升了调试效率。我们设计和开发了“转发适配”独立仿真平台，使得转发适配子系统代码能够独立仿真和调试；规划了路由器V8平台的服务演进架构，将V8系统拆分成若干个大的服务，使得各个服务能够实现“架构独立”：独立开发，独立部署和运行，独立验证……
　　

改进无止境。坦白讲，我们在路由器软件技术领域，离世界第一还有不小的技术差距，业务也相对保守和慢一些，我们还有很大的成长空间。现在的我，每天想的就是怎么去发现机会点，让V8的架构改进一点点，再改进一点点，有更多更快的技术创新冒出来。
　　

一个人的力量也许有限，路由器领域的机会点也可能相对少一些，但我始终认为，不管做什么，不管在哪个领域，都会有技术挑战和创新机会，只要你愿意，只要坚持钻研，就能发现新的机会，也许就能创造新的未来。