在慢速编译环境中进行编码的最佳方法是什么

我曾经以TDD风格使用C＃进行编码-编写/或更改一小段代码，在10秒内重新编译整个解决方案，然后重新运行测试。简单...

几年来，这种开发方法对我一直非常有效，直到去年我不得不回到C ++编码的那一刻起，我才真正感觉到我的生产率从此大大降低了。C ++作为一种语言不是问题-我有很多C ++开发人员的经验……但是过去。

对于一个小型项目，我的工作效率仍然可以，但是当项目规模增加时，情况会变得更糟，一旦编译时间达到10分钟以上，它就会变得非常糟糕。如果发现错误，则必须再次开始编译，等等。这简直令人沮丧。

因此，我得出的结论是：（像以前一样）一小部分是不可接受的-任何建议，当我手动检查代码时（不依赖快速的C＃编译器）如何使自己养成一个小时左右的古老编码习惯，并且仅在几个小时内重新编译/重新运行一次单元测试。

使用C＃和TDD，以进化的方式编写代码非常容易-经过十几次迭代之后，我开始的任何废话都以良好的代码结尾，但对我而言不再起作用（在缓慢的编译中）环境）。

我想到了几件事：

1. 利用分布式编译。您可以使用GCC（“ distCC”？）或VC（Xoreax的IncrediBuild并不便宜，但值得花每一分钱）来做到这一点。

2. 将您的项目拆分为动态加载的库，并仔细尝试最小化对它们的依赖。较小的可执行文件链接速度更快。

3. 针对小型测试项目而不是整个大型应用程序进行编程。

4. 采用模板元编程在编译时执行算法。是的，这实际上会增加编译时间，但也会减少测试所需的周转时间：如果编译正确，那就完成了。

5. 投资硬件。更多的CPU内核（在您的计算机或其他计算机中）将对分布式编译产生疑问，而大量的内存以及快速的磁盘（SSD而非HDD）将大有帮助。如果您拥有64位系统和大量的RAM，那么在RAM磁盘上进行编译可能会提供令人难以置信的速度提升。

其他人尚未提及的另一种技术解决方案是切换到固态驱动器而不是常规硬盘驱动器。在我之前从事的项目中，SSD将构建时间从30分钟缩短到了3分钟。

当然，它们很昂贵。对于您的老板，请根据一次性投资的价格来计算开发人员损失的时间。这笔投资可能会在几个月内收回成本。

进行更多的计划，编写更大的代码，编写集成测试而不是单元测试，并在一夜之间运行build +测试套件。

较长的编译时间有时是个问题，但是已经提到的模块化可以（大部分）帮助克服这一问题。

更加严重的是，您无法进行任何编译，每个代码更改都必须提交给另一个大陆的另一个部门才能应用到测试/开发环境中，而这个过程可能要花费数天才能完成。

我现在在这样的环境中工作，这个系统已经花了我一个多星期的时间（而且在预算用完之前，该项目的预算只有4周的时间），只是为了安装我们的变更的初始版本（然后他们犯了错误，导致部分文件无法被应用程序服务器接收，因此我们还要等待几天的延迟）。现在的每个微小更改（例如，我们在测试中发现需要修复的某些内容，例如错过的错误情况）都可能导致延迟一天或更长时间。

在这种情况下，您甚至在尝试编译您的代码之前，都应尽可能确定没有任何错误。感觉就像我回到大型机编程一样，在那里我们每个月有5分钟的CPU时间用于所有编译和测试工作。

我很容易记住，构建花费了很长时间。一些缓解方法：

• 通过组合库或dll构建系统。这样，当您修改某些代码时，唯一需要重新编译的部分就是您的部分。
• 实现功能所需编辑的代码点数不仅会影响您必须进行的编辑量，而且还会影响您输入错误的频率，从而扩大了compile-debug-edit-compile循环。减少代码冗余的任何内容（例如DRY）都可以帮助您。
• 如果您在调试器中，并且可以在不离开调试器的情况下进行编辑，重新编译和继续操作，那将非常有帮助。

