这群编码达人参加这个比赛后......

编者按

　　聚焦编码,激发广大开发者潜能，持续提升价值贡献，网络产品与解决方案公共开发部自2017年开始，以“自主、释放、贡献”为宗旨，率先在MANO产品部开展了万码奔腾活动，2018年继续扩大活动范围，覆盖了五个PDU，有近四百位软件开发者主动报名参赛。2019年万码奔腾已火热启动，覆盖了七个SPU/PDU，超过500名软件开发者报名。

　　“万码奔腾”改变以往自上而下“分活干”的传统，搭建自下而上“要活干”的舞台，围绕研发效率和产品价值，使能开发者自主思考并实践。今天我们为大家分享其中三位参赛者的故事。

一波三折，我是全栈小王子

（汪文威，半年赛季内个人完成工作量1.91万行，缺陷率2.1个/千行，三次获得月度TOP30“快码奖”）

　　2016年2月，华为在西安电子科技大学宣讲“软件精英挑战赛”。在计算机专业上研二的我，内心蠢蠢欲动，希望接触下这家全球500强的企业，也期望借助挑战赛，检验并提升一下自己的编码能力。经历了初赛、地区终赛、全国决赛，我最终晋级全国32强。在参观了公司深圳总部后，我决定成为一名华为人。

　　新员工转正后的第三个月，我所在的VNFM（网元生命周期管理）团队要切换高斯数据库，交付时间已定为一个月后，但涉及的五个项目组都没有高斯数据库开发经验，也没有验证环境。版本SE也未做过高斯数据库切换，完成了需求澄清后，实现细节只能靠开发摸索。配合验证的环境涉及版本经理和周边协调，搭建完成时间预计在两周后，按这个节奏计划很可能延期。看着大家既着急又不知所措，我决定自己摸索数据库验证的方法，确保大家能边开发边验证，节省出时间后应该能赶得上交付期限。

　　团队作战优于一个人单打独斗，手头工作之余我沿着高斯数据库驱动的线索，厚着脸皮找了CloudSOP平台、高斯部门以及我所在团队的工程组专家，了解到手动部署微服务流程、创建高斯数据库方案，以及在现有环境上如何部署数据库等，利用两天晚上琢磨出验证方案雏形。前进的道路总是曲折的，当我满怀信心地和需求SE、项目PL沟通验证方案时，满以为会通过，没想到他们认为有风险，方案验证不仅耗时比较长，而且以历史经验看大概率会失败，他们建议等版本验证环境搭建好后再做开发验证更保险。

　　没得到他们的支持，我有点沮丧，是我“too young,too simple”了？但是内心又不肯后退，一个声音告诉我：我是做过前期可行性分析的，还是再试试看吧。于是，结束自己每天的任务后，我都会分出一部分精力尝试搭建基于高斯数据库的验证方案，从部署产品微服务、到端到端验证数据库语法的正确性。期间又牵涉到没有接触过的高斯数据库创建，我利用新员工阶段自己创建过mysql数据库的经验，加上查询文档，尝试了几次后，数据库也创建好了！

　　成功需要不断披荆斩棘，我又面临新的问题：微服务部署的数据库从原来的mysql变为高斯后，涉及的数据库相关参数配置都需要调整，这个需要数据库DBA的积累，前辈们说的风险也在于此。但我没被吓倒，查文档、求助周边同事，我将每个步骤中涉及mysql数据库替换为高斯数据库相关配置，前后投入四天时间，最终成功搭建起基于高斯数据库的开发验证环境，并将整个过程整理成了一份验证指导。

　　看到了实实在在的验证环境，需求SE、项目PL都很惊讶。在我“攻关”的同时，团队也在用原方案按部就班切换高斯数据库，但由于开发代码合入前无有效验证，导致验证环节问题层出不穷，开发效率很低。现在开发环节就有验证环境，开发人员边开发边验证，快速反馈快速迭代，有效提高了数据库切换过程语法准确率、代码合入质量，最终将五个项目组原本4周的开发联调时间缩短为3周，推进了数据库切换整体进度。

