“板凳”十年不會冷

“板凳要坐十年冷”,這是公司倡導的一種文化,尤其是在研發體系,它強調的是要耐得住寂寞,精益求精,踏踏實實把產品做好的一種精神。據說,這條標語常年掛在新員工培訓的大教室裡,好多人理解“板凳”都是冷的,即便坐十年也是。

而我的經歷和體會卻是,再冷的“板凳”堅持坐總能把它坐熱,而已經坐熱的“板凳”,如果總是翹起屁股去張望,也會變涼。因此,一旦找到適合自己的“板凳”,就堅持坐下去。

燈的顏色不一致,讓我產生了敬畏感

1994年大學畢業,應聘去了廣東江門一家銀行的電腦部,那時候計算機專業還是很吃香的,銀行給的綜合待遇也不錯,工作很輕鬆,唯一的問題是沒怎麼有挑戰、有難度的事可幹,時常覺得很無聊。1997年年中,一起入職的校友不知怎麼聯繫到了華為,當時都不知道華為是個什麼公司,一起面試的幾個人都通過了,免不了俗,說實話最吸引我們的還是華為給的工資一下子較之前翻了三倍。

入職後,我到了傳輸業務部做網管,那時候還沒有IPD流程,軟件開發過程是很民間、很隨意的。當時產品也還沒有開賣,和網管一起的里程碑時間點就是一個試驗局,俄羅斯的一個客戶要來華為進行廠驗。為了把一個粗糙的半成品趕在客戶到來之前能夠示人,我們幾個人結結實實在公司睡了幾天,狀態好的時候我一個通宵就能完成一個模塊的開發。但是我內心排斥這種疲勞作戰的方式,從那之後我再也沒有熬過通宵。

這個網管系統是很初級的,就是實現一個網元級的基本管理,不復雜。客戶來現場體驗後認為做的還可以。按現在的說法,客戶的這個肯定,我們就算過了TR5點了,大家都很高興。但客戶的一個專家指出的一個小問題,讓我覺得有些汗顏。他說設備上這個燈是黃色的,可網管上你的這個界面上怎麼是綠色的呢?我解釋說我理解設備沒有故障就是應該綠色的。這位專家反駁道:“你這樣理解不對,網管要反映設備的真實狀態,如果設備狀態指示燈變成黃色的,你應該很快同步過來,這樣我的維護人員才能根據這個警示狀態去檢查設備到底有沒有故障,而不是非得指示燈紅了才採取動作,到那時候故障應該已經產生了。”

我很受啟發,這就跟寫代碼一樣,我應該重視一段代碼運行過程的狀態是要可控的,也就是說要用確定性的過程來確保確定性的結果。而不是說非得等程序的狀態機跑飛了或程序掛死了再去查找原因,救火滅火的成本都很高,也很耗精力。隨後,我就這個問題專門進行了整改。

這是我職業生涯裡第一次面對客戶,客戶指出的這個小問題卻讓我產生了一種敬畏之心,這個敬畏不是說害怕犯錯,而是對代碼怎樣實現需求這件事要有敬畏之心,實現的過程和呈現的結果要表裡如一,不能含糊不清。哪怕錯了就是錯了,改過來就好;不夠好就是不夠好,改進就是。我要為我輸出的每一行代碼負責任,這樣一個原則貌似也吻合了我們現在強調的過程可信。

唯一一次換“板凳”,讓我差點懷疑人生

寫代碼二十多年,常有人問我,公司平臺這麼大,為什麼不考慮試試其他崗位,換換賽道人生是不是會多一些可能?

我的答案很簡單,適合自己的才是最好的。我能長久沉浸在編碼世界,是因為寫代碼對於我來說是一件非常有趣的事,這裡面的樂趣常常讓我無法自拔。就如同作家來了靈感,寫文章停不下來一樣,編碼,對我就是如此一般奇妙的存在。

實際在2000年前後,我也伴隨著南京研究所的創立,被提拔為幹部,當研究部的經理做管理崗位一年多。之後又響應研發去支援市場的號召,到上海代表處當了一名光網絡的產品經理,那半年多對我來說簡直是“如坐針氈”,完全不適應。感覺自己無論在性格還是技能上都把握不了這個崗位,不懂市場的銷售運作方式。當時想著往回退,又不太敢開口,感覺不光彩,進退維谷之間都產生了辭職離開公司的想法。原來研發的主管得知我的情況後就給我打電話說,要不行就回研發吧。

