【翻译】乔尔测试：改进代码的12步

翻译文章：《乔尔测试：改进代码的12步》，欢迎提意见。

原作者：Joel Spolsky

原文链接：原文链接

JOEL谈软件

我叫 Joel Spolsky, 是纽约市的一名软件开发者。更多信息>>

2000-8-9, BY JOEL SPOLSKY

乔尔测试：改进代码的12步

Top 10, 开发界的摇滚明星, 新闻

你听说过 SEMA 吗？这是一个相当深奥的评估系统，它用于评估软件团队的优良程度。

不！等一下！！千万不要点击那个链接！你大概要花六个月时间才能搞明白那到底是个啥东西。

因此，我自己又提出了一个评估软件团队质量的测试方案，是我自己提出来的、高度不负责任、草率的测试。关键是它只需要你花 3 分钟，（相比而言）省出来的时间够你去学个医！

目录

“乔尔测试”有一个优点是它能很容易对每个问题给出“yes” or ”no” 的答复。你不必计算每日代码行数或拐点平均错误数。每回答一个“yes”, 给你的小组记一分。乔尔测试也有缺点，那就是你不应该用它来确保你的核电站软件是安全的。

对于测试的结果，12 分很完美，11 分倒也还可以，但是 10 分或者更低的话，那问题就严重了。事实上，大多数软件组织的得分是 2~3 分，他们需要认真的帮助，因为像微软这样的公司每时每刻都是以 12 分的状态在运行。

当然，这并不是决定成败的唯一因素：尤其是当你拥有一个优秀的软件开发团队，但开发的却是一个没人想要的产品，那么，大家也不会买你的账。我们可以想想一个“枪手”团队，他们不做任何这些事情，但仍然设法生产出改变世界的令人难以置信的软件。但是，在其他条件相同的情况下，如果你做到了这 12 件事情，你将拥有一个始终如一地交付任务的纪律性强的团队。

1. 使用源码控制了吗？[YES]

我用过商业的源代码控制包，也用过 CVS ，它是免费的，并且也CVS很好。但是，如果你没有源代码控制，让程序员一起协同工作，你感到非常有压力。程序员不知道别人做了什么，发生错误也不能轻易地进行回滚。关于源代码控制系统的另一件整洁的事情是，源代码本身是在每个程序员的硬盘上核实的（checked out?）——我从没听说过一个使用源代码控制的项目会丢失大量的代码。

2. 能一步就搞出来吗？[YES]

我是说：从最新的源快照创建一个发行版的构建（shipping build），需要多少步？在优秀的团队往往只需要运行一个简答的脚本，就可以从头开始执行完整的签出（checkout）、重新构建每一行代码、生成 EXEs、制作所有版本和语言和#ifdef 的组合、并创建最终媒体——CDROM布局、下载网站，等等。

如果这个过程超过一个步骤，就很容易出错。当你接近发行时，你会希望有一个修复“最后一个”Bug、生成最终的EXEs等的快速周期。如果编译代码、运行安装构建器等需要 20 个步骤，那么你会发疯的，而且会犯愚蠢的错误。

正是这个原因，我工作的上一家公司从 WISE 转到了InstallShield: 我们要求按照过程能够通过脚本，使用NT 调度程序在一夜之间自动运行，而WISE 不能在调度程序中在应用之间运行，所以我们抛弃了后者。（WISE 的热心人士向我保证，他们的最新版本确实支持夜间构建。）

3. 是否每天都进行构建？[YES]

当你使用源代码控制时，有时一个程序员会不小心签入一些破坏构建的东西。比如，他们新增了一个源文件，在他们的机器上编译一切都没问题，但是他们却忘了把这个源文件添加到代码仓库里。于是，他们锁上机器，高高兴兴地回家了。但是这导致其他人都不能工作，所以这些人也不得不回家，闷闷不乐地。

破坏构建是很糟糕的（而且也是很常见的），它有助于进行日常构建，以确保没有不被注意到的破坏因素。在大型团队中，确保立即修复漏洞的一种好方法是在每天下午(比如午餐时间)进行每日构建。每个人都尽可能多地在午餐前签入（Checkin）。当他们吃完饭回来时，构建就已经完成了。如果成功了，很好！每个人都检查了最新版本的源代码，并继续工作。如果构建识别，你可以修复它，但是每个人都可以继续使用预构建、完整的源代码版本。

在优秀的团队中，我们有一个规则，即任何破坏了构建的人，作为他们的“惩罚”，都要负责照看构建，直到有人破坏它。这不是破坏构建的一个很好的动机也是让每个人在构建过程中轮换的一个很好的方法，这样每个人都可以了解构建过程是如何工作的。

阅读的那个多关于日常构建，见我的文章： Daily Builds are Your Friend.

4. 建立了”Bug”数据库吗？[YES]