　　有了这次经历后，我体会到“走出庐山才能看清庐山真面目”，日常需求开发经常会产生需求开发偏差，这是因为开发实现仅仅是整个需求生命周期的一环，如果我们不了解需求的原始背景、测试方案以及验收标准等其他环节，就可能导致编码多次修改、问题单引入过多等问题。只有沉下心，了解需求涉及环节，才能真正把需求开发做好。

       这之后，我愈战愈勇，承担前后台开发，具备开发自测能力，掌握云龙流水线构建、产品版本安装、北向NFVO搭建、南向网元部署，并担任新员工培训讲师，我被身边同事戏称为“全栈小王子”。作为一名新人，一开始我担心自己很渺小、和老员工差距很大，经过一年的努力，我能感觉到这个差距在缩小。华为给了我们新人敢想敢干的空间，谁说几年后，下一个软件王不是我们呢？

8年了，我一直都在

（刘瑞妮，半年赛季内个人完成2.7万行工作量，缺陷率0.35个/千行，获得万码奔腾最高荣誉“头码奖”，部门“汗血宝码”奖）

　　2017年年中，休完产假回到工作岗位时，一切仿佛回到原点，需要重新开始。

　　休假期间部门调整重组，新团队、新同事，项目也是我没有丝毫经验的网管软件。如何快速进入工作状态？如何兼顾工作与家庭？我的优势在哪里？新手妈妈有点茫然，但也是产假期间，新手妈妈的角色和历练让我心态上发生了很大的变化，与其担忧紧张，不如振作精神奋发图强，办法总比困难多！

　　适逢传统网管向云化网管演进，云化网管是基于微服务的分布式网络设备管理系统，相比较传统网管架构，具有高可靠性按需伸缩性，且具有快速迭代、自动化部署、快速发布功能等优点。虽然我对传统网管没有经验，但是对微服务开发并不陌生。找到了自己的优势，我给自己定下一个个阶段性的小目标，如一周通读代码熟悉新的体系结构，两周梳理出资源采集流程，一个月时间总结出不同下游产品到平台的数据流程等等。

　　这样坚持了两个月下来，关键技术和关键流程都已经掌握，我渐渐地找到了自己的位置，完全进入了工作状态。

    “取法乎上，仅得其中”，我相信只有多做那些需要踮起脚尖通过努力才能做到的事，只有承担得多了，才能有所成长，有所收获。

　　我主动承担了资源EAM（Element Access Management）责任田的owner。资源服务是网管系统的基础核心服务，管理所有接入网络的网元及下级资源，就像是一个数据仓库，而EAM服务负责管理这个仓库中最核心的网元数据。

　　网管目前面临新的挑战，下游提出要支持30W大网的规模，这对EAM的接口提出了更高的性能要求。而EAM演进涉及规格点多，规格补齐工作量大，我需要同时兼顾规格不丢失和性能达标。

　　举个例子，在要支持多数据库的需求交付过程中，我牵头了sybase数据库切换，一方面要支持不同数据库上业务功能的平滑切换，牵涉120+数据表，另一方面要及时评估出数据库对接口性能的影响。当时我发现，与其他类型数据库相比，sybase数据库在分页查询方面性能较弱，我和小伙伴讨论了多套方案，尝试过临时表、存储过程、从数据库缓存中提取数据等等，无数次PK和尝试，最终找到了最优的解决方法。完成需求后，我总结分享了一套案例。后来周边的同事遇到sybase问题都会来找我咨询，这让我还蛮有成就感的。

　　EAM需求交付并不像一些产品交付，有时候可能被某个大的难点“卡”住，我们遇到的多是一个又一个细小但有些棘手的问题，比如高并发下数据库CPU高、内存基线不达标等，每次都需要有很多的耐心，去一个又一个解决。也因为这一个个点的积累，最终由点到面，提升了自己的技术能力。

　　平常工作中我也会留心影响工作效率的痛点，比如微服务出版本，动辄二三十分钟，我优化了最耗时的cobertura配置，重构了最耗时的UT用例，最终为版本节约了近40%的时间。

