软件质量之路（2）：日构建 软件质量保证
关键字：日构建
软件质量的重要性是不言而喻的，但是当所有人都意识到它的重要性的时候，却很少有人能够清晰的描述出如何才能够提高软件质量。软件质量框架的目的就在于提出一个评价的原型，帮助我们分析一种方法和技术是否能够提高软件质量。本系列文章分日构建、测试驱动开发、建立核心框架、面向组件的大规模软件架构来进行深入的分析。
日构建是一项非常基础的软件开发实践，遗憾的是，并没有多少组织真正意识到它的好处。通过本章的讨论，你可以知道日构建对软件开发的意义，了解日构建的基本情况以及如何着手进行日构建。
什么是软件开发的有效管理
在一个全国性的银行中，是什么保证复杂的资金清算的正确性的呢?每天，各个地方的网点在结束营业之前，需要保证账目、资金、票据的平衡;这些网点的数据不断的汇集，在每一个汇集点上都要保证账目余额的平衡，最终完成一个银行的一天的结算。天天如此，就像是一部设计精巧的机器一样运作不息。不仅银行是这样，任何一个企业都是如此。一个小杂货铺的老板，也知道每天算算账，看看今天是赚是赔。这些行为已经成为了工作的一部分，甚至成为了一种习惯。
软件开发也是一样的，必须找到一种方法，来衡量每天的工作，保证每天的工作能够有效的持续下去，最终把软件开发的过程变成一种内在的过程。这种方法就称为日构建或是持续集成。
为什么需要日构建
日构建和持续集成是类似的，对开放源码熟悉的人应该都知道Nightly Build。而持续集成这个词来自XP方法，它的频率可以比日构建更高，可以做到几分钟就进行一次集成，故而由此得名。在本文中，我们只讨论日构建，而要将日构建转换为持续集成是非常容易的。事实上，并没有规定持续集成必须是以分钟为单位进行的，如果你愿意，以一周为单位进行持续集成也是可行的。这样区分的目的是为了更好的使用日构建或是持续集成技术：至少以天为单位，频率越高，效果则越好。
那么，什么是日构建呢?我们传统开发软件的流程一般是这样，理解领域问题，然后分配任务，由不同的人负责不同的软件部件，在开发完成之后，再把各人的部件整合起来，形成完整的软件。这个思路看起来并没有什么问题，但是在实践中却问题多多。
首先，这种方式适合开发人员之间工作彼此没有交集的情况，以前这种现象很常见，但是现在，随着软件规模的扩大、分工合作的加深，开发人员间的相互依赖程度越来越高，这种清晰的职责划分已经变得越来越难了。
其次，在软件集成时，往往会出现各种各样的问题，可是却很难发现到底问题在哪里?公说公有理，婆说婆有理。每个人的代码都没有问题，结合到一起就出现大量的问题。
所以日构建就将平时难得一见的集成工作转换成频繁进行的一件工作，从而使得原先如同噩梦般的集成变成了一件简单的工作。这也是很容易理解的，如果集成工作几个月才进行一次，谁能够记起几个月前的细节呢?但是如果集成以天，甚至以分钟为单位进行，排除bug就变成一件很容易的事情了。
日构建范例
现在的时间是下午的17:00，马上就到日构建的时间了。团队里四名程序员中的三位已经将自己的源代码和测试代码提交到了一台名为宙斯的机器上，这台机器将负责对代码进行日构建。在他们提交代码之前，已经通过了本机上的构建，并完成了测试。剩下的一位程序员似乎碰到了麻烦，他的代码出现了一些问题，他现在需要编写更多的测试来完善测试网。看来时间来不及了，他只能够在明天再做提交了。由于他的代码没有和其他人产生依赖，所以迟些提交也没有关系，不过他在下个工作日的时候必须仔细的将最新的源代码检出到本地，在版本控制工具的帮助下，这项工作是很简单的。
文章来源于领测软件测试网 https://www.ltesting.net/