Joel测试：衡量代码好坏的12个准则

你是否听过SEMA？SEMA是一个晦涩难懂的衡量软件团队好坏的系统。等等，你千万别点这个链接，因为你会发现你理解不了SEMA系统里面的内容。
因此，我提出了自己的看法，粗略的，不是很精确的，衡量一个软件开发团队及其项目好坏的准则。这个准则的最大优点是简单易懂，且得到的结果真实。相比与SEMA你可以节省很多时间。

下面是12个测试题：
1、源代码是否有版本控制？
2、项目是否可以一键编译并构件？
3、是否有每日构件？
4、是否有bug库？
5、开发新功能前所有bug是否已经得到了修正？
6、开发计划是否一直保持更新？
7、所有功能是否有具体规格？
8、程序员是否有安静的工作环境？
9、是否买了最好的工具（即使花钱也不吝啬）？
10、是否有测试人员？
11、招聘新员工面试时候是否测试过编码能力？
12、“走廊可用性测试”？

测试题的简洁之处在于你只需要回答yes或no即可，而不需要去统计每天的代码量，代码的缺陷率等繁琐的指标。当然这个是粗略的，假如你开发一个核反应堆的控制程序，我想这些规则不适用。

我们给每个题目回答为yes为1分，no为0分。
得分12分是完美的，11分是可接受的，其他得分就表明你项目中有比较严重的问题了。
现状是很多软件开发团队的得分是2、3分，可想他们的问题有多严重。象微软这种公司，他们一直保持在12分。

当然，这12条准则不能算是圣经，并不能说不没有得到12分的团队就一定不能开发出好的产品。但是反过来看，一直保持准训这12条准则的团队，一定是一个可以持续战斗交付出好的软件产品的团队。

1、源代码是否有版本控制？
我曾经用过商业的版本控制软件，如IBM 的 Clearcase，也有开源的CVS，CVS是不错的选择。当然现在有很多更好的免费的版本控制软件，我也在使用：SVN，git等。
如果你项目中没有源代码的版本控制，团队中的程序员之间相互协作就没法开展，因为一个人不知道别人修改了一些什么。错误也不能很容易地回滚。版本控制还有一个好处就是所有的代码都check out到了每个程序员的硬盘上，我从未听说过哪个使用了版本控制的团队丢失过源代码。

2、项目是否可以一键编译并构件？
一键编译并构件的意思是需要花多少步骤多少时间，能从最新的源代码编译并发布出可用的产品？在好的团队里面，一个脚本可以完成代码check out、编译每一行代码、链接成可执行文件，即使项目中有不同语言开发的代码也是一样，同时还制作最后的发布包形势（如CD-ROM）。
如果需要很多脚本才可以完成上面的发布流程（假如执行20个脚本），那么在你临近项目发布的日子里，就会倍受煎熬，因为你总是会需要编译出最新的版本，来验证修正的bug。执行20个脚本是很容易出错的，这就意味着你在版本构件上需要花费很多时间。

3、是否有每日构件？
软件开发过程中，可能会有一些程序员check in的代码存在问题，导致编译构件失败。今天要出版本，但是他已经下班回家了，没有其他人能修改。（当然你可以打电话叫他过来公司修正这个问题，但是这会让他很不爽，当然你也可以不用考虑他的感受）。
因此在大型的项目中，都会采取每日构件的措施（有的更精细化的是每次check in代码都会触发编译构件），每日构件通常在下午，如中午午饭之前启动。吃完午饭后编译完成（项目的编译构件的时间不能超过30分钟，否则就有点不可接受），如果没有错误，那么大家基于新的代码继续开发，否则就找到问题责任人修正，大家基于之前的代码继续开发，不阻塞。
每日构件的文章可以参考 Daily Builds Are Your Friend

4、是否有bug库？
如果你在开发代码，即使是一个团队，如果没有bug库，开发出的代码也是低质量的。很多程序员认为自己可以记住所有的bug，但是只是自己认为，并不是每个人都可以。我只能记住2～3个bug，且很容易就忘记了。
bug库可以简单也可以复杂，但是必须包含下面的要素：
1）复现问题的详细步骤；
2）期望的结果；
3）实际的结果（有bug的结果）；
4）bug被分配给谁了；
5）是否已经修正了；
如果你因为复杂的bug跟踪软件而不想维护bug库，你做一个简单的包含上面5列的excel文件，即可做到bug库的效果。
关于更多的bug库维护，参考 Painless Bug Tracking

5、开发新功能前所有bug是否已经得到了修正？
微软Word第一个版本的开发项目，被认为是“死亡进行曲”，项目好像一直拖着永远不会结束。整个团队成员每天工作的小时数说出来都可笑（没日没夜），项目进度延迟，延迟再延迟，压力是难以想象的大。当项目结束大概一年后，微软将整个团队送到一个风景优美的地方度假，静下来讨论一些灵魂深处的问题（当然，我们社会主义只能吃吃瓜子在黑暗的会议室总结一下）。
讨论过程中他们意识到项目经理曾经是如此的坚持按照计划时间点进行，导致程序员只顾往前冲，增加新功能，然后就导致代码质量极差，因为修正bug的时间不在项目经理的计划中。他们没有机会将bug数量降下来，更甚的是，有的程序员为了实现计算文本高度，居然直接return 12，当然，bug就过来了。实现的功能越多代码越多，这个后来被称为“无尽缺陷方法”（在敏捷开发中这个也被称为 带病迭代）。
为了解决这个问题，微软后来提出了“零缺陷方法”，很多程序员听到这个后都开心的傻笑起来，因为这个好像是在说决策者已经要求管理者必须把bug消灭掉。实际上，“零缺陷方法”意思是在任何时间，解决bug都要比开发新功能的优先级高。
我们解释一下为什么。通常地，一个bug放置的时间越长，解决它的耗费（包括时间和金钱）越多。举个例子：

