2020年11月28日，传送与接入产品线工程师盛典在国内四大研究所同步举行，我有幸获得了产品线“十佳Committer”荣誉称号，同时，我们团队获得产品线最佳重构奖。当我上台接受表彰，我内心感到万分激动，作为团队的主力一员，我深知这些奖项是对我们团队重构实践和工作质量的肯定。

一路回望，我已进入公司七个年头了，在经历了一次次历练和挑战后，我对质量意识的理解也在不断加深，今天和大家分享我在质量方面的故事与心得。

质量意识的生根发芽

2013年，我刚从学校毕业，一进华为就被分配到了尖刀产品部门——波分产品部，开始从事光网络设备软件开发。记得入职那天，PL给我们说了几个关键信息：“波分是公司的主航道”“我们做的是通信的基础，是通信用的高速公路”“我们做的设备一旦出问题了，影响的是往往是城市之间、省之间，甚至小国之间的通信中断”……听到这些，我一边觉得自己马上要“大有可为”了，内心有点欣喜；但另一边，想到自己要做通信的基础“高速公路”，突然觉得压力好大。

我的导师海涵哥对我的要求很严格，刚见面，就给我立了“规矩”：每个问题单的修改环节，都要有清晰的问题原因和修改方案描述，要有修改文件的列表和比较报告，还要有详细的自验证报告和转测试建议……这些都需要提交给他审核，而一旦发现有任何地方描述不够清晰的，就会将问题单驳回来，让我修改。

一开始，我还有点不理解，嘀咕道：“就这一点点不清晰的，我直接跟您说一下就可以了吧，问题单走给我，我又要走半天流程。”

导师语重心长地解释：“一定要严格要求自己，问题单要能承载问题的来龙去脉。当前细节描述不清晰的，好在你记得，但是时间久了，你还能记得么？那问题单的价值就没有了，就只是流于形式了。如果问题单走到测试验证阶段，被打回了，将会被回溯的。”

那时候不懂什么是回溯，也没体验过，只从导师和老员工口中得知：如果真有问题单被测试打回来会很麻烦，开发人员会惴惴不安，感觉是很大的耻辱。经过导师的教诲，再加上前辈的经验，我对自己千叮万嘱：一定要守住质量关，千万不能被回溯，而且自己还是打造通信“高速公路”的，绝对不能掉链子！可能就是这个时候，质量的重要性在我心里深深扎了根，后来每次处理问题单流程，我都小心翼翼，深怕因为哪里遗漏或者考虑不周导致出现问题。

言传身教的力量

那时候部门倡导“一次性把事情做对”，就如“扁鹊论医”的故事，真正地“上医”治病于未发生之前，越晚发现病情，医治的成本越高。同样，在工作中，质量问题发现的阶段越晚，“医治”它的代价越大，后一阶段的代价是前一阶段的上十甚至上百倍，而且质量问题一旦流到现网，那代价相比于开发阶段，会是成千上万倍。每个环节，如果不能保证一次性把事情做对，对下游来说，都是人力时间的浪费。比如，如果开发自测试阶段不严格测试，导致有些严重的功能不可用问题或者异常复位类问题未被发现，下游集成验证部门批量升级后才发现，导致整个版本转测试流程废弃。

那段时间，我的导师正好也一直在做现网版本维护，时不时地拿现网新出炉的问题案例提点我：“你看看，上个版本修改的这段代码，上网了以后，出了XXX问题，定位了一晚上，今天要跟一线开会沟通解决方案。如果当时检视出来了，就不会有这么多事了呀！”

有一次，我负责的某需求功能还没有稳定，距离过点的时间越来越近了，周末也要奋战到转钟以后。那段时间正值元旦前后，我的导师外地出差，一个周日晚上快十点了，天很冷，实验室没有其他人，只有边上的设备风扇嗡嗡作响，我还在加着班，内心感觉无比凄凉，突然有人拍了下我的肩膀，把我吓了一跳，回头一看，原来是我的导师！他出差回来了，一听说我负责的需求还没有完全稳定，手上有几个问题单，就赶过来支援，我那个心里暖的啊！

