凡凡不“凡”

导师很坚定地认为我行

       2018年7月16日，激动中带着一丝小忐忑，走出校园的我来到华为，开始了人生第一份正式的工作。但面对即将入职的云核心网资料部，职场新人唯一的困扰是文采不行，语文、英文都是高考拉分项，我怕我难以胜任。但既来之则安之，不试试怎么知道自己不行呢？

       进入部门的第一天，一个长着圆圆脑袋的人主动走过来跟我打招呼：“我是你导师，以后跟我搞资料的信息服务。“我听完有点懵：“资料都还没搞明白，信息服务又是个啥？”

      导师带我去领电脑，一路上说起他在华为的经历：“我在资料岗位上干了8年，写过资料，当过资料经理，做过互联网式资料满意度运营，开发过硬件速查APP，效率提升小工具，也搞过Web的客户信息查询。我觉得你赶上好时候了，资料业务正在向‘ 信息服务’转型，就像现在的搜索引擎，通过大数据来智能识别用户的意图，然后联想出一堆你可能想要的答案。我看了你的简历，编码基础挺扎实的，超级对路……“

      导师说，未来我们想做的信息服务，除了提供资料内容，还要更智能地识别客户意图，更好地匹配客户的信息检索，提升用户查询信息的精准度，也可以随软件提供界面信息辅助，当然也可以开放接口给各种应用来调用……

      导师一口气说了很多，我觉得我好像听明白了，但是转念一想，用“似懂非懂”来形容更贴切些。还没来得及消化这些信息，他突然打断了我的若有所思，拍了拍我的肩膀，说：“所以不要有任何负担，勇往直前加油干！”我应景地猛点头，只因为我从他的语气中读出，他很坚定地认为我行。

代码不能凌驾于业务之上

       新员工期间，我的第一个项目是参与一个资料检测平台的增量开发，实现每日检测新增资料的基础错误，并通过邮件通知到作者，同时在这个平台上扩展Support网站的VoC（客户声音）分析系统，形成资料质量看板，实时反映资料内外部质量。

       因为考虑到可以复用现有的PHP语言框架的底层公共模块，部门最终决定采用PHP进行开发。而我恰恰不会PHP，刚开始真是丈二和尚摸不着头脑。导师说，“你先用一周熟悉一下PHP的语法，有啥不会的上网查。”

       求学期间，我自学了C++、java、web、数据库等语言和技术，是个编程爱好者。好在有多种编码语言的基础，不到一周时间，我开始能看懂代码了，然后我开始推测每段代码实现的业务功能，发现根本理不出个头绪来。于是我请教了部门这方面的专家，专家一句话点醒了我：“你千万不能把代码逻辑放在业务逻辑之上！”

       这句提点让我茅塞顿开，我的学习顺序完全反了，不应该是先代码后业务，而应该是先了解业务后开始代码。于是我立即纠正了自己的工作思路，从业务视角，把涉及的网元按领域分类，然后按照领域去梳理需求，再带着业务逻辑去理解代码，渐渐进入了状态。