1、如果你代码中有一个编译错误，那么编译器很快可以给你找出来，你很快可以修正它。
2、如果你在第一次运行代码前发现了一个bug，那么很快就可以修复它，因为这时候你对代码还是很熟悉，不怎么耗费时间。
3、如果有一个bug在你几天前写的代码中，那么你需要花费一些时间来定位，你重读一遍代码，还是可以找出问题。
4、如果有一个bug在你几个月前写的代码中，那么你就不那么容易定位出来了。
5、再假设你定位别人代码中的问题，这个人可能去度假了，这种情况，定位bug就像推理：必须慢慢地，有条不紊地，仔细地去读代码去推断逻辑，并且你不能确定多长时间可以修正它。

立刻修正bug的第一个理由是节省时间。
第二个理由是估计新开发代码的时间比修正bug的时间要准确（简单说是可以是计划更准确）。这个意思是说，加入你有一个bug列表需要修正，要计划这些bug完成的时间，几乎是不可能的。假设所有的bug都已经修正了，只需要开发一个新功能列表，那计划就会精确很多。
“零缺陷方法”的另外一个好处是你可以比竞争对手响应更快，因为你随时可以发布版本。

6、开发计划是否一直保持更新？
如果你的代码对客户来说非常重要，客户有很多原因要求知道你写的代码什么时候可以交付，所以计划是重要的。程序员对计划的反感是众所周知的：我的代码在该完成的时候就会完成。他们总是这么对客户咆哮。

不幸的是，这并不能消灭计划。太多的商业计划需要月选计划好什么时候交付demo，什么时候展示，什么时候做宣传，等等。支撑商业计划的只有做开发计划，并时刻保持更新。
计划的另外一个好处是逼迫你哪些特性优先开发，哪些无价值的特性可以不交付或延迟交付。
做计划并不难，可以参考 Painless Software Schedules

7、所有功能是否有具体规格？
编写规格说明书就像用牙线清洁牙齿，每个人都知道需要这么做，但是就是没有人愿意做。我不知道根因，我猜是大部分程序员都讨厌写文档。结果就是，当团队成员全部是为了解决某些问题的程序员时，他们更愿意用代码表达他们的解决方法，而不是文档。
这设计阶段，如果你发现方案存在问题，则通过改几行文本就可以解决。当方案转化为了代码，修正问题的成本就急剧上升，无论从情感上还是时间上，程序员都不愿意把自己代码删除了重写的，因此他们会产生抵触情绪，就是不解决这个问题。

在Netscape就有上面说的问题，当他们的前4个版本很混乱问题很多的时候，愚蠢的管理者决策将现在的代码废弃而重新开发（想必这个大家都知道）。

我的解决这个问题的理论是：给程序员们上一堂“写作的精读课程”。
另外一个解决方法是聘请一个管理者，他自己能够写规格书。
两种方法都需要你在团队中明确：没有清楚规格不能写代码。

8、程序员是否有安静的工作环境？
给程序员一个有自己空间的，安静的，能保护隐私的工作环境，他们的产出能够大幅度的提高。这个对其他职业如作家科学家也同样适用。
经典的软件书籍“人件”中很详细地阐明了这一点。

9、是否买了最好的工具（即使花钱也不吝啬）？
使用编译语言（如Java，C）开发项目是唯一一个不能在自家花园完成开发的工作，如果编写的代码编译需要花费很多秒，那么买一台最新的，性能强劲的电脑会节省你很多时间。
如果编译时长超过15秒，那么程序员将会变的烦躁，然后去做其他事情（比如读其他文章），那么效率就会变得异常低下。
调试GUI代码，如果你只有一个显示器那会非常痛苦，多买一个显示器如果可以的话。

10、是否有测试人员？
如果项目中没有专职的测试人员（每3个程序员需要一个测试人员），那么你会交付出布满bug的产品，或者浪费程序员的时间去做测试。
可以参考Top Five (Wrong) Reasons You Don’t Have Testers

11、招聘新员工面试时候是否测试过编码能力？
招聘新员工到项目中来，一定要在面试时候让其写一段代码，就像你婚礼中请的厨师一样，一定要先品尝一下他做的菜如何。
只是理论上的测试有时候会遗漏很多知识面没有观察到，毕竟软件开发是一项工程，动手的活，不是纯理论的。

12、是否有做过“走廊可用性测试”？
“走廊可用性测试”，这个名称的意思是：将你的产品放在走廊中，遇到路过的人，喊其停住，邀请他来使用你的软件。这样测试过后，你就很快能够发现你代码中易用性的问题了。

原文链接 The Joel Test: 12 Steps to Better Code

本文链接：https://www.yunweipai.com/566.html