概述 在昨天“正确地做事(善用工具)”的帖子里提到了代码提交频度的问题。当时我特别强调了“要保证提交的代码能编译通过”，理由是“对于每日构建很重要”。我估计列位看官中，不太熟悉每日构建的，大有人在；而且国内停留在手工作坊阶段的软件公司，为数也不少。因此今天我们就来说一下"每日构建"这个话题。假如你平时已经很善于运用"每日构建"这一有效的手段，可以直接略过本系列，去看其它帖子。 照例先来说说什么是“每日构建”，每日构建在洋文里也称为 Daily Build 或者Nightly Build。具体定义见“这里”。简单地讲，就是每天都把整个软件项目自动编译一遍，最终生成的产出物必须和交付到用户手中的一样（比如你最终提交给用户的是一个安装程序，那就必须在开发过程中每天编译出一个安装包）。 为了表明每日构建是一个很有效的手段，我可以给大伙举几个知名软件公司或者著名开源项目的例子： 1、微软公司内部几乎所有产品的开发过程，都会使用每日构建。 2、我不确定Google 是否所有产品都采用，但至少 Google 的 Chrome 浏览器是采用每日构建。 3、知名的开源组织Mozilla 也大量使用每日构建。 4、知名的 Linux 发行版Ubuntu 也使用每日构建。 ...... 上面这个列表还可以罗列很长。举这么多例子，无非想说，每日构建是一种牛X 的软件工程手段。尤其对于复杂项目和大型团队，它的好处更加明显。看到这儿，有同学可能要问了，具体有些什么好处捏？请看“软件工程进阶之每日构建[1]：好处和优点”。 [1]：好处和优点 上一个帖子“软件工程进阶之每日构建[0]：概述”提到说每日构建是一种很牛X 的软件工程手段。本帖子就来说说它到底有多牛X。为了加深大伙儿的印象，我先来说一些陈年往事。 话说上世纪末，我还在一家小公司干活，并参与开发了一个 C++的项目。当时公司的流程是：开发人员写好代码，自己编译好，丢给测试人员测试；测试人员如果发现bug，口头通知开发人员改；开发人员改好bug，再丢给测试人员测试...... ★案例 1（开发的混乱） 有一天，开发组的小头目找来程序员甲。 >>小头目：你负责的 XX 功能完成了没有？ >>程序员甲：早做完啦！ >>小头目：那测试人员甲怎么说一直没看到 XX 功能？ >>程序员甲：不会吧！我去瞧瞧。 若干分钟后，程序员甲回来。 >>程序员甲：不好意思，编译好的 EXE 我只发给了测试人员乙，忘记发给测试人员甲了。 >>小头目：!@#$%^&*（此处省略 15 字） ...
