12条自问让你更好地编程

《12条自问让你更好地编程》由会员分享，可在线阅读，更多相关《12条自问让你更好地编程（8页珍藏版）》请在金锄头文库上搜索。

1、12 条自问让你更好地编程条自问让你更好地编程你听说过 SEMA 么？ 它是一个用来测试一个软件团队有多好的相当深奥的系统。不， 等等！不要手贱点开这个链接！它会花费你大概六年的时间来了解这个东西。所以我提出 了我自己 的、跟它相比极不负责任的、草率的评价一个软件团队的质量的测试。这个测试 最棒的方面是它只会花费你 3 分钟的时间。你节省下来的所有时间，还可以去上个学院。Joel 测试The Joel TestDo you use source controlCan you make a build in one stepDo you make daily buildsDo you have

2、a bug databaseDo you fix bugs before writing new codeDo you have an up-to-date scheduleDo you have a specDo programmers have quiet working conditionsDo you use the best tools money can buyDo you have testersDo new candidates write code during their interviewDo you do hallway usability testingJoel 测试

3、的好处是很容易快速得出针对每一个问题的“是”或“不是” 。你不必去翻出那些 每日编程行数和每个拐点的平均 bug 数。如果你的团队有一个“是”就得一分。关于 Joel 测试令人失望的是，你真的不应该用它来确保你的核电站软件的安全。获得 12 分是完美的，11 分也还可以容忍，但 10 分或更低的分数表明你有严重的问题。事实上，大多数软件企业都以 2 分或 3 分的分数在运转着，他们真的很需要帮助，因为像微 软这样的公司一直以来都以 12 分的完美表现在运转。当 然，这些都不是决定成败的唯一因素：特别是当你有一个正在开发没人要的产品的伟大 的软件团队的时候，那么，人们是真的不会接受这个产品的。同

4、时一个没有这 么做的“神 枪手”仍然能产生出令人难以置信的改变世界的软件也是可能存在的。但是，在其他条件 相同的情况下，如果你把这 12 件事情都做好了，你就会拥有一 个能始终如一完成任务的 团队。你使用源代码管理么？我 用过商业源代码管理包，也用过 CVS，它是免费的，让我来告诉你，CVS 很好用。但如 果你没有对源代码进行管理，你就要应激尝试把程序员都弄到一块来工 作。程序员根本不 会知道别人都做了什么。犯过的错误不能轻易改过来。关于源代码管理系统的另一个好处 就是源代码本身可以在每个程序员的硬盘上进行验证 我还从没听说过哪个使用源代码管 理的项目丢失了很多代码。你能在一步之内编译程序么？

5、通 过这条测试我想明白：从最新的源代码的快速复制到进行能输出的编译需要多少步骤？ 再优秀的团队里，有一个单独的脚本，它能从零开始对代码做一个全面的检 查，重新编译 每一行代码，生成 EXE 文件，在他们各种各样的版本、编程语言和#ifdef 宏定义组合，创 建安装包和最终媒体CDROM 布局、下载网站 等等。如果这个过程需要一个以上的步骤，就很容易出现误差。当你接近完工的时候，你很想有 很快的修复“最后一个”bug 的周期，生成最后的 EXE 文件等。如果编译代码要用 20 步才 能完成，运行安装编译器，等等，你会抓狂的，并且会导致你犯下愚蠢的错误。正式由于这个原因，我曾工作过的上个公司就从“

6、聪敏”模式切换到了“软件安装打包” 模式：我们要求安装过程中可以运行，使用 NT 调度从脚本整晚自动地运行， “聪明”模式 做不到这些，所以我们就抛弃了这个模式。你每天都编译代码么？当 你使用源代码管理的时候，有时候程序员偶然会检查出会停止编译的东西。比如，他们 添加了一个源文件，一切在他们的机器上编译起来都很好，但他们忘记把源文 件添加到代 码库里了。所以他们锁定了机器就回家去了，比较健忘也比较高兴。但其他人都不能继续 工作了，所以他们也不得不很不愉快地卷铺盖回家了。打 断编译是很糟糕的（也很常见的） ，但它能帮助程序员每天都编译代码，以确保不会出 现没有预兆的编译中断。在大型团队里面，一个

