No codes, No reading -----论如何读懂java书
作者：张洪斌
No codes, No reading -----论如何读懂java书
在《定位自己，有的放矢——一位技术作家眼中的Java图书选购技巧》一文中，讲述了怎样在书店选购合适的电脑书。可是，真正的事实是，左挑右选、反复思量终于买了书之后，你的心情也不会很轻松，因为接下来的事情更艰巨：看懂它。在本人的记忆里，每本电脑书都有读起来费脑、甚至费了脑也看不懂的时候，包括本人和很多读者都喜爱的《Thinking in Java》。相信同病相怜的读者会有不少，因为到目前为止，很少听到有说看电脑书轻松如武侠小说那样的。所以，我想在本文中介绍一些自己的读书经验，与《定位自己，有的放矢》类似，仍然以Java书为例。
大家可能都会记得小时候父母老师教我们知识的情景吧？他们都是尽量用生动、具体的例子来做教育。据我父母讲，他们是这样教3、4岁的我学会1+1=2的：先放一个苹果在我的小桌子上，接着再拿出一个苹果……苹果这类看得见、摸得着、吃着酸酸甜甜的“实例”是小朋友喜欢的，抽象思维能力非常发达的成年人未必需要，但是肯定不会厌烦：你愿意研究“美女”这两个字，还是愿意研究美女的一个“实例”？
编程书与1+1并没有本质的区别。编程书内容主要由讲解（TEXT）和代码（CODES）组成，TEXT较抽象，而代码就是“实例”，书的总体结构一般是TEXT-CODE-TEXT。本人看编程书的体会是，如果书中没有用于举例的代码，或者代码没看懂，多数情况下很难学会有关的内容，我是否在暗示自己笨？但我认为和我智力相仿的人应该不少，例如《Thinking in Java》的作者Bruce Eckel也认为有这种情况，所以写书时还想到要特别体贴一下“笨人”。我看书的基本原则是：没有代码就不读。用英文表示也许更简洁：No codes，no reading。本文将据此原则展开讨论，如同上篇一样，这里仅代表个人观点。
不必认真阅读的TEXT
这个标题可能让读者感到有些吃惊，因为从小父母和老师就告诉我们要认真学习，当然也包括看书要认真。我们可能很调皮不愿学，甚至长大了也未必学习认真，但是都明白这个道理。
看书学习都有顺序，就是从前向后看，一般认为前面看不懂，后面也看不懂，比如不会加法，也就不会乘法。然而，本人的体会是电脑书可别这样看，我经常是看了后面才明白前面，甚至要看另一本书才明白这本书，这是我若干年前偶然发现的现象。依稀记得当时不知道看什么电脑书，前面的内容死活看不懂，那时就像老师的乖学生那样，停下来认真刻苦地钻研，仍然糊里糊涂，觉得自己真笨，白纸黑字都不明白，后来干脆破罐子破摔，好歹得把书凑合着看完吧，就挣扎着往后翻，结果发现，后面的竟然也能懂，并且前面莫名其妙的地方后来也莫名其妙地懂了。因为这种情况在以后的学习中屡屡出现，我就明白，笨人不是我，从此树立了“没有笨学生，只有笨先生”的坚定信念。
我的遭遇告诉我，书的很多部分都是不能认真看的，就编程书的TEXT-CODE-TEXT结构来说，CODE前的TEXT就属于此类。CODE后的TEXT通常是对代码的一些讲解和总结之类，明白了CODE，这部分TEXT也不难。
一般的编程书在讲解一个技术主题前，通常会首先以TEXT的方式讲解它，例如该主题运用的技术、结构、层次、协议、特点、好处等，你不可能完全看懂它，粗粗浏览一下即可。
例如，几乎每本Java基础书都会从总体上介绍Java本身，会涉及到一堆你可能闻所未闻的名词：跨平台、虚拟机、面向对象、多线程、安全性等。这些内容多半在前言或者第一章中出现，我从来不认真看这些内容，不知读者怎样处置？本人的书也有这些内容，不过不是第一章，而是最后一章。
《Thinking in Java》的第一章为Introduction to Objects，总体上介绍OO技术，基本没有代码。按照本人的原则，我是不会读的，至少不会很仔细，如果你坚持要读，作者Bruce Eckel还会劝阻你，下面是部分原文：
There are many concepts that are introduced here to give you a solid overview of OOP. However, many other people don't get the big picture concepts until they've seen some of the mechanics first; these people may become bogged down and lost without some code to get their hands on. If you're part of this latter group and are eager to get to the specifics of the language, feel free to jump past this chapter-skipping it at this point will not prevent you from writing programs or learning the language.
这段内容大意为：
本章要总体上介绍OOP中的许多概念。但是，很多人如果没有先看到一些代码的话，通常就会感到迷茫。如果你是这种人，那么就跳过本章，这不会影响你的学习。
我认为自己就是他说的那种人，同时作者不仅承认有这种人，而且还非常体贴我们，知道我们可能看不懂，特地写了上面一段。
在以前的一篇文章中，我曾经用苹果做了另外一个比喻：
如果你给一个从来没有见过苹果、也没有吃过苹果的人解释苹果，不要只告诉他苹果的概念和理论：“苹果是一种可食用的水果，形状为圆形，但是没有太阳那么圆，又不像桌子那样方；吃起来有的酸有的甜有的涩，但是一般三种味道都有……”；而要同时给他吃苹果。最好的方法是先让他吃，然后再告诉他苹果的理论：“你吃的就是苹果，苹果是一种可食用的水果……”。
我认为，编程书中的TEXT/CODE如同苹果理论/苹果实例一样，而我就是那种不让我吃苹果、我可能永远也不知道什么是苹果的那种人，你能知道吗？
上面举的例子中，TEXT部分没有代码支持。Java中，还有少数主题不好用例子演示，例如垃圾回收、虚拟机等，但是这样的内容很少。
某些TEXT后面有代码，这些TEXT通常也是不必认真学习的，起码不要指望没有例子的配合就能看懂。例如在讲解RMI时，首先会告诉你它的体系、结构、协议等，甚至会画出几张图来讲解，涉及到很多术语例如stub、skeleton等，也许在TEXT部分会包含一些代码片断，但是如果有完整的程序，我仍然建议你在粗粗地阅读这些TEXT后，更仔细地把完整的代码和TEXT进行对照，这样你就会既尝到了苹果的滋味，还学会了苹果的理论。
我手上有一本《Java服务器高级编程》，在RMI一段，像多数电脑书那样，首先是RMI的总体介绍，也有一张示意图，它在TEXT部分有完整的代码，属于“夹叙夹例”。我认为，这段内容应该是较容易学会的，如果能运行代码的话（我没有运行过）。
同样还是这本书，它有EJB一章，几乎全部是TEXT。其中虽然有代码，但是代码只是示意，有很多省略号，并且没有一个完整的、可运行的例子。我不会看这章的，即便我求知欲很强，非常渴望学会EJB。那怎样学会这种章节呢？这是下面要讨论的。
从TEXT中创建例子
上面说过了，某些书没有完整的例子，相信这种情况很常见，如果不常见，就不会有人抱怨电脑书难懂了，你认为能轻易地根据一堆苹果皮和苹果核，就知道什么是苹果吗？你可能会试图看懂它，也许看了几遍后，你真得以为懂了，除非你能编写一个可运行的例子。如同苹果的比喻那样，除非你能从琳琅满目的水果摊上，认出哪些是苹果，否则仍然是白学。
要根据TEXT自己编写一个例子，就必须非常仔细地阅读，也就是说，不能不认真了。本人当然遇到过这种情况，有时成功了，就非常有成就感，但是并不感激作者；有时失败了，也不灰心——反正不是我笨。
《Thinking in Java》的书很受欢迎，原因之一是其中的很多代码都是完整可运行的，并且很多的“理论/概念”都用代码进行了演示，所以作者认为该书在老外的书中还是比较好懂的，但只是“比较”好懂而已，因为还有不少TEXT没有完整的例子演示，让人不得不根据果皮果核建立起完整的苹果形象。
阅读代码例子
阅读完整代码并不比阅读TEXT部分轻松多少，我看懂代码的标准是要亲自编写一个例子，而不仅仅自以为看懂了别人的程序。我还是举苹果的例子，如果有人拿来一个苹果，但是自己吃了它，然后告诉我：这是苹果，味道酸酸甜甜的，我也不会认为我真得知道苹果是什么，除非我亲自吃一个。
在看书上的程序前，我一般会首先运行一下，确信没有错误，并且明白程序的功能是什么。有时候，程序的功能会在TEXT部分说明，说明可能详细，也可能不详细。下面是不详细的例子：本程序演示加法运算。
下面是详细的例子：
本程序从控制台输入两个参数，然后判断它们是否为数字，如果是就将其相加，最后输出两个参数和相加的结果。如果不是数字，那么输出一行提示信息。
详细的说明可能会帮助你阅读代码，遗憾的是，很多书没有详细地描述程序的具体运行机制，即便看到程序的运行结果可能也不明白要干什么，这时你仍然需要仔细阅读代码的细节。
在确信例子无误后，下一步是找到代码演示的主题在哪里，并且设法重写一个。我们知道，书上的例子可能很长，绵延多页，会包含不少非主题的知识，这些知识可能不需要认真理会。例如《Java服务器高级编程》的RMI部分，它把RMI有关的代码放在Servlet中，而Servlet还会涉及到一些HTML的代码，如果你不太明白Servlet或者HTML，只需要找到RMI的部分，然后重新编写一个只有RMI的独立运行程序即可。但有时非主题知识可能和主题有关联。例如Servle部分可能会传递一个参数给RMI部分，这时就要仔细阅读这些衔接点了。就这个例子来说，有些HTML代码是不重要的，例如设置字体、背景的HTML代码。实际上，本段的意思是要你放弃阅读非主题的代码，如果程序很长，你会觉得我的建议能让你快速学习。
糟糕的情况是例子正好用一个你没有学到的知识，来演示你正在学习的主题，你可能真的看不懂程序了。记得早先在刚开始学习Java的Exception时，书上的第一个程序用了和流相关的代码，说这段代码会产生Exception，尽管运行该程序确实如此，但是因为流是后面章节才讲到的内容，不清楚流的代码也就自然感到对Exception不太明白。在我自己写的书中，类似程序我用的是除零的代码，而除法代码是任何有一点程序设计经验的人都能看懂的。
有时书中程序会写得非常专业（也许可体现出作者的水平），例如《Thinking in Java》就是。这样的程序会考虑很周全，例如有较多的判断和循环语句等，但却造成代码不太好懂。对此，我的做法是，要么看懂它，要么在半懂不懂的情况下自己试着重写一个。我喜欢首选后一个方法，虽然花的时间多，不过值得。
平台上的Bug
Bug是常见的现象，例子中有，本书不讨论它，只要程序能运行，演示你需要学习的主题即可，不必设计的天衣无缝。只是平台上的Bug不好办，可能是API中的，也可能是开发工具中的，如果不幸碰到，即便书上的例子或者你自己编写的程序实际上完美无瑕，但是它不能正确运行，所以你仍然心里没底。下面举一个例子，也作为给读者的一道测试题。
Jar.exe的功能之一是打包，其中需要制作Manifest文件，这是文本文件，下面是两个文件内容的示意，你能看出它们的区别吗？（先别看答案）
这两个文件的内容看起来完全一样，但是请注意冒号，其中一个冒号后面是空格，而另外一个则没有空格。正是这一微不足道的差别，导致其中一个文件打包失败，即右边的文件是“错误”的。这非常不可思议，然而在JDK1.2.2上就是这样，有兴趣的读者不妨一试。
要解决这种问题，也许需要的就不只是知识或者经验了，你可能更加需要直觉、想象甚至运气，可惜这是任何教材包括本文都无法传授的“秘籍”。
如果怀疑是平台的问题，不妨换一个试试，好歹现在支持Java的平台不止一个。
总结
本文只是以个人的经历，介绍了一些自己看电脑书的体会，中心思想是No codes，No Reading，如果读者认为有道理，也可以把它作为选购Java书的一项原则。例如，如果发现一本书完整的例子太少，或者例子太长，这种书也许就不太好懂了。
看不懂电脑书可能还有这些原因：
深度超过了你现有的技术基础，就像小学生看大学课本一样；
TEXT部分表达不清，例如译著中拗口又蹩脚的译文；
CODE无法编译或者运行，比如漏掉一段代码；
……
对付这种书，本人只有一个字供大家参考：扔。
另外重要的一点是要有自信心，看不懂电脑书很正常，但千万别以为是自己笨，记住：只有笨先生，没有笨学生！
