高中的時候，我覺得當駭客很帥氣，心生嚮往，結果選擇了看起來能成為駭客、事實上只可能被駭客攻擊的計算機專業。2020年大學畢業時，看到華為面對制裁很“剛”、很酷，於是不假思索地選擇了華為，來到成研，成為了一名真正的程式猿，體會到了什麼是“休閒向左，成研向右”。
經過1年半的努力，我成了資料管理產品部OM（操作維護）開發部的MDE（模組設計師）和Committer，開始了和程式碼過招的日常。
“菜鳥”的不知所措：一天問800遍“是這樣嗎”
時間撥回2020年的夏天，當我還沉浸在晨練、紅白文化衫以及“物質激勵重要還是精神激勵重要”的辯論中時，突然發現自己成了資料儲存OM開發部最年輕的開發人員，擺在我面前的是一個完全陌生且複雜的業務領域。到現在我都能清晰地回想起來，自己面對數以十萬計的程式碼以及複雜的服務之間的關係時，那種不知所措、無從下手的茫然感。
我接手的第一個需求是作業系統切換的需求，涉及到新作業系統的適配以及python2、python3的相容。現在看來只是不到500行的小需求，但是對一個對linux的瞭解只侷限在cp、cd、mkdir命令的萌新、一個對所有需要改動的python指令碼功能都不瞭解的新員工來說，我的壓力是難以言說的。
那段時間，我每天晚上都難以入眠，總覺得自己能力不足，難以梳理如此複雜的業務，沒辦法按時高質量地交付，無時無刻不在思考如何才能完成業務。每天走在上班的路上，我就忍不住胡思亂想：昨天的程式碼在聯調中有沒有發現問題？今天的工作能不能按時完成？那段時間，我每天問自己、問別人最多的就是：這個地方是這樣的嗎？那個地方我理解得有問題嗎？
組內的同事給了我無限的包容。每次遇到一個問題，不論再忙，總有人幫我出主意，給出解決方案。隨著“為什麼”一個一個地減少，需求也進入了聯調階段。我所焦慮的問題也從“怎麼實現”變成了“怎麼定位解決當前遇到的問題”。
由於這個需求是系統層面的適配，很多問題要在聯調階段實際測試中發現，加之我們模組又是整個分散式儲存的入口，某種程度上我們的角色就是個“守門員”，需要了解每個問題。因此，遇到問題，我會先查詢相關程式碼，然後再跟組內的“老人”確認，是否跟我理解得一致，確認測試同事提出的問題是不是真的問題，或者將問題轉給對應模組的人確認，最後記錄到筆記本中。
隨著時間的推移，需求越來越多，我定位的問題也越來越多，儘管還是會碰到各種各樣不知道的技術，偶爾也會掉進沒有踩過的坑裡，但是看著筆記中越來越多的常見命令、常見問題，我已經不再焦慮，反而覺得這些問題越發可愛起來，逼著我不斷成長。
隨著積累越來越多，我發現自己可以解答不少問題了，也能夠為需求的高質量交付貢獻一份我的力量了。
終於有底氣說“這個問題我知道”
經過半年多的“打怪升級”，我在日常問題的處理上已經得心應手。但我覺得，這樣還遠遠不夠，我經常開啟問題列表，檢視組內的常見問題，思考每個問題為什麼會發生，怎樣做才能避免發生這樣的問題。看的問題越來越多，瞭解的業務越來越多，我開始有底氣說出“這個問題我知道”。
一天，我正準備修改一個不太複雜的安全單，突然發現，這個傳送LLDP（鏈路層發現協議）報文的小模組看起來並不簡單。這是一個定製化開發的模組，平時不會使用，也沒人關注，但卻是重點客戶採購規範裡“指名道姓”的功能。
當我上手這一模組的時候，有一種“不祥”的預感。果不其然，當我輕車熟路地修改完安全問題並進行測試的時候，驚訝地發現，這個從老版本直接同步過來的模組，根本沒有適配切換python3之後的作業系統，換言之，這個模組在當前版本軟體配套的作業系統上完全不能執行。
本來2個小時的工作量突然就變成為未知。此時我還是很樂觀，覺得自己應該可以快速搞定，因為python2和pyhton3之間的差異我並不陌生。但當我根據之前的經驗修改完程式碼，放到新的作業系統上調測時，發現雖然程式已經能夠不報錯執行，但是表現卻跟在舊的作業系統上面不盡相同。顯然，已有的經驗並沒有幫我解決這個問題。
這是一個直接工作在鏈路層的協議，我平常很少接觸。不過不熟悉不代表我會慫，我沒有害怕，而是仔細走讀程式碼，蒐集相關資料。很快，我就發現，程式碼中報文生成的部分是直接使用的二進位制內容書寫的，而python在兩個大版本之間，在編碼方式上的確有很大的不同。於是，我根據這個思路，重點審視協議報文生成部分的程式碼。果不其然，重新修改後，我再在python2、3的環境上分別執行這個模組，報文格式、內容完全相同。這意味著問題已經解決了！
但是對於一個完整功能模組來說，需要端到端的驗證才能保證功能完全正常。對於LLDP報文傳送模組來說，這就需要在交換機上檢視對應報文才能保證功能完全正常。提著一口氣，我第一次登陸完全沒有接觸過的交換機，使用剛剛搜尋到的命令檢視到了這個模組LLDP報文，很快就放下心來——問題解決了！這個“逍遙法外”許久的功能被我成功逮捕，成為了前端測試用例庫裡的又一個例行執行的用例。
“程式碼質量好，回家回得早”成了團隊的共識
作為一個典型的程式猿，我一直都有著程式碼潔癖。雖然是大學才接觸程式設計，但是卻很享受將想法變成一個個程式的感覺。大學期間，我開始閱讀各式技術書籍，從《Java核心技術》到《Thinking in Java》，從《設計模式之禪》到《重構》，每本都如數家珍。入職後，在快速熟悉業務程式碼之餘，我也依舊沒有放下閱讀技術書籍的習慣，並時常思考如何才能將書中的知識轉換為能力，如何才能寫好程式碼。入職6個月後，憑藉著對業務的熟悉和對程式碼的追求，我被任命為OM團隊內部最年輕的committer。
當我第一次看到自己的名字出現在正式的任命檔案上的時候，難免有些欣喜，但是也覺得壓力頗大。原來作為軟體工程師的我，只需要管好自己的一畝三分地，做好測試自驗證，保證自己的程式碼clean就可以了。但是作為committer，就要對組內的程式碼負責，需要看護好每一個經手的MR（合併請求）。再加上，我的組內全是前輩，面對他們的MR，我應該怎麼辦呢？
一時間，巨大的壓力如同一張巨大的網將我包裹起來，讓我不知所措。說來也巧，當時正要進行安全送檢，我承擔了安全排查的工作，一下感覺找了抓手。我梳理出100多個已有指令碼，發現了30多個問題，總結出常見提取模式、命令注入等共性的安全問題，在組內開展多次培訓。與此同時，在程式碼檢視中，我也提出了很多關鍵問題，將問題攔截在最前端。
慢慢的，大家從被動的必須讓我檢視才能合入，變成了驗證前先找我檢視看看有沒有“踩坑”。這時候，我就知道，大家已經認可了我的能力。
接下來，以肉眼可見的速度，大家程式碼越來越直觀漂亮，安全問題顯著減少。而且，大家還經常一起討論，這個地方提到公共類是否更加合適，那個地方多加一個換行是不是結構更加清晰的一些“小事”。
不過，這些“小事”在面對版本交付壓力的時候，突然變成了大事。在距離分散式儲存產品的最新版本釋出不到兩週的時候，PL（專案主管）找到我，說在超大叢集規模下，版本升級必然失敗，需要緊急定位分析，解決問題。
經過分析，我發現問題了所在。模組裡面包含一個從Excel檔案讀取配置資訊的功能，程式碼邏輯極其複雜，以前就是一個黑盒，沒有人改動程式碼，也沒有人知道里面的功能實現。從模組誕生之初，這段程式碼就平穩地在系統中執行。但是隨著版本的演進，叢集規模愈發擴大，單個單元格需要承載的內容越來越多。在新版本中，單叢集需要支援超過5000個節點，而當Excel中單個單元格字元長度超過32767時，讀取Excel的三方類就會直接報錯。
解決這個問題有兩個選擇，一是直接修改對應的類，對超長的單元格進行拆分，只需要不到100行，工作量低風險低。二是重構這部分邏輯，配置檔案改為Json，並修改對應的解析邏輯。風險高且工作量大。
當時距離版本釋出只有不到一個月的時間，PM認為風險較高，建議先使用簡化方案處理。但是在我詳細走讀程式碼後發現，該模組的程式碼已經不適合當前的實現，如果繼續修改會導致後續維護難度更大。作為開發者，我的程式碼潔癖不允許我選擇“簡化方案”，作為committer，我更需要以身作則。
所以，我堅決地選擇了方案二，但是針對當前修改風險大的現狀，跟PM和前端測試對齊，提前識別場景，做好用例設計並採用測試驅動開發的模式保證質量。最終，將解析程式碼由3K簡化為0。1K，並且在一週內完成了開發測試上主幹，高質量零缺陷解決問題。
由於升級業務的特殊性，我們所負責的微服務不能和產品包一起升級，需要在節點上手動呼叫相關指令碼升級。且升級過程中需要輸入3個使用者名稱、5個密碼，實施時極易因為密碼錯誤等原因失敗。針對這一問題，我仔細構思，設計並開發了自升級介面化功能。透過複用其他服務的通道，做到了在介面上一鍵完成升級，且升級時長較原先縮短50%，得到一致好評。
自升級介面化交付後可以在頁面一鍵式升級
現在，每次不論是遇到問題、做新需求還是設計新特性，我總是喜歡想一想，有沒有更好的方法，程式碼能不能更精簡，可用性、可靠效能不能更高。每次看到做完需求程式碼反而更少了，我覺得比交付了很多“湊工作量”的程式碼更令人激動。
隨著時間的推移，我經手的程式碼越來越多，被“挑刺”的越來越少。團隊的程式碼質量也越來越高，花費在修改問題單的時間越來越少。大家也逐漸認可了“程式碼質量好，回家回得早”的這個道理，越來越多的人開始重視程式碼裡的細節。
一點一滴的積累，一個又一個的細節最佳化，讓我們的團隊也變得更好。
穿越黑暗與苦痛，才能破繭而出
就像牛頓頭上的那個蘋果總是會落地一樣，軟體缺陷也是無法避免的，難免會有現網的緊急問題需要處理，尤其是我所在業務組負責的升級。為了不影響客戶使用，升級總是在深夜執行，且有著嚴格的時間窗。現在，當被深夜的電話會議驚醒的時候，我總是會條件反射般地告訴一線同事“稍等兩分鐘”，然後迅速起身開啟便攜，快速處理閉環問題。這時候我才突然意識到，我已經從那個小心翼翼地詢問“是這樣的嗎”的萌新，成長為“我馬上上來處理”的團隊骨幹。
路漫漫而修遠兮，吾將上下而求索。作為一個新上崗的MDE和Committer，我還有很多的知識需要學習和積累。就像被困在繭裡的毛毛蟲一樣，只有默默積蓄力量，穿越黑暗與苦痛，才能破繭而出，見到更廣闊的世界，遇見更好的自己。和大家共勉。
