每年二月末到三月初，公司都会安排一批实习生到各个部门实习。虽说去年经济危机了，但公司的实习生数量似乎并没有减少。起码我们部门"新同事"的数量基本与去年持平。按惯例，每位新同事都会有一名导师，与此同时各个部门还会根据自身的业务特点对这批学生进行有针对性的集中培训和交流。比起我入司那会儿，现在的实习生已经算是幸福多了。我那会儿实习生人数少，部门没有安排什么培训，完全靠导师安排自己努力学习。此次培训的内容是经过老员工们讨论和对新员工的需求调查后才确定的。其中新同事们普遍对如何进行程序调试这块比较感兴趣，我负责准备和实施了这个题目。虽说有过几年调试程序的经验，但是自已也没有系统的总结过，这次培训后顺便在这里做一下总结和记录。

说到程序员，各位大脑中第一反应就是编码；但我们知道软件开发可不仅仅只有编码，调试也占据了程序员很大一部分精力。程序员"简单"的工作中，80%的时间都是在编码和调试(现在文档工作也不少)。调试的对象是BUG，BUG是什么呢？BUG就是编码过程的伴生品。既然将之诠释为"伴生品"，那就意味着"凡是软件，内必有BUG"。也许有人不同意这样的观点，但无关大碍，因为如何看待BUG本身就可以看成是一个哲学范畴的话题，大可见仁见智。

调试前，首先做好心理准备。
调试BUG的过程可以用"艰苦卓绝"来形容；特别是一些"又臭又硬"的BUG，难于重现，难于定位，甚至在投入相当大的精力后仍然无法Fix。所以调试BUG前就要摆正心态，要保持清醒、保持耐心，甚至要做好打"持久战"的打算。要知道Unix下还有一些BUG也是在隐藏了几十年后才被Fixed。

预防BUG的发生，降低BUG发生概率。
我们还需要清醒的认识到：事实证明与编码相比，调试BUG的成本是更高的。BUG可简单分为产品Release前BUG和Release后的BUG。无论哪一种，你都要经历收集数据、重现BUG、定位问题、修正问题和Accepted等多个步骤后才能重新Release。这其中以Release后的BUG花费的成本为更高。既然如此，我们何不采用一些手段来相对的预防BUG的发生，降低BUG发生的概率呢！这里说说我想到的。从一个软件的整个生命周期来看，保证软件质量应从需求开始，但这里我们主要关注编码阶段。从个体开发者角度我们可以从以下三个方面考虑：

* 充分的静态代码检查
充分利用你手头上的工具对你编写的代码做严格的检查，这些工具包括编译器(尽可能将警告级别提升到你可以接受的最高级别)、LINT工具等。这将帮你将代码中潜在的细小问题发掘出来，避免这些问题在事后成为隐藏的大BUG。

* 调试版添加断言
充分利用断言Assertions这把发现BUG的利器，借鉴契约式编程的一些规则，在你的调试版代码中适当的地方添加Assertions。这样的方法同样可以帮助你及时发现代码中隐藏的缺陷。

* 充分的单元测试
充分的单元测试提高代码覆盖率，减少业务逻辑遗失导致的BUG；单元测试用例还可以结合断言发现更多程序潜在问题。如果能做到测试先行，也许效果会更好。

* 代码同级评审
让其他人来审核你的代码，提前帮你发现潜在的问题；如果能做到结对编程，也许效果会更好。
 
从组织的角度来看，持续集成的实践可以让组员更加及时的发现编码阶段的问题，不让问题遗漏到后面阶段成为严重BUG。

如果很好的实施了上述这些手段后，你的BUG发生率会大大降低，但是前面说过：BUG不能避免，一旦BUG发生了，该怎么办？其实与BUG做艰苦卓绝的斗争，也是有一定方法的。

* 收集"现场数据"
BUG是表象，我们要发现内部原因还是需要更多的表象数据去推理。我们需要收集到足够的"现场数据"。比较初级的、基本的、也是被大家常用的方法就加print语句，将BUG现场周围的"证据"输出到屏幕上或者文件中，这样你能更直观的看到；当然我这里是不推荐Print语句的，因为不够专业、不够高效；拿起你的源代码调试工具，诸如GDB来完成这一功能吧；有时候现场数据可以通过你的程序运行日志而直接得到这样就更简单了，调试阶段这种日志要保持尽量详细且必要；如果是运行在客户现场的程序，你无法添加Print，也无法GDB调试，那么你需要在测试环境下重现BUG表象，然后再利用工具收集数据。重现BUG表象多数情况较容易，但是也不乏找不到重现条件的时候；这时候你就只能根据已有的运行日志等通过"顺藤摸瓜"的业务逻辑分析去"猜测"可能的重现步骤，逐一尝试，做好尝试记录，隔一段时间对记录进行分析，找出一些"蛛丝马迹"，也许会帮助你节省些时间。