我不在乎你说什么。当你在开发代码时，即使是在一个团队中，如果没有一个列出代码中所有已知Bug 的有组织的数据库，你也交付不了高质量的代码。很多程序员认为他们可以把错误列表记在脑子里。这真是无稽之谈啊！我能一次记下的Bug 不超过两三个，在第二天早上，或者在匆忙的发布过程中，我就忘记他们了。所以啊，你必须正式地跟踪Bug。

Bug 数据库可以是复杂的，也可以是简单的。一个最小的可用的Bug 数据库中的每个Bug 必须包含以下的数据：

• 重现Bug 的完整步骤
• 期待的结果
• 观察到的Bug 行为
• 被分配给了谁
• Bug 是否已经被修复

如果缺陷跟踪软件的复杂性是阻碍你跟踪Bug 的唯一原因，那么只需要根据这些关键字制作一个简单的 5 列 表格，然后开始记录和构建 Bug 数据库。

1.重现Bug 的完整步骤	2.预期执行的结果	3.Bug发生的结果	4.交给谁解决	5.Bug 是否已修复

有关Bug 跟踪的更多信息，请阅读： Painless Bug Tracking.

5. 写代码之前，你们会先修复Bug吗？[YES]

微软Word 的第一个版本被认为是一个“死亡行军”项目。你们花了那么多时间，它却一直很拉胯。团队都在加班加点地工作，项目一次又一次地推迟，压力非常大。当这该死的东西终于发布的时候，已经晚了好几年，微软把整个团队排到Cancun 去度假，然后坐下来进行一些严肃的自我反省。

他们意识到，项目经理一直坚持遵循“时间表”，以至于程序员只是匆匆地完成了编码过程，编写的代码都非常的糟糕，因为Bug 修复阶段并不是时间表里的正式工作。没有人试图减少Bug 的数量。恰恰相反。有一个程序员必须编写代码来计算一行文本的高度，他只写了 return 12;然后等待错误报告，告诉他的函数并不总是正确的。

这样，日程表仅仅是一个等着Bug 出现的功能清单，在事后分析中，这被称为“无缺陷方法论”。公司了许多的程序员都笑了，因为这听起来像是管理层认为他们可以通过发号施令来减少 Bug 的数量。实际上，“零缺陷”恰恰意味着在任何给定的时间内，最高的优先级是在编写任何新代码之前消除错误。这个例子就是最好的说明。

通常**，修复Bug 之前耽误的时间越长，修复Bug 的成本（时间和金钱）就越高。**

比如，当你犯了一个由编译器捕获的拼写错误或引发错误时，修复它基本上是微不足道的。

当你在第一次尝试运行代码时，发现一个错误时，你可以立即修复它，因为所有的代码在你脑海中还是很新鲜的。

如果你在几天前写的代码中发现了一个错误，你需要花些时间才能找到他，但是当你重新阅读代码时，你会记住所有的东西，你就能在合理的时间内修复Bug 。

但是，如果你在几个月之前写的代码中发现了一个Bug, 那么你可能已就忘记了有关改代码的许多内容，而且修复起来要困难得多。到那时，你可能正在修复别人的代码，我让他们可能在 Aruba 度假，在这种情况下，修复Bug 就像是科学研究：你必须慢慢地、有条理的、一丝不苟地，而且你也不知道需要花费多少时间才能找到解决的办法。

如果你在已发布的代码汇总发现了一个错误，你会招致难以置信的费用去修复它。

这是需要立即修复Bug 的一个原因：因为这样花的时间是最少的。还有另一个原因，比起修复现有Bug ，预测编写新代码需要多长时间更简单。比如，如果我要求你预测编写一个对列表进行排序的代码需要多长时间，你可以给出一个很好的估计。但是，如果我问你安装了 Explorer 5.5 ，修复Bug 需要多长时间？你甚至无法猜测。问题溯源可能需要三天，也可能是两分钟的事情。

这意味着，如果你的计划中有很多漏洞有待修复，那么这个计划表就是不可靠的。但是，如果你已经修复了所有已知的Bug，剩下的就是新代码，那么你的时间表将会更加准确。

保持 0 Bug 状态的另一个好处是，你可以更快地响应竞争。一些程序员认为这是随时准备发布产品。然后，如果你的竞争对手推出了一个杀手级的新功能，正在窃取你的客户，你可以实现这个功能，并在现场发布，而不必费心修复大量累积的Bug.

6. 有保持更新的时间表吗？[YES]

这就引出了我的时间表。如果你的代码对业务来说很重要，那么有很多理由说明为什么知道代码何时能完成对业务来说很重要。程序员在制定时间表方面是出了名的暴躁。“It will be done when it’s done!” 他们对着业务员大喊大叫。

