有熟知的同事說我是軟硬皆通的“萬金油”，是某些領域碩果僅存的“活化石”。但在我看來，只是因為恰巧持續(xù)幾年在同一個領域摸爬滾打，有更多機會鉆得更深一點。
興趣，從和網(wǎng)吧網(wǎng)管“斗法”開始
2005年我入職公司，從此開始了和傳送網(wǎng)的緣分。其實，我大學的專業(yè)并不是軟件，但自從在課上接觸了代碼，我就發(fā)現(xiàn)這玩意兒能做的事情太多了，簡直讓人欲罷不能。
為了在代碼的世界里自由馳騁，圖書館和網(wǎng)吧成為了我學業(yè)之外的“常駐地”，從Pascal，到C/C++，Windows API/COM，再到Java，只要看下去，就停不下來。為了檢驗自己的技術，我還經(jīng)常和網(wǎng)吧網(wǎng)管“斗法”，破解網(wǎng)管軟件。記得有一次，我架設了個私有網(wǎng)站，在上面放了一段JavaScript腳本，激活了網(wǎng)管軟件屏蔽的“運行”對話框，重新控制了整個系統(tǒng)。這一招躲過了好幾個版本的網(wǎng)管軟件升級，讓我嘚瑟了好一陣子。
正是因為自己對軟件的“癡戀”，讓我對寫代碼這件事有著天然的向往。熱愛什么，就選擇什么。我一畢業(yè)就成為了一名程序員。
重構代碼，就像在鋼絲上跳舞
那時迭代還沒流行起來，產(chǎn)品剛過TR5，在瀑布流程下這就代表著產(chǎn)品質量相當穩(wěn)定。所以，每天除了學習產(chǎn)品知識外，我就是專心看代碼。
誰知這一看，我就動了改代碼的心思，因為我發(fā)現(xiàn)有些代碼完全是大段落的復制粘貼，中間偶爾有幾行差異點，修改問題時很難做到一次改全；另外還存在大篇幅的switch case，復雜度高的同時，處理流程也沒有統(tǒng)一模式，新寫的代碼不管往哪加，都感覺很別扭。
我和導師商量：“能不能重構下代碼？“導師一口答應了：“不過本地先改好了驗證，下個版本再擇機合入?！钡玫綉S后，我一氣呵成地抽取公共代碼，統(tǒng)一接口參數(shù)，將switch case換成表驅動方式。
很快，下個版本就這么在期盼中來了，導師看我對代碼這么上心，還交給了我一個新特性的開發(fā)任務，為此我復用了之前重構的成果，“玩”了下套路，很快就完成了開發(fā)。
當我滿懷信心的將代碼提交給測試時，原以為不會出現(xiàn)的低級問題冒出來好幾個。咋回事？這不是打臉嗎？為啥流程都梳理幾遍了，轉到測試還有漏網(wǎng)之魚？堵住漏洞后，我仍然不安：到底用什么方法才能保證代碼的基礎質量？作為軟件開發(fā)人員面對自測試，竟然是心有余而力不足。
后來公司引入了LLT（low level test）這個武器，專門解決代碼的及時、輕量而又可持續(xù)的自驗證，我們團隊有幸作為試點團隊，專門配了一個外籍專家手把手地教。于是，我操著一口蹩腳英語，向外籍專家“取經(jīng)”。經(jīng)過數(shù)十次的探討，我發(fā)現(xiàn)外籍專家對被測代碼邊界的劃分很有套路——用穩(wěn)定的接口來作測試邊界，基于測試邊界來寫用例，認為用例是測需求而不是測已經(jīng)寫好的代碼。這種加上黑盒測試思路的白盒測試方法讓我恍然大悟，既能享受白盒測試帶來的方便構造任意異常場景的好處，又能享受黑盒測試帶來的測試界面穩(wěn)定、用例可繼承的好處。理解這些后，我成了LLT堅定的擁護者。
后來，我在團隊的支持下，先后主導開發(fā)出模型驅動的LLT用例自動生成的工具、自動打樁的工具。比如，在團隊有意愿做LLT時，必須先搭建好LLT基礎工程，常會遇到成千上萬鏈接不過的情況，需要逐個打樁，動輒要專人花幾周時間完成。于是，我們開發(fā)了自動打樁工具，半小時就可輕松搞定。
在我看來，重構代碼就像在鋼絲上跳舞。在享受重構帶來快樂的同時，也需要用各種手段鋪墊好防護網(wǎng)，避免掉入功能前后不一致及質量下滑的深淵。
不管角色怎么變，寫代碼這件事不能丟
2006年，數(shù)據(jù)業(yè)務開始大力開發(fā)分組特性，我也從NP驅動軟件的骨干轉身為L3VPN特性的PL。
一開始，我對PL也沒啥概念，分配工作任務還好，最怕的就是管人，尤其怕給兄弟們打考評。幸運的是，當時我們團隊技術氛圍濃厚，我以平時的代碼交付結果作為績效考核的衡量標準，再輔以我在團隊內的技術威望，打考評這件對我來講最難的事算是勉強過關了。
當然，PL也是有很多便利的，可用的資源比單槍匹馬時要多了，只要有想法就不怕干不成事。PTN第一個項目組級別的“HLT（high level test）自動化工廠”，就是我主導搭建的，一舉解決了發(fā)版本需要所有組員留守搞自測試的困境。在組內高效工作的氛圍下，我也解放時間承擔起MDE（模塊設計師）的角色。在這期間，我發(fā)現(xiàn)各特性都有自己的硬件資源管理算法，重復實現(xiàn)，接口不一致，且大多采用遍歷算法，效率不高。于是，我總結了已有特性的所有資源管理需求，結合bitmap、棧、索引幾種技巧，完成了接口統(tǒng)一的資源管理算法，還憑此斬獲了網(wǎng)絡舉辦的第一屆“十大金碼獎”。
2010年，由于業(yè)務的需要，我又做起了專職MDE的角色，加入了新的團隊，心里偷著樂：不用管人，又能利用MDE的影響力在項目組推行各種改進措施。當時新團隊正處于第一個版本，需要補齊大量特性，我們不得不頻繁發(fā)布版本，而每一次版本構建的時間又很長。增加日志后，我發(fā)現(xiàn)時間主要消耗在編譯階段，就想解決這個問題。要不開源節(jié)流試一試？我一方面清理無效的編譯過程，一方面在網(wǎng)上搜索能并行編譯的工具。可前者節(jié)流僅縮短了10%的時間，距離期望還有很大差距。
所以我把更多精力投入在開源上。就在我找到網(wǎng)上的工具，以為可以拿來主義的時候，卻發(fā)現(xiàn)工具過于“傻瓜”，需要手動構造并行任務。為了讓工具更智能，我邊學邊做，經(jīng)歷了很多第一次：第一次深入研究makefile，第一次嘗試預編譯，第一次復雜的運用批處理……經(jīng)過一周摸索后，我終于把自動化并行的腳本做出來了，版本效率提升了3倍。
俗話說，挑戰(zhàn)和機會是對孿生兄弟，工作也是如此。在我看來，軟件工程師本來就應該是與時俱進的，不管環(huán)境怎么變，角色怎么變，始終要摸清業(yè)務的需求和約束，確定輸入和輸出，然后用軟件把它實現(xiàn)出來。
打開天窗，才能發(fā)現(xiàn)自身不足
2017年，我接任了傳送網(wǎng)的首席程序員，成為傳送DU的首席committer。
我有幸接手了D3A架構優(yōu)化項目。項目整體分為兩大塊，一是實現(xiàn)軟件上的抽象轉發(fā)建模，做到修改硬件方案對主機軟件“零感知”，另一個是讓微碼能夠按功能塊來拼裝，具備被軟件定義的能力。只要實現(xiàn)這些，更換硬件的工作量至少降低50%。
這個項目對于我們整個團隊意義重大，能徹底解決軟硬件解耦的難題。在這個過程中，我不僅體會到“開天窗”的美妙滋味，也有幸交到了美研所的業(yè)界頂級專家羅勇這樣的朋友。
一開始，我根據(jù)已有的經(jīng)驗判斷：微碼咋可能做得這么靈活？轉發(fā)性能是第一優(yōu)先級，跳來跳去肯定性能不達標。我和美研所的專家各種PK，發(fā)現(xiàn)他總是先讓我們講清楚需求，然后他出解決方案，我們疊加需求，他就再出方案，反正總是難不倒他。
比如，我們提到分布式轉發(fā)的時候，主機由于上下行單板的資源交互，需要管理差異化的資源，達不成主機軟件零感知的目標，咋搞呢？專家一分析：“為了讓主機看到一樣的轉發(fā)資源，微碼可以幫忙加映射。”但是這就會多查一張表，影響性能咋辦？“那就合表嘛，這里增加了開銷不一定非得在原地想辦法。我們面對的是整個系統(tǒng)，拆東墻補西墻有時候也會是個好方法?！笨傊?，不管我們的問題是什么，美研所專家都能逢山開路、遇水搭橋，幾個回合下來，我徹底服氣了。
后來，我才發(fā)現(xiàn)這場景似曾相識，方法都是細化打散了再排列組合。這不是和我以前給別人出主意的場景一樣的嗎？雖然我在所屬領域自認為還算有經(jīng)驗，也幫組織解決不少問題，但打開天窗一看，發(fā)現(xiàn)依然是井底之蛙。所以，老板講要經(jīng)常出來喝咖啡，吸收外面的能量，經(jīng)過這事兒我是信了。
當然，問題是最好的老師，你在幫助別人的同時，也是幫自己提升經(jīng)驗值。
我的偶像安德斯·海爾斯伯格（Delphi、C#和TypeScript之父）曾說過，程序員是最好的職業(yè)。第一次看到這句話時，我就很受鼓舞。代碼的千變萬化帶來了解決問題的無限能力，讓我體會到不可言喻的美妙感覺。13年來，我每天都在和代碼打交道，卻總是樂此不疲。如今，在武漢，在波分，在公司軟件服務化浪潮中，我依然利用代碼的魔力，讓更多人因寫軟件變得更快樂。
熱愛是點燃激情的火把，寫代碼可以是一輩子的事業(yè)。對我來說，如果到了60歲，還能每天堅持編碼，大概就是最大的幸福了吧！
來源：心聲社區(qū)
下載文檔
