畢業也有幾年了，也看了和學了不少東西，《編程高手箴言》讀後感。有時也想寫點什麼，但總是覺得頭緒很多，一直沒有動筆。最近翻了翻樑先生的《編程高手箴言》，突然想寫點什麼，權且用讀書筆記的形式寫點東西。
在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在你眼裏已經沒有什麼差別了。