导师做事很有一套，先根据几个问题的描述，根据影响程度大概分了下类别，对于影响功能测试的问题，当天晚上，我们一起分析原因然后讨论解决方案，修改验证完，已经很晚了，本想长舒一口气：第二天转测试终于有望了，然而我的导师还不忘构建出一个版本到设备上，全量跑了一下测试用例。用他的话说，“这样才能确保我们的修改对其他功能点没有影响，从而保证我们一晚上的劳动成果不会白费。”我被导师的质量意识震动了，也对他的雪中送炭感动得不知说啥好，他却大手一挥：“没啥，这是我们部门的传统，新员工如果有搞不定的问题，导师要陪同徒弟一起解决的！”

导师的言传身教，让我质量第一的意识更加强烈了，从此，做什么事，都认认真真，力求不返工，一次性把事情做对，从而保护自己的劳动成果。在这样的质量意识指引下，接下来的两年开发中，我高质量交付了几个波分光层软件特性模块，并且在网上运行平稳，没有出现一起质量问题。

体验什么是如履薄冰

由于在开发我做得还不错，PL和我沟通：需要培养我的全局观，了解我们的产品在现网是如何使用的，于是，2015年我以光层软件专家组成员的身份加入维护团队，负责网上运行版本的维护工作。

刚接手维护，打交道的人由测试变成了一线，再加上自己从未从事过维护工作，觉得压力和责任还是很大的。刚开始一接到一线反馈问题的电话，我就提心吊胆不知所措，经过一个月的前辈带领，加上自己不断学习摸索，慢慢地也掌握了一些方法和套路。

两年多的维护工作，体验过大冬天凌晨一两点被电话呼起来处理业务故障，周末在外面被紧急呼到公司处理问题，甚至攻关一个问题连续几天没回家。维护经历，让我深深地体会到质量工作是如履薄冰的，甚至是“要命的”。

印象最深刻的是印度某局点的现网设备要升级到新版本，我负责该局点的升级支撑。连续升级了十多天，都很顺利，然而突然有一天凌晨一点，一阵急促的电话铃声把我从睡梦中叫醒：“有个网元升级到你们最新版本，经过这个网元的业务全断了，你赶紧上来看看啥原因！”我一听，顿时心脏掉进冰窖，强行镇定让一线先别慌，赶紧打开电脑远程和一线一起把业务切换到备用路径上。考虑到当晚还有十来个网元要升级，让一线暂停了其余网元的升级。

在听了一线的操作描述后，我排查了半天，实在也找不到业务受损的原因，只能采集网元的日志信息来分析。在预料问题不是那么容易定位，估计要结合代码排查后，趁着一线采集日志的时间，我披着月色连夜骑着小电驴赶去公司。

到公司后，发现除了一楼大厅有个保安，办公楼层的走道连同办公区漆黑一片，空无一人，内心有点怕怕的。然而，时间紧迫，管不了那么多了，只能是硬着头皮摸黑打开电灯开关，坐到自己的办公位。打开电脑，平复一会后，一边分析日志信息，一边找代码可疑点。然而，一个小时过去了还是没有进展，一线在不停催促，我意识到根因不是那么容易找的，可能和特有的组网或者配置有关，赶紧求助测试兄弟到公司一起尝试复现。在经历了近十个小时的折腾后，我们最终定位到是某些特殊配置情况下才会触发的软件缺陷。之后的每天晚上升级，我们都事先采集待升级网元的日志和内存状态，分析是否存在该问题的风险，并安排专人轮班支撑，以防影响业务。连续一个月的升级保障，确保了客户网络平滑升级业务不受影响，一线兄弟也很配合，每天不厌其烦地帮我们采集日志用于分析，我很感激他。

维护的岗位上，我也有自己的一些想法：现网问题的处理时间往往很短，通常一天内要求给出问题根因分析和规避方法，对于软件类问题，还要和版本经理讨论给出补丁解决计划。一线之所以不厌其烦地催促维护人员，是因为他们需要及时看到我们的定位进展、风险是否可控以及结果是否可期。其实，换位思考，假如我是一线，直面客户层面的压力，我也很慌。所以，我们需要积极主动并及时告知一线我们的定位进展情况。

