管理回归
我本质上是一个冲动的程序员，并开始在编程中通过艰苦的方式学习耐心的美德。我表现不佳的领域之一是当我修改现有代码时。如果我没有把所有的细节都摆在我面前，我总是会错过某些有时会导致倒退的途径。在我阅读“实现模式”之前，我在编码方面还不错，但低估了代码的维护。
所以，我的问题是，如果您要维护现有代码，如何覆盖所有基础并确保不会留下坑洼？当您不确定代码可能在哪里损坏时，您会使用什么策略？
I'm an impulsive coder by nature and have started learning the virtue of patience the hard way in programming. One of the areas I fare badly is when I'm modifying existing code. If I don't have all the details laid out before me I invariably miss certain avenues that sometimes lead to regression. I'm okay in coding but underestimated maintenance of code until I read "Implementation Patterns".
So, my question is if you're maintaining existing code how do you cover all the bases and make sure you're not leaving potholes behind? What are the strategies you use when you're not sure where the code may break?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
简而言之，单元测试。您需要测试覆盖率来确保在进行更改时，可以重新运行测试并确保没有破坏任何内容。
如果您有持续集成，那么这将在您签入时显示。我会尽早/经常签入，以确保您的更改很小，并且您可以轻松跟踪原因错误。
令人头痛的是对现有框架进行单元测试改造。您可能需要重新设计一些现有的库才能允许依赖注入和< a href="http://en.wikipedia.org/wiki/Mock_object" rel="nofollow noreferrer">嘲笑。不幸的是，仅仅进行这些更改并非没有风险，这一切都意味着尽早编写测试（并将代码设计为测试友好）。
Unit tests, in brief. You need test coverage to ensure that when you make changes, you can rerun the tests and ensure that you've not broken anything.
If you have a continuous integration, then this will show up as/when you check in. I would check in early/often to make sure that your changes are small, and that you can easily track the causes of bugs.
The headache is retrofitting unit tests to an already existing framework. You'll probably have to reengineer some of the existing library in order to permit dependency injection and mocking. Unfortunately just making those changes is not without its risks, and this all points to writing the tests (and engineering your code to be test-friendly) as early as possible.
如果你能找出一些边缘情况，你就可以编写一些单元测试。然后，修改后，您可以检查以确保测试仍然通过。
这不是万无一失的，但总比没有好！
If you can figure out some edge cases, you can write some unit tests. Then, after the modifications, you can check to make sure that your tests still pass.
It's not fool proof, but it's better than nothing!
简而言之，单元测试。编写单元测试的好处之一是它可以使重构/以后的代码更改更安全，并让人们更有信心这些更改没有破坏任何东西。
将其与持续集成环境联系起来，在该环境中，最新的代码会定期从源代码控制中提取、构建，然后运行所有单元测试，如果任何代码更改破坏了构建，您将以自动方式获得非常快速的反馈。
Unit testing, in a nutshell. One of the benefits of writing unit tests is that it can make refactoring/later code changes safer and give more confidence that those changes haven't broken anything.
Tie this in to a Continuous Integration environment, where the latest code is periodically pulled out of source control, built and then all the unit tests run, and you have pretty quick feedback in an automated fashion if any code changes break the build.