用心“雕刻”每一个软件作品

用心“雕刻”每一个软件作品

杨学伟口述  李晓婷整理

　　每个人都有自己的发展方向，也许随着时间的推移，方向会不断地调整和变化。我也没例外，经历了一番曲折后，又回到了技术的老路。毕业后我在一家公司从单片机软件做起，从汇编到C语言，从硬件到软件，从项目经理到产品经理，轮回了一圈，最终发现自己还是对软件技术更有兴趣。2010年进入公司后，重新开始我的软件之路，它像我一个多年的老朋友，彼此在欣赏中一同成长，一起探索着软件改变世界的奥妙。

“世界没有BUG，问题在于自己。”   
　　已经忘记在哪本书上看到这句富有哲学意味的话，帮助我加深了对做软件的认识。
　　入职后我被安排在ONT（光网络终端）维护组做需求开发，当时导师安排我做一个控制RF（射频）模块的命令行，其实就是在现有的命令行框架上增加新的命令，通过底层驱动来控制射频模块。这对有数年开发经历的我来说并不难，我正好也借此熟悉下代码结构。很快，我就拿着写好的代码进行调试，结果令人纠结，射频模块始终没有反应。我调试了整个控制流程，没有问题；又把相关的芯片资料研究了几遍，编码设计没问题；硬件检测也没问题。
　　咦，是CPU的输出有问题？或者是芯片资料写错了？还是其他什么原因？我心里有种种疑惑，但找不到原因，只好求助FAE（芯片技术支持）。谁知我一问，FAE马上 “反弹”回来，他认为这个问题比较低级，一定是我没按照手册进行配置。
　　“怎么会呢？手册我都研究了不下十几遍，没准是你们芯片资料写错了，或者芯片坏了？” 我当时对自己的认识很有把握，直接“怼”了回去。
　　也许是我的执拗让他有些意外，他和我开始一项项认真比对寄存器设置，结果发现问题还真不在我这儿。“那我使用芯片的demo板测试一下吧。”FAE也拿不准了，后来他在demo板上验证发现，此射频模块控制确实有问题，找芯片研发人确认，果然是芯片逻辑电路存在问题。为此，我使用规避方案解决了该问题，而我也因为发现了一个芯片逻辑bug，获得了来公司的第一个及时激励。
　　虽然这个问题很简单，但也说明这个世界上没有真正的错误，只要自己去发现，就一定可以解决。
　　通过软件发现硬件bug，这件事使我认识到，做软件有时是需要“执拗”的，因为软件世界总会存在bug，它是人做的，就会受到各种因素影响，会考虑不周，会犯错，所以加强内功，做足功课，遇到问题大胆假设，小心求证，最终才可能减少bug或者到达“没有bug”。

在效率提升中谋发展
　　做接入终端产品，虽然我们在全球市场占有率早就第一了，但居安思危，如何可持续发展，提升自身竞争力，开拓更为广阔的市场？
　　2017年，部门组织结构调整，将不同部门的3个接入终端产品合并成固定终端产品部。3个产品的代码独立，开发人员也是独立的，各产品之间存在很多重复功能，整体开发效率可想而知。代码融合归一是大势所趋，但工作量大，且各产品迭代开发任务紧张，如果整合架构，质量如何保障，还不能影响正常的迭代交付，这让我们不敢轻易动手整改架构。但时间拖得越晚，人力和效率损失就越大。
　　“这真是一个艰难的决策”，领导把这个艰巨的任务交给我来整体负责。“任务很有挑战性，迟早要做，咱就来一次彻底的吧！”由我带队的MDE（模块设计师）迷你战队承担了这个优化项目的开发。经过了多次激烈的讨论，画了无数草图，最终我们一鼓作气，将阶段性方案设计框图做出来了。我们满心期待一件伟大的“艺术品”即将诞生，但心中的“得意”没多久就被一盆冷水浇灭了。
　　组织大家评审时，各种声音冒了出来。A方案认为，组件的范围还是应该大一些，从上往下一刀切；B方案认为，组件只负责业务层，底层还是应该统一。大家都有道理，各执一词，那到底哪种方案最好？与其争论不休，不如打开天窗，站在巨人肩膀上借力，最终我们参考了业界终端的主流架构，选择了B方案。但在讨论底层框架时，我们又一次在是否封装HAL（硬件适配层）上出现了分歧。如果增加HAL层，可以简化业务组件的调用，封装硬件差异，但需要把所有接口重新封装一遍，会加大系统调用负担。为了让产品更有效支撑多款硬件型态，我们最后采用了独立的HAL层。方案确定后，大家一起对代码进行大刀阔斧的优化，数个月前我满心期待的“艺术品”，终于在大家的手中被不断地打磨，渐渐将她的精美呈现出来，最终成功实现了一条主干支持3个产品族300+款盒子的交付，等效人力减少35%，支撑开发管道增长30%，TTM（Time to Market）缩短30%。
　　今年，我们持续提升产品生产效率，我组织MDE团队开发了独立装备版本，将产线终端启动时间由平均45秒缩短至20秒。在满足产线硬件测试场景下，进一步解耦和拆分组件，在主干代码基础上，做到一个装备版本支撑几乎所有硬件主板测试，按照年发货千万级别计算，生产效率得到了极大提升。
　　效率是竞争力的源泉，通过架构的优化、产线效率提升、运维效率提升，我们的竞争力在不断加强。下一步，我们将持续挖掘软件编程效率，我准备将常用算法和通用编程流程标准化和模板化，开发时可直接使用，让编程有更多套路，使复杂问题简单化。另外，还要引入一些新的工程工具方法，在架构守护、代码开发、编译上进一步优化，提高调试效率。
　　接入网产品市场很广阔，竞争也越来越激烈，需要我们通过自己的努力，不断提升接入产品的广度、宽度、竞争力，智慧家庭、智能宽带方向机会和前景十分巨大，我们需要坚持不懈，一步一个脚印，才会越走越精彩。