7、很好的确保中断能迅速修复的 方法是每天下午都对代码进行编译，比如可以在午饭时间做这个。每个人都尽可能多地在午饭前做代 码检查。这样当他们吃完午饭回来的时候，这个编译就已经完成 了。如果它能用，就太好 了！每个人都对最新的源代码进行检查，然后才继续工作。如果编译失败了，你就修复它， 但每个人还能在预编译、没有中断版本的源代码 上继续工作。在 Excel 项目组，我们有一条规则：谁中断了编译，作为对他的“惩罚” ，他就要在其他人 中断编译之前临时照顾代码编译的工作。这是一个很好的不中断编译的激励方式，也是一 个让每个人轮流参与编译工作从而都能知道编译原理的好方法。你有 bug 数据库么？我 不在乎

8、你怎么说。如果你在开发代码，即使是在一个人的团队，没有一个组织的列出代 码里所有已知 bug 的数据库，你将会产生出低质量代码。许多程序员都认为 他们能把众多 的 bud 存在脑子里。真是胡说八道。我根本就不能再同一时间记住两个或三个 bug，第二 天早上，或者在写代码的高峰时期，就记不起它们了。你 绝对要正式地跟踪 bug。但数据库可以是复杂或简单的。一个最小限度的 bug 数据库必须包含以下对每个 bug 的数 据：再次出现这个 bug 的完整步骤预期的行为观察到的行为它是被设计来干嘛的它是否已被修复如果 bug 跟踪软件的复杂性是让你不想跟踪你的 bug 的唯一理由，只用上面包含简单的

9、5 个元素的表格用在这些至关重要的领域，开始使用它吧。你在写新代码前会修复 bug 么？第 一个版本的 Windows 系统上的微软 Word 被认为是一个“死亡行军”项目。不知道这 项目要什么时候才能完成，它不断的延期。整个项目组在荒谬的时间里 工作着，项目再次、 再次、再次延期，这时候的压力的令人难以置信的。当讨厌的事情最终出货，几年以后， 微软把这整个团队都送到坎昆去度假了，他们可以静下 来做些严重的自我反省了。他 们意识到，项目经理一直在坚持按照“日程安排”部署工作，而程序员们只是头脑简单 的赶紧完成敲代码的过程，又因为修复 bug 阶段并没有成为正式日程安排的 一部分，这导致他们写出

10、了及其恶劣的代码。没有能试图保持住 bug 不发作的倒计时。恰恰相反，据说 一个程序员写了计算文本行高的代码，仅仅写了 “renturn 12;”然后就开始等待关于他的 功能总是正确的 bug 报道。日程安排仅仅是即将变为 bug 的功能的检查清单。事后，这个 被称为“无穷大缺陷的方法” 。为 了解决这个问题，微软普遍地采取了一种叫做“零缺陷方法”的东西。公司的许多程序 员都咯咯地笑，因为它听起来是一种好像通过行政法令就能够减少 bug 数量 的管理思想。 其实， “零缺陷”意味着在任意给定的时间内，优先级最高的是消除 bug，然后才是编写新 代码。让我来讲讲为什么。一般情况下，你等待修复 b

11、ug 的时间越长，这个 bug 就需要付出的代价就越大（在实践和 金钱上） 。比如，当你犯了一个编译器能捕捉的拼写或语法错误时，修复它的代价微不足道。当你第 一时间看到你尝试运行的代码里有 bug 的时候，你能够很快的把它解决掉，因为所以的代 码在你脑子里印象还很清楚。如果你在几天前的代码里发现了 bug，你会花费一段时间来找到它，但当你重读先前写下 的代码后，你就会记起一切然后就能在一个合理的时间内修复这个 bug。但 如果你在几个月前的代码里发现了 bug，你很可能把关于这段代码的大部分东西都忘了， 要修复它就很难了。这个时候你可能正在修复别人代码里的 bug，他们 可能会在阿鲁巴岛 度假

