答覆：我不會OOO，仍然可以XXX
3,285 views| 2008-11-25|
轉載時請註明出處和作者聯繫方式
文章出處：http://www.limodev.cn/blog
作者聯繫方式：李先靜 <[email protected]>
按照《審死官》裏的讀法，標題可以讀着：答覆：我不會圈圈圈，仍然可以叉叉叉。圈圈叉叉並不特指某個東西，而是一個通配符。代表諸如：我不懂COM原理，仍然調用COM組件。我不懂數據結構，仍然可以寫程序。我記不得常用API，仍然照樣用IDE。如此等等。
我是個愛好和平的人，不喜歡和別人口誅筆伐，幾乎從來沒有寫過主動攻擊別人的文章。亞里斯多德說，我愛更老師，更愛真理。讓我套用爲，我愛和平，更 愛真理。若只是爲了一已之私利，我不會寫這篇文章的。這裏闡明一些個人認爲正確的觀點，想和所有有興趣的朋友討論一下。但就事論事，不要進行人身攻擊，沒 有必要引發一場口水戰。
那些朋友說的也是事實，這不懂某些知識，確實仍然可以做相關的工作。這讓我想起一個小故事：記得上大二時，認識了一位開家電維修店的教授，我想跟他 學電器維修。他同意了，條件是要我堅持看兩年時間的電路圖。我找了一本長虹電視機的電路圖，看了幾天，發現太難了，兩週過去了，一個也沒看明白。
我找到那位教授，說，爲什麼要看電路圖，小學生連歐姆都不知道是什麼，更別說看懂電路圖了，他們爲什麼也可以修家電？你不想教我就算了，幹嘛要讓我 看兩年時間的電路圖。教授回答說，小學生能和教授相比嗎？對小學生來說，書上有的案例，他可以修，與案例有一點差別，他就摸不着頭腦了。而教授，對電器裏 面電路清清楚楚，不管是哪裏壞了，什麼現象，把幾個關鍵點的電壓電流一量，就找到問題的根源了。
用Window當然不需要了解操作系統原理，用瀏覽器當然不需要明白文檔對象模型，把excel嵌入到word裏也不需要知道OLE，用 PhotoShop的人不需要熟悉圖形學，用VS 2005的人不需要精通編譯原理。這沒有錯，對用戶而言，他們不需要知道他們不必知道的東西，這是用戶友好性，值得提倡。而作爲一個軟件工程師，你應該明 白操作系統原理，應該瞭解編譯原理，應該熟悉相關的東西。
我不想說別人浮躁，我自己也很浮躁，說別人浮躁只是五十步笑百步而已，這個年頭誰不浮躁呢? 但從實用的觀點來說，不知道某些知識，並不值得引以自豪。理論有沒有用，要不要弄清楚某個原理，要不要記住最常用的API。這都是仁者見仁，智者見智的問 題。後面列舉一些的個人經驗，合則取之。
從畢業後到現在，我一直帶在身邊的書，只有一本數據結構。前前後後，爲了學習的目的，我把裏面大部分數據結構和算法寫過三遍，這還不包括工作中零零 散散寫過的。開始是只是爲了熟悉其原理，後來開始想怎麼把代碼寫得更優雅一點，組織得更合理一些。這反反覆覆耗了我大量業餘時間，事實證明這些時間沒有白 費。後來的經驗告訴我，差不多所有程序，都是由這些基本算法和數據結構組合起來的。對這些基本算法和數據結構掌握得比較紮實，不但自己寫程序可以更快，閱 讀別人的程序也更容易。如果你還堅持說，不懂數據結構仍然可以寫程序。我會說，你永遠沒有別人寫得快，沒有別人寫得好，程序沒有別人的快，沒有別人的穩 定。
後來我又花了不少時間去學習設計模式。設計模式不是時髦，而是實用的東西，絕不止幾個概念而已。我不但認真的讀完了那本書，爲了實踐，總是找機會去 用它們，那怕只是自己寫個小程序，也不忘與設計模式掛鉤。現在再看那些程序，或許有些醜陋，但正是那些練習讓我熟練的掌握了設計模式。如今我再也不會動則 就用設計模式了，因爲我知道了什麼地方該用，什麼地方不該用。回想起來，設計模式在很多地方它幫我的大忙。如果你還在說，不懂設計模式，仍然可以寫程序 了。我只能替你感到惋惜，這麼好的東西，你卻固執的視而不見。
以前公司一個產品是基於Apache的，我只是負責維護mod_proxy模塊。我的任務是修改它，讓它支持HTTPS。不去研究apache的架 構，不去閱讀其它部分的代碼，我仍然可以完成的這個任務。但我利用大量業餘時間去研究apache的架構，去閱讀HTTP協議，我明白了它的併發模式，明 白了它的配置機制，明白了它的模塊加載機制，明白了它的LOG機制，明白了作爲一個服務器的基本架構。這對於完成自己的任務是有幫助的，更重要的是從中學 到的知識，對後來的工作也有幫助。剛到深圳時，在新一家公司，我的第一個任務是開發一個自動編譯服務器，整個過程都是自動化的，還是支持多用戶排隊編譯。 與apache相比，這自然是小菜了，包括需求分析、設計編碼和用戶手冊，不到十天時間就搞掂了。
有段時間我維護html tidy，那本是w3開發的一個小工具，功能是用來修復HTML網頁中的錯誤，並輸出到一個XHTML文件。它相當於一個HTML語言解析器，用到編譯原 理的知識。而我對編譯原理了解不多，如果湊合着修改BUG，問題也不大。我還是選擇了學習編譯原理，至少花了半年業餘時間學習相關理論，自己又寫了幾個微 型語言的解釋器，感覺自己成半個編譯原理專家。我發現這些知識非常有用，特別是狀態機，對於字符串處理非常方便。又利用編譯原理寫過一些代碼產生器，用它 們來產生那些類似而又不同的代碼，爲我節省了大量的時間。如果當初我固執的認爲理論沒有用，一定錯過了這樣一件強大的武器，那是多麼可惜的事情啊。
我維護過一個XMLTransformer，它的功能是調用xerces的函數把XML和XSLT文件解析成DOMTree，然後調用xalan的 函數把這兩顆DOMTree轉換成一個HTML文件。其實只要知道xerces的接口，不明白xerces的內部工作機制，完全可以勝任自己的工作。我還 是花了不少時間去研究xerces的代碼，此時我還沒有看過《設計模式》，看了SAX解析器的代碼，我明白了Builder模式，後來屢試不爽，用這種方 式，我寫一個解析apache配置文件的模塊，一個解析INI配置文件的模塊，一個解析XML配置文件的模塊，還有一個LRC歌詞解析器。你看，時間沒有 白費嗎。
有段時間老大讓我去寫microwindow的控件測試程序，我花了不少時間去研究microwindow的實現，明白了它消息機制，明白了各個控 件的實現機制，記住了各個控件的風格、消息、通知，總結出它們的規律，寫了一個通用的測試程序。不但提前完成了那個任務，這對於後來我用win32 SDK寫程序幫助也很大。因爲熟悉常用的控件和API，編程速度大爲提高，出錯機率也大爲降低。
我也曾去研究過Wine的代碼，主要是想知道COM的實現原理，這完全是爲了滿足我的好奇心。看似無關緊要的知識，也後來竟然派上了大用場。爲了簡 化進程間通信機制，我們在一個嵌入式系統中，實現一套進程間通信機制，大大簡化了進程間的過程調用，成爲那個平臺的基本架構之一。同樣是因爲興趣，我研究 了gdb和ptrace的實現，學習到的知識也在後來的工作中派上了用場。
還有很多這樣的例子，說這些無意炫耀自己，我只想說明這樣一個事實：書到用時方恨少。很多知識，知道比不知道好，知道了至少就多一種選擇，甚至可能在你意想不到的時候派上用場。
作爲程序員，固執的不去學習，或者因爲門戶之見而把自己限於一個小範圍，個人認爲不是明智之舉。一句話，知道它們，我們可能做得更好，不知道它們，決不可能做得更好！