辛辛苦苦构建的软件被破坏了，这是不是特别让人恼火？构建问题为人们带来计划外的额外工作负担。而这些问题似乎总在我们忙于解决其他问题的时候发生。通常情况下，构建问题会因为一些与目前工作无关的因素而造成中断。因此，我们不得不放弃停下手头的工作，调查导致构建中断的原因并解决问题，然后才能重新开始构建工作（希望只有一个问题需要解决），这可能相当令人懊恼。
今天，我在重建一些开源包时遇到了这个问题。几个月前，我们将 OpenSSL 的副本更新到1.0.0版，但我们没有对所有依赖它的包进行重建。恰好，当我去重建 subversion 客户端以修复一个bug时，我发现 subversion 的构建被破坏了，原因是 OpenSSL 1.0.0 引入了一些不兼容的更改。很快，我就找到了修复方法，因为这个问题在几个月前就已经被修复了，我只需要简单的网络搜索就能找到 bug 报告和修复方法。但我刚开始重建产品就遇到这个问题，还是比较让人恼火的。
我在这里也没有什么高明的建议。但我确实观察到一个现象，那就是现在机器时间很充裕。也许我们应该每天晚上重建所有软件，这样就可以在大家对问题还记忆犹新的时候就能发现构建问题。
而且，万一在构建过程中存在一些手动步骤，决定频繁重建将是消除这些步骤的一个很好的理由。手动步骤是常见的错误来源。
软件测试人员一般不喜欢在软件测试完毕后重新构建软件。他们认为这可能会引入新的缺陷。我对构建工具（编译器、链接器、makefiles）有足够的信心，所以我可以随时重建。鉴于我们使用的是高级语言，我们必须对我们的构建工具有信心。但在分阶段的开发过程中，则要综合考虑两种观点。
关于如何管理软件开发，以最大限度减少破坏构建的情况，或最大限度地减少修正构建问题所需的工作，如果您有任何建议，欢迎在文章下面留言。
旗下公司