开发人员生产力状态

        英文原文：The State of Developer Productivity

        评估开发人员的表现（performance）时，很难找到一个合适的、不依赖轶事证据（anecdotal evidence）的度量。所以当我们 Bowery 看到 Rebel Lab 开发人员生产力研究报告－下载链接时非常兴奋。这份 40 页的报告研究了开发人员在日常生活中使用的工具和实践。为了能够让报告抓住“表现”所蕴含的主旨，Rebel Labs 加权了不同实践和工具在软件质量和版本发布的可预测性上的效果。

        以下是研究报告中用于度量的一些实践：

• 对技术债务（Technical debt）的处理
• 监视和修正代码质量问题
• 自动化测试
• 结对编程
• 代码评审

        贯彻上述实践可以提高软件质量，但是需要付出的金钱和时间成本又如何？这时就要使用可预测性的度量。将这些实践与软件按时发布的可能性相比，我们可以妥当得出可靠度量，来审视提高质量花费的时间能否满足最终期限。

        处理技术债务

        技术债务是指为了其他任务而推迟的工作。大部分延后的工作都是不用马上处理的，但如果不好好处理这些任务，可能在将来引起更棘手的问题。

        结论：需要偶尔处理下技术债务。始终解决技术债务相比时不时解决下会有较小的提高，但并不显著。

        解决技术债务对可预测性和质量的影响：

        监视和修复代码质量问题

        结论：修复代码质量能够显著提高软件的质量和发布的可预测性，很可能因为这样的实践会让工程师们注意软件应用中潜在的结构性问题。

        修复代码质量问题对可预测性和质量的影响：

        自动化测试

        结论：100% 使用自动化测试要比部分测试覆盖率要好，但不使用自动化测试要比部分自动化测试要略微好些——很可能是这些工程师在人工测试他们的代码。

        自动化功能测试对可预测性和质量的影响：

        结对编程

        结论：结对编程（一人审核代码，另一人编写代码）对软件质量有显著影响。

        结对编程对质量和可预测性的影响：

        代码评审

        结论：从报告来看，评审代码对软件发布的可预测性有显著影响，但是对质量影响很小。这种实践可能会帮助开发人员发现设计和方向上的重大问题，但并不能暴露小问题，例如软件缺陷（bugs）。

        代码评审对质量和可预测性的影响：