异常驱动的开发(Exception-Driven Development)

你的网站或应用程序存在哪些问题?如果你在等着用户来告诉你,那么你只能看到所有的问题中已经暴露的那极小的一部分。要知道,那只是“冰山一角”!

异常驱动的开发(Exception-Driven Development)_第1张图片

而且,如果你真的是在守株待兔,我不得不很抱歉地告诉你,你有点失职——你应该比用户更了解你的程序的健康状况。每当有用户告诉我一个他们在使用我的软件的过程中碰到的“善意的错误”时,我总会感到局促不安。甚至有些惭愧。我没有在用户把问题告诉我之前发现它们,并且事先解决它们,这就是我的失职。我忽视了对程序崩溃应付的责任。

任何负责任的软件项目,首先要做的事是建立一种异常和错误报告机制。Ned Batchelder把这比作为“先给自己戴好氧气罩,然后再帮小朋友戴”:

异常驱动的开发(Exception-Driven Development)_第2张图片

当你的程序出现问题时,请你总是先去检查这个错误是否被适当处理了。如果没有被适当处理,那么先去解决错误处理代码里的问题。保持这个工作顺序很重要,原因有如下几方面:

  1. 在根源错误还在的情况下,你实际上为错误处理代码中的bug准备了一个完美的测试用例。但如果你先把根源问题解决了,你又将怎样来测试你的错误处理代码呢?记住,你的代码里之所以有bug,部分原因就是它在当初的开发阶段很难被测到。
  2. 一旦根源问题被解决了,解决错误处理代码里的问题的紧迫性便随之消失。你可能会说,“我以后会去解决的,现在急啥?”就好比你家屋顶漏了——下雨的时候,你没办法去修屋顶,因为外面正下着雨呢;但雨停了之后,家里又不漏水了(不急着去修屋顶了)!

你需要集中在一个地方去处理所有的错误。这个地方是你团队里的所有开发人员非常熟悉的,并且每天都会接触到。在Stack Overflow,我们采用了ELMAH(https://code.google.com/p/elmah)的一个自定义分支。

异常驱动的开发(Exception-Driven Development)_第3张图片

我们每天都在监视着这些异常日志;有时候每个小时都察看。这些异常日志实际上已经成为了我们团队的To-Do列表(待办事项)。我们这么做是有充分理由的。比如,微软收集类似的这种错误日志已经几年了,他们不仅收集自家软件的日志,还收集第三方软件的;他们的这个机制叫Windows Error Reporting(简称WER)。成效喜人啊:

当最终用户遇到程序崩溃时,他们会看到一个对话框,问他们是否想发送错误报告。如果他们选择发送,WER会收集应用程序以及发生崩溃的模块的信息,然后把这些信息通过一个安全服务器发送给微软。

于是,软件厂商可以访问到关于他们产品的数据,再加以分析,定位到问题的根源。他们可以通过错误对话框与用户交互,还可以通过Windows Update升级他们的程序。

在对错误报告数据的广泛分析之后,我们看到:80%的客服问题在修复了用户报得最多的20%bug之后就能得到解决。即使只修复用户报得最多的1%bug,也能解决50%的客服问题。这个分析结果通常对于各家公司都是成立的。

尽管我仍然推崇“测试驱动开发”(Test-Driven Development,缩写为TDD),但时间投入的投机性一直是我纠结的一个问题。如果你修复了一个真实用户永远也碰不到的bug,那你的修复有什么价值呢?我知道还有很多其他的理由促使我们去实践TDD,但若单纯作为一种修复bug的机制,在我看来,选用TDD就大可不必了;就像我们过早地进行代码优化一样,是不可取的。我更愿意把时间花在解决真实发生的问题上,而不是那些理论上存在的bug。

当然,你可以两者都做。但考虑到开发时间总是有限的,我更倾向于立足于实实在在的数据,把时间花在解决真实用户在使用我的软件过程中碰到的问题上。这就是我所谓的“异常驱动的开发”(Exception-Driven Development)——将你的软件发布出去,让尽可能多的用户使用它,然后一心一意地研究他们产生的错误日志。使用那些异常日志去找出问题的根源,并且专注在你的代码中有问题的区域。重新架构,重构代码,以消除最严重的3个问题。快速迭代,部署,如此周而复始。这种数据驱动的反馈机制是非常有效的,几个迭代下来,你的程序将非常稳定,坚如磐石。

异常日志可能是用户能够提供给你的最强有力形式的反馈。这种反馈基于已经发布的软件,为了得到它们,你不必去询问用户或者诱导他们,也不必理会他们关于问题的不可思议、似是而非的描述。真正的问题伴随着转储出来的堆栈跟踪信息,已经悄悄地为你自动收集好了。异常日志才是用户反馈中的根本

异常驱动的开发(Exception-Driven Development)_第4张图片

(译者注:2009年4月16日,DareObasanjo与Scott Koon ‏@lazycoder在Twitter上有过一次辩论;Dare Obasanjo的观点是:通过将产品发布出去,然后从客户那里得到真实的反馈,这比任何事先的沟通或调研更有价值。)

我是在提倡发布带有bug的代码吗?或者半成品?或者狗屎软件?当然不是!我的意思是说,你越快将你的软件推到真实用户的面前,你就会得到越多的数据以改进你的软件。异常日志在这个过程中扮演着很重要的角色,同样地,用户使用数据也很重要。当然,如果你受得了的话,你还应该跟用户交谈。

不管怎么样,软件在发布的时候总是会带有bug的。所有软件都是这样。只要是软件,它就会崩溃,它就可能丢失数据,它还会难以学习、难以使用。问题不在于你在发布软件的时候带出去了多少bug,而在于你能多快地修复那些bug?如果你的团队一直在践行异常驱动的开发模式,答案就很简单了——别担心,我们马上就会改进我们的软件!看着吧,我们会越做越好!

听起来多美妙啊!就像一首美妙的乐曲,在每个用户的耳边萦绕……


你可能感兴趣的:(异常驱动的开发(Exception-Driven Development))