如何更新奇怪的应用程序而不会出现相同的错误?

时间:2009-10-07 09:26:28

标签: design-patterns

我的新项目是更新客户多年使用过的软件。 就像我们都知道的那样......多年来事情都在增长。

所以我看了一下旧的应用程序。得到所有关于它的信息,并写下了很多用户故事。 清理后,我意识到我(最终)犯了一个错误,导致了客户现在遇到的同样问题。

这是一个不同的错误我做了但真的很烦人。

你们怎么防止这样的错误。你拒绝看旧的应用程序吗?

5 个答案:

答案 0 :(得分:2)

这是一个非常难的问题。如果旧代码非常大,我会描述我会做什么(并且已经做过)。

通常,旧代码充满了决策,错误修复和无证件行为。如果你抛弃它,你必然会犯下许多同样的错误,然后再犯更多错误。

对于它的价值,你应该演变系统围绕旧代码。尝试从旧代码中抽象出来,例如,通过创建接口,然后通过首先调用旧代码来实现它们。为接口编写大量单元测试,并获得有关旧代码如何工作的知识。新功能应该获得新的实现,因此旧代码和新代码将并存,只要需要,甚至可能永远存在。

现在,慢慢地,小心地入侵旧代码,重构它,替换它,并确保你的测试仍然通过。也写下新的测试。如果你有系统的回归测试(除了单元测试),他们仍然需要通过。

没有触及旧代码是可以的,通常如果它正常工作,没有报告错误,它通过了测试,并且不需要扩展。

一些好的资源:

http://martinfowler.com/bliki/StranglerApplication.html

Working Effectively with Legacy Code

我已经在StackOverflow中找到了它:

Strategy for large scale refactoring

答案 1 :(得分:0)

单元测试。但如果你之前没有进行单元测试,他们就不会帮助你。

答案 2 :(得分:0)

这个问题听起来像是通过“清理”来修改现有代码,而不是重写它。该过程有时被称为“重构”。 Martin Fowler写了一本关于重构的好书,名为“Refactoring”。他首先给出了对实际代码进行重构的具体示例,并将关于他正在使用的特定技术的未来章节链接到代码旁边。

他所说的关于重构的第一件事就是编写一个测试来测试你正在改变的代码对一些常见的输入集做同样的事情。然后,当您“重构”代码时,对其运行测试以确保它的功能完全相同。这可以是pre-bugfix或post-bugfix。但是如果有错误,当然除了重构之外你还要压缩它。

答案 3 :(得分:0)

为什么要从头开始重写?您可以重用现有应用程序的一部分并重构那些需要更改的部分。

答案 4 :(得分:0)

当我重新创建已经完成的事情时,我会尽量避免查看已有的实现。我试着把注意力集中在它应该完成的事情上,而不是看它是如何实现它的。