* 定位问题所在
有了"现场数据"，需要你用"火眼金睛"从这一堆数据中找出你真正需要的；如果无法直接识别出真数据，那么可以根据数据做几组不同数据组合的模拟测试，在数据变化中"去伪存真"，找到那个"真悟空"。有了信赖的真实数据，你一般都可以根据代码逻辑推理出问题所在。但有些时候还是需要通过隔离代码、缩小嫌疑代码范围等方法才能锁定一些较难BUG的具体问题所在。

* Fix and Test
既然找到问题所在了，那剩下的工作就是修正它并重现验证；新用例同时也补充了你的单元测试用例库。如果修正失败，那就从头开始新一轮分析过程吧。

BUG真的是种类繁多，情况多样。 上面也仅仅是一些常见BUG解决过程的体会。如果你已经在一个BUG上整整消耗了一天时间了，那么建议你休息一会儿，小憩一会儿，甚至是睡一觉到天亮。也许梦中你会发现问题所在。要知道大脑潜意识是会帮助我们的，估计很多人都有过类似经历，不是吗？

定期回顾你自己"出产"的BUG列表，你会发现很多BUG是你在预防阶段做的不够好而导致的，特别是一些涉及内存操作的BUG，如果前期预防工作没有做好的话，那么后期解决BUG花费的精力会很多；定期回顾还有一个好处就是强化你的思维意识，让你以后尽量不再犯同一个错误。

使用何种工具做Feature或Defect或Task的跟踪一直是挺让我闹心的一件事。用Excel记录，但却不便于共享、统计和直观展示；Jira算是做的好的工具之一了，但无奈它是商业软件，咱没付那份儿钱，所以也就"无福享用"；Mingle是著名的Thoughtworks公司的产品，虽说不到5个license是可以免费使用的，但它却是出了名的"内存杀手"，无奈我的机器配置太差，运行起来实在太慢，遂没有坚持下去(我"眼冒金星"的渴望着更换一台无所不能的超级计算机^_^)；甚至我曾经用过ONENOTE来做跟踪，可是条目多了后，就基本不可用了。寻觅依旧进行中，这不Trac这款软件进入了我的视线中。

网络让我知道了"Trac"。"Trac"这个名字，估计与Track"异曲同工"。至于Trac具体能做什么，你可以到其Demo站点去体验一下。简单的说，Trac = wiki + 问题处理工作流；Wiki可以用来做知识积累和管理；问题处理工作流恰是我需要的功能。但到底Trac做到啥子程度，那还需要用起来后才能知道。还有一件让我觉得很"幸福"的事，那就是Trac自带一个独立的web server程序Tracd，并且Trac可使用Python 2.5.x自带的SQLite，这样我可以不用安装和配置庞大的Apache和MySQL了。让用户能快速上手应该是Trac值得其他开源软件学习和参考的一个亮点，要知道一些庞大的开源软件繁复的安装和配置过程让很多使用者产生了"挫败感"而"另辟蹊径"了。

Trac是用Python开发的，可以跨平台使用。这里我以Windows上的Trac为例。Trac官方站上有详尽的文档可以指导你的安装、配置和使用。这里用中文做简单介绍吧，留下一个记录，也便于自己以后参考。安装不是最重要的，但是没有了安装却是万万不能的。

1、安装Python, 设置环境变量
对于Trac而言，其解释执行环境Python是必不可少的，虽然Python发布了最新版是3.0.x，但是在已存的Python代码中，Python 2.x版本还是占据绝大多数，过渡到Python 3.0还需要时间。我这里用的是Python 2.5版本。安装完Python后，别忘了将{Python_INSTALL_DIR}和{Python_INSTALL_DIR}/Scripts加入到你系统的环境变量(path变量)中去(一般Python_INSTALL_DIR为"C:\Python25")。

2、使用Windows installers安装Trac
比起手动安装(Manual Install)，在Windows上使用Installer安装Trac更为简便。依次下载和安装：SetupTools、Genshi和Trac 0.11。注意要下载对应Python 2.5版本的安装文件。如果你要用Trac与Subversion接口的话，建议你下载一份svn-python程序，使用其他svn客户端程序似乎不好用。另外Trac只支持连接本地svn repository，不支持远程svn repository。以上安装程序会把相应可执行程序或脚本放到Python相关目录下，所以不需重新设置环境变量。

3、初始化一个工程
完成以上两步，你就可以使用Trac了。Trac运行和管理的基本环境单位是一个工程(Project)。首先你要确定你的工程所在的目录，这里以D:\TracProjects\Foo为例，我们建立一个名为"Foo"的Trac工程。打开一个命令行窗口，执行：
trac-admin.exe D:\TracProjects\Foo initenv
这是个交互执行的过程，你需要填写一些工程的基本信息，比如工程名字、数据库连接字符串等，你大可一路默认下来就可以得到一个默认的工程环境。

