我就是程式，程式就是我嗎？ (轉)[@more@]

我就是，程式就是我嗎？

“我就是程式，程式就是我。”梁肇新先生在書《高手箴言》的封底上這樣寫到。看到這句話不竟有一絲共鳴和莫名的感動。回頭看看，中國第一代的程式英雄裡，梁先生是少數還在從事這個行業的戰士。我是報著對他們敬仰將我帶入這個殿堂的（雖然我說不清後不後悔）。梁先生出道很早，但成名卻不算早，在那個年代中屬於成名最晚的人(成名越晚的程式設計師所面對的挑戰不比機遇少，想想越來越惡劣的行業)。憑藉自己的超級解霸的“Direct CD”的硬功夫在國內如此惡劣的應用環境中殺出了一條血路，也算是我等碼工碼農（寫程式碼的工人農民）們敬仰的一位好漢。

第一次讀梁先生的文章是在《程式設計師》上，也就是《程式設計高手箴言》第一章，感覺是一篇不錯的文章，有很多觀點我很認同。也是因為這篇文章影響，我在看到《編》這本書後出於衝動一下就買了一本。我想想看看一位程式英雄的知識沉澱，也回憶一下自己的程式人生。

花了一週瀏覽完《程式設計高手箴言》一書（核心一章因為興趣不大沒有讀），感覺卻很難形容。一方面這本書是大陸這幾年難得技術方面原著書（大部分好書都是駁來品），一方面我卻覺得失望大於原來的期望。我個人感覺從這本書來看梁先生無疑是一位高手，但其距離大師的境界卻還是有距離。

《程式設計高手箴言》整本書涉及的知識面非常廣，從的核心到程式碼的編寫規範、分析、手段都有涉獵。但由此帶來兩個問題，一是沒有重點，很多問題沒有進行深刻刨析。二是造成整本書的結構很雜亂，比如第二章介紹80386的定址方式，這一節和其他文章沒有一點關係（其實整本書中各章節間的關係也不明確），放在那兒顯的突兀，也沒有說透徹，而且容易給新手給誤會（的可不是這樣定址的）。而且排版和編輯都不算理想，很多句子非常生硬，感覺倒像翻譯的書。大小寫、插圖也有很多不如人意的地方。當然我倒是比較喜歡那種有讀書筆記的排版設計，因為我有隨手寫點什麼的習慣。

整本書中，我比較喜歡的章節是第1章和第6章，喜歡第一章是因為他是有感而發，文字中透漏的幾分狂氣讓人覺得真誠可愛。特別是第1.2節高手是怎樣練成的寫的意氣風發，是我最喜歡的一節，特別是其對中國程式設計師人才結構的刨析，入木三分。在第6章中梁先生介紹一個小型軟體的開發過程以及思路，不喜歡枯燥無味軟體工程教條的程式設計師可以好好讀讀。

讓我覺得最糟糕莫過於PE結構分析的章節。我本來打算仔細的閱讀了這節，而發現理解困難時我不得不參考一些其他的書籍。最後我個人感覺這章文字有很多摘抄、拼湊。有興趣的朋友可以對比一下侯捷先生翻譯Matt Pietrek的《Windows 95 大奧秘（Windows 95 System Programming SECRETS）》。比如兩文的.TEXT一節，不光是圖一摸一樣，讓我們對比下兩邊的文字，《W》一書中“我很驚訝發現，在.text中除了製作出來的碼，以及runtime library 的碼之外，還有一些其它東西。在 PE 中，當你呼叫另一模組中的函式（例如 USER32.DLL 中的 GetMessage）編譯器製造出來的 CALL 指令並不會把控制權直接傳給 DLL中的函式，而是傳給一個 JMP D PTR [XXXXXXXX]指令”，而在《編》一書中“在.TEXT節中，除了我用編譯器建立的和從執行時間庫中用到的外，還有另外的附加程式碼時，我感到很驚奇。在PE檔案中，當你另一模組中（例如 USER32.DLL 中的 GetMessage）……”，不說大家也看的出這文字是摘抄修改的，但摘抄修改也應該請個高明負責的編輯作刀手，修改過後的文字不光有語病，而且生硬的將runtime library翻譯為執行時間庫，最有趣的是這位刀手的那句“我感到很驚奇”，Matt Pietrek在《W》書中後來自問自答，解釋了這個問題，而《編》卻還要驚訝別人已經了快10年的驚訝，這倒的確要讓我感到驚訝了。翻翻最後也沒有發現《編》有什麼參考書目，不知道是否又是編輯疏忽了。我覺得寫書和作軟體一樣是對自己的良心負責的一間事情，不知道梁先生覺得如何？

對《程式設計高手箴言》書中第5章程式碼的規範和風格網友的爭論比較多，我倒認為這節還算不錯。此外我認為梁先生說的“成對編碼”和“規範化編碼”是每一個程式設計師應該具備的基本素質和教養，無論你算不算所謂“高手”都必須遵守這些規範。而且梁先生的文章中的規範對於實際程式設計不是顯的多，而是相反顯的太少了。網上有一本網友們合作重新編排《程式碼大全》，就寫的更加全面一些。

