2003年我加入CSDN，6年之後離開。在2003年之後，我的技術身份就很難界定了。曾經有個朋友稱我爲“技術文化人”——不以軟件開發爲生，但整天都在拿軟件開發來說事，與這個行業的整體關係可能比任何一個具體的程序員或者架構師都更密切。聽上去像是一種恭維，又好像是暗諷，似乎我是站在戲臺下面帶頭起鬨的票友。其實在我看來，我與一線技術人的根本區別，在於關注的問題不同：他們關心的如何做好軟件，我關心的是如何做好軟件人。更確切的說，我關心的問題是，對於一個普通的程序員來說，如何能夠通過軟件開發這一職業，實現精神上的自由，獲得專業上的成就，生活上的安全感，以及對未來的信心。當然，這是很高的目標，在任何社會、任何時代、任何行業，最終都只有一部分人能夠到達這個境界。但是，我確實是曾經把這當成工作的中心，畢竟人的問題纔是最根本的問題。所以，我在這篇文章裏想講述的，並不是個人的那一單流水賬，而是我自己所見所聞所經歷的一些點滴片段，其目的也是希望能夠就“做好軟件人”這一命題，對自己的感悟做一點概括。
時勢可用而不可恃
與很多同齡人相比，我接觸電腦的時間比較晚，一直到1996年，我纔開始學習電腦操作。最初我的目標很簡單，就是打打字，畫畫圖，打打遊戲，看看影碟。如果說想寫程序的話，主要也就是用來應付一些專業課，確實沒有在程序設計上深究的想法。但初步學會了一點編程基礎之後，意識到編程並不複雜，我就不能自禁地在編程學習上投入越來越多的時間，並最終決定放棄本專業，轉行軟件開發。後來我瞭解到，很多同齡人都跟我有相似的“轉行”經歷。而之所以我們會放棄自己的專業優勢，串行到軟件開發領域，“興趣”固然是一方面原因，而更重要的原因，恐怕還是當時的時代潮流。
在九十年代中後期，隨着PC的普及和互聯網的出現，國內高校中計算機和軟件開發成爲顯赫一時的潮流，“電子化”、“信息化”勢不可擋地涌入各個專業領域，給幾乎所有成熟行業帶來了巨大的衝擊。社會上對於軟件開發人才的需求突然增加，待遇也有明顯優勢。再加上美國克林頓時期的“高科技浪潮”、“新經濟繁榮”的光環，以及微軟、Borland、金山、江民等等成功傳奇，使得人們普遍對於計算機和軟件行業的未來產生了過於樂觀的預期。很多人都覺得，只要搞了軟件，成功是唾手可得的。
在這種大潮流之下，學校裏能擺弄電腦，特別是會寫程序的學生，特別受老師的器重，在就業市場上也有特別的優勢，一個個器宇軒昂，盛氣凌人。今天聽起來可以當笑話，但當時我認識的本校和外校的同學當中，至少有三個人信心滿滿地宣稱自己要做中國的比爾蓋茨，其他的人呢？很多隻是沒有說出來，心裏的夢想是一樣的。在這樣的一種狂熱氛圍之下，一旦你學會寫程序，就不可避免地開始在腦海裏編制各式各樣的美夢，在這些美夢的誘惑下，“串行”就成了理所當然。
如今，我們這一批“串行生”中，有不少已經成爲中國IT產業的骨幹，從這個意義上講，似乎實現了當年的願望。但IT產業在中國卻縮水爲一個競爭激烈、外部估值嚴重下調的普通行業。曾經的美夢，對絕大部分人來說並沒有成真，反而是當年大家並不熱衷的公務員、國企等去處，靠着似乎取之不盡的公帑和用之不竭的公權成爲高通脹時代的幸福特區，這不得不說又是當初沒有想到的。於是很多人在失意之餘，經常“悔不當初”地設想，如果自己當年不轉行，或者如今已經在某機關爬到處長的位置，如何如何。
我不以爲然。
不可否認，當年我們這麼一批人轉行IT，有很大的跟風投機的成分。對於這個行業以及其發展趨勢，缺乏基本的瞭解和積累，對於自己的發展也缺少基本的定位和構想，而是看到這個行業的火爆，就迫不及待地想衝進去分一杯羹。進入這個行業之後，很多人也繼續保持投機的心態，今天看到這個火了，就過去撈一把，明天看到那個有上升趨勢，就衝過去佔個位置。然而事實已經證明，我們所處的這個時代，是一個外部環境變動不居，複雜性不斷加劇的時代。就拿IT產業內部的這點事情來說，我在CSDN的六年，說長不長，說短不短，而風潮的變化何等激烈！最初，企業應用市場中.NET與Java之爭是所有人關注的中心，誰知Google的崛起掀開Web 2.0大幕，一時之間人人都想着“做網站、賺大錢”。Web 2.0泡沫還未散去，雲計算和移動又成爲顯學，引得無數人趨之若鶩。這還是相對較大的趨勢變化，更具體地看，軟件工程領域裏從CMM到敏捷，J2EE領域裏從EJB到SSH，編程語言領域中從Java、C#到動態語言再到Erlang、Scala等新生代語言，還有無數飄起來又迸碎的肥皂泡，如果是追風潮，只會無所適從。因此，在這個時代，我們已經不能基於對外部環境的簡單預期來制訂自己的規劃，只有打好基礎，積累優勢，守時待勢。換句話說，時勢可以“用”，而不可以“恃”。我認識的成功的技術人，或多或少都經歷過一段咬牙堅持的低谷。衝過低谷，就能夠獲得別人無法企及的積累，時機一到，便能勢如破竹。
從這個意義上說，今天去羨慕公務員，就跟當年投機IT一樣。當年不假思索地認爲搞軟件就能發大財，今天則堅信公權力的揮霍可以長期持續下去，一樣的盲目，一樣的篤信。但時勢的變化，孰能逆料？
擡頭看路，埋頭趕路
我最初迷上編程，也就是用Turbo C 2.0開發一些DOS下的結構計算和簡單的有限元程序，然後用Visual Basic去寫一些例子水平的Windows程序，照着書上的例子用彙編語言調用DOS的INT 21h中斷。但很快，我就感到不滿，我意識到自己對於編程這個領域知之甚少，完全是盲人瞎馬，無法確定自己是在朝什麼方向前進。今天的年輕學生很難理解當時我所有的這種不安全感，但處於我當時的環境，走錯路的風險是現實存在的。身邊沒有什麼高手可以請教，更沒有互聯網來開拓視野，我甚至從老師那裏得到諸如“DOS將會永遠是主流”、“Visual Basic將取代C語言”、“C++將被Visual C++淘汰”之類的“專業建議”。這些糟糕的經驗讓我強烈的不安，所以我決定，在進入這個行業之前，要先對它有一個基本的認識。我的方式，就是大量的、廣泛的閱讀。
那時候在我出沒的範圍之內，有三四家上規模的計算機專業書店。沒課的下午和週末的大塊時間，就成了我的閱讀時間。我幾乎每週都要去幾次，站在書店的角落裏，一讀就是半天。書店裏一排排的書櫃，在我看來就是了解軟件開發這個行業的一幅幅地圖，不管是有關的、無關的，看得懂的、看不懂的，聽說過的、沒聽說過的，我都不放過。通過如飢似渴的閱讀，我瞭解到，除了DOS和Windows 95之外，世界上還有Windows NT和UNIX，瞭解到Win32不是Windows 3.2，COM跟.com不是一回事，VBA也不是Visual Basic Advanced，瞭解到Delphi正在跟Visual Basic激烈競爭，瞭解到C/S體系結構的含義，也明白了當時仍然走紅的FoxPro將很快被SQL數據庫所取代。逐漸的，我的大腦裏出現了一副軟件開發領域的全景地圖，儘管今天看來，這幅地圖非常不精確，也並不全面，但是對當時的我來說，已經可以用它來爲自己的學習導航了。
事實上，這段時間的經歷對我正反兩方面的影響都非常深遠，一方面，我由此形成了對軟件開發領域的全局性的理解，多年之後，這種理解成爲我在CSDN工作的主要優勢，也使我對於行業發展的趨勢形成了自己的觀點；另一方面，過於關注大格局，使我少了埋頭鑽研的恆心，對關鍵領域深入不夠，這又成爲我的遺憾。
我後來在CSDN工作的時候，曾經用“擡頭看路”和“埋頭趕路”這兩個狀態來描述一個程序員理想的學習週期。“擡頭看路”，就是專門拿出一個時間段，把所關注行業的大趨勢看清楚，並結合自己的情況，設定目標和計劃。“埋頭趕路”，就是在目標和計劃設定清晰之後的一段時間裏，把自己封閉起來，“兩耳不聞窗外事”，不再關心行業的風雲紛擾，而是踏踏實實實現自己的目標，形成特長。
拿我自己的例子來說，我那時拒絕了計算機專業課老師主攻Visual Basic的建議，果斷地選擇C語言作爲自己的主攻方向，應該說是基於“擡頭看路”所得出的正確決策。而之後過早的從C過渡到C++，則應該說犯了一個錯誤。C語言的小巧、明快、圓滿和強大，迄今無出其右。由於其語言簡捷，沒什麼可學的，學習者的旺盛精力將很快“被迫”轉向真正有價值的東西——算法、數據結構、編譯、圖形、系統編程，等等。我後來認識的很多高手，就是因爲早走了幾步，“沒聽說C++”，就在C上下了苦功夫，“埋頭趕路”，反而“因禍得福”練成了很強的動手能力，而能有一方成就。而我過早進入C++之後，在C++的語言裏打了幾年的滾，反而對於算法、編譯、彙編語言等基本領域投入不夠，基礎沒有打牢，離開學校之後不得已花了很多倍的精力來彌補。現在回想起來，這就是專注不夠的教訓。
到後來我在CSDN工作的時候，這方面的體會就更深。那幾年裏，爲了能夠與各路高手平等交流，我幾乎涉獵了所有重要的技術領域，研究了大多數熱門的技術概念，閱讀之廣，嘗試之雜，遠遠超過一般軟件開發者的需要。正因爲這種“博”，使我對於各技術派別以及各主要企業之間的關係和沿革能夠瞭然於心，從而對於行業發展形成自己的見解。這對於我在CSDN的工作來說，固然是一種必要，但是其實身處其中，甘苦自知。俗話說“樣樣皆通，必然樣樣稀鬆”，廣泛涉獵的代價就是深入不夠，我對此可謂有切身之痛。
反而是到了現在，我可以在業餘時間以平和的心態深入研究自己喜歡和擅長的領域，便又可以享受“埋頭趕路”、不聞世間紛擾的充實與快樂了。
遇高人不可交臂而失之
我在初步掌握C語言之後不久，就一步踏進C++。C++複雜的語法、強大多樣的抽象機制、奇妙的各種語言現象，極大地滿足了我的好奇心和求知慾。我買了好幾本書，幾乎是手不釋卷地每日暢遊於其中。我不想過多渲染當年學習C++的艱辛，其實對於語言本身，我並沒有花多長時間就形成了一個大概的認識。但是C++的真正挑戰在於從“知”到“行”。我最突出的印象是在當年學習計算機圖形學時，老師佈置了一個大作業，我信心滿滿地希望用最新掌握的Visual C++在Windows下來完成。那時候我已經熟悉Win32 SDK開發，在窗口過程（wndproc）之中援引定義好的一組類，就可以完成手上的工作。構思起來似乎很容易，但是一下手就發現腦子非常亂，要設計哪些類，在類與類之間建立什麼樣的關係，是不是使用模板，選擇似乎非常多，而似乎每一條路都有優勢，也有問題。以我當時的經驗，完全沒有選擇的依據。勉強下手之後，很快遇到了一系列的問題，產生了一連串新想法，進一步動手寫出一堆新的類，就這樣，我在問題的外圍架牀疊屋地打轉，幾乎寫了一個小小的Windows圖形類庫，但好像代碼越多，距離要做的具體事情反而越遠，心裏越發虛。到了即將交付任務的日期，我已經積累了一大堆沒有測試過的類代碼，結果可想而知，當最後我終於將任務代碼寫完之後，編譯運行的結果就是程序崩潰。在進行了幾個小時的調試之後，我喪失了耐心和信心，於是推翻全部代碼，轉而用C風格重寫了整個程序。這一次效果非常明顯，僅僅熬了一個通宵就完成了一份高分作業。
當時這件事情對我的刺激很大，在一種羞辱的感覺中，我強烈地意識到我的C++水平其實非常低下，於是我就到處尋找能夠提高C++水平的書。很自然的，MFC就被我納入視線之中。
當時正值MFC處於其頂點，書店裏介紹MFC的書不但數量多、篇幅大，而且那行文的派頭也最足，給我的印象，好像MFC就是軟件開發皇冠上的明珠，掌握了它就可以俯瞰衆生。所以我買了好幾本大部頭的MFC書來啃。老實說，如果抱着知其然而不知其所以然的心態去學習MFC，其實也並不是那麼困難的事情。在微軟強大的開發環境支持之下，照着書上的例子多做多練，上手並不難。但對於我來說，越是使用MFC，我就越是不滿。第一，我不明白MFC爲什麼要這麼設計，特別是那個Document/View，到底有何奧妙，第二，我看不懂MFC裏那許許多多奇怪的宏，第三，我不知道MFC是怎麼跟我熟悉的Windows API環境結合起來的，或者更具體的說，MFC是怎麼能夠把Windows巨大的switch消息處理結構拆接到一個個類的消息處理成員函數的。簡單的說，我完全無法把MFC與我熟悉的C++連接起來，兩者之間似乎存在一個巨大的斷層，讓我覺得MFC完全是另一門語言。我花了不少心思去猜測、分析，並試圖閱讀MFC的源代碼，但是那時候的能力還非常淺薄，完全無法理解MFC的奧祕，也無法彌合那個斷層。很多次，我都不禁灰心地想，也許自己並不是寫程序的料，或者不是搞C++的料，或許應該放棄。
就在我爲這些問題感到困惑和鬱悶的時候，在一個陰天的下午，我在一家書店的櫃檯上發現了一本裝幀普通的新書，書名是《深入淺出Windows MFC程序設計》，作者侯俊傑。我只站在那裏翻了五分鐘，就被其中的內容“雷”得頭皮發炸——這本書不但正中靶心地直接打到我的興趣點上，而且語言之優美，內容佈局之巧妙，都是前所未見。記得那本書的價格不菲，我當時着實負擔不起，於是找同學借了錢也要把它買下來。在接下來的幾個星期裏，我每天捧着這本書反覆琢磨到深夜，感覺所獲得的長進，比前面幾年都要多。通過這本書我瞭解了一個完全超過我之前層面的C++的世界，也把作者的名字牢牢記住。當時我就想，如果有朝一日，能夠結識這位侯先生就好了。
幾年之後，這本書的第二版以《深入淺出MFC》爲名發行，暢銷海內，終於有更多的人得以見識這本技術圖書的典範之作，也認識了這位侯捷先生。不過這個時候我對於C++的關注點，已經從面向對象的應用框架轉向泛型和STL，相反，對於MFC我有了更多批判的看法。在2000年底，我動手翻譯了STL之父Alex Stepanov的一個長篇訪談，大約兩萬多字，翻譯之後發表在CSDN網站上。後來又轉載到《程序員》雜誌上。因爲這篇文章，我得以認識了CSDN的掌門人蔣濤，並且經他介紹，終於認識了心儀已久的侯先生。
與侯先生的相識，是我C++學習生涯的一個重要的轉折點。當時侯先生也已經將注意力轉向泛型和STL技術，並且在《程序員》雜誌上發表了著名的《C++大系》系列文章，爲國內的C++學習者打開一片全新天地。與侯先生剛剛認識不久，他就通過當時《深入淺出MFC》的編輯周筠女士，向我贈送了好幾本“C++大系”中的重要作品。我至今還能回憶起打開那個大包裹時興奮得幾乎要暈厥過去的感覺，也還能清楚得記得那其中的內容：Scott Meyers的Effective C++和More Effective C++，Bjarne Stroustrup的The C++ Programming Language，Matt Austern的Generic Programming and the STL，Nicolai Josuttis的The C++ Standard Library和那時剛剛出版的Andrei Alexandrescu成名作Modern C++ Design。一下子有了這麼多經典，我幾乎廢寢忘食的閱讀、試驗，遇到困難，就用郵件向侯先生請教，在侯先生的指導之下，僅僅短短的幾個月，我對於C++的理解便上了一個大臺階。特別是Scott Meyers的兩本書，對我的作用可以說是醍醐灌頂、脫胎換骨。在那之後，侯先生又邀請我與他合譯The C++ Standard Library，以共同合作的方式給我另一個層面的教益。在那之後幾年裏，侯先生總會時不時的給我幫助和關懷，幫我購買珍貴的資料，關心我的事業和生活。與侯先生的交往，套用一句俗話，“千言萬語說不盡”，但如果可以概括的話，可以歸爲八個字：知遇之恩，師生之情。至今，這段回憶對我來說，是深藏心底裏的一份溫暖，也是一份歉疚。侯先生曾寄希望我走入技術寫譯和培訓的行業，並幾次爲我創造這樣的機會，但是我卻最終沒有從命。雖然多爲國內現實所限制，卻也少了報答先生的機會。
實際上侯先生不光幫助了我一個人，在七八年前，我們這羣在內地的C++愛好者中，先後直接受到侯先生幫助的有數十人，其中有不少與我保持聯繫。據我的觀察，這些人中的大部分都有着還算不錯的發展。而如果算上侯先生圖書的讀者，侯先生幫助的人何止十萬衆。一個人的貢獻，可至於斯！
所以每當我總結這段歷史的時候，就會不禁感嘆，對於一個學習者來說，高人的點撥確實可以令人“頓悟”，走到一個全新境界。因此，遇高人不可交臂而失之。我也知道，像侯先生這樣品質和才情的高人畢竟是極少，但我認識的大部分技術高手，其實都是可師之人。如果能夠放下身段，認認真真向高人請教，那麼對於自己的成長和發展，都將有莫大的好處。
文武之道
在技術這個行業觀察思考了多年之後，我認爲我發現了程序員實現事業發展的一個關鍵原則，那就是在編程技術上保守一點，而在專業及行業領域進取一點。我稱之爲“技術組合的文武之道”。有趣的是，這個“文武之道”，恰好與一般程序員的實踐相反——大部分程序員在編程技術上比較激進，卻疏於在行業領域下功夫。
我最早注意到這個問題，是在研究生實習期間。在研究生的第二學年，我被導師派往清華同方參與一個大型專業軟件項目的開發，體驗到了真實環境下的團隊軟件項目開發。這個項目由於脫離具體的條件，目標過高，與同時期很多雄心勃勃的科幻項目一樣，最終都以失敗告終，但是這段經歷卻使我受益良多。正是在這個專業項目的開發當中，我重新認識了領域知識與編程技術之間的主次關係。
項目本身的目標是開發建築工程企業的ERP系統，第一階段的任務是形成概預算自動計算功能，其中涉及大量的圖形繪製、對象建模、數據存儲等我非常感興趣的技術內容。在參與這個項目的初期，我非常興奮地設想過一個雄心勃勃的技術方案：用VC/MFC爲開發工具，自主開發圖形庫和建築構件類庫，支持3D可視化建築建模，並且用類似對象數據庫的方式進行持久化，等等。然而真正進入這個項目，我發現項目主管並沒有帶領我們衝向這些令人興奮不已的技術高峯，而是一個會接着一個會的分析需求，研究當時的概預算規範，瞭解有關領域知識。這個冗長繁瑣的過程，讓我大失所望。然而更令人鬱悶的還在後面，當項目進入到編碼階段時，項目主管竟然選擇Visual Basic作爲開發工具，而數據庫服務器更是非常陽春的Jet DB，也就是Microsoft Access。我對此強烈不滿，幾次醞釀之後，終於找到項目經理，反應我的想法。這位項目經理是清華的畢業生，已經通過Visual C++的MCSD認證，是當時極爲罕見的技術人才，在聽了我的想法之後，他陳述了自己的看法。他說，這個項目是一個專業軟件，主要的困難和障礙都集中在專業領域，而在編程技術本身，無論是VB還是Jet DB，都足以在現階段滿足要求。在這樣的情況下，如果選擇MFC或者其他更酷的技術，無疑會大大增加技術實現的難度，純屬是毫無意義的自找麻煩。他的原則，就是儘可能用可實現項目需求的最簡單的技術來完成任務，因爲技術越簡單，項目風險就越低，團隊開發的管理成本就越小。
事實上，當年我驕氣很盛，並沒有被說服，反而覺得他缺少冒險精神。但是他對於編程技術與領域知識之間輕重關係的闡述，確實也引起了我的思考。而且在項目實踐中我也確實發現，相對於變化多端的概預算規則，在屏幕上畫個3D的房子並不是這個項目的關鍵。在一起工作的專業程序員們，似乎很快就可以完成類似這樣的任務，但是面對複雜的業務規則，他們就莫名其妙，非常無助了。
畢業之後，我的第一份工作是在聯想做掌上設備的軟件開發，在那裏我也觀察到相同的問題。在聯想，我搞了一些編程技術上的創新，把SGI STL和 Boost的幾個組件移植到Windows CE平臺上，並自己寫了一個遠程設備的軟件調試庫，還爲幾個自主軟件設計了非常符合設計模式精神的架構。但是所有這一切都沒有得到大家的認可，大家關注的中心，是新設備的產品特色，軟硬件配置，營銷重點，成本控制，項目實施等等。領導和同事們對於我的這些努力，既沒有鼓勵，也沒有反對，而是任我自便，我當時對此確實是大有“懷才不遇”的抱怨。但幾年之後，當我有了更多的職業積累、更廣闊的視野和更成熟的心態之後，我才能更客觀地反思自己在聯想期間的經歷。其實，無論是手機、掌上電腦還是平板電腦，消費電子類產品的開發當然是以產品設計、營銷規劃和工程控制爲中心，這纔是這個行業的關鍵領域知識。相比之下，什麼STL，設計模式，完全不是重點。如果我當時的心態更成熟一些，能夠主動學習和掌握消費電子產品的產品設計專業知識，讓自己的編程技術能夠爲組織的整體目標服務，那麼我今天的職業發展可能會是完全不同的另一番模樣。
進入CSDN之後，我的所見所聞就更多了。大量的技術高手，把主要精力放在“改善程序員開發體驗”的事情上，比如新潮酷派的語言，漂亮的開發環境，方便的代碼生成和魔術般的設計抽象，倒是能贏得程序員圈子裏的一片叫好聲，但是卻得不到客戶的認可。反而是很多團隊，由於對應用理解到位，用普通的技術爲客戶創造了巨大的價值。比如我認識的一家企業，經過深入交流和分析之後，發現移動財務審批是客戶沒有提出來，但卻非常需要的功能，於是用簡單可靠的技術手段，實現了這個功能。客戶非常興奮，大加讚賞，甚至破天荒地將其在全國各地的中層幹部召集到北京，專門針對這個功能進行培訓。
這些經歷和見聞，逐漸使我意識到了領域知識與編程技術之間的主次關係。事實上，從客戶和管理者的角度來看，你使用什麼先進的編程技術並不重要，重要的是你的軟件能夠正確地做好該做的事情，你是否能對所解決的現實問題有深刻的認識，有所洞見，有所創新。很多時候，在程序員圈子裏被追捧的新概念、新思想和前衛技術，實際上並沒有經過時間和實踐的檢驗，存在很多問題，過於積極地引入它們，對於客戶的利益，反而是一種危害。真正能夠意識到這個問題的開發者，在編程技術本身上會趨向於穩妥保守，不急於追新趕潮，寧可做一個後知後覺分子。但在行業領域，他們則完全是是另一個姿態，積極進取，敢於創新和嘗試，總是殫精竭慮地思考如何爲客戶提供更合用的功能，更高的價值。在我所見範圍之內，凡是這樣做的，不論是企業還是個人，也無論是在企業應用市場還是在消費類市場中，都能夠更快的走向成功。
正是基於這個認識，我在很多場合都提出程序員要懂行業，或者重視領域知識。我相信，如果能夠掌握好編程技術和行業知識之間的文武火候，作爲程序員個體，無論是在企業中服務，還是自己創業，成功會相對容易些。
結語
2009年，我開始了一段新的人生嘗試，究竟將走向何方，尚未可知。但對於我來說，作爲“軟件文化人”的這段經歷，已成爲我生命中的一段充滿精彩與遺憾的篇章。當然，現在還遠遠沒有到正式總結時候，這段旅途對於我的意義，可能也尚未真正揭示出來。我在這裏用了這樣一種鬆散的手法，隨意收集了幾個片段和感悟，由於漏掉了許許多多幫助過我的人，這篇東西是不可以稱爲“成長故事”的。但寫下來的這幾個散片，倒也確實是我有感而憶，有感而發。不知道過幾年以後，再讀到這些，是否又會有不同的看法？那就不得而知了，到那時再說吧。
作者簡介
孟巖，現就職於IBM中國公司企劃傳播部。曾任CSDN和《程序員》雜誌技術總編。