我是一个冲动的编码器，并且已经开始在编程中学习耐心的美德。我糟糕的一个方面是当我修改现有代码时。如果我没有摆在我面前的所有细节，我总会错过某些有时导致回归的途径。在编写“执行模式”之前，我没有编写代码但是低估了代码的维护。
所以，我的问题是，如果你维护现有代码，你如何覆盖所有基础，并确保你不会留下坑洼？当您不确定代码可能会破坏的位置时，您使用的策略是什么？
答案 0 :(得分：4)
单元测试，简而言之。您需要测试覆盖率以确保在进行更改时，您可以重新运行测试并确保您没有损坏任何内容。
如果您有持续集成，那么这将显示为/您在办理登机手续时。我会提前/经常检查以确保您的更改很小，并且您可以轻松地跟踪错误的原因。
令人头疼的是将单元测试改造为现有的框架。您可能需要重新设计一些现有的库才能允许dependency injection和mocking。不幸的是，只是进行这些更改并非没有风险，而且这一切都指向尽可能早地编写测试（以及设计代码以使测试友好）。
答案 1 :(得分：0)
如果你能找出一些边缘情况，你可以编写一些单元测试。然后，在修改之后，您可以检查以确保您的测试仍然通过。
这不是万无一失的，但总比没有好！
答案 2 :(得分：0)
单元测试，简而言之。编写单元测试的好处之一是它可以使重构/后来的代码更改更安全，并使这些更改没有破坏任何内容更有信心。
将其绑定到持续集成环境，其中最新代码定期从源代码控制中取出，构建然后运行所有单元测试，如果任何代码更改破坏了构建，您将以自动方式快速获得反馈