12、，这种情况下，修复 bug 就像科学一样：你不得不放缓步调、有条不紊、细致地开始 工作，并且你还不能确定需要多长时间才能找到问题的 治疗方法。如果你在已经售出的代码中发现了 bug，你会招致令人难以置信的代价修复它。这 是要立刻修复 bug 的一个原因：因为这样花费更少的时间。这关系到写新代码之前而不 是修复 bug 之前还要等多长时间。比如，如果我要你预测写一个给列表排 序的代买要多长 时间，你可以给我一个很好的估计值。但如果我要你预测修复一个安装 Explorer 5.5 版本后 代码就不能工作的 bug 需要多长时间，你猜都猜不出来，因为根本不知道到底什么导致了 这个 bug。它可能需要

13、 3 天时间才能跟踪到，或者仅仅 3 分钟就足够了。这句话的意思是，如果你有一个很多 bug 有待修复的日程安排，这个日程是不靠谱的。但 如果你修复了所有已知的 bug，并且所有剩下的都是新代码，这样你的日程安排才会更加 惊人的精确。关于把 bug 控制到零还有另一件重要的事，那就是你可以对竞争响应更快。一些程序员认 为这点能让产品在任何时候为发售准备好。如果你的竞争对手从你的客户那里引入了一个 杀手级的新功能，你就能在发售之前只实现这个功能，而不必去修复大量累计下来的 bug。你有最新的日程安排么？这条测试把我们带到了日程安排上来。如果你的代码对生意是很重要的，会有很多知道代 码完成日期怎么

14、对生意很重要的原因。程序员在制定日程安排上是出了名的倔。 “该完成的 时候就完成了！”他们会这样对商务人士尖叫。不幸的是，这并没有让一切变得更好。在发售代码之前，公司需要做太多的计划好的决定： 软件演示，展会，广告等。而要做到这一点的唯一方法就是拥有一个日程安排，并保证其 为最新版本。关于要有一个日程安排的另一个至关重要的原因是，它能强迫你决定要做哪些功能，然后 迫使你挑选出最无关紧要的功能并砍掉它们，而不是陷入长期的犹豫中去。同时，跟随日程安排做事并不一定要很苛刻。你写代码有规范么？书写规范就像牙线，每个人都同意这是一个很好的事情，但却没人做。我不知道这是为什么，但很可能是因为大多数程序员讨

15、厌写文档。结果，对一个大部分有 程序员组成的团队遇到了一个难题的时候，他们更倾向于用代码来表达他们的解决办法， 而不是用文档。他们宁愿埋头写代码而不是先写一份规范。在 设计阶段，当你发现问题时，你可以很容易地通过编辑几行文本就修复它。一旦开始写 代码，修复问题的代价就大大地提高了，无论在感情上（人们讨厌扔掉代码） 还是在时间 上，所以这时候修复问题是有阻力的。不是从规范开始建立起来的软件通常会很糟糕地结 束设计，并且日程安排会不受控。这个在 Netscape 好像 已经成为大问题了，Netscape 的 前四个版本慢慢变得一团糟，然后管理层愚蠢地决定抛弃旧代码再重新开始。然后他们又 在 Moz

16、illa 上再一次犯了这 个错误，创建了一个失控的怪物，并且浪费了好几年时间才又 回到初始阶段。我的一贯主张是，这问题可以通过把程序员送去学习写作的集中课程，把他们变为差不多 的写手来解决。另一个方案是雇佣一些聪明的程序管理人员，让他们来写代码规范。在这 两种情况下，你应该执行简单的规则“无规范不出代码” 。程序员有安静的工作环境么？广泛的记录表明，通过给知识型员工提供空间、安静和隐私就能提高生产力。经典的软件 管理书人件就广泛地记录了生产力受益于这些方面。问 题来了。我们都知道知识型员工随着“灵感流动”工作最好，就是我们所说的“进入状 态” ，在哪里他们会全身心专注于他们的工作，并且完全脱离了周围的环境。 通过绝对的 专注，他们忘记了时间，产生出伟大的代码。这是他们把工作完成的过程。作家、程序员、 科学家，甚至篮球运动员都会告诉你要进入状态。问题是，进入状态并不那么容易。当你尝试去考量它的时候，在最大生产力下好像需要 15 分钟才能开始工作。有时，如果你累了或那天已做了很多创造性工作时，你就是进入不了 状态，你会把这天剩下的时间都用来摆弄点什么，看看网页，或玩玩俄罗斯方