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和《程序員》雜志技術總編。 (本文來自《程序員》雜志2010年11期，更多精彩內容敬請關注11期雜志) 《程序員》2010年11期精彩內容：互聯網架構集結號 《程序員》雜志訂閱

總結

以上是生活随笔為你收集整理的一个“技术文化人”的片段感悟的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。