问当被要求修复程序中的错误时，您会发现超过100个实例

EN

这在一定程度上取决于你能有多积极。这个应用是内部的还是外部的？您的更改很快就会部署到实时系统上吗？您是否有特定的bug需要修复，或者只是被认为是一场灾难？

为了尽可能快地减少bug数量，但具有最大的严重损害风险，只需删除所有catch块，并让异常冒泡。要获得更精细的方法，只需添加日志记录即可。

如果可能的话，你也应该和写这个应用程序的人谈谈。试着找出为什么他们有这么多的异常吞噬块。他们真的理解异常吗？我怀疑，这里需要一定的机智:)

下一站:单元测试...

修复你要做的bug，并将吞噬代码块的异常报告为新的、严重的bug。

第一个中间目标是很好地了解哪些异常被忽略以及在哪里被忽略；为此，您可以简单地将日志记录代码添加到每个可怕的catch-everything块中，从而准确地显示它是什么块，以及它捕获和隐藏了什么。在这样插入指令的代码上运行测试套件，您将拥有修复作业的起始“蓝图”。

如果您没有测试套件，那么，首先，创建一个测试套件--单元测试可以等待(查看使用遗留代码的Feathers' great book --遗留代码肯定是您的问题所在；-)，但是您需要一套可以自动运行的集成测试，并且可以修复您应该修复的所有bug。

当你去修复一个又一个的bug时(许多错误不是由过宽的catch块引起的，只是被它们隐藏/“推迟”了；-)，确保以一种主要“测试驱动”的方式工作:添加一个记录bug的单元测试，确认它被破坏，修复bug，重新运行单元测试以确认bug已经消失。你不断增长的单元测试套件(所有可能的东西都是模拟的或伪造的)将运行得很快，你可以在工作时保持低成本地重新运行，以捕捉可能的回归ASAPs，当它们仍然很容易修复的时候。

分配给您的任务实际上比“高声望”的软件开发任务(如原型和新体系结构)更难(而且往往更重要)，但经常被误解和低估(因此奖励不足！)管理/客户；确保与利益相关者保持非常清晰和开放的沟通渠道，指出你正在做的大量成功的工作，它有多么具有挑战性，以及(为了他们而不是你自己)，他们从一开始就可以节省多少(也许下一次他们会...我知道，我天生就是一个狂热的乐观主义者；-)。也许他们甚至会在任务中为你指派一个合作伙伴，然后你就可以进行代码审查和结对编程，从而极大地提高生产力。

最后但并非最不重要的是，祝你好运！--不幸的是，你需要它...幸运的是，正如杰斐逊所说，“我工作越努力，我似乎就越幸运”；-)