unit-testing - 为单元测试优化一个类是好的做法，还是为时过早？

Question

我在 StackOverflow 上看到(并搜索过)很多关于过早优化的问题——大街上的一句话是，它是万恶之源。 :P 我承认我经常为此感到内疚；我并没有真正以代码易读性为代价来优化速度，但我将使用看起来更适合任务的数据类型和方法以逻辑方式重写我的代码(例如，在 Actionscript 3 中，使用类型化向量而不是非类型化数组用于迭代)，如果我可以让我的代码更优雅，我会这样做。这通常有助于我理解我的代码，并且我通常知道我为什么要进行这些更改。

无论如何，我今天在想——在 OOP 中，我们提倡封装，试图隐藏实现并促进接口(interface)，从而使类松散耦合。这个想法是在不必知道内部发生了什么的情况下制作一些可以工作的东西——黑匣子的想法。

因此，这是我的问题——尝试在类级别对代码进行深度优化是否明智，因为 OOP 促进了模块化？或者这是否属于过早优化的范畴？我在想，如果您使用一种易于支持单元测试的语言，您可以测试、基准测试和优化该类，因为它本身就是一个接受输入并生成输出的模块。但是，作为一个编写代码的人，我不知道等到项目完全完成后再开始优化是否更明智。

供引用:我以前从未在团队中工作过，所以对于有这种经验的开发人员来说显而易见的事情对我来说可能是陌生的。

希望这个问题适合 StackOverflow - 我没有找到另一个直接回答我的查询的问题。

谢谢!

编辑:考虑到这个问题，我意识到“分析”可能是正确的术语，而不是“单元测试”；单元测试检查模块是否正常工作，而分析检查性能。此外，我之前应该问的部分问题 - 在创建单个模块之后对它们进行分析不会减少应用程序完成后的时间分析吗？

我的问题源于我正在尝试做的游戏开发 - 我必须创建应该以最佳方式执行的模块，例如图形引擎(它们是否会是一个不同的故事:D)。在性能不太重要的应用程序中，我可能不会担心这一点。

Answer 1

I don't really optimize for speed at the cost of code legibility, but I will rewrite my code in logical manners using datatypes and methods that seem more appropriate for the task [...] and if I can make my code more elegant, I will do so. This generally helps me understand my code

这不是真正的优化，而是 refactoring更简洁的代码和更好的设计*。因此，它是一件好事，它确实应该不断地练习，小幅度地练习。 Bob Martin 叔叔(在他的书 Clean Code 中)推广了适用于软件开发的童子军规则:让代码比你找到的更干净。

因此，要回答您改写的标题问题，是的，重构代码以使其可单元测试是一种很好的做法。其中一个“极端”是 Test Driven Development ，首先编写测试，然后添加使测试通过的代码。这样，代码从一开始就被创建为可单元测试的。

*不要吹毛求疵，只是澄清常用术语并确保我们以相同的含义使用相同的术语是有用的。