软件开发就像建房子，一定要有追求
　　2018年初，固定终端发展品质宽带项目，需要在终端上做数据采集上报，我承担了采集中心模块的设计和开发。之前我们已经实现了在演示版本上基于二进制文件方式的上报方式，虽然效率较低、扩展性不好，改改还是能用，但考虑到业务场景，采集系统的秒级采集数据多达几十项，而且会持续增长，采集效率非常关键，如果还是采用现有的演示版本方案，将会给以后扩展带来极大束缚。于是，我重新设计了采集方案，采用了在互联网公司最流行的GPB序列化编码技术，优点是编码开销小，能有效减少传输数据，并且支持兼容日后采集参数随时扩展，极大地提升了可维护性。
　　我找来SE、领域专家评审，听取意见，大家都认为“数据采集是个系统工程，效率非常重要，架构一定要设计好，要做就要做到最好。”在进一步和业务模块讨论数据采集细节时，我发现还可以进一步优化，整体效率还可以提升。之后，我快速完成了新的采集框架的开发，保证了交付和现网运行的高质量。
　　由于设计不够合理导致系统的累赘和负担，我们已经遇到过太多次，既然能提前预见，那就一定要及时采用更好的设计或重构，防患于未然。
　　软件开发就像建房子，如果需求简单，只是盖平房，无论是使用砖瓦混凝土还是框架结构，都能满足质量要求。但如果需要盖高楼，又要牢固，那就不能用一层一层堆砌的砖混方式了，要使用坚固的钢筋混凝土框架。做软件也是如此，牢固和可扩展更为重要，需要采用最合适的技术框架，一定要有自己的技术追求。
　　说到追求，我的体会是，首先要追求代码的结构，无论是大架构还是小模块、函数，都要有一个追求完美的心态，先把结构想清楚再动手编码，就是说要有良好的设计，不能一上来就直接开干，最后弄得一团糟，也给后续维护带来麻烦。其次，追求代码的质量。代码要写得工整、美观，短小精悍，细节好，符合smart原则，看上去赏心悦目，越简单越明了。软件一定不是追求复杂，把复杂的东西简单化，就是完美的追求。第三，追求也体现在坚持上。做软件时间长了，比较枯燥，但新技术会层出不穷，需要及时学习、充电，跟上时代和前沿技术的步伐，将新的软件思路、方法、技术应用到现有产品、代码结构上，与时俱进。

　　梦想不在于伟大，在于坚持。一旦你认准了方向，就要坚持到底。这些年，我也一直努力做一个“坚持”的程序员，在代码一线持续耕耘，用心去雕琢一件件软件“作品 ”，大至宏观的主题，小至微观的细节，都需要一丝不苟，精雕细刻，才能最终成就完美的作品。

本文为《华为人》版权所有，未经允许不得转载。如需转载请联系编辑部hwrb@huawei.com