4、启动Trac
一切就绪。我们现在就可以启动Trac了。到目前为止，一切都是那么简单，这也充分证明Trac入门简单。在命令行下执行如下命令启动Trac Web server：
tracd.exe -p 8000 D:\TracProjects\Foo
现在你打开浏览器，访问Url: http://localhost:8000，Trac的界面就会展现在你面前。界面上你只能看到"Available Projects"的列表，由于我们只是建立了一个Project，所以你只能看到Foo这一个超链接。点击Foo，进入Foo的工程页面。

5、为Trac Project添加用户
Ticket是Trac Project管理和操作的基本元素，但是在通过上面方式以匿名登录方式打开的页面上你只能"View Tickets"，而无法"New Ticket"；要想拥有"New ticket"的权限，你需要以一个Trac用户的身份登录。初始情况下，Trac没有建立任何用户。Trac创建用户是通过建立"Password file"的方式来完成的。Trac默认的密码文件格式与Apache的相同，都是.htdigest格式的。如果你的系统内没有安装Apache，你可以用Trac wiki上提供的trac-digest.py脚本来生成密码文件。你可以将trac-digest.py文件放到{Python_INSTALL_DIR}/Scripts下面。

# trac-digest.py
from optparse import OptionParser
# The md5 module is deprecated in Python 2.5
try:
    from hashlib import md5
except ImportError:
    from md5 import md5
realm = 'trac'

# build the options
usage = "usage: %prog [options]"
parser = OptionParser(usage=usage)
parser.add_option("-u", "–username",action="store", dest="username", type = "string",
                  help="the username for whom to generate a password")
parser.add_option("-p", "–password",action="store", dest="password", type = "string",
                  help="the password to use")
parser.add_option("-r", "–realm",action="store", dest="realm", type = "string",
                  help="the realm in which to create the digest")
(options, args) = parser.parse_args()

# check options
if (options.username is None) or (options.password is None):
   parser.error("You must supply both the username and password")
if (options.realm is not None):
   realm = options.realm
  
# Generate the string to enter into the htdigest file
kd = lambda x: md5(':'.join(x)).hexdigest()
print ':'.join((options.username, realm, kd([options.username, realm, options.password])))

我们使用如下命令生成密码文件：
python trac-digest.py -u "foo" -p "foo123" >> d:\tracprojects\foo\conf\users.htdigest，
这里我们建立一个用户：用户名为foo，密码为foo123。

我们再次来启动Trac，这次由于带有了用户鉴权，启动命令行与前面略有不同。
tracd –port 8000 –auth=Foo,d:\tracprojects\foo\conf\users.htdigest,trac d:\trarojects\foo
启动后，我们点击login，Trac会提示我们输入用户名和密码，输入foo/foo123后，你就可以看到界面显示：logged in as foo，并且"New Ticket"菜单出现在页面上方。

6、Trac.ini
conf目录下的Trac.ini是针对Foo这个Trac Project的主配置文件。里面各个字段的含义说明在Trac官网都有说明。通过修改Trac.ini你可以很简单的在页面上添加你喜欢的Project Logo。

7、Ticket
Ticket是Trac的核心，默认情况下，Trac为Ticket设定了诸多属性，并且设定了围绕Ticket的默认工作流。对于Ticket的每个属性字段，我们都可以通过trad-admin工具对字段取值进行增删改，以适合你的需要。诸如：trac-admin d:\TracProjects\foo  component add Webms foo，这句的含义就是添加一个属于foo工程的名为"Webms"的组件值。Ticket没有类似"Deadline"的时间属性，我们可以用milestone和priority来约束解决Ticket的时间范围。在"View tickets"页面中，Trac内置了多种"Report"，你同样也可以自定义搜索，但是目前用户尚不能在"View Tickets"中保存自定义搜索为固定的"Report"，但是你可以将自定义搜索语句放到一个WIKI页面的链接选项中，这样你就可以方便的直接得到搜索结果了，无需每次都配置搜索条件。

8、WIKI
Trac内置WIKI引擎，你可以通过trac-admin d:\TracProjects\foo wiki list来查看当前Project的所有WIKI page名称。你也可以通过trac-admin d:\TracProjects\foo wiki import WIKI_PAGE_NAME new_WIKI_page.txt为Foo Project导入一个名为"WIKI_PAGE_NAME"新WIKI页，该页内容来自文件new_WIKI_page.txt。和所有其他Wiki一样，你可以任意定制你的Project中的任意Wiki页面。

从上面的8个步骤来看，Trac简单而且实用，我已经根据我自己的需要对Trac Project进行了初步定制，并导入了我要追踪的需求、任务和问题，更多的高级功能还需要一段时间去发掘，今天的发掘到此为止了。