凡凡不“凡”

導師很堅定地認為我行

2018年7月16日，激動中帶著一絲小忐忑，走出校園的我來到華為，開始了人生第一份正式的工作。但面對即將入職的云核心網資料部，職場新人唯一的困擾是文采不行，語文、英文都是高考拉分項，我怕我難以勝任。但既來之則安之，不試試怎么知道自己不行呢？

進入部門的第一天，一個長著圓圓腦袋的人主動走過來跟我打招呼：“我是你導師，以后跟我搞資料的信息服務。“我聽完有點懵：“資料都還沒搞明白，信息服務又是個啥？”

導師帶我去領電腦，一路上說起他在華為的經歷：“我在資料崗位上干了8年，寫過資料，當過資料經理，做過互聯網式資料滿意度運營，開發過硬件速查APP，效率提升小工具，也搞過Web的客戶信息查詢。我覺得你趕上好時候了，資料業務正在向‘ 信息服務’轉型，就像現在的搜索引擎，通過大數據來智能識別用戶的意圖，然后聯想出一堆你可能想要的答案。我看了你的簡歷，編碼基礎挺扎實的，超級對路……“

導師說，未來我們想做的信息服務，除了提供資料內容，還要更智能地識別客戶意圖，更好地匹配客戶的信息檢索，提升用戶查詢信息的精準度，也可以隨軟件提供界面信息輔助，當然也可以開放接口給各種應用來調用……

導師一口氣說了很多，我覺得我好像聽明白了，但是轉念一想，用“似懂非懂”來形容更貼切些。還沒來得及消化這些信息，他突然打斷了我的若有所思，拍了拍我的肩膀，說：“所以不要有任何負擔，勇往直前加油干！”我應景地猛點頭，只因為我從他的語氣中讀出，他很堅定地認為我行。

代碼不能凌駕于業務之上

因為考慮到可以復用現有的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

華為人期刊

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。