一般而言，构建的顺序是本地构建确保所有的功能运行正常，然后提交等待持续集成工作正常。本地构建超过 5 分钟就变得难以忍受，大多数情况下我们希望这个反馈时间越短越好。项目的初期我们往往会运行所有的步骤：编译所有代码，运行所有大连软件修复二次开发测试。随着项目周期的变长，代码的增多，时间会越来越长。在尝试若干次重构构建脚本再也没办法优化之后，“分阶段构建”成为绝大多数的选择。通过合理地拆分、分层，每次运行特定的步骤，例如只运行特定的测试、只构建必要的部分，然后提交，让持续集成服务器运行所有的步骤。这样开发者能够继续进行后续的工作。

      即便本地快了起来，采用分阶段构建的大连微信公众号停车场计费系统开发团队很快也会发现，CI服务器的构建时间也越来越让人不满意，每次提交半小时之后才能得到构建结果太不可接受了。各种各样的分布式技术被创建出来。除了常见的CI服务器本身提供的能力，许多团队也发明了自己的分布式技术，他们往往将代码分布到多台机器进行编译和运行测试。这种解决方案能够在比较长的一段时间内生效——当构建变慢的时候，只需要调整分布策略，让构建过程运行在更多的集群机器上，就可以显著地减少构建时间。

      致远服软认为：http://www.soft8.com.cn/一些新的工具能够显著地提速开发人员的工作。JRebel能够将需要编译的Java语言变成修改、保存立即生效，减少了大量的修改、保存、重新编译、部署的时间；Spork能够启动一个Server，将RSpec测试相关的代码缓存于其中，这样再运行RSpec测试的时候就不用重新进行加载，极大地提升了效率。

      上述的大连软件修复二次开发测试解决方案在特定的时间域内很好地解决了一部分问题。然而，在项目运转一年、两年或者更久之后，它们最终依然无法避免构建时间变长、开发变慢、代码变得混乱、架构晦涩难懂、新人难以上手等问题。到底问题的症结是什么？

      人们喜欢简洁，但这更多地看起来是一个谎言——没有多少团队能够自始至终保持简洁。人们喜欢简洁只是因为这个难以做到，并不是说人们不愿意如此。很多人都知道大连软件修复二次开发测试不比其他的劳动力密集型的行业——人越多，产量越大。《人月神话》中已经提到，项目增加更多的人，在提升工作产出的同时，也产生了混乱。短期内，这些混乱能够被团队通过各种形式消化；但从长期看来，随着团队人员的变动（新人加入，老人离开）以及人正常的遗忘，代码库会逐渐失控，混乱无法被消化，而项目并不会停止，新功能不断地加入，架构就在一天天的过程中被腐蚀。