软件随想录(local.joelonsoftware.com/wiki)-2001年01月27日 每日编译(Daily Build)是你的好朋友 - Daily Builds Are Your Fri

2001年01月27日 每日编译(Daily Build)是你的好朋友 - Daily Builds Are Your Friend

 

The Joel on Software Translation Project:每日编译

From The Joel on Software Translation Project

Jump to: navigation, search

每日编译(Daily Build)是你的好朋友

作者：周思博 (Joel Spolsky)
译：Paul May 梅普华
Saturday, January 27, 2001
属于Joel on Software, http://www.joelonsoftware.com

1982年我家人带了一台很早期的IBM-PC到以色列，当时我们还是跑去仓库等PC由港口进来。我不知道用了什么方法，说服老爸买齐完整配备，有两台软碟、128 K内存、再加上一台点阵式打印机(印草稿用)和一台兄弟牌印刷品质的菊轮式打印机(列印时的声音和机关枪一样，不过更吵)。

我想我们把能买的配备几乎都买齐了：PC-DOS 1.0、75美元的技术参考手册和完整的BIOS源代码列表、Macro Assembler、还有能显示完整80行和小写字母(！)的高级IBM单色屏幕。全部加起来大概是10,000美元(含荒谬的以色列进口税)。真是奢侈啊！

「每个人」都知道BASIC是种小孩用的电脑语言，要让你写出面条般纠缠不清的程序，还会让你的脑袋变成和乳酪一样都是空洞。所以我们花了600大元去买总共有三片磁片的IBM Pascal。这个编译器的第一轮编译要用第一片磁片，第二轮要用第二片，连结器则是在第三片。我写了一个简单的"hello, world"程序拿来编译，用的时间总共是8分钟。

嗯，这时间蛮长的。我写了一个批次档把整个过程自动化，把时间压到7分半。有快一点，不过当我想写长一点的程序(比如我的名作：一定会赢我的黑白棋)时，还是得花很长的时间等编译完成。「没错，」有位专业程序员告诉我：「我们通常会在办公室放块板子，等待编译完成时就去做仰卧起坐。写了几个月程序之后我就有腹肌了。」

有一天从丹麦传来了一个叫Compas Pascal的绝妙程序，Philippe Kahn把这只程序买下来并且改名为Borland Turbo Pascal。Turbo Pascal有点夸张，因为他和IBM Pascal的功能基本上相同，可是连文字编辑器一起只要33K内存就可以执行，这实在只能说佩服。更惊人的是一只小程序只需不到一秒就可编译完成。这就像一家默默无名的公司推出别克LeSabre的同型车款，可是时速有一百万英英里而且极为省油，环游世界一圈用的油还淹不死一只蚂蚁。

突然间我的生产力就提升了许多。

我就是在这时候学到REP循环的概念。REP代表「Read, Eval, Print」，是叙述lisp直译器一直在做的事：它会读取你的输入，把它求出来，然后印出结果。下面显示一个REP循环的范例：我键入某些东西，lisp直译把东西读进去，求解，然后印出结果。

以稍大一点的尺度来看，你写程序的动作其实是一种放大版的REP循环，是一种名为编辑-编译-测试的循环。你编辑你的程序，进行编译，测试，然后看看能不能正常运作。

这里有个重要的观察结果，就是写程序时会一再重复这个循环，所以编辑-编译-测试的循环进行得愈快，你就愈有生产力，最快时就是能瞬间完成编译。电脑程序员想拥有真正飞快的硬件，而编译器开发者会无所不用其极地做出超级快的编辑-编译-测试循环，这正是电脑科学上正式的原因。Visual Basic会在输入每行程序时进行字汇和文法分析，所以最后的编辑超级快速。而Visual C++的方法则是提供渐进编译、预先编译的档头和渐进连结。

不过当你进入拥有多个开发人员和测试人员的大团队时，又会遇到相同的循环，不过更大更复杂。测试人员找到程序的问题并回报问题。程序员会去修正问题。测试人员要等多久才会拿到修正的程序呢？在某些开发组织中，这种开发-修正-重测的循环要花好几个星期。表示整个组织的运作完全没有生产力。要让整个开发组织运作的更平顺，就得专注让开发-修正-重测的循环更紧凑。

要达到这个目的有个好方法，就是每日编译。每日编译是一个自动、每天、完整的编译动作，把全部原始程序重新编译一遍。

自动 - 因为你会用cron(在UNIX上)或是Tash Scheduler服务(在Windows上)安排每天在固定的时间编译程序。

每天 - 更密集也可以。连续编译更吸引人，不过由于版本管理的问题(待会就会提到)可能做不到。

完整 - 你的程序可能有很多版本。针对不同的语言的版本，不同的操作系统，可能还有分豪华版和入门版。每日编译必须建立所有的版本。而且必须从头建立每个文件，不可以依靠编译器有潜在问题的渐进重新编译功能。