不幸的是，这并不能解决问题。在交付代码之前，企业需要做出太多的计划决策：演示、交易展示、广告等等。要做到这一点，唯一的办法就是制定一个时间表，并且保持随时更新。

制定时间表的另一个关键因素是，他会迫使你决定要做什么功能，然后迫使你挑选最不重要的功能并删除它，而不是陷入功能蔓延 / featuritis（又名“范围蔓延”）。

遵守时间表并不难。请阅读我的文章“无痛软件计划“ Painless Software Schedules，他描述了一种简单的制定多功能计划的方法。

7. 有说明书/规范吗？[YES]

写说明书就像用牙线洁牙一样：每个人都认为这是件好事，但没人这么做。

我不确定这是为什么，但看是因为大多数程序员讨厌写文档。因此，当团队完全由程序员组成时，他们更喜欢用代码而不是文档来表达他们的解决方案。他们更愿意一头扎进去写代码，而不是先写一个规范。

在设计阶段，当你发现问题时，可能有通过编辑几行代码轻松地修复它们。一旦编写好代码，修复问题的成本会非常高，无论是从感情上（人们讨厌扔掉写好的代码），还是时间上来说都是如此，所以实际上修复问题是有阻力的。没有根据规范构建的软件通常设计得很糟糕，进度也会失控。这似乎是网景（Netscape）公司的问题所在，最初的四个版本变得一团糟，以至于管理层愚蠢地决定推倒重来。然后他们在 Mozilla 身上又犯了同样的错误， 创造了一个失控的怪物，花了几年时间才进入 alpha 阶段。

我最喜欢的理论是，这个问题可以通过让程序员参加密集的写作课程 an intensive course in writing.，让他们不那么情愿地成为作家。另一种解决方案是雇佣聪明的程序经理来编写规范，无论哪种情况，你都该执行简单的规则“没有规范，就没有代码”。

通过我的四部分系列 4-part series 文章，了解有关编写规范的所有内容。

8. 程序员有安静的工作环境吗？[YES]

通过给知识员工提供空间、安静和隐私，生产力得到了大量的提高。经典的软件管理书籍 Peopleware 广泛地记录了这些生产力方面的好处。

但是麻烦来了。我们都知道，知识型员工通过进入“心流”状态工作得最好，也被称为“进入状态了”，**在这里，他们完全专注于自己的工作，完全脱离他们的环境。**他们忘记了时间，通过绝对的专注创造出伟大的作品。这是他们完成所有有成效的工作的时候。作家、程序员、科学结，甚至篮球运动员都会告诉你这个状态。

问题就是，进入“状态”并不容易。当你试着测量它时，看起来平均15 分钟才能开始以最高效率工作。有时候，如果你累了，或者你那天已经完成了很多创造性工作，你就是无法进入那个状态，转而会把剩下的工作时间用来消磨，比如看看网页，玩玩俄罗斯方块（Tetris）之类的 。

另一个问题就是，你很容易被干扰出这个”状态“。电话、噪音、出去吃午餐、补短板开五分钟车去喝星巴克，以及同事们的干扰——所有这些都会让你分心。如果一个同事问了你一个问题，打断了你一分钟的工作花时间，但这却让你失去了正常的工作状态，你要花半个小时才能重新开始工作，那么你的整体工作效率就遇上大麻烦了。如果你处在一个办公环境嘈杂的充满咖啡因的网络公司，营销人员在程序员旁边对着电话尖叫，这时知识型工作者一次又一次地被打断，你的生产率将会下降，此后你再也别想进入好的状态了。

对于程序员来说，这尤其困难。生产力依赖于能够一次性处理大量短期记忆中的小细节。任何形式的干扰都可能导致这些细节崩溃。当你回复工作，你不记得任何的细节（比如你使用的局部变量的名字，或者你在实现一个搜索算法的哪一步了），你必须继续寻找这些东西，拖慢你很多进度，直到你恢复原有的速度。

这是简单的代数运算。假设（正如证据表明的那样）如果我们打断一个程序员，即便只有一分钟，我们真的会损失15 分钟的生产力。在这个例子中，让我们把两个程序员 Jeff 和 Mutt，放在一个标准的 Dilbert 小牛肉育肥农场的开放隔间里。Mutt 不记得strcpy 函数的Unicode 版本名称。他可以花30 分钟查一下，也可以直接去问 Jeff。因为Jeff 就在旁边，他去问了Jeff。Jeff 分心了，失去了15 分钟的工作效率（为Mutt 节省了15 秒的时间）。

现在让我们吧他们搬到有墙有门的独立办公室。现在，当Mutt 想不起那个函数的时候，他可以查一下，这仍然需要30 秒，或者他可以问 Jeff，但是现在这种情况需要45 秒，并且还要起身（考虑到程序员的评价身体素质，这可不是个简答的任务！），所以他自己去查了。现在Mutt 失去了30 秒的工作时间，但是我们却为Jeff 节省了15 分钟。神奇吧！

