[修复bug导致的bug]为什么修复每个bug后都要问这3个问题？
你与否曾复原了两个 bug ，随即又辨认出了两个跟刚复原 bug 相关的 bug ，又或者复原 bug 的形式引发了另两个 bug ？当我修正 bug 时，就要问自己四个难题，以保证我已经细细考量了它的象征意义。每天你指出辨认出并修正了两个 bug 时，能采用那些难题来提升劳动生产率和标识符产品质量。
那些难题另一面的主要就价值观就是：每两个 bug 都是下层民主化的两个不当整体表现。你要处置那些病症，但如果你实际上是处置那些外在病症，你就会有总有一天化解不完的难题。你如果找出造成 bug 的民主化，因此复原那个民主化。当你确认到底出现了甚么和出现那些的其原因时，或许你就会知道造成 bug 的此基础民主化不是乱数的，而要受控的。
在问这四个难题前，你须要消除直面 bug 的这种与生俱来的感到恐惧，详细预测 bug 。查阅标识符并说明手忙脚乱的其原因，从能检视到的现像开始，向后预测，急速嗯为何，直至你能找出造成 bug 的商业模式。一般来说，你该跟同僚一同做整件事, 即使说明你指出会出现的事，将逼使你直面一些假定——那些流程是做甚么的。
它外溢了，即使负号J越境了。
为何？
J 是 10，但字符串串最小负号为 9。
为何？
J 是两个字符串串宽度，字符串串的初始负号是 0，所以字符串串宽度为 1 的最终两个字符串的检索是 0。
找出 bug 后，搜寻其他不幸情况。档案管理手忙脚乱时主要就的流程表达式的值，与否能说明那些值。
为何 name 是 null？
为何它总是输手忙脚乱误信息呢？
记录下你做了哪些操作，出现了哪些变化。你须要知道到底出现了甚么，这样做就意味着你时刻有一把标尺和历史记录。
当完成那些步骤后，你能准备问第两个难题了。
查阅标识符中采用相同商业模式的地方，系统地改变商业模式找出类似的 bug 。
我还在其他甚么地方采用宽度作为负号的吗？
所有字符串串的初始负号都一样吗？
对于两个宽度为 0 的字符串串会出现甚么？
试着描述这部分标识符中如果是正确的，但是那些 bug 没有遵循的规则。寻找那个不表达式 [ 1 ]的过程将帮助你找出其他潜在的 bug 。
初始偏移加上宽度减去1就是结束的负号，除非字符串串宽度为 0。
对于你辨认出的每两个 bug ，你都能化解一批 bug ，这是非常高效的。尝试用概括性的语言描述那些 bug 也能提升你对流程的理解程度，并帮助您避免在流程中引入更多的 bug 。
一旦你确认了如何复原那个 bug ，你就须要考量一下复原后会出现甚么。那个执行失败的语句后面的语句也可能有难题，但是流程还没有执行到此就不知道有没有 bug ，或者有些标识符即使你复原 bug 而第一次出现在流程中，那些标识符也可能有难题。查阅那些未执行的语句，检查标识符中的 bug 。
下一条语句会正常运行吗？
当你在想流程的控制流的时候，能弄清楚还有哪些地方流程没有执行到。
与否有我从来没有测试过的功能组合？
在流程中插桩（instrumentation）并不会耗费太多时间，在运行流程各个部分的过程中就能进行检查，但是你会惊讶地辨认出开发者测试过的标识符还有很多都不能正常运行。
我能测试出所有的错误信息吗？
注意两个地方的改动可能会引发其他地方的 bug 。一些表达式的局部改动可能会在执行时违反后来的假定。
如果仅是从 J 中减去 1，当宽度为 0 时，后面的语句会操作字符串串中 -1 位置的元素。
如果流程已经做了大量改动，就要细细考量与否有必要增加另外两个补丁，或者是时候考量重新设计和重新实现了。
（有时候调 Bug 就是这样的）
问问自己如何改变编程方法，根据定义避免 bug 的出现，通过改变方法或者工具，经常能移除整个类的错误而不用两个两个的化解 bug 。
如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣能175317069，群内会有不定期的发放免费的资料链接，那些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料能私聊发我，就要注明出处之后分享给大家。
从 bug 是何时引入的那个难题开始：在流程开出现命周期的哪两个阶段能阻止 bug 的造成？
设计是没难题的；我在编程时引入了 bug 。
细细检查 bug 造成的其原因，考量 bug 造成时正在运行的民主化，并想想怎么改变它来阻止 bug 的造成。
将偏移的数据类型和宽度分离出来将会在编译时捕获那个错误。
每两个文本项能用隐藏了负号计算的宏输出，然后我就能一次找出它。
不要满足于肤浅的答案。假如你对于两个 bug 的说明是，我记不清了，那还怎么改进那个过程，让你不再须要记住它？你能更改编程语言，使被忽略的细节能完全隐藏，否则你遗漏的部分会被检测到从而引致编译难题。对那个难题域，你可能采用了预处置器或者智能的编辑器，有默认值，错误检查，智能提示和快速文档。那个 bug 可能是编程团队沟通的难题，亦或者须要讨论的设计冲突。
思考辨认出 bug 的形式，并问问自己如何能更早辨认出它。测试怎么能更严密一些？能否进行自动化测试？与否要添加标识符实时检测功能，以便能及时捕获错误信息？
我如果在我的测试单元中尝试宽度为 0 的字符串串。
我如果进行负号检查，提前捕获不符合的负号。
有必要创建一些系统方法和自动化工具，用于编译、构建和测试，它们能减少长时间的调试和查明具体事实的过程。
养成这样一种习惯：每当你辨认出两个 bug 时，问自己这四个难题，甚至你不必等到有 bug 时才采用这四个难题。
在设计和审查过程中，你都能用这四个难题来处置你得到的每一条意见。审阅意见是潜在的沟通过程的结果，使你能有所改进。如果你指出读者评论是错误的，比如，你可能会问是甚么使你的文章没被理解，如何更好地与审稿人沟通。
设计评审和标识符审查是找出 bug 的强有力手段，你能对审查过程出现的每两个缺陷都提出四个难题。如果审查彻底，前两个难题不会出现太多新的 bug ，但第四个难题能帮助你找出方法，用来避免未来可能会出现的 bug 。
您的关注是我前进的动力，私信【资料】有惊喜哟！
