英文原文：The Joel Test: 12 Steps to Better Code

你听说过SEMA没？这是个用来衡量软件开发团队好坏的相当深奥的系统。噢，不，别点那个链接！仅弄明白这个东西，你就得花6年的时间。所以，我自己总结了一套方法，很不靠谱，但凑合可以衡量一个软件团队的质量，这个方法最牛的就是只要花三分钟，省下的时间都够你去医学院拿个学位神马的了。

乔尔测试

1. 你们使用版本控制系统吗？
2. 有一键部署吗？
3. 有每日构建吗？
4. 有Bug数据库吗？
5. 你们是否在写新代码前保证Bug都修复完了？
6. 有最新的开发计划吗？
7. 有需求文档吗？
8. 程序员们有安静的工作环境吗？
9. 你们使用能买到的最好的工具吗？
10. 有测试团队吗？
11. 应聘者在面试时写代码吗？
12. 你们进行目标用户随机可用性测试吗？

乔尔测试最简洁的是每个问题都可以快速地用是或否来回答。你不用去数每日代码行数或计算每拐点平均bug数，对于上述问题每个“是”的答案得1分即可得出评价结果。不过，请不要头脑发热使用乔尔测试来确保一个核电站的软件是否安全。

12分表示完美，11分还可以接受，但10分或更低就说明其中的问题很大了。而真相是大部分的软件机构跑分只有2分或3分，他们严重需要帮助，因为像微软这样的公司可一直都是12分。

当然，这并非决定成功或失败的唯一因素；具体来说，如果你有一个很棒的软件团队在做一个没人想用的产品，那么，还是会没人用的。同时也不难想象，一个糙快猛的团队虽然完全不管这些，仍然做出了令人惊叹的、改变世界的产品。但是，在其他条件等同的情况下，如果你能把这12件事做好，你会得到一个训练有素的团队，可以稳定地交付。

1. 你使用源码控制吗？
我用过收费的源代码管理包，我也用过免费的 CVS，让我告诉你吧，CVS不错。但如果你没有源码控制，你会疲于奔命于努力让程序员一起工作。程序员没办法知道其他人做了什么。错误不能容易地回滚。源码控制系统的其它好处是源代码本身被签出存放到每个程序员的硬盘上——我从来没有听说过使用源码控制的项目（因磁盘故障而）失去了很多代码。

其它翻译版本 (1) 加载中

2. 可以一键部署(build)吗?
我的意思是：从上一次部署的结果到一次新的可以发布的部署，中间要经过多少步？好的团队只需执行一个脚本，它会彻底 checkout，重新构建每一行代码，生成 EXE，包括各种各样的版本、语言和 #ifdef 组合，创建安装包，并且产生最终产品——CDROM 格式，官网下载，等等。

如果这个过程包含不止一步，就会更有可能出错。而且在比较靠近发布的时候，你会希望修改“最后一个”bug、创建最终版 EXE 的周期能尽量加快。如果要用20步来编译代码、运行安装程序构建器等等，你会疯掉，会犯一些低级错误。

正是这个原因，让我工作的上一家公司从 WISE 转到了 InstallShield：我们需要安装过程能从脚本运行，要自动，要能连晚运行，要能用 NT 计划任务，而 WISE 不能用计划任务来连夜运行，所以我们抛弃了它（WISE 的热心人士向我保证他们的最新版本可以支持连夜构建）。

3. 有每日构建吗?
用版本管理的情况下，有时候一个程序员会一不小心 check in 一些东西，导致构建被破坏（即无法再编译运行了）。例如，他添加了一个新的源代码文件，在他自己的机器上编译运行都没问题，但是他忘记提交这个新文件到仓库(repository)了。然后他关上机器，下班回家了，高高兴兴、一无所知。但其他人都无法工作了，所以他们也只能闷闷不乐地回家。

破坏构建如此糟糕（又如此常见），因此有必要做每日构建，来保证破坏能被及时发现。对于大型团队，要保证破坏能第一时间修复，一个好方法就是每天下午做一次构建，午饭时间就可以。每个人在午饭前都尽量多 check in。等他们吃完饭回来，构建已经完成了。如果构建成功，那就没问题了！每个人都 check out 最新版的源码，然后继续工作。如果构建失败，那就马上修复，但其他人还可以用之前构建的，没被破坏的版本工作。