在這兒有兩個規範問題想和梁先生探討一下。梁先生在文章中提提倡TAB應該使用8個位置長度TAB鍵進行縮排。一方面8位長度的TAB鍵過長，影響程式碼排列，另外如果TAB鍵和空格鍵混排（在實際使用中這樣的情況非常常見），這樣的程式碼拿到別的機器或者用別的程式開啟，如果其TAB鍵的長度定義是4位那麼程式碼格式又會變混亂。所以說最好的解決方法是在程式碼中不要使用TAB鍵，全部使用空格。這一點也可以在VC中自己設定。另外梁先生提出的程式碼縮排方式也有點特例獨行，其要求函式的“{”和“}”要和前面程式碼頂行，但是函式內的“{}”卻要都縮排。形成如下的格式。

int main()

{

if(arg == 2 )

{

//程式碼

}

梁先生認為這樣的縮排表示“{}”是下一個層次的內容。而“{}”頂格會影響對程式碼的閱讀。而傳統的認識是“{}”表示一段程式碼（層次）的開始，恰恰方便了閱讀，都縮排就沒有這樣的效果了，而且這樣縮排和函式的縮排方式一致，歧義也小。當然這些都是對編碼規範的一些不同見解。

《程式設計高手箴言》文中的除錯，程式語言的章節顯得有點蒼白了。特別是除錯方法一章，唯一讓我眼前一亮的是其中使用INT 3 進入除錯的例子，但梁先生淺嘗即止，沒有深入，實在是隔靴搔癢。斗膽向梁先生推薦一本書。《Windows 程式除錯（Deging Windows Programs）》。Everett N.McKay和Mike Woodringx兩位可以說是Windows除錯的大師。而且寫的書行雲流水，落地生花，那本書曾經讓我受益匪淺。

另外，《程式設計高手箴言》一書，很多地方行文不夠嚴謹，給人的感覺是有太多的武斷。但舉幾例：

梁先生在整本書中多處乏貶MFC，最讓人詫異的就是第6.1節中的插曲中的那段話。“其實，MFC的很多東西是針對介面來做的，所以他事實上沒有多大用處……例如，某程式先啟動一個顯示的窗體，接著窗體馬上就被隱蔽，之後就倒螢幕右下角程式設計托盤小圖示。這種程式肯定是用MFC做的，因為MFC的程式在開始的時候，視窗是隱藏不掉的。”且不說大概對MFC稍有了解的人就會對這句話發笑，這樣的話出現在BSS上的帖子還過的去，在一本技術書籍中就有失嚴謹了。在我看來，MFC是一個Windows開發的C++框架，為快速開發提供框架才是它的目的，由於歷史原因和編譯器限制，MFC對Windows 的封裝是比較初步的，可以說不如VCL。梁先生編寫的軟體多設計底層和編解碼，這些MFC根本沒有涉及，但要說MFC只能玩玩就太牽強了，而且MFC開創了C++框架的先河，很多地方的設計也很精巧（比如實現RTTI的宏）。架構才是一個軟體的核心和靈魂，（梁先生在第6章也介紹了豪傑大眼睛的體系架構，可見其對框架也是非常重視的），而設計一個優美的框架是何等的難。合理的運用框架、理解學習別人的框架體系正是進入這個境界的第一步，所以MFC絕不是開放思維的禁錮。又比如在函式呼叫方式一節中，梁先生把_cdecl和stdcall呼叫清棧方式分為手動和自動，但實際上應該是函式呼叫者和被呼叫者。自動和手動這樣的說法很容易讓人產生誤解。

總的說來《程式設計高手箴言》這本書更像雜文，而不是一本定位在論述技術問題的書。我甚至覺得如果全書很多章節按照雜文獨立成文更精彩，那樣不僅文風可以更加輕鬆隨便，也不會顯得沒有重點，而且此書的初稿應該是梁先生日常的學習工作筆記，總結位雜文也應該更容易。梁先生在前言中自己也承認“這種以說為主的書確實太難”，不知道是不是這個原因。我個人感覺全書的瑕疵不少，如果你想研究技術或者你已經得道，這本書都不算一本合格作品，但如果你想和一個老程式設計師一起對自己多年的思索的問題進行一次反芻，這本還是有其可讀之處。另外國內去年來值得一談的原創技術書籍能數的出大概就是《程式設計高手箴言》，《與（第二版）》，足見寫一本好書是如何的困難。在CSDN這本書也排行在第12位。可見其還是得到了很多人的認可。

合上《程式設計高手箴言》，靠在沙發上，點燃一根香菸，我不僅在想：我就是程式，程式就是我嗎……

後記：

《》中費老的那句“做人要厚道”就徘徊在耳邊，對於《程式設計高手箴言》這樣少有的國內原創技術作品，我卻在此吹毛求疵，班門弄斧，的確有點不地道。寫書不容易，寫好書更難，但我希望看到更好的書，僅此而已。但望梁先生能原諒我。祝豪傑新年買的好！

2004-2-7 深夜

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10794571/viewspace-974706/，如需轉載，請註明出處，否則將追究法律責任。