http://blog.gkong.com/more.asp?name=linkman&id=27854
我不知道，自己现在还算不算一个程序员。如果还算程序员的话，我肯定不是那种绝顶聪明的程序员。

我不是一个聪明的程序员，不能在键盘上手指翻飞，灵光似剑，一日千行，闭目成章。大师的高度，远非我能指望，我会犯很多错误，只是一个普通的程序员。

所以，对于编程，我是一个悲观主义者。

我不相信，所编写的程序能够一次编译通过；也不相信，能在家里将程序的所有错误都找出，而不需要出差现场；更不相信，我的程序能够在不同的环境下，对各种异常，都处理得非常完美；尤不相信，我的程序没有任何内存丢失，可以连续运行一周。

我本来不是一个悲观主义者，曾经的我，是那么激扬那么狂妄，只是一次次被打击，让我越来越务实，越来越冷静，越来越清醒地看待自己。随着岁月的增长，我编程的次数已越来越少，但是，我的悲观主义思想却越来越浓。

一打开程序，我便想到，因为软件出错，而不得不给用户写检讨；便想到，因为每月死机一次，客户对我大发雷霆；便想到，因为产品质量问题，而陪客户喝酒，连饮七大瓶啤酒。

那七瓶要命的啤酒，依然不能让客户回心转意，于是，我成了一个悲观程序员。

我是悲观主义程序员，好在还有五件武器。

第一件武器：断言（ASSERT）；

我希望，任何调用我的模块的程序，都能按照希望的参数格式和调用方法，正确地调用我的模块。因此，在我所编写的每一个模块内，都会大量地使用断言（ASSERT），在模块中加上了断言，我便相信，程序模块有了一个一个相对真实的调用环意，便有了一种虚幻的安全感。

第二件武器：静态代码检测工具，如PC-lint，有时也使用编译器的最严格的编译级别；

我从不认为，自己是一个对C/C++/VC等，都非常熟悉的程序员，经常会不小心使用一些不正常的语法，或是不太考虑字段的边界，因此，在程序编到一定的阶段，都会采用pc-lint，对我所编写的程序，进行严格的编译检查。

第三件武器：动态代码检测工具，如boundcheck；

对于C/C++程序员而言，最大的痛苦就是内存泄漏，或其它资源泄漏了，我对内存泄漏有天生的恐惧，也经常在内存丢失方面犯错误，因此，在产品发布给用户前，一定会采用动态代码检测工具，进行一次彻底的测试。

第四件武器：单元测试工具，如cppunit；

我没有足够的自信，认为自己能够很好地驾驭多个模块的大型程序，也不相信自己写过的、超过50行的程序会没有问题，因此，我会尽量引入单元测试，对每一个重要的函数或模块进行地毯式单元测试，当看到那一遍测试通过的绿色，才能够安心地回家睡觉。

第五件武器：调试信息；

我相信，我所编写的所有程序，都不可能一次成功，即便再认真地调试检查，再多地厂内工作，在现场还是免不了会出问题。因为，不可能在家里模拟现场所有的情况，也不能够对各种异常情况进行完整地猜测。因此，在我所编写的很多程序中，特别是与监控有关的、需要长期、连续运行的程序，都会加上尽可能多的调试信息。

在程序中加上调试信息，是我最后的稻草，有了它，我终于敢将产品战战兢兢地交给客户。

那么，调试信息应该记录哪些内容？我想说的是，调试信息应该能够记录现场所有的信息，包括：

程序的启停状态；
调用它人程序的边界参数；
被它人调用的程序的边界参数；
与外部环境的边界，包括操作系统、文件系统、硬件、数据库等；
与网络交互的两端边界；
重要模块的被调用参数；
模块内的重要过程的当前参数；

有了这些调试信息，我便可以不出差了，当现场发生了事情时，我的第一反应便是要求查看这些调试信息。

今天一位朋友问我，你如何保证你的程序能够稳定，我告诉他：我有五件武器。

宝刀配英雄，现在我已很少编写程序了，这些武器，就送给战斗在第一线的程序员吧，也许你们现在不觉得它们有多重要，但总有一天，你们会自觉地将它们带在身边的。