這一段與代碼分離的日子,反而讓我更加看清了自己的內心:我發現比起和人打交道,自己好像更擅長和代碼做朋友。於是當有機會回到編程崗位,我毫不猶豫地回來了。就這樣,兜兜轉轉我又坐回了熟悉的小“板凳”——Coding和架構設計,從此就再沒挪過屁股。

網絡版配置器,讓我酣暢淋漓了一把

這些年,參與和支持了公司很多重量級的項目,有對內的、也有產品化走向市場的,有成功的、也有不了了之的。現在回憶起來,當初參與網絡版配置器的整改印象很深刻,感覺支持這個項目把當時所學酣暢淋漓地發揮了一把。

公司業務繁雜,從客戶需求到最終產品到現場的鏈條很長,早期各體系的IT系統建設也不成熟,相互間的銜接不夠順暢,“發正確的貨”一度成為公司上下追求的重要目標之一。這其中,一線產品經理用的銷售工具——配置器(Unistar),就是很關鍵的環節,它要從源頭上確保客戶的需求轉化成各產品線銷售的具體模塊及配套輔料等。

2008年前後,無線產品線找到中軟的領導求助,說當時在用的單機版配置器越來越難以支撐海量發貨對齊套準確性的要求了,簡直是焦頭爛額,請中軟務必儘快派人解燃眉之急。

中軟領導對這個事情非常重視,知道對公司很重要,就把包含我在內的幾個骨幹召集起來:“你們幾個過去一定把這個事情搞定!”言外之意,中軟的名聲可不要被我們幾個搞砸了。

我們去一看,無線已經決定把配置器從單機版改成網絡版了,就是C-S(客戶端-服務器)模式,雖然用了新技術,但是架構卻很亂,怎麼也搭不起來。配置器這個玩意兒雖然感覺很小,但是前前後後、裡裡外外涉及的東西還挺多。就拿其最核心的配置算法來說吧,一個基站根據需求配幾個什麼制式的主控板、基帶板、哪個模塊的RRU?配套幾根光纖,配套光模塊的速率是多少等等。這些規則一條一條順下來感覺很簡單,但是面對全球那麼多紛繁複雜的場景,一套完整地適應各種需求的配置規則算法維護起來就不那麼簡單了。

最早的單機版都是各產品線的PDE(產品數據工程師)通過Excel裡面的宏來維護配置規則和算法,宏有兩個問題:一個是很難維護,另外一個是有些邏輯它很難表達。後來就改成了Python來描述和維護,就是用腳本,但是配置算法用這個通用語言描述起來很吃力,再就是容易犯錯誤,有時候會莫名其妙的跑偏。這次我給他們用上了DSL(領域專用語言),在公司也屬首創,相當於給PDE開發了一個專用的語言和配套的IDE(集成開發環境,Unistar Studio)來描述、設置和測試配置算法,有了這個之後,縮短一半以上的規則配置時間,而且即便是產品線的MO都可以很輕鬆、很清晰地描述並維護配置邏輯。通過DSL來解決這個問題得益於我從網上得來的想法,只不過根據實際需要將概念進行抽象和落地,後來還在部門講了好幾堂關於DSL的課。

除此之外,我還給這個配置器重新寫了一個底層框架,包括Server端的框架也重新寫了。支撐這個項目,相當於把配置器的前端呈現和後端server的框架都重新搭了,還把其關鍵的配置算法用了專有技術搞定,相當於救治一個危重病人,能用的重器都給用上了,自然也不輕鬆,在百草園攻關住了好幾個月。

好在我們幾個算是不辱使命吧,幫助網絡版的配置器按時上線,沒給中軟掉鏈子。

基礎軟件開發,讓我很有成就感

中軟基礎軟件項目很多,我有幸多次深度參與其中。

編譯器內核項目原型版本初測,時常出現丟幀、卡頓等現象,內存管理的瓶頸較為突出。項目團隊經過對Beta用戶的大量數據採集,對系統內存分配、釋放行為和時機進行大數據解析,將瓶頸鎖定在GC(垃圾回收)停頓時長這個突出問題上。長期和代碼打交道的我,喜歡研究各種編程語言的實現技術,對GC算法也有所研究。考慮內存管理的複雜度及項目商用訴求對工程能力和經驗的要求,項目組找到我,希望我能跟他們一起攻克這個難題。

