Martin Fowler说我们应该在添加新功能之前进行重构(假设原始程序结构不合理).
所以我们都想重构这个脏代码库,这是肯定的.我们也知道,如果没有单元测试代码,很容易引入细微的错误.
但它是一个庞大的代码库.添加一整套测试似乎是不切实际的.
在这种情况下你会做什么?
我的建议是尽可能少地触摸并添加你需要的东西.我发现最好留下足够好的,特别是如果你在一个紧迫的截止日期.
如果您进行过单元测试,那将是一个不同的故事,但是当您更改代码时,它可能就像触摸蜘蛛网一样.改变一件事会影响其他一切.
让我推荐Michael Feathers 的" 有效使用遗留代码 "一书.它包含许多实际示例,并展示了处理遗留代码野兽的良好技术.
将单元测试添加到要重构的代码中.
请参阅Repose涓流理论中的Rands,了解他遇到大量漏洞时遇到的类似问题.他的建议:
我的建议是:START
当单元测试不存在或非常难以在给定的时间范围内添加适当的覆盖时,您将不得不依赖于常规测试.理论上,你所谈论的这个庞大而肮脏的代码库已被认为适合现在使用一段时间.为了做出这个决定,有程序员测试,QA测试或客户进行的某种测试.你想知道它是如何完成的,做了什么,如果它足以涵盖你将做出什么改变,然后得到承诺再次完成,再加上新代码需要的任何测试,直到产品好足够.
单元测试对于程序员来说是一项很好的服务,但它们并不是唯一一种测试.