下面列出每日编译众多好处中的几项：

1. 当某个问题修好之后，测试人员可以很快就拿到新版本重测，看看问题是否真的修好了。
2. 开发人员可以比较放心自己的修改不会破坏到要出货的1024种版本，不必真的自己准备一套OS/2来测。
3. 在每日编译开始前把程序存入版本管理系统的开发人员会比较安心，因为知道自己不会因为放入某些会「破坏(break)」编译的东西而干扰到别人。所谓破坏编译就是让编译无法进行。这对整个程序团队来说就等于Windows的蓝色当机画面，当某个程序员忘记把新增的文件放入版本管理系统时常常出现。在他们的机器上都正常，不过等别人由版本管理系统拿程序出来编译时，就会遇到连结错误，然后什么事都不能继续做。
4. 行销部门及beta测试者之类的外部人员都必须用到尚未完成的产品，这时候就可以选一个已知相当稳定的版本暂时用一阵子。
5. 如果有维护一个存放所有每日编译结果的文件库，当你发现很奇怪的新问题又搞不懂原因时，可以利用二分法搜寻过去的文件，找出问题问题第一次出现的时间。再配合良好的版本管理，或许就能找出哪一些更动造成这个问题。
6. 当某个测试人员回报一个程序员认为已修正的问题时，测试人员可以说在哪一版看到这个问题。然后程序员可以回头查查自己什么时候把修正存入，就知道是否真的修好了。

接下来是实施的方法。你需要一台每日编译的服务器，它可能会是你能拿到最快的电脑。然后写一个脚本命令，由版本管理系统取出所有最新的程序代码(你有在用版本管理系统吧？)，然后从头编译会出货的所有版本。如果有安装程序或设定程序，也要重新编译。所有会出给客户的东西都应该由每日编译程序产生。把每次编译的结果存在依日期编码的专属目录里。每天在固定时间执行你的脚本命令。

1. 建立最终编译结果的所有动作都必须由每日编译脚本完成，这一点非常重要。由取得源代码开始，一直到把结果放到网站上适当位置供人下载(在开发过程中当然会有一个测试服务器)，所有过程全部都包含在内。想要确保整个编译制作过程中没有任何步骤只有某个人知道，这也是唯一的方法。这样子就绝对不会发生由于某人被车撞，而且只有他会做安装程序，所以不能发行产品的鸟事。在Juno的团体中，只要知道编译服务器在什么地方以及双击「每日编译」的图示，就能从头建立一套完整编译结果。
2. 以下是绝不能容许的行为：在准备发行程序时发现一只小虫，于是你就在每日编译服务器上直接把它修好然后发行。每日编译有条黄金定律：只有从完整取出程序代码开始，并经过完全重新的每日编译所制作的程序才可以发行。
3. 把你的编译器的警告等级开到最高(在微软的世界里就是-W4，用gcc的话就是-Wall)，并且设定成即使遇到最小的警告都要停止编译。
4. 如果每日编译失败，就要冒险停止整个团体的作业。全部动作都停下来重新编译，直到问题修正为止。有时候一天之内会做很多次每日编译动作。
5. 你的每日编译脚本应该用电子邮件把失败状况回报给整个开发团队。用grep把"error"或"warning"记录抓出来再放入电邮里也不是难事。脚本也要能把状态报告附加到大家都能看到的HTML网页上，这样程序员和测试人员就能很快地知道哪个编译结果是成功的。
6. 在微软的Excel团队有一个很有效的规则：破坏编译的人必须开始负责照顾每日编译，直到有其他新的人破坏才换手。这样做能让大家有强烈动机维持编译正常运作，而且几乎每个人都会轮流照顾编译动作，所以大家都会知道编译结果是怎么产生的。
7. 如果你的团体成员都在同一个时区工作，午餐时间会是个进行编译的好时间。这样子大家都在午餐前把最新的程序放入版本管理，大家吃饭时就进行编译。等人吃完午餐回来，如果编译失败大家就来解决问题。只要编译正常完成，大家就可以取出最新的版本继续作业，不必担心会被编译错误卡住。
8. 如果你的团体分散在两个时间，每日编译的时间得适当安排，以确保第一个时区的人不会卡到另一个时区。在Juno的团体中，纽约的开发人员会在下午7点把程序放入版本管理然后回家。如果他们破坏了编译，在印度海得拉巴的团队正要工作(大约是纽约时间下午8点)却因此卡住一整天。于是我们开始实施两次每日编译，分别在两边下班前一小时进行，就完全解掉这个问题了。

进阶阅读：

1. 有些针对每日编译工具的讨论
2. 实施每日编译非常重要，所以列入迈向高品质的12个步骤。
3. 在G. Pascal Zachary的书Showstopper里有很多关于Windows NT团体编译制作(每周一次)的趣事。
4. Steve McConnell在这里谈每日编译。

这些网页的内容为表达个人意见。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.