一個程序員的自我修養(yǎng)

一天晚上，我和老婆聊天，說部門要我寫個“大咖談軟件”的文章，老婆斜了我一眼，淡淡地說：“Linus大神21歲就寫出了Linux內(nèi)核的雛形，締造了一個自由主義的開源世界；張小龍28歲寫出了foxmail，在2000年就賣出了1200萬的價格。大咖，認識您這么久了，還不太了解您有什么杰出的成就？”我訕訕地咽了口水：“好吧，我重新組織下語言，我需要寫個談軟件的文章……”

回首過去這半年，軟件總工、軟件專家的任命，還有新年伊始任總《全面提升軟件工程能力，打造可信的高質(zhì)量產(chǎn)品》的發(fā)文，都讓我們這些寫了十多年代碼的軟件工程師激動不已。

我2006年進入公司，幾乎參與了華為3G控制器產(chǎn)品的完整生命周期，見證了華為3G從起步、上升、靈魂深處的改進、巔峰、回落的波瀾壯闊歷程，并在35歲“高齡”有幸加入到5G開發(fā)部的大家庭。

十幾年來，我一直堅持在編碼崗位，經(jīng)歷了普通開發(fā)人員、TL、MDE、MDEL、SDM（云化團隊）、Committer、軟件專家等各種崗位。然而我卻深知，不算大牛的我，從事編碼這個“高?！甭殬I(yè)十幾年而沒有被拿去“祭天”，依靠的是一個程序員的自我修養(yǎng)——扎實的基礎(chǔ)軟件能力、如履薄冰的工作態(tài)度、對技術(shù)孜孜不倦的追求。

▲幽默的“祭天”說明

1.好代碼長什么模樣？

記得幾年前部門第一次評選優(yōu)秀代碼，我成為“金碼獎”獲得者之一。是因為代碼很炫嗎？并不是。我參與評選的代碼，遵循著簡單的原則：簡潔、邏輯清晰、函數(shù)職責單一、合理的數(shù)據(jù)結(jié)構(gòu)設(shè)計。并沒有使用高深的編碼技巧，也沒有應用某某設(shè)計模式。正如公司最新的C/C++語言編程規(guī)范，也是將編寫簡潔的程序放在首位。簡潔、邏輯清晰的代碼，易于閱讀和維護，這段代碼后面也因需求變化而被修改，但卻從來沒有引入過網(wǎng)上問題。

當然，簡單不代表沒有思考，恰恰相反，更需要我們在寫代碼之前謀定而后動、三思而后行。有一次項目組安排我做性能優(yōu)化，通過反復分析熱點函數(shù)、反復測試比對不同話務模型下的性能差異，前前后后花了3個星期的時間，我找到了引起性能惡化的最關(guān)鍵因素。最終我決定采用修改備份機制、減小備份數(shù)據(jù)的優(yōu)化措施。這些方案代碼改動都很小、很簡單，但實際優(yōu)化效果卻很好，滿足了未來幾年業(yè)務發(fā)展的需求。

再來看另一個例子，某局點升級新版本后出現(xiàn)CPU負載上升的問題。經(jīng)過近兩周的攻關(guān)，我最終定位是新版本在業(yè)務處理流程中新增了直接讀取DB內(nèi)核的操作。直接讀取DB內(nèi)核，代碼處理簡單，也能正常實現(xiàn)業(yè)務功能，但是性能卻非常差。如果開發(fā)過程中能多想一步，采用緩存的方案，性能會有天壤之別，也是更好的代碼。

人們常說唯一不變的就是變化，客戶需求一直在變化，我們的代碼也會被動或者主動地在變化。設(shè)計出可擴展、自動適應客戶需求變化的軟件架構(gòu)，是軟件工程師永恒的追求。這說說容易，做起來卻很難。需要我們不停積累業(yè)務知識，擴展知識面，勤于思考，識別技術(shù)未來演進趨勢。我們無法從一開始就做一個無所不能的架構(gòu)，來包含未來的千變?nèi)f化，即使能，交付節(jié)奏也不一定允許。滿足當前及未來一定時間內(nèi)業(yè)務需要的設(shè)計，或許就是最合適的。

2.練好扎實的基本功

能寫出好代碼，更要能持續(xù)地寫出好代碼，需要我們深刻理解技術(shù)原理和業(yè)務邏輯。前提是具備扎實的編程基礎(chǔ)，即基礎(chǔ)軟件能力，如基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)和算法、編譯原理等。

