三行代码 与 一天半

为什么软件开发是一项艰难的工作。看一下这个例子：

星期五，tester告诉我说一个月前改得bug依然存在。好的，让我来看一看。先看一看上一次我是怎么修理这个bug的。先赞一下我们的源代码管理系统。它可以把你当前机器上的代码和源代码对比生成一个pack. 这个pack可以用diff的工具打开。做了什么修改，看上去一目了然。在bug tracking系统里，我当时把fix的pack也记录下来了。整个change看上去只有一行代码。非常明了。看不出任何问题。

嗯， 可是在她的测试服务器上的确如此。看一看测试服务器上的log， 没有发现任何异常和有价值的信息。看来没有办法。好吧让我来debug一下。

这是一个软件升级过程中的bug。要debug这个问题，需要一台干净的服务器。安装好以前的版本，找到出问题的版本，安装出问题的版本。然后在安装的过程中，attach到调试器上。可是，我的开发环境也在进行另一个feature的开发。不可能进行这个测试。 幸运的是，我还有第二台开发机。虽然目前没有在上面开发，但是我还是一直保持同步。更幸运的是，已经有工程师开发了一个脚本。只要一运行。就会有一个虚拟机自动从网络上copy一个镜像，然后开始安装旧版本在用开发机上的build升级。看上去我所需要做的就是如此。小case.

我来到team的wiki上，找到了使用这个脚本的步骤。

开始执行

。。。

。。。

15分钟用来从网络上copy虚拟机的镜像。

25 分钟用来安装旧的版本。

15分钟将我本地的build copy到虚拟机的镜像中

一个小时以后，升级过程开始了。

啊偶， 一个错误跳出了。看上去和我的问题无关。又看了一下wiki。怀疑我的build没有全。（这种情况经常发生）。 好，再来一个full build.

。。。

 一个半小时过去了。问题依旧。又仔细的看了一下log和错误提示。 发了wiki上的内容没有即时更新。终于Fix了这个问题。再来，好的，debugger  attach 上去了。可是symbol找不到。在visual studio 上，选load symbol，选中之后。 Visual studio 就crash #$#@

把symbol拷贝到虚拟机， 万岁，Visual studio 不crash 了。 Symbol load起来了。设置断点。把虚拟机设到全屏。虚拟机蓝屏了#$#@

再来一次。终于可以debug了。五分钟后，发现了问题。加了两行代码。ok了。

这个过程，花了整整一天半。因为， 其中每重复一次，都要重新安装旧的版本否则升级无法进行。

看一看这个过程， 我们已经有相当好的软件工程了。为什么还会这样：

1.       1. 对于这种升级的代码一定要多写log。没有人在意升级的时间。一定要把每一步都log下来。这种问题一旦debug所花费的时间是巨大的。

2.       2. 工具的文档要更新。安装虚拟机的步骤没有即时更新。原先的人已经不在了。很久没有人使用了。