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

Question

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

这种开发方法对我来说非常好用了几年，直到去年我不得不回到C ++编码时才真正感觉到我的生产力从那以后急剧下降。 C ++作为一种语言不是问题 - 我有很多C ++开发经验......但在过去。

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

因此我得出结论，在一小块（如前所述）是不可接受的 - 任何建议如何让我自己进入编码一小时左右的旧习惯，手动查看代码（不依赖于快速C＃编译器），并且只在几个小时内重新编译/重新运行一次单元测试。

使用C＃和TDD，以渐进的方式编写代码非常容易 - 经过十几次迭代后，我开始使用的任何废话都以一个好的代码结束，但它对我来说不再适用（在一个缓慢的编译环境）。

非常感谢您的投入和回忆。

P.S。不确定如何标记问题 - 欢迎任何人适当地重新标记问题。

干杯。

Answer 1

我发现重新编译和测试有点让我脱离了“区域”，所以为了获得TDD的好处，我经常将其提交到git存储库，并运行后台进程来检查任何新提交，运行完整的测试套件并使用结果在git中注释提交对象。当我绕过它（通常在晚上）时，我会回到测试结果，修复任何问题并“重写历史记录”，然后重新运行新历史记录上的测试。这样我即使在重新编译（大部分）我的项目所需的短时间内也不必中断我的工作。

Answer 2

我不明白为什么你不能在C ++中使用TDD。我在2001年使用过CppUnit，所以我认为它仍然存在。

您没有说出您正在使用的IDE或构建工具，因此我无法评论这些因素会影响您的步伐。但小型，增量编译和运行单元测试仍然是可能的。

或许正在调查Cruise Control，Team City或其他不干涉的构建和测试过程将是您的一杯茶。您可以尽快签入，并让自动构建在另一台服务器上进行。

Answer 3

有时你可以避免长时间的编译。除了提高构建文件/流程的质量之外，您还可以选择一个小东西来构建。如果您正在处理的文件是.cpp文件，只需编译一个TU并将其与项目的其余部分隔离进行单元测试。如果它是一个标题（可能包含内联函数和模板），那么在它们之间引用大部分功能的少量TU（如果不存在这样的TU集合，为头文件编写单元测试并使用它们）也是如此。 。这使您可以快速检测到无法编译的明显愚蠢错误（如拼写错误），并运行您认为与您正在进行的更改相关的测试子集。一旦你有一些可能含糊不清的东西，就要对项目进行适当的构建/测试，以确保你没有破坏任何你认为不相关的东西。

如果长编译/测试周期是不可避免的，我会同时处理两件事。为了使其高效，其中一个需要足够简单，以便在主任务准备好恢复时可以丢弃，并在主任务的编译/测试周期结束时立即再次拾取。这需要一些计划。当然，辅助任务有自己的构建/测试周期，因此有时您希望在源的单独签出副本中工作，以便一个中的错误不会阻塞另一个。

次要任务可以是，“通过减少组件间依赖性来加速主任务的部分编译时间”。即便如此，一旦花了10分钟来链接你的程序的可执行文件，你可能已达到了一个硬限制，因为将事物分成多个dll就像开发黑客可能不是一个好主意。要避免的关键是次要任务是“命中SO”或this。

Answer 4

由于简单的更改会触发10分钟的重新编译，这意味着您的构建系统不正确。您的构建应该只根据更改的文件重新编译已更改的文件和文件。

除此之外，还有其他技术可以加快构建时间（例如，尝试删除不需要的包含。然后代替包含标题，使用前向声明等），但这些东西的加速并不快重要的是在改变时重新编译的内容。