10分钟以上即可进行编译？认真吗

您是否正在使用进行增量构建的IDE（例如Eclipse）？如果没有，您可能应该这样做，它将在几秒钟而不是几分钟内完成基本编译。

还是在谈论集成的东西，您需要在其中构建整个应用程序以测试您的更改？如果是这样，请在进行完整构建之前查看较小的测试，以确保主要错误不在您的代码中。

首先，为什么首先要花这么长时间进行编译？

• 您的环境（IDE，制造商或其他）是否支持增量构建？确保只重新编译更改，而不是整个过程。
• 如果您有多核计算机，则您的IDE可能支持并行编译。我知道Visual Studio可以做到这一点。显然gcc也是如此。因此，请获得更好的计算机，并启用并行编译。
• 考虑使用预编译头。
• 如果您尝试了所有这些操作，但编译仍然很慢，请查看您的代码。寻找不必要的依赖项。您是否包含一个头文件，其中前向声明就足够了？考虑使用PIMPL习惯用法来减少对标头的依赖性。

如果毕竟您的构建时间仍然很慢，那么请解决该问题：创建许多小型测试项目，并分别处理每个项目。确保您有一个每晚自动执行的构建系统，该系统可以进行全新签出，构建所有内容并自动运行所有单元测试。

最后，如果仍然需要很长时间来测试您的更改，请多加思考。确保在版本控制系统中进行差异化测试，并在测试之前仔细查看所有更改。简而言之，这非常类似于嵌入式系统开发，在该系统中，测试的周转时间很长，并且检查系统状态的能力受到限制。

这使我想到了另一个想法：检测您的代码以使用日志记录。这样一来，您无需重新构建和重新运行多次就可以查看问题所在。

您可能需要多管齐下的方法：

1）更快的构建系统。尽可能多的核心/内存/快速磁盘。对于较大的C ++项目，您会发现磁盘通常是一个限制因素，因此请确保使用快速磁盘。

2）项目的更多模块化。分解内容，以便更改不会轻易导致对所有内容进行完全重新编译。坦率地说，将尽可能多的基本内容推入单独的dll / so文件中，以便使项目的一部分与其余部分完全脱离。

3）增量构建/分布式构建/缓存，以适合您的环境。在某些系统上，distcc（分布式构建）和ccache（缓存部分构建的内容）可以节省大量的编译时间。

4）确保您的构建可以很好地并行化。尤其是在makefile环境中，不难进入意外设置Makefile使得无法并行构建的情况。

大量的日志记录和内部验证有助于延长周转时间。构建完成后，一次运行即可一次发现大量可能的问题。

当处理相当复杂的算法或簿记时，将一个高度简化的版本与“真实”版本同时包含会有所帮助。在任何运行中，都包含有用的参考数据。

@sbi和@Michael Kohne说了什么。

在构建过程本身上花费时间和精力。曾几何时，我们拥有一款庄重，成熟的产品，整个构建花费了一个多小时。花了很多时间和精力来修复构建依赖项所声称的内容，然后再修复/减少它们的实际存在。构建时间降至约30分钟。

更改构建工具后，它的下降幅度更大。对于多部分项目，“ scons”可以在进行任何链接之前进行所有编译。使用多个makefile的“ make”会在该项目的链接之前执行一个项目的编译，然后继续进行。

这使我们意识到，所有单独的编译命令都可以大规模并行完成。在慢速计算机上为'distcc'，在多核计算机上为make / scons -j8。如此一来，完整的构建工作就减少了几分钟。

用另一种方式，创建一个自动的每晚构建过程。这样，如果有问题的东西提交到您的源存储库，则第一个上班的人来查看并解决问题，可能会阻止多个人（重新）进行多个失败的构建。