网站前后台,修改wordpress用户密码,网站打不开dns修改,WordPress判断设备大家好#xff0c;我是Z哥。可以不夸张地说#xff0c;程序员可能有一半的时间都在修bug。虽说#xff0c;根据28原则大部分bug都可以在搜索引擎上搜到#xff08;业务性bug除外#xff09;#xff0c;但是往往剩下的那20%bug会花费我们80%的时间。虽然解决这个问题最好的… 大家好我是Z哥。可以不夸张地说程序员可能有一半的时间都在修bug。虽说根据28原则大部分bug都可以在搜索引擎上搜到业务性bug除外但是往往剩下的那20%bug会花费我们80%的时间。虽然解决这个问题最好的是方式减少产生bug但是再怎么减都不可能减到0我们还是有必要提高自己Debug的效率。因为在Debug方面水平高的人可能在效率上能领先至少一个数量级。我在这个行业从业将近9年我见过太多这样的案例了。网上也流传过一个传播度很高的案例有一个阿里内部的团队排查好几天未果的一个问题去请教多隆大神分分钟就搞定了。很多人的Debug能力之所以长期止步不前在我看来主要原因是两个。一是对IDE的功能不够了解只会用平时一直在用的基础功能。二是没有掌握一个合理的Debug思路属于“运气型”选手。不同的编程语言主流的IDE都不同所以我主要就第二点展开说说我的经验。有些经验的程序员都知道Debug的过程最重要的不是怎么修复bug而是怎么找到产生bug的地方。所以下面要讲的思路主要也是围绕排查bug相关。/01 缩小问题范围/缩小问题范围的方式有很多本质上其实是从当时的环境中找到与问题更高相关的变量。最常见的变量主要在以下这些运行环境所操作的数据浏览器对应的源码版本建议你先从这几个变量进行验证。然后再弄清楚上一次正常操作与当前出现bug的操作之间的这段时间发生过什么。大多数情况下问题的根源就藏在这里面。那种潜藏很久才遇到的疑难问题毕竟是少数。/02 提炼并优化每一类bug的标准处理流程/工作中很多流程需要SOP在修复bug这件事上也可以这么做如此可以将每一次修复一个疑难bug的过程给沉淀下来。常见的bug类型主要有4类输出与预期不符程序报错程序明显响应慢程序crash每一类都有适合它们的排查方式如果你总是用同一个套路去排查这4类问题效率自然不会太高。01 输出与预期不符这种bug最头疼为什么呢因为它不像那种异常、报错的bug有堆栈信息可以快速缩小排查范围甚至直接定位到产生的地方。那么怎么办呢如果这个问题在测试环境那么最简单直接单步调试走起这个时候如果对IDE的调试工具掌握得越深入效率也会越高比如条件变量、多线程调试等等。这里多说一句强烈建议每个人掌握自己所用IDE的条件变量和多线程调试这两种方法在当前的大环境下整个软件开发领域的大型项目和多线程运用都比几年前高得多。如果没法单步调试的情况那么只能通过多打一些日志来达到接近单步调试的效果。不过这点需要你做一些预判在一些代码分支、可疑位置打上日志即可毕竟编写记录日志的代码也需要时间不是。02 程序报错这种bug对有些经验的程序员来说是最简单了因为直接告诉了你产生异常的代码位置。但是对新手就不同了很多新手会拿着描述异常的一堆文字去搜索引擎搜比如NullPointer Exception搜出来N多文章一篇一篇看下来并尝试都发现不能解决自己的问题其实就是由于自己还没习惯于去看堆栈信息。因为别人的NullPointer Exception和你的NullPointer Exception产生的原因并不一样。堆栈信息中记录了整个调用链路所以通过这里你可以看到完整的方法调用顺序。不过值得提醒的是在日常编写的代码的时候千万不能随意的try catch代码块然后throw一个new exception因为这会导致堆栈信息不完整。03 程序明显响应慢这种问题一般是在产生资源竞争或者资源紧张的时候发生。排查他们的难度也比较高。如果说前面两类问题中高水平和低水平的区别只在于解决效率的高低上那么这个问题对低水平的程序员们来说可能是不管花多少时间都找不到问题的原因。不过不要紧我建议你以后遇到这种情况优先从以下这几个指标入手。TCP连接数内存占用率线程数对于TCP连接你身边得常备一份netstat命令手册然后敲入命令分别查看连接数是否接近到了65535TIME_WAIT、CLOSE_WAIT状态的连接是不是过多大多数情况下TCP连接相关的问题主要就是两个连接使用完后未及时释放针对高频调用未使用长链接而使用了短链接。此时一旦下游服务响应慢就会快速打满65535个连接。对内存问题的分析主要是就是通过分析GC来进行主要关注是否有什么类型的对象占用内存过大了。如果存在过大的情况主要原因是以下两个某个大对象应该是共享使用的在代码里不小心写成了每一个实例各自一份。某个对象分配的时候不小心带上了static关键字导致GC一直无法回收为其分配的内存。不同的编程语音有不同的GC分析工具需要熟练掌握。对线程的分析和TCP连接类似主要集中在线程的数量和状态上。线程并不是数量越多、性能就越好。数量越多可能花在线程之间的上下文切换上的时候就比实际执行代码逻辑还要多。另外是不是有大量线程blocked或者deadlocked了随便挑其中一个线程分析其当前的堆栈信息就是问题所在。04 程序crash导致crash的主要原因有两点。是由于前面提到的原因3未及时察觉导致程序运行直到资源耗尽由操作系统干预强行终止运行。代码中存在未捕获的exception。第一点参照原因3的处理方式。第二点就很简单了在代码的最外层做一个大大的try catch然后打上日志将堆栈信息记录下来发布到线上自然就能看到是那里出现的问题然后转到原因2的处理方式。最后提高Debug能力必须要多实践。所以我是非常建议你在条件允许的情况下勇敢地去挑起排查线上疑难杂症的任务甚至并不是你直接负责的功能模块。可能在外人看来你在帮别人“擦屁股”但这会让你的Debug能力得到明显的提升并且容易形成对你的依赖让你越来越强。好了总结一下。这篇呢Z哥和你分享了我对提高Debug效率这件事的看法。想要提高Debug的效率一是要对IDE工具有熟练的了解知道一些高阶的使用方式。二是要对Debug有一套自己的思路。对于第二点我建议的步骤是缩小问题范围提炼并优化每一类bug的标准处理流程Bug主要分为4类我在文中给出的思路也区分了这4类输出与预期不符程序报错程序明显响应慢程序crash希望对你有所帮助。在我看来Debug是一件很好玩也很有成就感的事情不亚于设计一个项目的框架。而且Debug还能让你真正地体会到什么是“魔鬼藏在细节里”。推荐阅读过于在意别人的看法怎么办你见过的“垃圾”项目是这样子么原创不易如果你觉得这篇文章还不错就「在看」或者「分享」一下吧。鼓励我的创作 如果你有关于软件架构、分布式系统、产品、运营的困惑可以试试点击「阅读原文」
