Write tests as soon as you can. Preferably against the requirements (if they exist). Start with functional tests. Refactor in small chunks. Anytime you touch code, leave it cleaner and better than when you started.
I have seen, worked and am working in a codebase which satisfies all the conditions that is mentioned in the question :-)
The approach followed in maintaining this codebase is NOT TO BREAK ANYTHING. FWIW, the code works and the end users are happy. No one is going to listen to the developer cries that there is duplication of code, hard coded strings etc. We just steal some time to fix whatever possible and take the utmost care to not introduce new bugs..
But more seriously, I think it has to be evaluated. If the code continually is a source of requests for change and the changes are difficult then before long you have to consider if it is worth it to try and refactor/re-engineer the system into something more modern. Of course this isn't always practical, so you often end up with just a few people on the team who are responsible for maintaining the legacy parts. As much as possible, everyone on the team should be able to maintain all parts of the system......
One more thing that I think is important is to track the amount of time and effort that a team spends working on a legacy system doing maintenance/feature requests. These metrics can be convincing when evaluating the planning of a new effort to replace the legacy systems/components.
I basically agree with everything Paul C said. I'm not a TDD priest, but anytime you're touching a legacy codebase -- especially one with which you're not intimately familiar -- you need to have a solid way to retest and make sure you've followed Hippocrates: First, do no harm. Testing, good unit and regression tests in particular, are about the only way to make that play.
I highly recommend picking up a copy of Reversing: Secrets of Reverse Engineering Software if it's a codebase with which you're unfamiliar. Although this book goes to great depths that are outside your current needs (and mine, for that matter), it taught me a great deal about how to safely and sanely work with someone else's code.
发布评论
评论（7）
您需要Michael C. Feathers 所著的《有效处理遗留代码》一书。
You need the book Working Effectively with Legacy Code by Michael C. Feathers.
尽快编写测试。 最好符合要求（如果存在）。 从功能测试开始。 分成小块进行重构。 每当您接触代码时，请使其比刚开始时更干净、更好。
Write tests as soon as you can. Preferably against the requirements (if they exist). Start with functional tests. Refactor in small chunks. Anytime you touch code, leave it cleaner and better than when you started.
两件事情。
您完成此任务的速度可能很慢......通常，您应该“只是维护它”而不是修复它。
然而，在“学习如何维护它”阶段，您可以编写大量单元测试。
然后，当发现错误并请求增强时，您可以添加更多测试。
它是敏捷，应用于遗留。
Two things.
The rate at which you accomplish this may be slow.... Typically, you're supposed to "just maintain it" not fix it.
During the "learning how to maintain it" phase, however, you can write a lot of unit tests.
Then, as bugs are found and enhancements requested, you can add yet more tests.
It's Agile, applied to legacy.
我已经看到、工作过并且正在使用一个满足问题中提到的所有条件的代码库:-)
维护此代码库所遵循的方法是不要破坏任何东西。 FWIW，代码有效并且最终用户很满意。 没有人会听开发人员抱怨存在重复代码、硬编码字符串等。我们只是花一些时间来修复任何可能的问题，并极其小心地不要引入新的错误。
I have seen, worked and am working in a codebase which satisfies all the conditions that is mentioned in the question :-)
The approach followed in maintaining this codebase is NOT TO BREAK ANYTHING. FWIW, the code works and the end users are happy. No one is going to listen to the developer cries that there is duplication of code, hard coded strings etc. We just steal some time to fix whatever possible and take the utmost care to not introduce new bugs..
我想我会创建一小组最新信息：什么操作调用哪些函数等。
从那里，我会考虑重构。 重复的逻辑似乎是可以重构的东西，但请记住，
我认为最大的抵制冲动是“重建整个该死的东西！” 首先了解一下系统的概况，揭开这头野兽的神秘面纱。
I think I would create a small set of Up To Date information: What Action calls which functions etc.
From there, I would look at refactoring. Duplicated Logic seems to be something that could be refactored, but remember that
I think the biggest urge to resist is "Just rebuild the whole damn thing!" and get an overview of the system first, to demystify the beast.
sudo rm -rf /
但更严重的是，我认为必须对其进行评估。 如果代码持续成为更改请求的来源，并且更改很困难，那么不久之后您就必须考虑是否值得尝试将系统重构/重新设计为更现代的系统。 当然，这并不总是可行，因此团队中通常只有少数人负责维护遗留部分。 团队中的每个人都应该尽可能地维护系统的所有部分……
我认为另一件重要的事情是跟踪团队在遗留问题上花费的时间和精力系统进行维护/功能请求。 在评估替换遗留系统/组件的新工作的规划时，这些指标可以很有说服力。
sudo rm -rf /
But more seriously, I think it has to be evaluated. If the code continually is a source of requests for change and the changes are difficult then before long you have to consider if it is worth it to try and refactor/re-engineer the system into something more modern. Of course this isn't always practical, so you often end up with just a few people on the team who are responsible for maintaining the legacy parts. As much as possible, everyone on the team should be able to maintain all parts of the system......
One more thing that I think is important is to track the amount of time and effort that a team spends working on a legacy system doing maintenance/feature requests. These metrics can be convincing when evaluating the planning of a new effort to replace the legacy systems/components.
我基本上同意 Paul C 所说的一切。 我不是 TDD 牧师，但每当你接触遗留代码库时——尤其是你不太熟悉的代码库——你需要有一种可靠的方法来重新测试并确保你遵循了希波克拉底：首先， 不要伤害。 测试，特别是良好的单元测试和回归测试，是实现这一目标的唯一方法。
我强烈建议您获取一份逆向：逆向工程软件的秘密 如果它是您不熟悉的代码库。 尽管这本书的深入探讨超出了您当前的需求（就此而言，也超出了我的需求），但它教会了我很多关于如何安全、理智地使用别人的代码的知识。
I basically agree with everything Paul C said. I'm not a TDD priest, but anytime you're touching a legacy codebase -- especially one with which you're not intimately familiar -- you need to have a solid way to retest and make sure you've followed Hippocrates: First, do no harm. Testing, good unit and regression tests in particular, are about the only way to make that play.
I highly recommend picking up a copy of Reversing: Secrets of Reverse Engineering Software if it's a codebase with which you're unfamiliar. Although this book goes to great depths that are outside your current needs (and mine, for that matter), it taught me a great deal about how to safely and sanely work with someone else's code.