调试Web运用的准则
不管编码能力如何，我们都会出错。不但自己代码中会有bug，多数的web运用是由团队创建的，所以队友和你一样，都有可能出错。另外，接手遗留代码意味着同时继承了其它团队的bug。在此情况下，调试技能就派上用处了。
花点时间和精力去提升调试能力是值得的。我会介绍1些小诀窍来拓展你的调试技能，也会给出一些建议，以便更容易的定位bug。
本文主要是关于调试原则的，不会深入具体的技术细节，也不会探索有关浏览器和开发工具的技能。下篇文章会更加专业，介绍实际操作中运用的调试工具。
了解成果
最重要的调试工具就是你的想法。我可以告知你很多调试技能，但是只有在你具有足够的特定知识，可以在上下文使用它们的情况下才会对你有所帮助。在你知道问题是什么之前，不要尝试使用这些技能。
调试工具的目的是验证假定。最重要的是首先要知道代码应当做甚么。
如果你发现自己已在代码的不同位置插入了10个断点，那末你就错了。如果你知道问题在哪的话，你就应当知道在哪里插入断点。消息记录也是一样的。如果有10条不同的消息，你也没法确认你在找甚么。做做作业，试着用不履行代码就能理解它。
履行环境很有帮助
编写可测试的代码。假定你常常给代码做单元测试，那末你应当可以创建业务对象并且在履行环境中调用它们的方法。最简单的履行环境是你选择的开发工具。你可以使用控制台创建对象，调用它们的方法。在Mocha,Chai和SinonJs可用的调试模式下，如果运用可以使用的话也很有帮助。
开发团队的基本训练应当包括练习如何使用运用的对象。
履行环境可以有多种用处：
-通过视察特定输入所对应的输出结果，验证代码的构思模型
-对方法进行黑盒测试来验证你所推断的fault
-重现failure场景
改正缘由，而不是表象
在前面的部份，我特地使用了fault和failure这两个单词。如果你不知道fault、error和failure之间的区分，可以读读此文的“Fault，error，failure”部份。
人类健康和修补bug很类似。好比一个名叫John的病人因缺少维他命而感冒了。医生告知他服用扑热息痛来减缓症状。扑热息痛隐藏了很多的症状，直到John好起来。感冒好了以后，John仍旧不会想着去改变自己的饮食。
这中情况在代码上就体现为设计糟的意大利面条代码（指那些结构上完全不可理解的系统）。这里的“病症”就是没有完全理解代码的开发者写出来的fault。假定这个bug造成了�的损失，公司会给开发团队施压以即刻修复bug。开发者们快速的了解bug的表现然后用“扑热息痛”来对付：
varparacetamol=function(erroneousValue){
//...herebehacks...
returngoodValue;
}
//Beforethefailuresurfaces:
if(isFailureVisible){
state[erroneousKey]=paracetamol(state[erroneousKey]);
}
和发高烧一样，在紧急的情况下，病症需要即刻处理。这类修补方式看起来起作用了，所以开发者就将它用到产品中。多数情况，造成bug的缘由却被忽略了。这会造成甚么问题？
从长时间的角度看，扑热息痛会破坏人体的肝细胞。只解决表象问题的代码会摧毁软件的可维护性。我们应当抛弃快速修补的想法，而去正确修补造成bug的真正缘由。
如果bug不紧急的话，一定要查找bug缘由。确保你完全理解了failure、error扩大和实际的fault，并且修补fault要遵照业务对象的作用和职责。例如，在根据MVP模式编写的代码中，千万不要在presenter中修改model的毛病。
假定代码很难调试或修改，那末可以斟酌重构代码。这就触及下一部分的内容了。
调试困难的代码需要重构
当开发者觉得测试、调试、更改代码困难时，就要斟酌重构了。重构的好处在于保持功能相同，又可以提升代码的可维护性。
设计糟的代码有以下特点：
WET代码（WeEnjoyTyping）
不清晰的作用和职责
冗杂的方法、高循环复杂度
糟的或不清楚的命名
相同类多个方法中有重复的switch语句，涉及到该类的不同子类
如果代码难以理解，那末终究一定会产生bug。即便是利益相干者都应当知道新特性和可维护性之间比例公道的必要性。修复你了解的fault总比调试可读性糟的failure本钱要低。
一次测试一条假定
回想一下你不得不对代码做出假定，来看看哪里出错了。一点控制台日志和断点就可以测试你的假定。或你可以在报错的上下文中插入一个断点，然后用开发工具的控制台创建一个履行环境。
当假定证明是毛病的，就要在验证下条假定前清算断点和控制台日志。如果你以后想要回顾这些日志和断点，可以用Git储存。
gitstashsaveShortDescriptionOfAssumption
日志和断点的注释没有意义，由于你不知道哪一个调试声明是属于哪一个假定的。
一旦调试器声明和日志堆在代码中，它们通常会干扰你。这类干扰会使你从定位bug的清晰思惟中分散注意力。
测试驱动的bug修复
一种再现bug的方法是基于bug描写编写失败的测试用例。即便测试通过了，你也不是在做无用功：这个测试也减少了运用的bug。最后你总会找到试错用例，捕捉到failure。
回溯毛病扩大，定位毛病。当你理解了毛病的缘由后，用试错用例进行测试。这些测试会指引你修补fault。测试的最大好处是，只要坚持在每次部署前都履行单元测试，一样的bug就再也不会在产品中出现。
不要在产品上调试
我曾听说不愉快的事，产生在由于一些特殊数据只能在实际的数据库中找到，而在产品上调试代码时。这是很外行的行动。
像这种情况下，可以参考以下方法应对。
如果开发者有实际数据库的权限，复制数据库是一种选择。在一些情况下，这会花费很长的时间。解决方法是可以用专门的转储脚本只复制相干数据到开发者的数据库。
也有可能开发者对一些敏感数据没有权限。这种情况下糟的惯例是每当bug严重伤害公司利益时，开发者便会收到一份临时报告。任何解决方式都比这类好。可以是创建同类匿名数据的转储脚本，或是一系列精确的bug报告，给开发者足够的数据和追加问题的机会。你的开发团队应当时刻有应对紧急情况的计划。
疏忽权限的问题，要确保开发环境的数据库和产品中同量级的最新数据保持定时更新。这不仅有助于再现bug，对定位性能瓶颈也有帮助。
作为1名前端开发者，你可能会遇到只在特定装备或浏览器下出现的bug。或adblocker软件会阻碍你的AJAX要求。尽量多的搜集环境信息，同时确保可以和遇到问题的用户进行沟通。
要捕捉只在特定环境下出现的bug，更主动的方法是使用一款毛病追踪运用，比如SherlogJs。毛病会在用户斟酌给你发送bug报告之前出现在你的仪表盘上。有许多bug从不会上报，所以这是捕捉这些failure的唯一方法。
Bug没法在开发环境再现还有另外一个缘由。额外的库和附加服务可能会迫使你在产品上搜集信息。修补这些bug需要专门的支持和与其它团队间的良好合作。建立不依赖产品环境就可测试的服务总是很重要。
总结
基于bug描写再现bug后，思考一下哪一个地方错了。构想出假定并且研究代码。你应当清楚的知道哪一个类和哪一个方法可能会遭到影响。运用相干的业务对象来验证你关于代码和bug的假定。当使用对象或调试时，一次性只核实一条假定来排除干扰项。修改fault，而不是failure。如果调试或修复很苦难，可以斟酌重构代码。确保你修补后的代码全面的测试过。在failure很难重现的情况下，斟酌升级基础设施以支持局部调试。
此文就要结束了，我没有论述调试器声明如何生效，或应当如何使用浏览器的开发者工具，希望你没有失望。调试不但仅是工具。希望你可以收获一些有用的观点，更加善于捕捉bug。如果你对调试工具感兴趣，请看下篇文章。
皮肤病治疗最好的医院北京主治白癜风医院