去年底，我跟部門幾個軟件高手一起，去外部參加了一次互聯(lián)網(wǎng)架構(gòu)大會。AI、區(qū)塊鏈、物聯(lián)網(wǎng)、云、中間件等時尚、熱點、風口相關(guān)的議題非常多。但是我沒想到，最火爆的卻是一些基礎(chǔ)軟件設(shè)計、架構(gòu)設(shè)計和演進之類的專題。就像武俠小說寫的一樣，練好基本功、練好內(nèi)功，后續(xù)無論什么精妙招式，都會信手拈來。

另外，一些編程習慣，如果堅持下去，對于編程修養(yǎng)提升也是非常有用的。比如快捷鍵的使用、有效的代碼注釋、命名規(guī)則、代碼風格等。每次寫代碼除了追求好代碼之外，我都會時刻去思考軟件上的優(yōu)化，能否能使用更少的內(nèi)存，能否有更好的性能。重視數(shù)據(jù)結(jié)構(gòu)中的每一個字段，重視每一處小的代碼優(yōu)化，都有可能給我們帶來意想不到的收獲。比如去年做性能優(yōu)化，我們僅僅是將流程中的一處動態(tài)內(nèi)存申請修改為靜態(tài)內(nèi)存池，卻意外獲得了30 CAPS（每秒呼叫次數(shù)）的性能提升。

3.一行代碼引發(fā)的慘案

有人問，道理我都懂，為什么卻依然寫不出好代碼？

很多開發(fā)人員，因為個人習慣、趕工期、外部要求不高等多種原因，在編程時特別隨意，直接Copy-Paste。我覺得程序員應當像追求生活品質(zhì)一樣，養(yǎng)成不將就的編程習慣、嚴謹?shù)木幊虘B(tài)度。

對于代碼上庫，我一直都是戰(zhàn)戰(zhàn)兢兢，如履薄冰。上庫前我會反復看自己修改的代碼，看修改代碼的上下文，并進行修改前后代碼比對。代碼上庫后再看幾遍，確保都已按預期合入。進入公司這么多年，自己從來沒有多合、漏合、錯合過任何一行代碼。

大家可能會覺得我這是小題大做，但事實上，這都是歷史上曾經(jīng)發(fā)生過的慘痛教訓。我們在某國升級新版本后發(fā)現(xiàn)用戶接入成功率惡化，最后定位是由于一行代碼被誤刪除導致的。事后回溯，開發(fā)人員自己都不記得這一行代碼為什么會被刪除。還有一次，一行代碼被誤刪除，導致一個關(guān)鍵KPI指標：軟切換統(tǒng)計次數(shù)有變更。部門把這兩起事件總結(jié)為“一行代碼引發(fā)的慘案”，無論是對產(chǎn)品品牌、客戶印象、還是對于個人，都造成了惡劣的影響。

事后大家都在思考，我們有結(jié)對編程、代碼檢視、開發(fā)者自測試等非常完善的開發(fā)流程，還有MDE（模塊設(shè)計師）檢視作為代碼上庫前的“守門員”，為什么還會發(fā)生這么低級的錯誤？是流程沒執(zhí)行到位，還是MDE疏忽、沒把好關(guān)？

在IPD 2.0變革中，公司借鑒開源組織的Committer運作，來加強我們的Committer機制和文化。5G開發(fā)部也選拔、任命了一批Committer，我有幸成為其中之一。剛開始履行Committer職責時，我有點疑惑：這不就是給MDE角色披上了新的外衣，把MDE原先“私下”做的事情，通過Committer統(tǒng)計數(shù)據(jù)給呈現(xiàn)出來嘛？

不過，經(jīng)過幾個月的摸索、實踐后，我漸漸地明白，Committer機制應該是一種文化上的變革，牽引大家提升自己的軟件能力。Committer的職責很多，作為代碼提交前的最后一道關(guān)卡，這是在當前人員能力不足階段有效果，但是最終應該被弱化的一項實踐。參與編碼前的軟件設(shè)計、持續(xù)做好架構(gòu)看護和技術(shù)債務清理，讓大家都有更大的機會寫出更好的代碼，我認為這是Committer更大的價值。

隨著個人和組織的軟件工程能力提升，自動化測試防護網(wǎng)和變更防護墻建設(shè)完善之后，前面提到的“一行代碼引起的慘案”，是可以避免的。

4.“變更防護墻”夠不夠可靠？

對于大部分老員工，特別是無線2G/3G/4G等部門的老員工來說，一提到變更控制，都會如臨大敵。版本升級后，KPI變差是絕對不允許的，嚴重時可能面臨版本回退、客戶投訴和上報事故。而KPI變好，除了要向客戶解釋，還有可能面臨商務風險，客戶會覺得之前吃虧了。現(xiàn)實世界對我們就是這么苛刻，誰讓我們是影響世界的通信軟件工程師呢，他們這是愛之深、責之切??！