可信不是拍胸脯就能搞定

       随着对业务和资料工作越来越熟悉，我逐渐体会到了导师口中常说的“资料向信息服务转型”这件事的必要性。

       原先我们交付的产品文档，都是先考虑满足客户的场景，因此文档会涉及产品描述、安装、配置、调测、维护等。到了信息服务化这种新的研发模式下，仅从场景出发考虑资料架构就不行了。资料的架构从静态变成了一个动态组装的过程。因为产品由一个个独立的服务模块组成，就好比乐高的组装部件一样，服务与服务之间通过接口相互调用，在产品不更新发布的前提下，“服务”可以单独升级、单独回退。因此，当产品的一个“服务”更新了描述、安装、配置、调测、维护这些小的信息模块，怎么完美插入Support网站已有的产品资料中呢？怎么随着服务的更新，动态加载到已经发布的产品界面上呢？问题的核心在于，必须解决每个服务的信息模块解耦和灵活组装的问题。

      为此，部门专门成立了信息服务组，导师和我们几个小伙伴开始了第一个资料服务化的探索：helpcenter服务。顾名思义，它是用来承载和拼装每个服务的信息的，我们也称它为信息服务。资料组把以前大篇幅的静态资料，拆成一个个信息模块，给每个小的信息模块定义服务标识，当每一块的服务更新时，helpcenter服务就能加载相应的信息插入到原有资料合适的位置。同时还可以给每个小的信息模块定义和其他内容的关联标识，这样就能实现信息的关联推荐了。

       别看我现在把helpcenter服务说得头头是道，然而刚开始时却是异常艰难的。每次都需要导师协助才能勉强完成，写代码时只知道功能，不知道功能干什么用、不理解业务端到端怎么用这个服务，每每因为惧怕引起代码隐患而辗转反侧，不能入眠。

       我自感这样下去不行，于是花了大量时间开始恶补资料业务：理解资料开发、评审、测试和发布的流程；学习行业背景知识，如产品资料包、用户场景、服务和微服务、服务资料、资料模块化和最小化、资料发布、信息 中心等。再聚焦到helpcenter服务的架构、helpcenter和其他产品基础服务的关系、资料的进仓出仓原理。当架构、逻辑、流程、内容等都清楚之后，一切就豁然开朗了。之后写代码手不抖了，心也不慌了，胆子也越来越大了。

       然而故事的发展永远不可能是一帆风顺的。平台产品必须支持解决方案多模式应用，但随着模式的不断扩张，原来的架构代码复杂度越来越高，维护成本也会越来越高，能否重构呢？犹如硬币的两面，重构可以让代码更简洁，但往往也可能因为考虑不全面导致功能出现继承性问题。

     “为未来框架的扩展和健壮性考虑，我们必须重构！”我鼓起勇气向团队提出了我的想法。尽管交付压力很大，但团队认为重构是最好的办法，最终采纳了我的建议，顶住压力给了我两个月时间完成重构。

       以为一切尽在掌握中，就等着解决方案版本在今年国庆后发布，我还幻想着可以在国庆好好“浪”一把，没想到却在放假前一天的下午收到了多张问题单。helpcenter服务加载不到某类服务的信息，全组联合定位问题到深夜，最终发现了“罪魁祸首”。原因是我在重构时，对抛出的异常范围设置不合理，使业务在运行过程中没有捕获到相关异常，出现了代码运行中断，导致了该服务的信息不能显示。找出了问题，我赶紧通知资料组执行临时方案，手工弥补我在重构中引入的兼容性bug，害他们奋斗到凌晨。

       这起因我重构而导致的质量事故复盘时，我很内疚，也很懊恼。原来“可信”不是拍拍胸脯就行，重构必须慎重全面，如履薄冰。为此，我参加了产品线组织的可信培训，在iLearning上自学了很多可信课程，时刻提醒自己在工作中培养CleanCode编码习惯，并一次性通过了公司的可信工作级编码考试。

       当看到helpcenter服务随着IoT、5G核心网等产品商用，说不激动那是假的，说没有成就感那也是假的。从一个没有系统概念的小白，在完全不知道从何下手，也不敢下手的窘境中，我挺过来了。现在我不但能够独立完成关键特性的开发，还成了helpcenter服务的owner。我把项目组所有人的经验汇编成了helpcenter维护手册，不仅自己能够淡定地面对现网问题，还能帮助同事们迅速地定位问题。

“平凡之路”走出不平凡的路

       为了磨练自己的编码水平，2018年11月，我和导师、同事组队参加了产品线编码大赛。两个月的时间，白天搞helpcenter需求开发，周末、晚上对战来自产品线各个部门的编码高手，精进自己的技能，不断优化效率性能算法。虽然艰辛又煎熬，但是能从200支队伍脱颖而出，从32强到16强，再到8强，每一次看到胜利的曙光就不会感觉到累。

       产品线半决赛的时候，刚好和我们PK的队伍的队长就坐在我身边，他笑着说：“我们两个队PK晋级决赛，你觉得谁的胜算更大？”我语气很轻松说：“看运气呗！”其实我内心的OS是：“肯定是我晋级！”然而幸运女神与我擦肩而过，最终我们拿到了产品线第4名。

       从研发管理部长手中接过奖状的时候，我突然有一种真正的轻松和释然，虽然没能站到巅峰，虽然离成功只有一步之遥，虽然心中略有遗憾，但打了一场又一场精彩的对决，我亦心满意足。它让我在敬畏对手的同时，更加坚信自己，只要努力向前，胜利就不再遥远。

       我们给战队起名为“平凡之路”，实际是希望资料向信息服务转型，我们能走出一条不平凡的路。资料的价值在于应用，而承载了应用体验的信息服务才刚刚起步。我在这条路中找到了自己的位置，更找到了工作的价值。我能感觉到，我正随着信息变革的一波波巨浪涌向浪潮之巅。

       时间过得真快，一转眼入职四百多天了，在这四百多天里，我有过新手的迷茫，有过引入bug的沮丧，有过信息服务成功商用的喜悦，但更多的是工作中渐渐学会理性和平实。走在平凡之路上，我和我身边的同事都在努力磨练自己的写作技能、编码技能、多媒体制作技能，积极地实现信息的模块化、结构化、数字化，向资料全栈工程师发展。我希望自己有一天能成为他们中的佼佼者。

       我的导师说，他体会过资料客户满意度提升背后团队的付出和努力；而我，正见证着资料向信息数字化和智能化转型的每一天。

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