我的意思并不是说为新系统编写测试，而是编写在旧系统上传递并将通过新系统的测试。这将是您验证是否已重新创建原始功能的方式。我认为在一个已经存在的系统中，您可以很容易地（尽管很乏味）创建 可以在 BDD 中执行的功能规范 a> 风格。
The most important thing will be automated verification (aka unit/functional tests). Please see this question. As a lot of the advice will be simillar.
By this I don't mean writing tests for the new system, I mean writing tests that pass on the old system and will carry through the new system. This will be how you will verify that you've recreated the original functionality. I think in a system that already exists you could quite easily (though tediously) create functional specs that could be executed in the BDD style.
I'd say a common pitfall is trying to fix things that are not broken. Think about how you can re-use the existing software w/o re-inventing it. If it's been around for a long time, it may be because it worked really well. You will have a big task ahead of you to match the functionality w/o introducing new bugs.
Then again, it may be because your company outgrew this legacy system. Think about why you are asked to re-architect this and what limitations the old stuff had that you need to solve.
Michael Feathers：有效地处理遗留代码介绍了许多可使用的技术，并替换遗留代码。我发现它很有可读性；有些方法（以及许多技巧）对我来说是新的。
Michael Feathers: Working effectively with legacy code presents a number of techniques to work with, and replace, legacy code. I found it quite readable; some of the methods (and many of the hacks) were new to me.
Consider your goals carefully. Are you just interested in replacing the COM foundations? Are you also going to change data base implementations (e.g, from indexed to SQL?) Screens (from GUI to Web?) ...?
If this is a very small application, it might be possible to rewrite it by hand completely. If it is modest size, you might be able to modify the existing application (presumably to replace the COM facilities with some other equivalent scheme). If this is medium to large, you will not practically be able to rewrite or modify it reliably within a reasonable time frame.
For such large scale changes, you may want to consider automating the changes. A tool for implementing such changes can be found here: DMS Software Reengineering Toolkit. Using DMS, for a customer with 800K SLOC of C++ code, we implemented most of a C++ to C# translator that replaced the COM interfaces with equivalent C# facilities (a birdcage management shuffle about 3/4 of the way through the project killed interest in the translator in spite of its near completeness).
One thing to consider while you do this: keep focus on modernizing the application without changing the functionality. Often management can't resist scope creep ( "well, while we're in there, lets change the applicaiton to do ...") which is the road to disaster. Remember, making all the changes that lead to the current one took years.
The most important advice I can give is to re-spec the system. Without a fresh set of expectations for what you will deliver, you will be held to the standards of the old system. Those standards can't be great, or else you wouldn't be rewriting it.
Determine, from the people using the current system, what they are actually trying to accomplish, and built that, rather than a straight port. Everyone involved will be better off in the long run.
Short of that, don't try to add features during this process. That opportunity will come after you have re-architected the application. There is nothing worse while doing a port than taking on a new requirement which contradicts existing functionality.
Remember that, as you deploy the newly re-architected system you are most likely going to have to convert or port a whole heap of data from the old, to the new. Consider this as you go because that job alone could become as big as your rewrite if you don't. Not converting well, reliably or efficiently could doom you new system from day 1, even if the functionality is spot on.
发布评论
评论（6）
最重要的是自动验证（也称为单元/功能测试）。请参阅此问题。因为很多建议都是相似的。
我的意思并不是说为新系统编写测试，而是编写在旧系统上传递并将通过新系统的测试。这将是您验证是否已重新创建原始功能的方式。我认为在一个已经存在的系统中，您可以很容易地（尽管很乏味）创建 可以在 BDD 中执行的功能规范 a> 风格。
The most important thing will be automated verification (aka unit/functional tests). Please see this question. As a lot of the advice will be simillar.
By this I don't mean writing tests for the new system, I mean writing tests that pass on the old system and will carry through the new system. This will be how you will verify that you've recreated the original functionality. I think in a system that already exists you could quite easily (though tediously) create functional specs that could be executed in the BDD style.
我想说一个常见的陷阱是试图修复没有损坏的东西。考虑如何重新使用现有软件而不需要重新发明它。如果它已经存在了很长时间，那可能是因为它效果非常好。您将面临一项艰巨的任务，即在不引入新错误的情况下匹配功能。
话又说回来，这可能是因为您的公司已经无法满足这个遗留系统的需求。想想为什么你被要求重新构建这个，以及旧的东西有哪些限制你需要解决。
I'd say a common pitfall is trying to fix things that are not broken. Think about how you can re-use the existing software w/o re-inventing it. If it's been around for a long time, it may be because it worked really well. You will have a big task ahead of you to match the functionality w/o introducing new bugs.
Then again, it may be because your company outgrew this legacy system. Think about why you are asked to re-architect this and what limitations the old stuff had that you need to solve.
Michael Feathers：有效地处理遗留代码介绍了许多可使用的技术，并替换遗留代码。我发现它很有可读性；有些方法（以及许多技巧）对我来说是新的。
Michael Feathers: Working effectively with legacy code presents a number of techniques to work with, and replace, legacy code. I found it quite readable; some of the methods (and many of the hacks) were new to me.
仔细考虑你的目标。您只是对替换 COM 基础感兴趣吗？您是否还要更改数据库实现（例如，从索引到 SQL？） 屏幕（从 GUI 到 Web？）...？
如果这是一个非常小的应用程序，则可能可以完全手动重写它。如果它的大小适中，您也许能够修改现有的应用程序（大概用其他一些等效方案替换 COM 设施）。如果这是中型到大型的，您实际上将无法在合理的时间范围内可靠地重写或修改它。
对于如此大规模的更改，您可能需要考虑自动化更改。可以在此处找到用于实施此类更改的工具：DMS 软件重新工程工具包。使用 DMS，对于拥有 800K SLOC C++ 代码的客户，
我们实现了 C++ 到 C# 转换器的大部分内容，用等效的 C# 设施取代了 COM 接口（项目进行到 3/4 时，鸟笼管理洗牌消除了人们对转换器的兴趣，尽管它接近完整）。
执行此操作时需要考虑的一件事是：在不更改功能的情况下专注于应用程序的现代化。通常，管理层无法抗拒范围蔓延（“好吧，当我们在那里时，让我们更改应用程序来执行......”），这是通往灾难的道路。请记住，导致当前变化的所有改变花费了数年时间。
Consider your goals carefully. Are you just interested in replacing the COM foundations? Are you also going to change data base implementations (e.g, from indexed to SQL?) Screens (from GUI to Web?) ...?
If this is a very small application, it might be possible to rewrite it by hand completely. If it is modest size, you might be able to modify the existing application (presumably to replace the COM facilities with some other equivalent scheme). If this is medium to large, you will not practically be able to rewrite or modify it reliably within a reasonable time frame.
For such large scale changes, you may want to consider automating the changes. A tool for implementing such changes can be found here: DMS Software Reengineering Toolkit. Using DMS, for a customer with 800K SLOC of C++ code,
we implemented most of a C++ to C# translator that replaced the COM interfaces with equivalent C# facilities (a birdcage management shuffle about 3/4 of the way through the project killed interest in the translator in spite of its near completeness).
One thing to consider while you do this: keep focus on modernizing the application without changing the functionality. Often management can't resist scope creep ( "well, while we're in there, lets change the applicaiton to do ...") which is the road to disaster. Remember, making all the changes that lead to the current one took years.
我目前正在做几乎完全相同的事情。
我能给出的最重要的建议是重新规范系统。如果对您将交付的内容没有一套新的期望，您将被迫遵守旧系统的标准。这些标准不可能很好，否则你就不会重写它。
从使用当前系统的人那里确定他们实际上想要实现的目标，并构建这个目标，而不是直接端口。从长远来看，每个参与其中的人都会受益匪浅。
除此之外，不要尝试在此过程中添加功能。在您重新构建应用程序之后，这个机会就会出现。在进行移植时，没有什么比接受与现有功能相矛盾的新需求更糟糕的了。
I am currently doing almost this exact thing.
The most important advice I can give is to re-spec the system. Without a fresh set of expectations for what you will deliver, you will be held to the standards of the old system. Those standards can't be great, or else you wouldn't be rewriting it.
Determine, from the people using the current system, what they are actually trying to accomplish, and built that, rather than a straight port. Everyone involved will be better off in the long run.
Short of that, don't try to add features during this process. That opportunity will come after you have re-architected the application. There is nothing worse while doing a port than taking on a new requirement which contradicts existing functionality.
请记住，当您部署新架构的系统时，您很可能必须将整个旧数据堆转换或移植到新系统。边走边考虑这一点，因为如果你不这样做，这项工作本身就可能变得和你的重写一样大。如果转换不顺利、可靠或高效，您的新系统从第一天起就可能会失败，即使功能是正确的。
Remember that, as you deploy the newly re-architected system you are most likely going to have to convert or port a whole heap of data from the old, to the new. Consider this as you go because that job alone could become as big as your rewrite if you don't. Not converting well, reliably or efficiently could doom you new system from day 1, even if the functionality is spot on.