目前我正在从事C++项目,它可以被归类为“遗留”项目。由于缺乏经验和在截止日期的压力下,许多糟糕的编写代码被提交。当我试图修复bug时,我最终做出了新的。
最近我有更多的空闲时间,我想把这个项目做得更好。确切地说,我想开始使用TDD。然而,事实证明,这并不容易。我面临的问题是我不能为任何一堂课写测试。单身人士到处都是。甚至基本类也使用静态成员。
例如,在项目中,我们广泛使用“数字”类(它是用于十进制计算的decNumber C库的包装器)。该类具有静态成员以保持上下文(精度、舍入模式等)。显然,我需要重构这个类以避免静态字段。
我立刻想到了依赖注入和工厂模式。工厂将保持单个上下文,每个用户类都应该只使用该工厂创建数字实例。但是代码会很混乱,因为工厂应该被注入到每个想要构造“数字”实例的类中。
这个案子我可以用哪种模式?哪一个使我确信“数字”类的每个实例都使用单一共享状态?
P.S.:与这个问题有显著的相似之处-- 依赖注入;减少样板代码的良好实践。
发布于 2013-12-15 13:54:42
为此,我非常喜欢迈克尔·羽毛的“有效地使用遗产代码”一书。在这里,我将继续讨论并不同意gbjbaanb;测试对于遗留代码非常有用,但是您可能需要在比单个类更高的级别上来处理它。从编写功能测试开始:模拟出一个对象,通过系统发送它,并查看它在另一端是否如预期的那样出现。这一过程是痛苦的,但却是必要的。
一旦对要重构的代码部分进行了这种测试,就可以开始进行大规模的重构,比如将静态方法从测试的类中提取出来,然后开始扩展重构的范围。
发布于 2013-12-15 13:39:04
这取决于您在哪个平台上工作-- Microsoft有Moles (现在称为Moles),它允许您将程序中的对象替换为其他对象,这样就可以用特定于测试场景的对象替换单个对象。它的美妙和该死的景观更容易使用比破坏您的代码使用接口在任何地方,所以较小的单元测试系统可以工作。
但是,一般来说,对于遗留代码来说,TDD是不受欢迎的--正如我前面提到的,当编写用于测试驱动的代码时,您必须以某种方式对其进行编码。使用现有的代码库并不容易,因为它从来没有像这样编写过(我认为TDD编码方式是不自然的)。
我会忘记把DI之类的东西放进去,因为你只会使系统变得更加复杂和混乱。您可以更改类上的静态方法,删除静态方法,使构造函数设置默认值,并允许类设置不同的属性--但是,如果数字的静态始终是一个常量值,那么更改它的意义是什么,以便每个对象都携带状态而不是类?这样你就能用TDD了?当你这样做的时候,你带来的是更多的复杂性,而不是更少。
对于遗留代码,除了拆分部分并试图隔离它们之外,没有其他简单的方法。然后花时间了解系统的其余部分。这里没有银弹,你只要把手弄脏就行了。
https://softwareengineering.stackexchange.com/questions/221416
复制相似问题