在读完无痛软体时程之后，ㄚ琪要继续读每日编译(Daily Build)是你的好朋友，‘1982年我家人带了一台很早期的IBM-PC到以色列…’，咦，以色列？约耳是犹太人，这下我可有兴趣看他的生平了，他15岁的时候回以色列，看起来是很忠信的以色列人，那么每日编译是你的好朋友，不就跟每日读经文是你的好朋友有关联！
‘REP循环的概念。REP代表“Read, Eval, Print”，是叙述lisp直译器一直在做的事：它会读取你的输入，把它求出来，然后印出结果。’约耳进一步解释成‘写程式的动作其实是一种放大版的REP循环，是一种名为编辑-编译-测试的循环。’像ㄚ琪在写程式的时候，就会从很小的程式开始写，写个几行，就编译看看有没有错，然后执行看看结果对不对，然后再接下来继续写，我承认这个方法有点笨，因为看到有些人他可以一气呵成把整篇的程式都写完后再编译执行，就很佩服，不过我的方法我觉得是很小心的一种，万一功力没有那种火候，写一大篇程式有编译错误可能还好，万一执行错误时那侦错可能就代志大条了！
所以个人在写程式可能不需要每日编译吧，可能吧！因为约耳提到的案例是团队的开发，那么我会觉得每日编译看起来会很需要，所以‘每日编译是一个自动、每天、完整的编译动作，把全部原始程式重新编译一遍。
自动 – 因为你会用cron(在UNIX上)或是Tash Scheduler服务(在Windows上)安排每天在固定的时间编译程式。
每天 – 更密集也可以。连续编译更吸引人，不过由于版本管理的问题(待会就会提到)可能做不到。
完整 – 你的程式可能有很多版本。’
每日编译的好处：
-
- ‘当某个问题修好之后，测试人员可以很快就拿到新版本重测，看看问题是否真的修好了。
- 开发人员可以比较放心自己的修改不会破坏到要出货的1024种版本，不必真的自己准备一套OS/2来测。
- 在每日编译开始前把程式存入版本管理系统的开发人员会比较安心，因为知道自己不会因为放入某些会“破坏(break)”编译的东西而干扰到别人。所谓破坏编译就是让编译无法进行。这对整个程式团队来说就等于Windows的蓝色当机画面，当某个程式师忘记把新增的档案放入版本管理系统时常常出现。在他们的机器上都正常，不过等别人由版本管理系统拿程式出来编译时，就会遇到连结错误，然后什么事都不能继续做。
- 行销部门及beta测试者之类的外部人员都必须用到尚未完成的产品，这时候就可以选一个已知相当稳定的版本暂时用一阵子。
- 如果有维护一个存放所有每日编译结果的档案库，当你发现很奇怪的新问题又搞不懂原因时，可以利用二分法搜寻过去的档案，找出问题问题第一次出现的时间。再配合良好的版本管理，或许就能找出哪一些更动造成这个问题。
- 当某个测试人员回报一个程式师认为已修正的问题时，测试人员可以说在哪一版看到这个问题。然后程式师可以回头查查自己什么时候把修正存入，就知道是否真的修好了。 ’
- 实施的方法：
- ‘建立最终编译结果的所有动作都必须由每日编译脚本完成，这一点非常重要。
- 以下是绝不能容许的行为：在准备发行程式时发现一只小虫，于是你就在每日编译伺服器上直接把它修好然后发行。每日编译有条黄金定律：只有从完整取出程式码开始，并经过完全重新的每日编译所制作的程式才可以发行。
- 把你的编译器的警告等级开到最高(在微软的世界里就是-W4，用gcc的话就是-Wall)，并且设定成即使遇到最小的警告都要停止编译。
- 把你的编译器的警告等级开到最高(在微软的世界里就是-W4，用gcc的话就是-Wall)，并且设定成即使遇到最小的警告都要停止编译。
- 如果每日编译失败，就要冒险停止整个团体的作业。全部动作都停下来重新编译，直到问题修正为止。有时候一天之内会做很多次每日编译动作。
- 你的每日编译脚本应该用电子邮件把失败状况回报给整个开发团队。用grep把”error”或”warning”记录抓出来再放入电邮里也不是难事。脚本也要能把状态报告附加到大家都能看到的HTML网页上，这样程式师和测试人员就能很快地知道哪个编译结果是成功的。
- 在微软的Excel团队有一个很有效的规则：破坏编译的人必须开始负责照顾每日编译，直到有其他新的人破坏才换手。这样做能让大家有强烈动机维持编译正常运作，而且几乎每个人都会轮流照顾编译动作，所以大家都会知道编译结果是怎么产生的。
- 如果你的团体成员都在同一个时区工作，午餐时间会是个进行编译的好时间。这样子大家都在午餐前把最新的程式放入版本管理，大家吃饭时就进行编译。等人吃完午餐回来，如果编译失败大家就来解决问题。只要编译正常完成，大家就可以取出最新的版本继续作业，不必担心会被编译错误卡住。
- 如果你的团体分散在两个时间，每日编译的时间得适当安排，以确保第一个时区的人不会卡到另一个时区。在Juno的团体中，纽约的开发人员会在下午7点把程式放入版本管理然后回家。如果他们破坏了编译，在印度海得拉巴的团队正要工作(大约是纽约时间下午8点)却因此卡住一整天。于是我们开始实施两次每日编译，分别在两边下班前一小时进行，就完全解掉这个问题了。’
-
- 有些针对每日编译工具的讨论
- 实施每日编译非常重要，所以列入迈向高品质的12个步骤。
- 在G. Pascal Zachary的书Showstopper里有很多关于Windows NT团体编译制作(每周一次)的趣事。
- Steve McConnell在这里谈每日编译。
- ㄚ琪在这里几乎快引用了全部文章的内容了，这其实不足为怪，因为ㄚ琪根本没有每日编译的习惯，所以这篇文章看起来就很觉陌生，既然陌生就无法将文章再摘录一些重点出来，直觉所有内容都恨有重要，其实就是因为不熟了关系嘛，希望这一篇研读后可以化为行动力来执行，愿与ㄚ琪的朋友共勉之！
-
进阶阅读：