9. 你用的是用钱能买到的最好的工具吗？[YES]

用编译语言编写代码是最后一件还不能在不同家庭电脑上立即完成的事情之一。如果你的编译时间超过几秒钟了，那请您去换个最新和最好的计算机吧，这能节省不少时间，如果编译只需要15 秒，程序员在编译器运行时就会感到无聊，转为阅读 The Onion，这将会吸引他们，并消磨数小时的生产力。

用单个显示屏调试GUI 代码？即便有可能实现，那也很痛苦。如果你正在编写GUI 代码，两个显示屏将会使会把事情变得容易很多。

大多数程序员最不得不为图标或工具栏操作bitmaps，而大多数程序员没有一个好的bitmaps 编辑器可用。用微软绘图板操作bitmaps 很可笑，但这是大多数程序员必须做的。

在我的上一份工作中 my last job，系统管理员不停地自动给我发送垃圾邮件，抱怨我用了服务器上超过220M 的硬盘空间… 我指出，考虑到现在硬盘驱动器的价格，这个空间的成本友谊第一我使用卫生纸的成本。即使花上十分钟去清理我的目录也会极大地浪费我的生产力。

顶尖的开发团队不会折磨他们的程序员。即使是由使用功能不足的工具引起的小挫折也会让程序员脾气暴躁和不开心。并且一个暴脾气的程序员是效率低下的。

除此之外，程序员也很好讨好，只要能给他们最酷最新的东西。这是让他们为你工作的一个比实际的支付诱人薪水更加便宜的方法！

10. 你们有测试员吗？[YES]

至少每两到三个程序员就应该有一个测试员。如果你的团队没有专门的测试员，你要么就是准备发布错误百出的产品，要么就准备让每小时 100 美元的程序员做每小时 30 美元测试员可以完成的工作，这可完全就是在浪费钱。在测试人员身上节省开支是一种可耻的错误的做法。我很惊讶，很多人居然没有意识到这一点。

阅读我写的一篇关于这个主题的文章：你没有测试员的五大（错误）理由 Top Five (Wrong) Reasons You Don’t Have Testers。

11. 应聘者需要在面试过程中编写代码吗？[YES]

你会股雇佣一个没给你表演过魔术的魔术师吗？当然不会。

你不先偿一下婚宴承办商的食物就直接股用他们吗？当然也不会。（除非是 Marge 姑妈，如果你不让她做她那“著名的”切肝蛋糕，她永远都会恨你的）。

然而每一天，程序员被雇佣都是基于令人印象深刻的简历，或者因为面试官喜欢和他们聊天。或者他们会问到一些琐碎的问题（如，CreateDialog()和 DialogBox() 之间有什么区别？），这些问题通过查看文档就能回答。你不关心他们是否记住了成千上万的编程细节，你关心的是他们能不能写出代码。更糟的是，他们会被问到“啊哈！”问题：当你不知道答案是，这里问题看起来很容易，但如果你不知道答案，就很难回答出来了。

恳求亲不要再这么做了。在面试过程中，你可以做任何你想做的事情，但是要让候选人写一些代码。更多的建议，请阅读我的：游击战指南。Guerrilla Guide to Interviewing.

12. 你做过“走廊“可用性测试吗？[YES]

走廊可用性测试是指你抓住下一个经过走廊的人，强迫他们尝试使用你刚刚编写的代码。如果你对五个人这样做了，你会学到代码中 95% 的可用性问题。

好的用户界面设计并不像你想的那么难，如果你想让客户喜欢并购买你的产品，这是至关重要的。你可以在网上阅读我关于UI 设计的免费书籍 free online book on UI design。这是一本程序员入门书。

但是关于用户界面最重要的事情是，如果你向少数人展示你的程序（事实上，五六个就够了），你将会很快发现人民遇到的最突出的问题。阅读 Jakob Nielsen 的文章可以理解原因。及时你缺乏UI 设计技能，只要你强迫自己做走廊可用性测试（无需任何成本），你的UI 也能做得更好。

订阅！

你正在阅读 ”Joel 谈软件“ Joel on Software，里面摆满了多年来关于软件开发、管理软件团队、设计用户界面、运行成功的软件公司以及橡胶鸭子的疯狂十足的文章。

如果你想知道我上面时候发布新东西，我建议你买一个想 NewsBlur 这样的RSS 阅读器，并订阅我的 RSS feed。

关于作者

2000年，我与人合伙出版量Fog Creek 软件公司，在哪里我们创造了很多很酷的东西，比如FogBugz Bug 追踪器，Trello, 和 Glitch. 我也和 JeffAtwood 一起创建了 StackOverflow，并作为2010-2019年Stack Overflow 的CEO。现在，我担任着 Stack Overflow, Clitch 和 HASH 的董事会主席。