Question

互联网软件的另一个技术优势在于，你能再现大部分的bug。用户的数据都在你的硬盘上。如果某个用户使用软件时出错了，你就不必像开发桌面软件那样苦苦猜测到底发生了什么事情。一般来说，只要用户通过电话向你描述一番，你就能把问题再现出来。如果你的程序中有自动侦测错误的代码，那么不用等到用户找上门，你可能已经知道哪里出错了。

互联网软件每时每刻都在被使用。你的代码一上线，就会经历严酷考验。bug很快就会浮出水面。

软件公司有时会受到指责，因为他们竟然把发现bug的任务交给用户去完成。说实话，我其实提倡这种做法。对于互联网软件，这样做的好处很多，因为它的bug相对比较少，而且处理周期比较短。我们连续不断地发布新版本，所以bug就比较少。我们能够再现用户遇到的问题，又能在修复后立刻发布，使得用户不用等很长时间，所以大部分bug的处理周期都比较短。我们的bug数量一直不多，以至于没有必要使用一个正式的bug追踪系统。

当然，在发布之前，你应该对修改之处进行测试，避免出现重大的bug。难免会有一些bug成为漏网之鱼，不过它们纯属罕见情况下才会发生的个案，在真正接到用户投诉之前，几乎不会影响到什么人。只要你能立刻解决bug，对于普通用户来说，他们就会觉得你的软件几乎是亳无问题的。我觉得，普通的Viaweb用户可能一个bug都没遇到过。

解决新代码的bug要比解决历史遗留代码的bug容易。在自己刚刚写好的代码中，找出bug往往会比较快。有时，你只要看到出错提示，就知道问题出在哪里，甚至都不用看源码，因为潜意识中你已经在担心那个地方可能会出错。如果你要解决的bug出自于6个月前写好的代码（假定你一年发布一个新版本，那么6个月就是发现bug的平均时间），那么就麻烦了，就要大费周章了。那时，你对代码也已经不熟悉了，就更可能采用危险的方式解决问题，甚至引入更多的bug^。

^「这个观点引申自特雷弗·布莱克韦尔（Trevor Blackwell）的话，他说：“随着软件规模的增大，开发成本指数式上升。这可能是因为修正旧bug的原因。如果bug都能被快速发现，成本的上升形态就能基本保持线性。”」

早一点发现bug就不容易形成复合式bug，也就是互相影响的两个bug。举例来说，一个bug是楼梯很滑，另一个bug是扶手松了，那么只有当这两个bug互相作用时，才会导致你从楼梯上摔下来。在软件中，复合式bug是最难发现的bug，往往也会导致最大的损失^。传统的方法是：“把软件彻底拆开，将所有bug统统清理干净。”这样做难免产生一大堆的复合式bug。如果软件是经常性发布，每次只有小幅度的变化，那么就不容易产生复合式bug。这就好比做扫除：你一直在打扫大厅，掉落在地板上的东西会被立刻清理，省得它们时间一长与其他东西粘在一起。

^「复合式bug有一个子类型：两个bug是互相弥补的，好比“负负得正”，软件反而能正常运行。这种bug可能才是最难发现的bug。当你修正了其中的一个bug，另一个bug才会暴露出来。这时对你来说，你会觉得刚才修正错了，因为那是你最后修改的地方，你就怀疑自己在那里做错了，但是你其实是对的。」

有一种编程方法叫做“函数式编程”（functional programming），它对你会有帮助，可以避免一些副作用。函数式编程在学术文献中研究得比较多，在商业软件中用得比较少。但是，对于互联网软件，它却很有用。很难用纯粹的“函数式编程”完成整个程序，但是它可以用来编写一些重要的部分，使得这些部分易于调试，因为它们不包含“状态”（state），非常便于不断进行小幅的修改和测试。我大量使用这种方法开发Viaweb的编辑器，我们自己的脚本语言RTML就是一种纯粹的函数式编程语目。

桌面软件行业的人可能很难相信，找出Viaweb的bug几乎成了一种游戏。因为软件发布以后，大多数bug都是罕见情况下才会发生的个案，受到影响的用户往往都是高级使用者，他们喜欢试验那些不常用的、难度大的操作。高级使用者对bug的容忍度比较高，尤其如果这些bug是在开发新功能的过程中引入的，而这些新功能又正是他们所需要的，他们就更能理解了。事实上，因为bug不多，你只有经过一些复杂的过程以后才会遇到它们，所以高级使用者往往因为发现了bug感到很得意。他们打电话给客服时，多半是一副胜利者的口吻，而不是怒气冲冲的样子，好像他们击败我们得分了一样。