《程式設計高手箴言》的讀後感
《程式設計高手箴言》的讀後感
畢業也有幾年了，也看了和學了不少東西，《程式設計高手箴言》讀後感。有時也想寫點什麼，但總是覺得頭緒很多，一直沒有動筆。最近翻了翻梁先生的《程式設計高手箴言》，突然想寫點什麼，權且用讀書筆記的形式寫點東西。
在PC這個領域，現在的程式已不等於軟體了。
現在的程式不等於軟體,那麼什麼時候的程式等於軟體呢?我想,不管什麼時候,都存在有用的和沒有的程式,而軟體,software,在計算機領域裡就應該指那些有用的程式，而不論這些程式有沒有商業化。呵呵，應此只要我們在為自己或者為別人寫有用的程式，那麼我們就可以說我們是在寫軟體了。
商業軟體的功能和所要達到的目標就不是一個人能"玩"的起來的了。這就是美國新的軟體公司沒法產生的原因。比如Netscape網景是在1995~1996產生的新軟體公司，但是，兩三年後他就不見了。
所謂商業軟體的功能和目標從來都沒有過嚴格的定義，也不會有嚴格的定義。何謂商業軟體?看釋出時的程式碼量?看可執行程式的尺寸?看有沒有複雜神妙的演算法?看有沒有優良的售後服務?還是乾脆就把大公司釋出的東西就叫做商業軟體?當然，現在在一些通用領域，一些不涉及複雜演算法設計的場合，一些已經有大公司進入的場合，單憑個人的力量想要做出可以和大公司抗衡的東西確實幾乎不太可能。但是，計算機科學是門涵蓋很廣的學科，很多分支，比如數字影象處理，影片音訊處理，人工智慧和機器人，等等，只要有人得到了突破性的發現，我想快速形成商業軟體也非不可能。當然了，很可能這些剛出現的小公司很快就被那些巨無霸吞併了。如果稍微看看現在這些巨無霸公司的發展軌跡，就會發現它們吞併剛出現的小公司是家常便飯的事。但即便是這樣，矽谷還是有很多小軟體公司出現。畢竟，軟體業這塊平面上單憑巨無霸公司那些大圓還是填不滿的，圓和圓的結合部總會有空隙存在。至於說到Netscape的消失，原因大家都明白，這其實更多的不是取決於技術。事實上微軟進軍這個領域太直接不過了，軟體上已經有了Visual Studio和MS Office，因此開發瀏覽器的技術對他而言幾乎都是現成的。即便這樣，Microsoft的IE還是在NCSA Mosaic的基礎上完成的。所以Netscape沒有被收購，而是徹底被打敗了。
任何一個行業初始階段時的門檻都很低，但是，只要發展到一定的階段後，它的門檻就必然抬高。
筆者十分贊同這句話，軟體業創意太重要了。什麼東西都是最先做出來的那幾家獲益最多，後來者通常都是分些殘羹。前兩天在同事那裡看一個搞笑的flash，突然冒出一個念頭，怎麼當初我就沒有想到在瀏覽器裡寫個外掛來支援動畫和音樂呢。呵呵，歸根結底還是個人的水平有限啊：-)大家每天睡覺前不妨花個幾分鐘想想，說不定就被你想到個點子從此一步登天了呢，呵呵。
現在中國軟體行業正在形成，所以現在做一個程式設計師一定要有耐心。
我想程式設計師不管什麼時候都需要耐心，耐心可以說是軟體開發者的必備素質，並且體現在各個方面：寫程式的時候沒有耐心那你就等著後面抓不盡的蟲吧；給自己充電的時候你沒有耐心，那麼你永遠只能掌握膚淺的東西；追女朋友的時候沒有耐心，那你就暈，怎麼有番茄扔過來了，我閃。
軟體設計是門要靠腦力的活，而軟體發展的迅速和需求的不斷提高是人所共知的。什麼時候我都不敢奢望把所有的問題都搞清楚了。實際上每個開發者，哦，不，是我本人在開發的過程中總是不斷髮現新問題，不斷在解決問題，是個螺旋提高的過程。我一向認為在開發中學習是最快最有效的。
事實上，美國的商業編譯器也不是一個人能"玩"的，現在你可能覺得很簡單的，甚至Linux還帶了一個GCC，且源程式還在。你可以把它改一改，做個VC試一試，看它會有人用嗎?即使你再做個介面，它也還是GCC，絕對不會成為Visual C++那樣能商業化的'軟體。
我依稀記得曾經看過一篇章，說Borland當初的Turbo Pascal主要就是一個牛牛用匯編寫出來的。呵呵，如果有人給GCC寫個類似VC的介面我舉雙手雙腳贊成，免費幫他測試：-)有時我在想，Borland當初開發Delphi的時候不用Pascal而用C++的話，現在開發工具的市場份額會是個什麼格局?(本人絕對沒有瞧不起Pascal的意思，事實上我的第一門語言就是Pascal，只是因為圖書館裡Pascal的書被人借光了才自學了C)如果我給Gcc寫了個介面，當然還是GCC。用過GCC的人從來不會說GCC比不上Visual C++，兩者實在沒有辦法比，不在一個數量級上。GCC是個強大的編譯器，支援N種硬體平臺和官方的軟體標準，同時也引入了很多軟體開發者急需的好特性。大多數優良的庫，罕有不能在GCC上編譯透過的。嘻嘻，有為GCC做廣告之嫌?至於GCC的商業化，我就看到過一些賣硬體產品的公司，它們附帶的編譯器就是GCC或者其變種，讀後感《《程式設計高手箴言》讀後感》。再說了，大量大型的軟體都可以用GCC編譯出來的，從穩定上講我想不會比Visual C++差吧。事實上，我用Visual C++的時候就遇到過所謂的Internal Error，而我用GCC，就從來沒遇到過這種莫名其妙的內部錯誤的抱怨。我想，GCC絕對有商業軟體的潛質，呵呵，就是在視覺化方面比不上Visual C++，雖說也有一些GCC的圖形前端。
機遇是從耐心中產生的，越有耐心，就越有機遇。
如果你是從MFC入手的，或者是從VC入手的，那麼要做出一個真正的能應用個人領域的通用軟體，就會走非常多的彎路。
怪了去了，怎麼從MFC或者VB入手就會走非常多的彎路呢?從MFC或者VB裡呼叫Win32 API很直接，尤其在Visual C++MFC裡。《箴言》很看重底層，Win32 API難道還不夠底層嗎?難道非要在彙編一級才可以寫出真正的通用軟體嗎?那我乾脆去給CPU寫微碼去了，呵呵~。VB我用的很少，就不說了。至於MFC，如果你真正弄懂了MFC那麼你對於Windows的各個方面幾乎就全部精通了(當然，我是指Windows核心外使用者空間的東東)。
計算機這個東西不管是硬體還是軟體，層次很重要。開發很重要的一個方面就是要弄明白你自己需要在什麼層次上做東西。一個用java寫中介軟體的開發人員，有多大必要去精通系統底層的東西呢?我想如果你不立足於自己的層次做東西，而胡亂搞跨層的東西，結果可能就是出力而不討好了。自己研究研究還行，如果在工作中還是這樣層次不清楚的話，呵呵，就很危險了。
當然，我沒有讓大家不去鑽研，但我想最好還是找個前輩請教，根據自己的興趣制定自己的學習計劃。人的精力畢竟有限，我們要把有限的精力投入為人民服務之中去嘛，可不要浪費了喲，呵呵。
只想混口飯吃，找個工作，可能教你成為MFC的高手之類的書對你就足夠了。
現在的同志好幸福啊，國內在不停的引進國外的名書。想當年在95年左右的時候，外國參考書實在是不多。我建議大家在計算機領域裡面看書最好是找老外的。不是我崇洋媚外，老外出書基本上還是蠻負責的，而國內引進的大多還不錯。但是即使你在修煉國外大牛們關於MFC的書，如果你不認真實踐，那麼光靠書你是不可能成為MFC高手的。MFC這個類庫的設計已經有很多人在抨擊了，我們不多談，但是如果你真的深入到MFC的原始碼裡面去，其他我不知道，但是你肯定可以對Windows的運作有個很深入的理解。
從最低層做起，從最基本坐起。
筆者的看法是從中間層做起。就以Win32上的Java為例，一開始我絕對不會從Java虛擬機器規範，java和本機系統的互動，Java垃圾回收演算法的實現等等很底層的東西著手。也不會一開始就涉及那些什麼設計模式，Frameword框架之類的高層抽象。我會就從Java語言本身著手，熟悉它的語法，熟悉它的基本庫，試著不斷用Java描述問題。在這個過程中，你自然會遇到一些或高層或底層的問題，這個時候你在去鑽研它們絕對不遲，並且只可能是事半而功倍。
高手成長的六個階段
《箴言》一書把程式設計師的成長分成了六個階段。筆者卻認為只有第一階段，即熟練的使用某種語言是每個程式設計師必備的。其他的一些能力對於不同的開發方向應該是不同的。比如《箴言》認為第二階段是精通某種平臺的介面(比如Win32 API)。然而，很多做高層開發的同志，往往不太接觸這些底層的API，因為在他下面，作業系統上面已經疊加了很多的層次了。比如，如果你用Java在Win32上面程式設計，幾乎不需要和系統API打交道。這其實也體現了軟體分層的思想：每一層只負責自己的職能，只和自己相鄰的層通訊。
《箴言》認為能夠進行VxD程式設計，或者進行作業系統核心的修改就算進入了高層次了。且不說VxD已經被Microsoft拋棄了，新的Win32驅動模型WDM，Linux/Freebsd kernel的小修改筆者都參經碰過，但是我從來不認為我到了很高的層次，尤其和那些做高層開發的朋友比。因為實在是沒有辦法比，比較是要在同一個層面上進行的，不同層面的東西你怎麼比?就算你設計了作業系統，如果讓你去規劃一個ERP系統，你也未必成功。再說了，我寫過WDM，覺得WDM也不那麼神秘。但反觀如果讓我設計一個ERP Framework，我倒是覺得很多東西需要學習，我想反之也是一樣。至於說到底層開發，難度大概應該實在比較少的資料和例子程式(尤其在Win32下面)，不太友好的除錯工具，以及較少的系統支撐。不妨舉個例子，在做應用程式開發的時候，開發環境往往有完善的除錯工具，也不太容易把整個作業系統搞死。然而做Kernel開發就不一樣了，一不小心作業系統就崩潰了。記得筆者在做WDM開發時，就掛了第二個硬碟，隨時準備Ghost，呵呵。
這時Win32或Linux在你眼裡已經沒有什麼差別了。