出错时的软件开发

出错时的软件开发(译)

出错时的软件开发

在开发的过程中有错误发生了，此时你该如何应对呢？John Ferguson Smart在他的最新博客中提出了一些想法，大家可以参考一下(2008.10.27最后更新)

    现今比以后任何时候，都需要开发者更加高效。极度高效。组织需要提高从它们的开发项目中得到的附加值，并且它们也乐于寻找实现这一目标的方法。
当然，你可以采用传统的方法--努力工作。为了消除项目中不可预见的症状，每天工作16个小时，还没有周末。但做的更聪明一点儿，会不会更好些？
在引进新的实践方法及改进现有方法方面投入的相对多一些，以使组织能努力获得更多回报，这就是开发的过程。一般而言，事物中有许多方面都可以被改进，但此处有一些小窍门能使你的开发流程更加合理，只是为你开个头罢了。

持续集成(CI)通知策略的再思考
    到目前为止，最通用的CI通知机制就是陈旧的邮件服务器。然而，你能肯定在你手边能完成这项任务的最合适系统就是电子邮件吗？尝试不使用电子邮件，而使用即时消息去完成你的CI通知。记住，电子邮件易成为一种干扰--如果你仅仅大约每两小时才查阅一次邮件，你就会变得十分高效。电子邮件只是，或至少是，用于构建失败--人们需要快速地知晓失败任务。

积极地优化构建过程
    构建度量(Build Metrics)是一种监控构建过程健康状况的极好方法。为什么过去3周中，代码覆盖率一直在下降？为什么单元测试的数量并未呈有规律的增长？为什么要花费很长的时间去修复这样的构建？运行单元测试需要多长时间--是否有一些测试需要执行过分长的时间？这些信息并非华而不实的东西--在不断改进构建过程的工作中，它们都扮演着关键的角色。现代CI工具，如Hudson，Bamboo和TeamCity，能为构建展示丰富的统计。Bamboo在这方面做的尤佳。无论你正使用何种CI工具，都要学习如何最大限度地使用它的报表特性，并使用这些特性去定位及修复开发过程中讨厌污点。如果你的CI工具不能给你所需要的全部信息，那就找一个能做到的。

合理化发布过程
    在发布过程中有许多必做的工作，如准备发行说明，确定该版本中哪些问题已被解决了，标记版本，等等。这些都是软件生命周期的重要部分，如果你忽略了它们，QA们和最终用户可能会很生气。但要尽量自动地去做这些工作。许多CI工具能很好地与问题追踪系统(如JIRA和Trac)进行集成，以便你能基于版本控制日志看到某个问题是在哪次特定的构建中被解决的。如果你在使用Eclipse，Mylyn能帮你将处理过的问题归总成逻辑变化组，并使用标准的模板列出在某项工作中已被解决的(或仅是影响到的)问题。或者你可使用Subversion的hook脚本去确保每次向Subversion做的提交都能对应到一个有效的问题编号。
    这只是一些想法罢了--还有更多。底线就是--你不需要忍耐一个次理想的开发过程--相反，要进入其中，并做些能改进它的事情。祝好运!