在 Excel 团队我们有一条规则：谁破坏了构建，作为“惩罚”，就得负责看护构建，直到下一次被其他人破坏。这会很好地鼓励大家注意不要破坏构建，也是一个很好的方法让大家轮换经历构建过程，这样每个人都能学到它的机制。

更多了解每日构建，可以参考我这篇文章 每日构建益处良多。

4.你有制作bug数据库吗？

我不管你说什么。或许你正在开发代码，也或许你是开发团队中的一员，但如果你没有条理清晰地列出相关bug数据库，那么你的代码质量势必会降低。很多程序员认为他们能把已有bug记在脑中，这是很荒谬的，我不可能在同一时间记住2个或3个bug，而且在第二天早晨或是在忙碌的运作中，他们仍会被忘记。所以你必须做好bug跟踪记录。

bug数据库的制作可复杂可简单，一个小小的且有用的bug数据库必须包含以下几项与每一个bug相关的内容：

• 完整复制bug步骤

• 相关预测

• 相关观察

• 是谁造成

• 是否已调试

如果唯一能阻止你犯错的bug跟踪软件较复杂，那就现在开始尝试简单地记录下这重要的5项内容。

更多bug跟踪，可阅读Painless Bug Tracking

5.你是否在写新代码前修复了所有的Bug？

为Windows开发的Microsoft Word的最早期版本被认为是“死亡行军”项目。它确实是，而且一直在衰退。整个团队荒唐地工作着，项目曾多次延后，团队承受着巨大的压力。这件麻烦事最终过去，年底微软把整个团队送到Cancun度假，才静下来进行认真的反省。

他们意识到，由于项目经理坚持按照“时间表”行事，使得程序员匆忙地完成编码任务，写了相当烂的代码，因为Bug修复并不在正式的时间表里。程序员没有理由减少Bug数量，甚至相反，一个程序员不得不简单地写"return 12;"来计算文本行的高度，然后等待关于为什么他的函数有时出错的Bug报告到来。时间表纯粹变成一个等待转化为Bug的清单。在项目总结中，这被称为“无限缺陷方法论”。

为了修正这个问题，微软通常采取“零缺陷方法论”。公司里的许多程序员感觉好笑，因为它听起来像是管理者认为他们只要执行命令就能减少Bug。事实上，“零缺陷”意味着在任何时间里，最高优先级是在写新代码之前先去消除Bug。为什么要这样.

一般来说，在Bug被修正之前等待的时间越长，以后要修正时的代价越大（时间和金钱）。例如，当存在输入错误或者语法错误，编译器会捕获到错误，修正它基本上是微不足道的。

你首次运行程序时，发现代码中有一个Bug，，你将能够立刻修正它，因为所有的代码在你大脑中仍是清晰的。

如果在一些代码中发现一个Bug，而这些代码是几天前写的，那么它将花费你一段时间去找到它，当是当你重新阅读你写的代码时，你将回忆起任何事情并且在合理的时间内去修正Bug.

但是如果在你几个月之前写的代码中发现一个Bug，你可能关于这段代码已经忘记了，这种情况下它很难修正。有时你可能修正其他人的代码，而他们可能在阿鲁巴岛度假，在这种情况下，修正Bug就像科学实验：你不得不慢慢的，有条不紊，一丝不苟的进行，但你还不能确定需要多长时间去追查到Bug并修正。

如果你在已经发布的代码中发现一个Bug，你将会产生难以置信的费用去修正它。

立刻修正Bug的其中一个理由是：它需要的时间少；另一个和实际相关的理由是：相比修正存在的Bug，你更容易预测写新代码需要多长时间。例如，如果我让你预估需要多长时间写完代码，并给出相应时间列表， 你可能给我一个很好的估计。但是如果你我让你预估需要多长时间去修正一个导致代码不能执行的Bug，并且你还安装了IE5.5，你甚至猜测不到，因为你不知道什么原因引起的Bug，它可能需要3天追查到，或者只需要2分钟。

这意味着，如果你有一个剩余很多错误需要修复的时间表，这个时间表是不可靠的。但如果你已经修复了所有已知的错误，剩下的都是新的代码，那么你的时间表会令人震惊地更为准确。

保持错误计数为零的另一个伟大的好处是，你可以对竞争做出更快的反应。一些程序员把这认为是保持产品随时可以准备上线。如果你的对手介绍了一种可以拉走你客户的杀手锏级新功能，你可以只立即实现那个功能就可以上线，而无需修复大量积累的错误。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务