我就是程序，程序就是我吗？

    “我就是程序，程序就是我。”梁肇新先生在书《编程高手箴言》的封底上这样写到。看到这句话不竟有一丝共鸣和莫名的感动。回头看看，中国第一代的程序英雄里，梁先生是少数还在从事这个行业的战士。我是报着对他们敬仰将我带入这个殿堂的（虽然我说不清后不后悔）。梁先生出道很早，但成名却不算早，在那个年代中属于成名最晚的人(成名越晚的程序员所面对的挑战不比机遇少，想想越来越恶劣的盗版行业)。凭借自己的超级解霸的“Direct CD”的硬功夫在国内如此恶劣的应用软件环境中杀出了一条血路，也算是我等码工码农（写代码的工人农民）们敬仰的一位好汉。

    第一次读梁先生的文章是在《程序员》上，也就是《编程高手箴言》第一章，感觉是一篇不错的文章，有很多观点我很认同。也是因为这篇文章影响，我在看到《编》这本书后出于冲动一下就买了一本。我想想看看一位程序英雄的知识沉淀，也回忆一下自己的程序人生。

花了一周浏览完《编程高手箴言》一书（内核优化一章因为兴趣不大没有读），感觉却很难形容。一方面这本书是大陆这几年难得技术方面原著书（大部分好书都是驳来品），一方面我却觉得失望大于原来的期望。我个人感觉从这本书来看梁先生无疑是一位高手，但其距离大师的境界却还是有距离。

    《编程高手箴言》整本书涉及的知识面非常广，从Windows的内核到代码的编写规范、分析、调试手段都有涉猎。但由此带来两个问题，一是没有重点，很多问题没有进行深刻刨析。二是造成整本书的结构很杂乱，比如第二章介绍80386的寻址方式，这一节和其他文章没有一点关系（其实整本书中各章节间的关系也不明确），放在那儿显的突兀，也没有说透彻，而且容易给新手给误会（WIN32的汇编可不是这样寻址的）。而且排版和编辑都不算理想，很多句子非常生硬，感觉倒像翻译的书。大小写、插图也有很多不如人意的地方。当然我倒是比较喜欢那种有读书笔记的排版设计，因为我有随手写点什么的习惯。

整本书中，我比较喜欢的章节是第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 DWORD 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 程序调试 （Debugging Windows Programs）》。Everett N.McKay和Mike Woodringx两位可以说是Windows调试的大师。而且写的书行云流水，落地生花，那本书曾经让我受益匪浅。

    另外，《编程高手箴言》一书，很多地方行文不够严谨，给人的感觉是有太多的武断。但举几例：

    梁先生在整本书中多处乏贬MFC，最让人诧异的就是第6.1节中的插曲中的那段话。“其实，MFC的很多东西是针对界面来做的，所以他事实上没有多大用处……例如，某程序先启动一个显示的窗体，接着窗体马上就被隐蔽，之后就倒屏幕右下角编程托盘小图标。这种程序肯定是用MFC做的，因为MFC的程序在开始的时候，窗口是隐藏不掉的。”且不说大概对MFC框架稍有了解的人就会对这句话发笑，这样的话出现在BSS上的帖子还过的去，在一本技术书籍中就有失严谨了。在我看来，MFC是一个Windows快速开发的C++框架，为快速开发提供框架才是它的目的，由于历史原因和编译器限制，MFC对Windows API的封装是比较初步的，可以说不如VCL。梁先生编写的软件多设计硬件底层和编解码，这些MFC根本没有涉及，但要说MFC只能玩玩就太牵强了，而且MFC开创了C++框架的先河，很多地方的设计也很精巧（比如实现RTTI的宏）。架构才是一个软件的核心和灵魂，（梁先生在第6章也介绍了豪杰大眼睛的体系架构，可见其对框架也是非常重视的），而设计一个优美的框架是何等的难。合理的运用框架、理解学习别人的框架体系正是进入这个境界的第一步，所以MFC绝不是开放思维的禁锢。又比如在函数调用方式一节中，梁先生把_cdecl和stdcall调用清栈方式分为手动和自动，但实际上应该是函数调用者和被调用者。自动和手动这样的说法很容易让人产生误解。

    总的说来《编程高手箴言》这本书更像杂文，而不是一本定位在论述技术问题的书。我甚至觉得如果全书很多章节按照杂文独立成文更精彩，那样不仅文风可以更加轻松随便，也不会显得没有重点，而且此书的初稿应该是梁先生日常的学习工作笔记，总结位杂文也应该更容易。梁先生在前言中自己也承认“这种以说为主的书确实太难”，不知道是不是这个原因。我个人感觉全书的瑕疵不少，如果你想研究技术或者你已经得道，这本书都不算一本合格作品，但如果你想和一个老程序员一起对自己多年的思索的问题进行一次反刍，这本还是有其可读之处。另外国内去年来值得一谈的原创技术书籍能数的出大概就是《编程高手箴言》，《加密与解密（第二版）》，足见写一本好书是如何的困难。在CSDN这本书也排行在第12位。可见其还是得到了很多人的认可。

    合上《编程高手箴言》，靠在沙发上，点燃一根香烟，我不仅在想：我就是程序，程序就是我吗……

 

后记：

《手机》中费老的那句“做人要厚道”就徘徊在耳边，对于《编程高手箴言》这样少有的国内原创技术作品，我却在此吹毛求疵，班门弄斧，的确有点不地道。写书不容易，写好书更难，但我希望看到更好的书，仅此而已。但望梁先生能原谅我。祝豪杰新年买的好！

 

                                                                      2004-2-7 深夜