最近，有两位Google Maps API的初学者向我请教他们按照最简单例子写的程序为
什么不能正常的运行。其中一位用GTalk跟我交流，我仔细了看了他的代码，没看
出问题，把代码保存在本地，打开Firefox的错误控制台，用Firefox打开他的页
面。出错的那一行被清晰的显示出来，我再仔细端详那句话，原来有两个应该是英
文逗号的地方，写上了中文逗号。另一位，在我的论坛跟我交流他的Google Maps
API中遇到的问题，我看他代码的时候也没有马上发现问题。然而，同样在用
Firefox打开后，问题很明显的找到了，原来是一个方法openInfoWindow被他写成
OpenInfoWindow了。在我帮助别人解决的程序调试问题中，这是非常常见的。人人
都可能打出中文逗号，人人都可能把大小写写错。但是在我帮助他们解决问题以
后，他们总是感慨的说，谢谢我解决了这个问题，这个问题困扰了他们几个小
时，甚至是几天。这其实并不是只有初学者才会遇到的问题，我还帮助过些有非常
丰富经验的工程师解决问题，有时候问题仅仅出自某个参数没有传递进来，或者是
拼接字符串的时候少些了一个冒号，或者是拼接地址的时候漏掉了http:。我甚至
帮助一些人调试一些我根本不懂的语言的程序，因为多半出现的问题，都和语言特
性无关，不是程序员写错了字符，就是写错了逻辑，或者是错误理解了一个函数。
出问题是正常的，写程序是一个复杂的边思考边打字的过程，笔误和一时糊涂都是
难以避免的。程序员一般把这种问题叫做低级问题，因为这类问题跟你的智商完全
无关，任何人都可能犯。但是，问题在于，有时候即使是很优秀的程序员，也会被
一个低级错误困扰，可能会几天都解决不了。所以，关键在于，如何找到问题。遇
到问题的时候：
- 不要怨天怨地。出了问题，当然有可能是系统的bug，API的问题，但是那些几率
往往比你犯低级错误的几率要低多了，先从自己身上找原因，是不是自己写错了。
- 要掌握工具。最低限度你要会写Log，最好是Log和调试器结合。好 的工具可以
大大的提高效率。以前有人跟我说，Dll不能调试，我发现可以；有人说多线程不
能调试，我发现可以；有人说COM不能调试，我发现可以；有人说 IE插件不能调
试，我发现可以；有人说OE插件不能调试，我发现也可以。当然，你确实会遇到不
能调试的时候，当年我们做东芝芯片的嵌入程序，一个组都没有 一个仿真器和调
试器，但是至少可以用Log嘛，无非是麻烦点。
- 分析问题要有逻辑。遇到问题可以先把所有的可能性都列出来，然后一个一个分
析，肯定能找到原因的。
- 要学会隔离问题。问题涉及到的代码越多，越难以理解，问题越难以解决。遇到
这样的情况，可以利用Log或者调试器，一行代码一行代码的给它们洗清嫌疑，这
样很快你就可以找到出问题的地方。如果代码特别长，程序特别复杂，可以用二分
法来做，效率很高。
- 千万不要懒惰，不要事事求别人。一次复杂的调试过程就像一步侦探剧，如果你
有非常好的逻辑性，那这部剧的主角就是福尔摩斯，剧情一定非常精彩。我说这个
是有巨大风险的，说真的我帮人调东西挺上瘾的，很有意思。但是我还是要告诉大
家，一次高难度的调试之后，你的满足感绝对不亚于写了一个伟大的程序。要想不
遇到问题，写代码的时候：
- 要对写出来的代码负责。我很佩服那些写代码写100行都不执行一次的 高手，如
果他们最后不被低级错误困扰的话我就更加的佩服了。我写程序几乎是写一行两行
就要执行一次，每句话我都要确保执行效果跟我的预期一致。没错这样写的时候
可能慢一些，但是调试的时候很轻松，我可以很简单的确定哪些代码绝对没有问
题。所以我写代码整体速度比一般人高。很多人学习新东西的时候喜欢把例子抄一
遍，运行一下，改改，再运行。我喜欢一句一句的抄例子，抄一句两句执行一
次，这样可以把例子透彻的理解，而且很难会遇到出现了问题找不到原因的时候。
- 函数体功能块不要过长。我认为我的智商并不高，我很难接受一个程序的一个函
数体或者一个功能块超越3屏（当然逻辑真的有那么复杂除外，你会发现越是简单
的逻辑越是容易被人写的冗长）。很多人对面向对象耳熟能详，对封装继承看起来
驾轻就熟。但是动不动就写出来个函数体超长的程序。这就像写本书从头到尾不点
句号一样，会累死读者的。自己看的时候，估计也会被累的喘不过来气。这是我对
基础教育的微词所在，他们连教会学生写函数都没教会，虽然表面上他们连面向对
象这么高深的东西都教。
- 缩进要对。这点很重要，虽然大部分语言不是像Python那样用缩进来决定逻辑块
的位置，但是人看到缩进的时候，总是会以为这些缩进位置跟逻辑相关。尤其是在
有大量的ifelse或者for循环等等的嵌套逻辑的时候，如果缩进错了，可能会直接
让人把程序的逻辑读错。所以我拿到别人的代码，第一件事情就是整理缩进。我见
过一些比较优秀的页面工程师，他们会在div结束的位置用注释写上这个div的
id，这样层级关系就一目了然了。
- 不断重构。随着程序的不断修改，有些部分会不断的增长，原来看着清晰的架构
可能因为问题的复杂而慢慢模糊，也可能被修正bug的权宜之计弄的面目全非。不
信你找一个经过多次修改的程序看看，是不是满目疮痍，是不是都很难认出是你自
己的作品了。这在多人参与的项目中更加严重，每个人有不同的代码风格，经过多
次杂交后，你肯定认不出你的代码是骡子是马，还是四不像了。随着程序的慢慢成
长，原来有些函数体会慢慢膨胀，需要拆分；有些原来简单的功能块四处都需
要，应该被提炼成函数或者方法，等等。现在不重构，未来等到代码复杂到无法控
制的时候，重构的工作就会变得更加困难。我见过最强的案例是，一个几千行的电
子辞典配套联机软件，经过无数次的改版，变成了一个几乎无法维护的主窗体的
cpp有1万8千行的怪物。最后经过复杂的重构，才变成一个出新版本只需要新增一
个驱动程序的可以维护的几千行的程序。这个故事详见：一个具体项目的重构
（一） ，一个具体项目的重构（二），一个具体项目的重构（三）。

--
由 tiny 于 12/28/2007 01:40:00 上午 在 Tinyfool的开发日记(blog) 上发表