我們開發(fā)一個版本，動輒涉及幾十萬代碼的新增、修改或重構(gòu)。要想不引入變更問題，除了做好設(shè)計、結(jié)對編碼、代碼檢視和測試之外，我認為最關(guān)鍵的就是完善的自動化防護網(wǎng)。在3G時，我?guī)е鴥蓚€同事將IT測試工程從只有幾百個用例擴充到上萬個用例。全方位的場景覆蓋、嚴密的信元有效性檢查、完善的用例失敗判決機制、無死角的資源泄漏檢查等手段，讓變更錯誤無所遁形，給3G留下了一道變更防護墻。

開發(fā)過程中補充IT和PC-ST測試用例，不是為了提升代碼覆蓋率，而是為了自動化防護。而要能達成自動化防護的前提，是每個用例都具備完善的有效性檢查，否則防護網(wǎng)就是形同虛設(shè)。幾年前，我跟一個同事開玩笑：“我會故意將某行代碼改錯，看看你補充的用例是否能檢查出來。”讓我意外的是，在交付緊張的情況下，他仍然多花了半天時間完善用例有效性檢查，并請我故意改錯代碼來做試驗。當然，最終的結(jié)果是，他準備得很充分，我沒能發(fā)現(xiàn)問題。多么有自我追求的一個程序員！

5.保持對于新興技術(shù)的好奇心

說起程序員的追求，我還想起了2016年參與的一個產(chǎn)品云化項目，我負責彈性伸縮特性的方案設(shè)計。在此之前，我一直在投入嵌入式軟件開發(fā)，雖然期間產(chǎn)品也換了好幾代的硬件，經(jīng)歷了產(chǎn)品與平臺解耦、制式間解耦、軟件與硬件解耦等過程，但是對于服務化、微服務化、云化等概念，我卻基本處于懵懂的狀態(tài)。

不懂怎么辦，只能是“站在巨人肩膀上，為我所用”。兄弟產(chǎn)品線不是已經(jīng)做了嗎，那就找他們做同行協(xié)助；友商不是有路標和規(guī)劃了嗎，那就在他們的有限材料中尋找可借鑒的地方；互聯(lián)網(wǎng)的亞馬遜云、阿里云不是有非常成熟的方案了嗎，那就下載他們的產(chǎn)品手冊和用戶指南……那段時間感覺自己就像是入了魔一樣，瘋狂地學習分布式軟件相關(guān)技術(shù)，瘋狂地吸收各方面的能量為我所用，最終給出了一個令自己和項目滿意的設(shè)計方案。

這也讓我充分意識到自己之前把眼光局限于所在產(chǎn)品、系統(tǒng)、子系統(tǒng)的不足。作為一個程序員，除了要提升自己的基礎(chǔ)軟件能力，我們也要始終保持對于新興技術(shù)的好奇心，孜孜不倦的追求，不斷拓寬自己的視野。而這方面的能力和訴求，在5G時代更是如此。

當前我們?nèi)A為5G面臨的網(wǎng)絡安全問題，雖然有著很大的政治因素，但也從側(cè)面反映了5G的戰(zhàn)略意義。超高速率、超大連接數(shù)、超高可靠低時延，對我們在軟件處理時延、可靠性、安全、韌性等方面的能力都提出了更高的要求。同時，5G承載的垂直行業(yè)應用、接口開放和硬件“白盒化”等趨勢，也必將對我們當前的知識和技術(shù)體系，提出更大的挑戰(zhàn)。

公司計劃用五年的時間，全面提升軟件工程能力，對我們是考驗，也是機會。統(tǒng)一編程規(guī)范、整潔代碼、整潔優(yōu)雅的架構(gòu)，不同的人有不同的追求，需要我們有持之以恒、水滴石穿的決心。五年或者十年后，當我們回首時，會發(fā)現(xiàn)自己曾經(jīng)的付出是值得的。正如，清代著名學者王國維提出的讀書三境界之第三境：“眾里尋她千百度，驀然回首，那人卻在燈火闌珊處?！?/p>

也許我們絕大多數(shù)人終其一生也無法成為Linus、張小龍這樣的大神。然而，我們能夠做一個有修養(yǎng)的程序員，并參與到改變世界的華為5G產(chǎn)品開發(fā)中來，在人類的通信史中留下自己的優(yōu)秀代碼，幸哉。