现网运行设备的维护工作就是这样如履薄冰，然而另一项工作更会让你战战兢兢——补丁开发。补丁不同于之前开发的“大版本”，它的周期很短，使用范围又广，补丁本身是为了解决现网运行版本的问题，因此绝不能引入新的问题，任何一个质量问题，都会立马全球范围爆发，给开发人员来个“现世报”。对维护人员来说，补丁的质量比“大版本”开发的要求更高。经过两年多的补丁开发工作，我深刻认识到写代码要力求做到每一行代码都要是不多不少、经得起多个人员的检视和推敲的。

在可信重构中践行质量第一的理念

2019年，在公司浓厚的可信氛围下，各团队掀起了轰轰烈烈的代码重构大潮。我有幸加入了软件学院，成为一名软件特战队队员，经过系统的学习，我深刻认识到软件重构的重要性，同时它和质量是相辅相成的，没有坚持重构的代码是会腐化的，从而导致产品质量劣化；而盲目无章法的贸然重构，又可能会给产品带来质量风险。而质量是重构的前提，不谈质量看护的重构是灾难。

2019H2版本的某新产品需要支持XX功能，该功能之前只在老的产品上具备，而老产品的代码腐化严重，代码中充斥了各种特殊处理，硬编码满天飞，一个函数上百行随处可见，有兄弟笑称：“这样的一坨代码简直是屎山！”如果直接把这样的代码移植到新产品上，再针对新产品的单板进行适配开发，代码腐化会越来越严重，更别说质量了，随便一个问题，都可能会让你陷入某个细节中不能自拔。所以，我们一致认为这个模块需要重构的。

然而这个模块代码完全没有测试用例，如果直接重构，无异于大庭广众之下“裸奔”，质量绝对是没有任何保障的。我想到了在训战中学到的“先写测试用例，再写代码”的思想，提出可以试着先写用例。

开始项目经理是很担心的：“你那一套太理论化了，没实战过。再说了，项目很紧，留给我们的时间不多啊。”

“测试用例对重构的质量保障很重要，给我两个晚上的时间，我给团队的人讲一下这个理论，可以按照这种方式感受下，看下这种方式是否对我们有帮助，如果没有，最多也就浪费两个晚上而已。”我争取道。

“那好吧，给大家赋能下，提升下认知也行。”

于是，我收集之前训战中学到的理论、案例，用两个晚上的时间，极力介绍和演示先写测试用例的好处，让大家切实感受到测试用例的威力。项目经理听了之后，也觉得不错，同意了“实战”。但项目进度紧，完全按照理论写所有函数的测试用例，是不现实的，于是，我们对所学的理论做了一些调整：以大颗粒的功能点为单位，构建测试用例来保障质量。借鉴这种思路后，构筑质量防护网，每写一个功能点，就写几个测试用例；每写几个函数，就跑一下测试，让大家对刚写的代码做到心中有数，这样也更有信心了。

在有质量防护网的保护下，我们大胆进行框架的优化，提取了一些公共的框架代码，通过屏蔽设备差异，实现多个产品共用一套代码，并将XX模块代码量减少了一大半。由于有测试用例的看护，我们版本转测试质量很高，版本很快就稳定了，进度上也得到了保证，重构后的功能初试牛刀就取得了商用测试成功。这种开发交付模式的成功探索也为提升重构效率和重构质量提供了可借鉴经验，目前已被复制并大范围推广到其他重构项目中。而通过这次实践，我深刻体会到了重构要以质量为本，以质量为本方能事半功倍。

作为公司尖刀产品的一员，公司值此艰难之时，软件的重要性更加凸显出来，如何在现有条件下依旧打造一流的产品，是我们每个软件人应该思考的问题。高质量是一流产品的基础，我们要时刻将质量牢记在心中，并将质量意识落实在工作中，这样才能做最好的软件！