你听说过SEMA吗？这是一个相当深奥的系统，用于测试软件团队的能力。不，等等！不要贪图便宜，点击此链接！你需要大约六年的时间才能理解这些东西。所以我想出了我自己的，相比之下，它是评估软件团队质量的不负责任、草率的测试。这个测试最好的部分是它只需要你3分钟的时间。对于您节省的所有时间，您仍然可以上医学院。Joel测试（Joel测试）你使用源代码控制吗？你能一步构建吗？你每天构建吗？你有错误数据库吗？你在编写新代码之前修复错误吗？你有一个up-to-日期安排？你有规范吗？程序员有安静的工作环境吗？你使用金钱可以买到的最好的工具吗？你有测试人员吗？新候选人在面试时写代码吗？你做走廊可用性测试吗？乔尔测试好处是很容易快速得出每个问题的“是”或“否”。你不必去挖掘那些每天的编程行数和每个拐点的平均错误数。如果你的团队有一个“是”只有一点。关于乔尔测试的令人失望的事情是你真的不应该用它来保护你的核电站软件。得到12是完美的，11是可以容忍的，但10或更少2或3的分数表明你有严重的问题。事实上，大多数软件业务都是以2的分数运行的或3.他们确实需要帮助，因为像Microsoft这样的公司一直都是完美的，得分为12。性能正在发挥作用。当然，这些并不是决定成败的唯一因素：尤其是当你有一个很棒的软件团队正在开发一个没人想要的产品时，那么人们真的不会接受这个产品。同时，不这样做的“神枪手”仍然有可能生产出令人难以置信的改变世界的软件。但是，在其他条件相同的情况下，如果你把所有12件事都做对了，你就会拥有一支始终如一地完成工作的团队。你使用源代码管理吗？我用过商业源代码控制包，我用过CVS，它是免费的，让我告诉你，CVS工作得很好。但是，如果您没有适当的源代码管理，您将不得不尝试让程序员一起工作。程序员不知道其他人做了什么。犯下的错误不容易改正。源代码控制系统的另一个好处是源代码本身可以在每个程序员的硬盘上进行验证——我从未听说过使用源代码控制的项目会丢失大量代码。你能一步编译程序吗？通过这个测试我想明白：从一份最新源码的快速拷贝到一个可以输出的编译需要多少步？在最好的团队中，有一个脚本从头开始对代码进行全面检查，重新编译每一行代码，生成EXE文件，在它们的各种版本中，编程语言和#ifdef宏定义组合，创建安装包和最终媒体–CDROM布局、下载站点等。如果该过程需要多个步骤，则很容易出错。当您接近完成时，您希望有一个快速循环来修复“最后一个”错误，生成最终的EXE等。如果编译代码需要20个步骤，请运行安装编译器，.正式出于这个原因，我工作的最后一家公司从“智能”模型切换到“软件安装包”模型：我们要求它在安装过程中可以运行，使用NT调度程序从脚本中自动运行一整夜，“智能”模式无法做到这一点，因此我们放弃了该模式。你每天都编译代码吗？当您使用源代码管理时，有时程序员会不小心检查出停止编译的东西。例如，他们添加了一个源文件，一切都在他们的机器上编译得很好，但他们忘记将源文件添加到代码库中。于是他们锁上机器回家，更加健忘和快乐。可其他人干不下去了，也只好收拾东西回家，郁闷不已。中断编译是不好的（而且很常见），但它可以帮助程序员每天编译代码以确保编译不会在没有警告的情况下中断。在大型团队中，确保快速确定休息时间的一个好方法是每天下午编译代码，例如在午餐时间。每个人在午餐前尽可能多地进行代码审查。所以当他们吃完午饭回来的时候，汇编就完成了。如果有效，太好了！在继续之前，每个人都会检查最新的源代码。如果编译失败，你修复它，但每个人都可以继续使用预编译的、完整的源代码版本。在Excel项目组里，我们有一个规矩：谁打断了编译，作为对他的“惩罚”，他必须在别人打断编译之前暂时负责代码编译。这是一个很好的激励不间断编译的方式，也是让大家轮流参与编译工作，让大家了解编译工作的好方法。你有错误数据库吗？我不在乎你说什么。如果您正在开发代码，即使是在一个人的团队中，也没有一个有组织的数据库列出您代码中的所有已知错误，您将生成低质量的代码。许多程序员认为他们可以在头脑中保留很多萌芽。胡说些什么。根本就不能再同时记住两三个bug，第二天早上，或者写代码的高峰期，又记不住了。您绝对必须正式跟踪错误。但是数据库可以很复杂也可以很简单。最小错误数据库必须包含每个错误的以下数据：重复错误的完整步骤预期行为观察到的行为它的设计目的是否已修复错误是否被跟踪软件的复杂性是您不这样做的唯一原因想要跟踪您的错误，只需对这些关键区域使用上面的简单5元素表，并开始使用它。你在编写新代码之前修复错误吗？Windows版MicrosoftWord的第一个版本被认为是一个“死亡行军”项目。不知道这个项目什么时候完成，一直在推迟。整个项目组都在加班加点，项目一拖再拖，这时候的压力大到令人难以置信。几年后，当这个讨厌的东西终于发布时，微软派整个团队去坎昆度假，在那里他们可以坐下来认真地反省一下。他们意识到项目经理一直在坚持“时间表”来部署工作，而程序员只是匆匆忙忙地完成敲代码的过程，而且由于错误修复阶段不是官方时间表的一部分，这导致他们写出极其糟糕的代码。没有倒计时来尝试防止错误发生。恰恰相反，据说一个程序员写代码计算文本的行高，简单的写“return12;”。并开始等待他的功能始终正确的错误报告。时间表只是即将变成错误的功能清单。事后看来，此法后来被称为“无限破绽之法”。为了解决这个问题，微软一般采用一种叫做“零缺陷法”的方法。公司的很多程序员咯咯地笑了起来，因为这听起来像是一种管理理念，可以通过行政命令来减少错误的数量。事实上，“零缺陷”意味着在任何给定时间，最优先考虑的是消除错误，然后再编写新代码。让我来告诉你为什么。一般而言，您等待修复错误的时间越长，错误的成本（在实践和金钱上）就越高。例如，当您犯了编译器捕获的拼写或语法错误时，修复起来很简单。当你第一次看到你试图运行的代码中有一个错误时，你可以很快地解决它，因为所有的代码在你的脑海中仍然清晰可见。如果你几天前发现代码中的错误，你会花一些时间才能找到它，但是当你重新阅读之前编写的代码时，你会记住所有内容并且可以在合理的时间内修复错误。但是，如果您在几个月前的代码中发现了一个错误，您可能已经忘记了大部分关于该代码的内容，并且很难修复它。此时你可能正在修复别人代码中的错误，而他们可能正在阿鲁巴岛度假，在这种情况下修复错误就像科学：你必须放慢速度，有条不紊，一丝不苟地开始工作，而你还没有知道找到解决问题的方法需要多长时间。如果您在已售出的代码中发现错误，修复它的成本可能会高得难以置信。这是立即修复错误的原因之一：因为它花费的时间更少。这是关于在编写新代码之前等待多长时间，而不是在修复错误之前。例如，如果我让你预测编写一个对列表进行排序的代理需要多长时间，你可以给我一个很好的估计。但是，如果我让你预测在安装Explorer5.5后修复代码不起作用的错误需要多长时间，你无法猜测，因为你不知道是什么导致了错误。跟踪可能需要3天，或者只需3分钟就足够了。这意味着如果你有一个有很多错误需要修复的时间表，那么这个时间表是不可靠的。但是如果你修复了所有已知的错误，剩下的就是新代码，那么你的日程安排就会出人意料地更加精确。将错误减少到零的另一重要事情是您可以更快地响应竞争。一些程序员觉得这样可以让产品随时发布。如果您的竞争对手从您的客户那里引入了一项杀手级的新功能，您可以在发货前仅实施该功能，而无需修复大量累积的错误。你有更新的时间表吗？这个测试把我们带到了调度。如果您的代码对业务很重要，那么知道代码完成日期对业务很重要的原因有很多。在制定时间表时，程序员是出了名的固执。“该干就干了！”他们会对商人大喊大叫。不幸的是，这并没有让一切变得更好。公司在发布代码之前需要做出太多计划性的决定：软件演示、贸易展览、广告等。唯一的方法就是制定一个时间表并保持最新。制定时间表的另一个重要原因是，它会迫使你决定要处理哪些功能，然后迫使你挑选出最不重要的功能并削减它们，而不是陷入长期犹豫不决的泥潭。同时，遵循时间表并不一定是苛刻的。你有写代码的标准吗？编写规范就像牙线，每个人都认为这是一件好事，但没有人去做。我不知道为什么，但可能是因为大多数程序员讨厌编写文档。因此，当一个主要由程序员组成的团队遇到问题时，他们更有可能用代码而不是文档来表达他们的解决方案。他们宁愿把头埋在代码里，也不愿先写规范。在设计阶段，当您发现问题时，您可以通过编辑几行文本轻松修复它。一旦你开始写代码，修复问题的成本就会急剧增加，无论是情绪上的（人们讨厌扔掉代码）还是时间上的，所以这个时候修复问题会有阻力。不是根据规范构建的软件通常以设计不佳而告终，而且进度会失控。这似乎已经成为Netscape的一个大问题，Netscape的前四个版本慢慢变得一团糟，然后管理层愚蠢地决定丢弃旧代码并重新开始。然后他们在Mozilla上又犯了同样的错误，创造了一个失控的怪物，并浪费了数年时间回到起点。我的一贯主张是，这个问题可以通过让程序员参加强化写作课程，将他们变成或多或少的作家来解决。另一种解决方案是聘请一些聪明的程序经理，让他们编写代码规范。在这两种情况下，您都应该执行简单的规则“无代码，无代码”。程序员有安静的工作环境吗？广泛记载的是，通过为知识工作者提供空间、安静和隐私来提高生产力。经典的软件管理书籍《人件》大量记录了生产力从这些方面受益。问题来了。我们都知道，知识型员工在受到“启发”时工作得最好，我们称之为“进入状态”，在这种状态下，他们全神贯注于工作，完全脱离周围环境。通过绝对专注，他们忘记了时间并产生了伟大的代码。这是他们完成工作的过程。作家、程序员、科学家，甚至篮球运动员都会告诉你要进入最佳状态。问题是，进入心情并不那么容易。当您尝试考虑时，开始工作似乎需要15分钟的最大工作效率。有时，如果您累了或者那天做了很多创造性的工作，您就是进不去，剩下的时间您都在四处闲逛、浏览网页或玩俄罗斯方块。另一个问题是很容易摆脱那种状态。噪音、电话、出去吃午饭、不得不开车5分钟去星巴克喝咖啡，以及被同事打扰——尤其是被同事打扰——会让你脱离那种状态。如果一个同事问你一个问题，打断你一分钟，但是这会很惨地把你打昏，你需要半个小时才能恢复工作效率，你的整体工作效率会受到很大影响。如果你处在一个嘈杂的牛棚式环境中，咖啡因网络公司喜欢创造这种环境，营销人员在程序员旁边的电话里尖叫，你的生产力会随着知识工作者一遍又一遍地下降我被打断了一次，我不能一直进入状态。对于程序员来说，这就更难了。生产力取决于能够同时处理短期记忆中的许多小细节。任何形式的中断都会导致这些细节崩溃。当你回去工作时，你不记得任何细节（比如你刚才使用的局部变量的名称，或者你刚刚想出的实现搜索算法的好主意），你必须保持考虑这些事情，这会让你变慢，直到你再次变得有效率。这有一个简单的代数运算。可以争论（证据表明）如果我们打断程序员，即使是一分钟，我们实际上会损失15分钟的工作效率。在此示例中，我们假设有两个程序员Jeff和Mutt在一个标准的相邻开放式隔间中。Mutt不记得Unicode版本的strcpy函数的名称。他可以查找，这需要30秒，也可以问Jeff，这需要15秒。由于他坐在杰夫旁边，他选择直接问杰夫。Jeff分心并损失了15分钟的工作效率（只为Mutt节省了15秒）。现在我们把他们两个分到两个办公室，隔着门和墙。此时，如果Mutt忘记了函数名，他可以在30秒内查找，或者在45秒内问Jeff，这需要站起来（考虑到程序员的平均身体素质，这不是一件容易的事！）。所以他会选择自己去查。Mutt损失了30秒的生产力，但为Jeff节省了15分钟。哈哈哈哈！你是钱能买到的最好的工具吗？在公园里用家里的电脑立即用编译语言编写代码仍然是你最后能做的事情之一。如果您的编译过程花费的时间超过几秒钟，请使用最新最好的计算机来节省您的时间。当编译器运行时，程序员会感到无聊。这是他们将转向阅读其他内容的时候。这会吸引他们的注意力并损失数小时的工作效率。使用单个监视器调试GUI代码很痛苦，但并非不可能。如果您正在编写GUI代码，那么两个监视器会使很多事情变得更容易。大多数程序员最终都会处理图标或工具栏的位图，而且他们中的大多数人都没有像样的位图编辑器。尝试使用MicrosoftPaint来操作位图是一个笑话，但大多数程序员都是这么做的。在我上一份工作中，系统管理员不断向我发送自动垃圾邮件，抱怨我在服务器上使用了超过220兆字节的硬盘存储空间。我指出，考虑到如今硬盘的价格，所有硬盘空间的成本甚至比我使用的卫生纸的成本要低得多。即使花我10分钟来清理我的邮件目录也是对我生产力的可笑浪费。顶级开发团队不会折磨他们的程序员。即使是不完美的工具造成的小挫折，加起来也会让程序员变得脾气暴躁和不开心。脾气暴躁的程序员不会有生产力。程序员是最容易被最酷、最新的东西贿赂的人。让他们为你工作比支付有竞争力的薪水更便宜。你们有测试人员吗？如果你的团队没有专门的测试人员，你至少应该有一个测试人员供两三个程序员使用，你会写出一个有很多错误的产品，或者你花很多钱请一个测试人员来做它30一个小时工作交给一个每小时100的程序员去做。在测试人员身上省钱是一种极其虚假的经济，我只是想让更多的人意识到这一点。求职者面试会写代码吗？你会雇用一个没有见过他的魔术的魔术师吗？当然不是。你会为你的婚礼聘请一个没有尝试过他的食物的餐饮服务商吗？我对此表示怀疑。然而，在日常工作中，程序员是根据令人印象深刻的简历被聘用的，或者是因为面试官喜欢与他们聊天。或者他们被问到详细的问题（“CreateDialog()和DialogBox()之间有什么区别？”），这些问题可以通过查看文档来回答。你不关心他们是否记得关于编程的成千上万的细节，你只关心他们是否真的能写代码。或者，更糟的是，他们只会问“嗯？”questions:那种知道答案看起来容易，不知道答案就什么都答不出来的问题。请不要再这样做了。面试的时候想问什么就问什么，但是一定要让招聘的程序员写一些代码。你做走廊可用性测试吗？走廊可用性测试是当你在走廊里遇到路人并强迫他尝试使用你刚刚编写的代码时。如果你和五个人一起做这个，你会在你的代码中找到你需要学习的95%的实际问题的答案。好的用户界面设计并没有你想象的那么难，想要用户喜欢并购买你的产品，它是必不可少的。但关于用户界面最重要的是，如果你向很多人展示你的程序（实际上五六个就够了），你会发现人们最大的问题。即使您的UI设计技能不是很好，如果您强迫自己进行走廊可用性测试，它的成本很低，而且您的UI会越来越好。
