嗯，我昨天寫了一篇《我這一年》，表示最近有點時間了，可以寫點博文了，網友們就很熱情，馬上在回帖中提問，其中有一篇比較引起我注意，就是和我討論我的書《0bug-C/C++商用工程之道》裡面對C和C++的應用比例和深度問題。
應該說，我自己一直定位還是技術人員，我呢，也有興趣在關於技術方面展開一些討論，所以我暫時放下准備回復的一些其他朋友們的問題，先回答這個問題。
先立一個大前提，我無意引發語言之爭，在我心目中，各種語言無優劣之分，合用的就是最好的，不同意這個觀點的朋友，就不必向下看了。謝謝！
原文如下：
肖舸老師您好！
我是一名在校計算機專業在校研究生，一直默默關注您的博客，您所寫的東西給了我莫大的幫助，開闊了不少視野。之前買了您的書《0 bug C/C＋＋商用工程之道》，目前閱讀了大概2/3，我覺得的書中的內容對我受益匪淺，除了增長了經驗性質的東西，也學習了不少實用的以前不曾所知的技術，真的非常謝謝您！希望以後還能出這樣類似的好書！
學習歸學習，肖老師是業界的專家，而我只是初出茅廬的小鳥，不過我對肖老師書中的個別觀點不太苟同。肖老師C語言的功底非常深厚，但是對C＋＋的理解一定不夠深，或者說對面向對象的編程不夠深至少在寫這本書之前）。肖老師鼓勵我們不用多態、繼承等面向對象的高級特性，只是把C＋＋當作了一門多了封裝特性的C語言，開發方式上仍然是純面向過程的，這點至少這是本人從書中所看到的，我想肖老師那時肯定沒看過關於設計模式方面的書吧，以至總是把C＋＋當做只是多了對象的C語言去用。《0 bug C/C＋＋商用工程之道》中講解到的基礎庫，因為都只是基礎功能性質的數據結構或庫，所以對面向對象的高級特性依賴不多，但是在開發實際應用層面上的東西或軟件架構時，面向對象的高級特性能有效降低系統的耦合性，增強系統可維護性。
不過我仍然覺得《0 bug C/C＋＋商用工程之道》是一本不可多得的好書，個人只是不太苟同裡面對於C＋＋使用的觀點，這個純屬自己本人觀點。再次謝謝肖老師，希望能再讀到類似的好書！
我的回復：
這位朋友你好，感謝你對我書的關注，關於你的問題，我可以做一點說明和探討。
嗯，關於C和C++使用深度比例的問題，我同意你的看法，我其實對C++了解並不深入。對於你說的多態、繼承等面向對象的高級特性，理解不深刻。設計模式也沒怎麼看。呵呵，是不是有點失望？
是這樣的，我是商業化程序員，從1995年我進入游戲公司，正式成為一個職業程序員開始，嗯，怎麼說呢，壓力一直在這麼多年伴隨著我，其中主要就是生存壓力。
了解我的朋友都知道，我原來是學習建築的，計算機軟件專業是半路出家，就是因為喜歡，所以我放棄以前國營單位的建築施工員職務，專門跑到成都一家公司打工，寫程序。
這種情況下，我起點比別人低，又要在這個行業裡面生存，怎麼辦呢？
我首先要學習，以獲取足夠的職業技能，來滿足工作的需求，不然就會被炒掉。但另一方面，我也不可能像大學裡面的學生一樣，系統地學習，為啥？我還得先寫出程序來，讓老板賺到錢，我也才能領到我的薪水吃飯。
所以，我的學習，我想，社會上很多職業程序員的學習模型，大概都差不多，我歸納就是“用以致學”。即用到哪塊知識，就惡補哪塊，很K書，多做實驗，多掌握一點細節特性，以便立即應用到工作中。
說個笑話，以前我基本上每找到一份工作，都需要惡補1~2個月，為啥，因為工作機會這個東西，只有我將就他，不可能他將就我，如果他需要的知識我沒有，我就惡補，然後還要在以後的工作中，邊做邊學。
這樣做的好處和壞處都是顯而易見的：
壞處是我沒有經過系統的理論訓練，對於很多理論上已經定論的東西，不知道，非得自己試驗出來，才能深刻了解。實際上，這是走了很多彎路，做了無用功。而且，我在工作中的用詞、用語習慣，和很多科班出生的人不一樣，大家溝通不容易。
但好處是我們腦子裡面沒有條條框框，一個語言、一個技術，大家都說好，我未必說好，我喜歡自己來測試，看能不能帶到我的工作中有效幫助我，不行的就算了。並且，由於很多試驗我不是聽人說的，而是自己做試驗的結果，所以很多東西很凌厲，實用性很強，對於解決實際工作中的問題，很有幫助。
所以，這個問題我認為見仁見智，還真說不好那個就是最優秀的，科班出身和實做出身，都能成才，也都有混不下去吃不上飯的。你說是不？
但我想有一點是最重要的，長期這麼堅持，我養成了一個習慣，就是“實踐是檢驗真理的唯一標准”，特別強調實驗法和方法論，很少去人雲亦雲。結合到我們的軟件專業，我也總結出一句話，你看看能理解不：“計算機是檢驗程序的唯一標准”。
一個程序、一個語言，一門技術，你說好不好，沒用，我說好不好，也沒用，計算機說了算。我今天有個用戶需求，它滿足了，並且開發起來多快好省，就是好東東，滿足不了，說什麼都是假的。這就是我對技術的看法。呵呵，你看呢？
嗯，歸納到C和C++語言上，我是這麼看得，兩個都是語言啦，它們和其他Basic語言、匯編語言、C#、PHP、Java。。。等等，這些語言來說，並不具有什麼高貴之處，任何語言，能解決問題就是好語言。大家覺得呢？
我呢，前期從匯編入行，如果說我有面向過程的情節，我是同意的，對於面向對象，我學了一點，能理解，夠用了，我覺得就好了，我畢竟不是語言專家，不需要對一門語言掌握到100分的。只要它能滿足我程序開發需求就好了，這中間，還不能產生太大的學習成本，因為我不可能脫產幾個月去學習，那不用等我學好，工作就丟了，我也餓死了。呵呵。
但是，後來即使我薪水慢慢增高，已經有條件深入研究C++這門語言的時候，其實我也沒有興趣去研究它了。
我想我說到重點了：為什麼我沒有興趣去研究它？
我得說，是開發需求。
長期的程序生涯，我想很多職業程序員都會意識到一個問題，語言不重要、平台不重要、技術不重要、算法不重要、數據結構不重要，所有這些，其實都不重要。
重要的是如何滿足用戶需求。
在開發中，用戶需求千變萬化，程序員如果不能夠抽象需求的共性，而是疲於奔命地以項目制，就事論事的開發，自己的經驗技術沒有一個高效的積累，會累死的。
年輕時，我們還可以加班拼命，但是年紀大了呢？也和年輕人一樣加班？我今年快40了，這半年加班說實話自己覺得有點來不起了，現在還行，過個三五年，我也加不動了，那個時候怎麼辦？
這時候我想到了庫，即，能否通過對以前工作的歸納和總結，為自己總結出一套高效的、沒有多少bug的，可以拿來就用的基本開發庫，通過對自己這個庫不斷地增補、優化、長期維護，來不斷支持自己以後的工作，使自己以後的工作越來越輕松，而不是每個工作都從零開始，最後自己累死。
我後期的興趣主要就在這上面，所以，大家看見了《0bug-C/C++商用工程之道》這本書裡面的工程庫。
因為我覺得，這個庫的維護和精益求精，更能幫助我賺錢，而不是我去把C++語言背的滾瓜爛熟。
這裡我也奉勸學計算機軟件專業的學子，或者正在從事程序員這個職業的朋友，如果你想在這個行業裡面走得很遠，走一輩子，成為專家級程序員，最好從現在開始，就准備自己的工程庫。只有有了這些沉澱和積累，你才可能平安度過程序員35歲現象，寫程序寫到60歲去。嗯，這其實是我個人的一個夢想，中國還沒有多少60歲的程序員，我想做這種程序員。
總結庫不難的，一個人再跨行業，但是軟件專業有些通理是不變的，把這些總結下來，不斷根據新的需求調整，每次調整力求沒有bug，最終，會有一套真正屬於自己的庫的。
嗯，這個時候又有人說了，“不要做重復造輪子的事情！”，言下之意，只要這個世界上有了現成的庫，就完全不必自己做無用功。
不知道大家怎麼看，我發現，說這話的，學校裡面的學生說最多，我也一直認為，這裡面或多或少有點自我解釋，有點給自己偷懶找個理由的味道。
原因很簡單，以後大家走到工作崗位，面臨的機器、平台、需求千變萬化，每個庫在寫的過程中，都是開發者憑想象在預估未來的需求，總有不滿足之處，如果一個人，只會依靠現成的庫來寫程序，嗯，如果有一天沒庫給你用了，你怎麼辦？
我不敢想，起碼，我自己不敢做這種程序員。
事實上，走上工作崗位的程序員，不多，1~2年，我想一定就會碰到找不到現成庫來用的情況。
我的感覺，大多數庫在大多數時候都是無用的。
怎麼辦？自己來咯。
舉幾個例子吧，就說我最近做實時數據庫的問題。
二分法大家知道吧，我想這種算法是高校裡面最喜歡研究的，也是庫最多的。
我們面臨的情況比較特殊，二分法可能查找時間點，可能匹配時間段，也可能去一個數序中模糊檢索一個偏移位置，然後決定是否再進一步精細查找。。。。還有很多特殊的應用需求。
最變態的，我們需要二分法給我反三，即最後模糊查到最靠近的三個元素，並論述我們標定的查詢條件在三個元素的相對關系。
還有就是我們要求送進去的可能是幾種結構體，也可能是一個浮點數表示的時間點，還有可能是一個包容了某個時間戳的一個大型結構體。
還有返回值，可能我們需要一個精確的index，一個反三的報告，或者一個時間段與時間段比較的兩重報告。
這些都是應用需求。
怎麼辦？自己寫咯。
最後我們光二分法開發出好幾個模塊，嗯，而且基本上都是純C的，沒用C++，為啥，這一個純方法，沒有實體數據，我確實想不出有什麼封裝的必要，面向對象，這個對象的定義如果我沒有記錯的話，是一堆數據以及其方法的集合，數據都沒有，咋封裝？
封裝一個類，裡面全是靜態函數？那我還真不如用純C完成。
還有樹，我們玩來玩去，最後做了一個非常奇怪的結構，甚至我們都不知道它算不算樹，一個雙向鏈表，上層還有另外一個雙向鏈表，二者每個元素之間還彼此耦合，以便獲得檢索尋路的最大方便性，大家想象一下火車的鐵路橋，有那種加固鋼架那種，我們就是那種結構。
這也是自己努力分析了半天，學習了國外很多先進經驗之後，定義出來的一套核心數據組織架構，最後證明，我們這套架構比較科學，我寫了一套檢索算法，自動優選路由，也就300行代碼左右，最多遍歷40幾個塊，就能精確定位一筆數據。
這意味著什麼？在服務器上，我的cache每秒鐘能吞吐125萬塊左右，除去寫入的20萬塊，我還有100萬塊地交換能力，除以40，我每秒鐘能承接2500路並發查詢請求。目前國內外最高的才500，大家覺得我這麼寫程序，能不能賺到錢？
說到cache，嗯，LRU算法，大家可能學得多了，我想這方面的庫很多，但是，我們從一開始就沒打算用庫，為啥？效率。
所有的LRU算法，基本上都是雙向鏈表，OK，多任務環境下，要不要加鎖？不加就崩掉了。
如果用別人的庫，我就只能在外面加一把大鎖，即每個塊被訪問時，是排他的，cache同時只能支撐一個塊被訪問，這麼做當然沒問題，就是賺不到錢了。程序效率太爛了。
那怎麼辦？我自己想了一個辦法，也做了一些斷言和推論，最後讓cache自己就變成一把單寫多讀鎖，針對每個塊分別加鎖，實現了這個需求，這個，可是找不到庫的。也就是因為我這麼設計，大家以為前面每秒125萬塊的交換能力怎麼來的？呵呵。
嗯，就這麼幾個例子，大家覺得能說明問題不？
好吧，最後還是要回歸到C和C++的討論，總結一下吧。
我認為，對於語言，學校中的學習需求和實際中的應用需求，並不完全一致。
學校裡面是“學以致用”，老師無法預估到大家以後從事何種行業，何種工作，因此，必須把一門語言所有的特性都交給大家，還要考試，因此對於一門語言學習的廣度和深度，很好，但是，如何在以後的應用中，巧妙地利用語言的某個特性，來解決實際中的問題，這個沒有講。甚至很多老師自己都不知道。
實際中呢，是“用以致學”，可能對一門語言，一門技術不求精准，特別強調實用性，這個呢，能有效解決問題，但是由於缺乏理論支撐，容易走彎路。浪費很多無用功，很多不必要的加班。
最好呢，是二者結合，即在學校中努力學習，理論掌握盡量扎實，以後到了實際中呢，也不要帶著太多的偏見、成見，虛心學習很多別人的竅門、經驗、實用技術，同時善於總結歸納，不斷形成自己獨有的一些開發思想體系，方能成才。
至於把C++當做多了對象的C語言用，沒有用到它的高端特性，我想既然這麼多年，它擔任這個角色挺好，在我庫中和工作中，也挺合適，那就讓它繼續做下去吧。呵呵，不然，我的書就不是C/C++商用工程之道了，而是《0bug-C語言商用工程之道》了。
呵呵。
嗯，這樣回復你還滿意嗎？
肖舸
本文出自 “肖舸的blog” 博客，請務必保留此出處http://tonyxiaohome.blog.51cto.com/925273/573178
