日构建的价值

　　可能有些人认为日构建过于浪费时间，但是实际上，比起最后除错的成本来说，日构建成本是微不足道的。当然，在企业中建立日构建制度确实需要花费不少的时间，但从长远来看，这绝对是值得的。

　　从表面上看，日构建能够减少最终的排错成本，但这仅仅是日构建最基本的价值。实际上，日构建更为关键的作用是能够引入日构建的制度。这是什么意思呢？日构建的思路将会为软件企业的开发流程带来变化：开发人员将会在日构建的制度下更加频繁的协作，开发进度一目了然，软件的质量也会更加的稳定。

　　软件开发本身就是一项强调沟通和协作的活动。但是在日常的活动中，常常出现阻碍沟通的情况，例如需要沟通的双方不在同一个地理位置、噪声、沟通双方的意愿等等。因此在软件管理中需要提供一种方法，来鼓励人们进行沟通。日构建就是其中的一种方法（但它并不是唯一的方法）。每一次的构建将会涉及到团队中的所有成员，因此沟通是少不了的，在日构建实践的驱动下，每位开发人员都朝着最终的目的－"成功的构建"努力。

　　在Alistair Cockburn的敏捷软件开发的第三章中，详细的阐述了团队沟通和协作中的相关问题。例如沟通的实质，影响沟通的各种因素，以及如何克服他们。最后，他还论述了如何促进团队的沟通，来打造一支成功的团队。

　　在日构建的驱动下，项目的进度将会变得非常的明显。每一天的构建结果将会通过某个渠道发布出来，团队和团队的老板可以看到软件现在的样子，项目的完成情况，出现的问题等等。这些信息构成了软件开发的基本信息。不但可以清晰地描述出项目进度，也为管理人员安排计划提供了基础数据的支持。有了基本的量化数据，软件开发才不是靠拍脑袋出成果的。

　　日构建的最后一个价值是提供了整合性。目前软件开发中并没有一种统一的管理软件，未来似乎也很难做到，因为不同的软件组织差异很大。在开发过程中，一些有价值的实践被加入、集成到日构建的过程中，在日构建的推动下，这些优秀实践很容易成为开发过程的一部分。在文章倡导的另一个优秀实践－测试驱动开发实践，就很容易集成到日构建中来。事实上，软件测试是非常重要的，它已经成为日构建成功的判别因素。

　　选择日构建还是持续集成

　　虽然日构建和持续集成的本质是相同的，但是他们在集成的频率方面的差异也导致了一些管理上的差异：

　　首先，日构建树立了一个明确的以工作日为单位的小目标，团队的目的就是为了使代码能够通过每天的构建。开发人员在明确的目标的指导下，往往能够发挥出很高的效率。持续集成则将这个频率变得更小，只要你的代码提交到代码库中，立刻就会检验你的成果，如果有问题，你必须立刻排除，否则，要么集成的过程无法继续，要么出错的开发人员的信箱被集成过程中的警告信息所填满。这种做法对团队的要求要更高一些。对于刚刚开始接触日构建的团队来说，可能会手忙脚乱。

　　其次，日构建有一条非常明确的分界线，开发工作要么是完成，要么是没有完成，不存在第三种状态。

　　日构建的基础实践

　　日构建的基础包括三个实践：自动构建、统一代码源和集成测试。

　　● 自动构建

　　自动构建的思路是通过脚本语言，而不是通过在IDE环境中点击构建按钮来完成项目的构建过程。日构建需要不断的进行集成的工作，如果手工来完成这项工作，既费时，效果又不好。所以更聪明的做法是把这件工作给自动化。在早期的Unix环境中，都是采用Make编写相应的脚本来完成构建的过程。随着先进的IDE 环境的发展，慢慢的人们就不愿意再编写Make脚本了。可是现在，为了自动构建的目标，我们需要回归到手工编写Make脚本的历史上去。应该说，IDE环境中的构建方式侧重于个人开发，而自动构建则侧重于团队开发

　　自动构建目标就是通过一个简单的命令就能够全部的构建过程。

　　● 统一代码源

　　其次，保证一个开发团队共享统一的代码源。这时候我们需要使用版本控制工具。共享的代码库同样也是XP的一个基本实践。虽然XP还要求开发人员可以修改他人的代码，但我们并不提倡这种做法，这要求团队成员之间有非常高的默契程度。统一的代码源能够保证所有人的代码都归总到一起，这是日构建的基础。如果没有这一点的保证，每一次的构建我们都不得不把所有人的代码集中起来，这无疑会使构建过程变成灾难。

　　统一代码源能够保证任何一位团队成员获得所有的代码，并以此为基础进行开发。

　　● 集成测试

　　只是把代码编译通过并不能够证明软件可以正常工作，评价软件的标准应该是测试。在日构建中必须要执行集成测试，来保证软件确实是能够工作的。

　　集成测试也是一个同义词相当多的名词，有人把它称为验证测试（BVT－Build Verification Tests），因为他们认为这种测试主要的目的是为了验证构建的正确性。有些人把它称为冒烟测试（Smoke Test），因为他们觉得这个测试的目的是运行软件，看它是否会"冒烟"。

　　测试应该全部执行完毕，而不是遇到未被满足的错误就放弃测试过程。测试将形成结果，成功的测试，失败的测试，失败测试的细节。最后的结果将通过某种方式通知给相应的人员，要求他们修改设计或测试（如果是测试本身的问题的话）。

　　集成测试是证明构建成功的关键因素。和构建一样，集成测试也应该是自动化的。