貢獻代碼上萬行,涉及編譯器前端、後端、運行時,GC最大停頓時間由開始的分鐘級降到毫秒級,產品上市表現穩定,我很自豪有這個機會從一個編譯器的“User”,搖身一變,成了“Provider”!

還有一次印象比較深刻的“小確幸”,要從大家可能都聽過的“畫一條線一萬美元”這個故事說起:福特公司廠房的電機出故障了,萬般無奈之下請來了著名的物理學家、電機專家斯坦門茨。斯坦門茨檢查完用粉筆在電機外殼畫了一條線,讓工作人員在記號處把裡面的線圈減少16圈後問題就解決了。事後斯坦門茨要1萬美元的酬金,並給出理由:畫一條線,1美元,知道在哪兒畫線,9999美元。

無獨有偶,公司一個重量級產品到了階段性里程碑之後,邀請了產品線專家、客戶側的專家,和中軟的專家一起幫他們檢視代碼以進行質量加固。我一共提了幾十條檢視意見,其中有一條最有價值,它是一個隱藏的bug,我寫了一行內存屏障的底層代碼,告訴項目組說,假設我們的產品相當於砌了一面“牆”,如果沒有這行代碼,意味著最底下的一層“磚”是不穩固的。我把我寫的測試用例給他們看,測出了好多莫名其妙的併發場景的問題。迎著兄弟們欽佩的目光,當時真的成就感爆棚。雖都是職責所在,但在幫助項目把問題解決的那一刻,除了如釋重負之外,也感到一點點自豪。

我說這兩件小事並不想吹噓什麼,是覺得做技術,過程中需要有深扎到底的信心和決心,只有紮下去,才能在這個領域有所建樹,時間久了才能融會貫通,處理跨領域、更復雜的問題。另一方面是要細心,小小的疏忽很可能造成災難, 無論是自己寫代碼、還是去檢視別人的代碼、還是被指派解決疑難問題,我始終堅持細節藏魔鬼,大膽懷疑,小心求證。

不當“碼農”的秘密,讓我把“板凳”坐穿

“板凳要坐十年冷,文章不寫半句空”,寫代碼也是一樣,我很慶幸讓自己大部分時間處於Coding的狀態,就像此刻我作為中軟極客組成員又投入在公司新的重要項目中一樣。

回到編碼本身,我始終認為軟件更像是工藝品,而不是工業製品;軟件工程師更像是工匠而不是流水線工人。所以軟件工程師需要的是工匠精神,有時也需要一點獨具匠心。

我覺得每一個程序員都是在創作,就如寫文章沒有固定的句式,編碼可以有自己的創作發揮,需要你去排兵佈陣。我們平時經常說,研發有設計與編碼,其實我覺得編寫代碼本身就是一種設計,架構設計與編寫代碼都屬於設計。我們經常把寫代碼的軟件工程和建築工程相比,大家總覺得架構設計才是設計,編寫程序的是就是在簡單地碼磚,其實並不是。比如貝聿銘設計的作品,他可能只設計整體的大框架,裡面的細節結構設計還是要他人繼續設計,這樣的人也是真正的設計師。

所以,程序員給自己的定位是很重要的。平日裡大家經常自嘲自己是“碼農”,二十多年的編碼生涯告訴我,不再當“碼農”的秘訣,首先就是要擺正自己的心態,我們也是設計師!每一個小的函數,每個小代碼塊,都是一個設計,要把他的功能實現,都可以有自己設計的小巧思在裡面。因為所謂的設計有很多種,你要選最合適的那個。軟件設計裡面有一句話:沒有最好的,只有最合適的。我們作為寫代碼的設計師,經常面臨有很多選擇,但我們的標準只有一個,那就是選擇最合適的,然後打造出可信的軟件!

回顧這些年,激勵我把寫代碼這條“板凳”堅持做下去的,還是老闆講話中的一段話“你終於會享受到這種默默無聞的無私奉獻的快樂。當你回首往事,不因虛度年華而悔恨,也不因碌碌無為而羞恥。你可以自豪地對兒孫說,我參與的平臺,數十年了還在全世界運轉……不要在乎別人說三道四,自己激勵自己,才能實現人生的偉大。”



分享到:


相關文章: