dbcc 错误修复_修复错误就像抓鱼

dbcc 错误修复

经理：那么，修复此错误需要多长时间？

没有经验的程序员：也许一个小时？ 两个上衣？ 我马上就做！

经验丰富的程序员：好吧， 钓到鱼要花多长时间 ？

很难知道要花费多长时间来修复错误，尤其是如果您不知道代码的话。 詹姆斯·肖尔（James Shore）在《敏捷的艺术》中指出，很明显，在修复某些问题之前，您必须找出问题所在。 问题是您无法准确估计找出问题所在需要多长时间。 只有在知道出了什么问题之后，您才可以合理估计修复该问题所需的时间。 但是到那时为时已晚。 史蒂夫·麦康奈尔 （ Steve McConnell）表示， “发现缺陷并加以理解通常是90％的工作。”

许多错误修复仅是一行更改。 需要时间的是弄清楚改变的正确路线-例如知道在哪里敲击锤子，或者什么时候和什么地方在咬鱼。 一些错误很容易找到并且易于修复。 有些错误很难找到，但易于修复。 其他错误很容易发现并且很难修复。 而且根本找不到一些错误，因此可能无法修复。 除非您最近编写了代码，否则您可能不知道要求您处理哪种错误。

查找和修复错误

让我们看看发现和修复错误所涉及的内容。 在调试中！ Paul Butcher用经验丰富的程序员熟悉的结构化和规范的方法，很好地描述了您需要执行的步骤：

1. 确保您知道要查找的内容。 查看错误报告，看看它是否有意义，确保它确实是一个错误，并且您有足够的信息来找出问题并重现。 检查它是否已被报告为重复项，如果是，则检查您之前采取的措施（如果有的话）。
2. 清理甲板–找到并检查正确的代码，清理工作空间。
3. 设置您的测试环境以使其匹配。 如果客户在您无权访问的配置上运行，这可能是微不足道的，甚至是不可能的。
4. 确保您了解代码应该执行的操作，并且现有的测试套件可以通过。
5. 现在该去钓鱼了。 重现并诊断该错误。 如果无法复制，则无法证明已修复。
6. 编写新的（失败的）开发人员测试或修复现有的测试以捕获该错误。
7. 解决问题，并确保您没有破坏其他任何东西。 这可能包括一些重构工作，以便在进行修复之前更好地理解代码，以便可以安全地进行操作。 然后进行回归测试，以确保您没有引入任何新的错误。
8. 如果可以的话，请尝试使代码更安全，更简洁，并逐步进行重构。 至少要确保您不会使代码变得更脆弱，更难于通过您的修复程序来理解。
9. 请其他人审查此修补程序，以确保您没有做任何愚蠢的事情。
10. 检查修复。
11. 如果您不是从主线工作的，请检查是否需要在其他任何分支中修复此错误。 合并更改，处理代码中的差异，然后再次进行所有相同的检查和测试以及其他工作。
12. 停下来想一想。 您了解问题出在哪里，为什么？ 您了解您的修复程序为何有效吗？ 您还应该在哪里寻找这种错误？ 在《实用程序员》中 ，安迪·亨特（Andy Hunt）和戴夫·托马斯（Dave Thomas）还问“如果修复此错误花了很长时间，请问自己为什么”，以及如何使将来的此类调试问题更容易？ 您如何改善所采用的方法或所使用的工具？ 您可以深入研究的深度取决于错误的影响和严重性以及您有多少时间。

需要更长的时间，查找错误或修复错误？

设置测试环境，重现问题或对其进行测试所需的时间可能远远超过了在代码中查找并修复问题所花费的时间。 但是对于少数错误而言，找到它所用的时间并不长，而是修复它所涉及的内容。

在制作软件中， 大多数软件缺陷从何而来？ ，Dewayne Perry分析了查找错误（理解并重现错误）与修复该错误所需的时间相比有多难。 该研究发现，大多数错误（几乎3/4）易于理解和发现，并且不需要花费很长时间来修复：5天或更短的时间（这是在具有重量级SDLC的大型实时系统上，评论和测试）。 但是有很多bug可能需要花费更长的时间才能修复，即使是很难发现的bug：

查找/修复工作	<= 5天修复	> 5天修复
问题可以重现	72.5％	18.4％
难以复制或无法复制	5.9％	3.2％

因此，当您发现一个容易修复的错误时，您可以打赌。 而且大多数时候你都是对的。 但是，当您错了时，您可能会错很多。

在后续文章中，我将更多地讨论复制，查找和修复错误所涉及的问题和成本，以及如何（或是否）估算错误修复。

参考： 修复错误就像在Building Real Software博客上从JCG合作伙伴 Jim Bird 抓到一条鱼一样 。

翻译自: https://www.javacodegeeks.com/2012/07/fixing-bug-is-like-catching-fish.html

dbcc 错误修复