　　入行八年，切换过部门，变换过业务，彷徨过也失落过。曾有朋友建议，程序媛太辛苦了，换个轻松的岗位吧。夜深人静时，回想着一路的点滴过往，编程仍是最能带给我兴奋感、成就感的事情，作为一个程序媛，能一直从事自己所热爱的事，值得坚守与执着。

 做解决疑难杂症的“定海神针”

（郭放，获得万码奔腾代码质量最高荣誉“好代码奖”）

　　2013年底，项目组有两个严重的core dump问题没有进展，此时离过点只剩两周时间，DI（遗留问题密度）超标，主管安排我攻关。

　　由于是偶现问题，定位了三天也没有找到根因，只在做这一件事情却没有任何进展，我内心觉得很愧疚：是不是白拿工资了？

还好主管带我找部门高手求助，有兄弟向我介绍了思维导图，有兄弟向我推荐了各种内存工具，虽然他们并没有直接帮我定位问题，但是从他们那里我学到了方法与工具，打开了思路，最后定位出了问题原因。由于工具熟练了，很快又定位出另一个问题的根因是野指针踩内存。当时心情别提多激动，所有的煎熬都是值得的，这两个问题的解决让项目组DI在过点前达标，没有阻塞版本发布。

　　这次攻关让我对疑难问题定位产生了极大兴趣，也建立了不小的信心，遇到疑难问题不要畏惧，全场景定位，加上查找资料、使用工具一定会快速找到问题根因。

　　这件事也让团队主管和兄弟们对我刮目相看，渐渐地，团队里的各种疑难杂症都来找我了。有一个周四，项目组同事来求助，反馈sqlite版本升级后在执行建表语句时总是报错，实在搞不定了，希望我来“救场”。面对这样的信任，我想赶在周五下班前定位出问题，但进展不理想，周五晚上我躺在床上反复琢磨也没睡踏实，于是周六一早就来到公司加班，调试了sqlite源码，终于在下午定位出原因，是我们编译未加入某个可重入参数导致。难题解决，我开心地回家早早休息一觉睡到了天亮。周一来上班，同事给我抛来佩服与感激的言语及表情，我还是蛮有成就感的。

　　就这样，解决疑难问题的信心越来越足，兴趣也越来越大，我也养成了深入钻研、及时总结、及时分享的习惯，日积月累，便提炼了一套方法，在部门树立起了技术领导力的形象，被大家戏称为定海神针的“放神”。

　　2017年后开始投入某业务开发，这块业务近几年发展很快，软件规模从十万级别猛增到百万级别，大量人员参与需求的交付，也带来了一些副作用，开发人员大量出现组网分支上的问题，例如忘记同步遗漏问题，例如库不匹配导致服务失败等，增加了大量维护成本，严重影响了开发效率与产品质量，到了历史欠账不得不还的地步，借用一句电影台词：“出来混，迟早都要还的”。

于是，我主动整理了代码清理的列表，并抱着试试看的态度跟主管沟通重构的想法，没想到主管一口就答应了，随后也得到了整个团队的支持。

　　有些重构比较容易实现，但是有些重构却像是散了的毛衣线连绵不绝，稍有不慎就是灾难性后果，中间由于影响太大而不得不回退多次。幸运的是，伴随着整个产品需要切换到云化平台，重构正好可以“借东风”达成效果。

　　云化平台对服务的要求更严格，例如第一个原则“服务自治”，代码没有组件化没法安装部署，这就要求必须重构。于是，我们通过编写代码清理工具自动化清理，提升效率减少出错；解除不合理依赖，内聚代码；实现组件独立编译、运行与出包……持续大半年，终于实现了一套代码适应多种组网，服务能独立编译、运行、集成，清理了数十万行的代码，减少了*人年维护成本，现在看来，重构真是个明智的选择，也感激自己当时没有放弃。

　　这些年，我在编码路上最大的动力就是源于兴趣，兴趣是最好的良师益友，工作中总会遇到各种疑难问题需要攻克，有兴趣就总能找到解决方法。

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

▶进入2019华为软件精英挑战赛专区瞅瞅