我的程序问题方法论

来源:互联网 发布:lg d2341软件 编辑:程序博客网 时间:2024/05/23 01:13

“这个问题非常诡异......”  ,“我都试过了,都没用!”,“实在没法解释原因,只能说是人品问题”..........................

2007毕业到现在快10年了,上面的这些话自己说过,也经常听到别人说,程序员的生活里总是充满了无数待解决的问题,其中还有一类叫做“诡异的问题”,它常常突然之间冒出来然后把你逼得快疯掉。不过,小心脏承受的折磨多了,解决问题慢慢也有了套路,今天就把我的经验总结一下,欢迎大家拍砖!

我认为解决程序问题的关键是定位问题,问题一旦准确定位了,解决掉它往往就是水到渠成的事情。

那好,下面就来介绍一下我采用的方法

(1)想尽办法让错误现象再现
    这算是方法吗?我都不大好意思说。但是人混蛋的时候往往就是连错误现象都不能再现就去尝试解决问题,想想你可能成功解决吗?你连错误如何再现都不能,就算被你蒙对了,你确定问题哪天不会再次出现?所以你必须把错误的重现路径找出来,让错误随时可以重现。有时候测试人员会告诉你你的程序有问题,不知道怎么点了点,就出现了一个bug,这个时候你就可以要求他把错误的重现方法找出来告诉你,否则你可以不解决。


(2)把问题分段-------切香肠法

你有没有遇到过这样的场景,辛辛苦苦写出来的程序终于前后台可以跑通了,可是性能实在不佳,从请求到返回结果花了几十秒,且项目上线在即,压力大啊,如何解决?

着急不能解决问题,抗议也不能解决问题(抱怨时间紧?以为自己是外交部发言人?),那肿么办?好办,把问题分段,逐个确认是最快的方法。

程序从点击开始可能经历以下几个阶段:

前台数据准备(js中构造数据结构,是不是还进行了其他的运算导致消耗了时间?)

发送请求(网络有没有问题?测试一下网速如何)

后台逻辑处理(有无数据绑定,是否耗时?是否存在大循环处理?是否会去访问的其他服务,比如调用其他服务的webservice?)

数据库操作(数据库查询的响应时间如何?是否牵扯到多个数据库交互?如果是,每个交互的响应时间如何?)

返回响应结果(网络有无问题?返回的结果是html还是ajax数据?如果是html是否页面上加载数据量太大或者说返回的内容过于碎片化?)

经过把问题分成几个阶段,按照括号里的猜测去逐个排查,最终就会比较准确的定位到问题的所在。卖个乖,就这个例子而言多数情况都是数据库交互导致时间消耗过多。


(3)通过异常来解决问题-----专家法
先说句废话,你要保证你的应用可以正确的输出有效的日志,不要不输出,也不要输出几个没用的汉字。

通过异常可以精准的定位问题所在,精确到代码行,所以如果你是专家的话也许分分钟就能把问题解决了,虱子遇到的多了,几条腿都知道吧。也许你不知道怎么解决,但是 有了那一堆的异常,到百度、Google或者stackoverflow.com上你至少有了搜索的资本,剩下的不多说了,就是一篇篇看帖子,不要抱怨有太多的重复帖子,怪就怪自己不是专家,你要是专家直接就知道怎么解决了。

工作快十年了,遇到了很多bug,但是不敢说自己是专家,偶尔用用也只是因为碰到的多了,经验而已。所以说专家法仅适用于你有类似的经验,否则那一堆异常只会让你更心慌。


(4)通过比较来解决问题-----比较法

你有没有碰到项目实施人员或者客户突然打电话告诉你程序不能运行了,又或者程序慢的让人无法承受了?再或者有个人品的问题困扰你,因为“同样”的程序写法别人都没有问题就唯独你的程序有问题?更有下班前刚测试通过的程序,项目经理晚上9点钟打电话告诉你不能运行了.........

<<甲方乙方>>这部电影里有句台词“世界上没有无缘无故的恨,更没有无缘无故的爱”,我来加一句,“所以也没有无缘无故的BUG”,不管是别人打电话找你说程序有问题还是自己在那边纠结,请记住,这一切都不是无缘无故的。这种原来好的,突然就不好了,别人好的,自己的就不好之类的问题往往让人感到无从下手,甚至只能归咎于人品。其实这类问题往往解决起来是最有套路的,那就是比较法。其实这个方法大家都不陌生,我们都经常和别人比工资来着是吧......

比较法的使用和比工资一样,你不能只比较工资额的不同,你还要比较你和那个你嫉妒的家伙之间到底有什么差别,比如承担的岗位一样吗?工龄一样吗?毕业学校一样吗?(有些国企在意啦)工作能力一样吗?你擅长的地方有他多吗?你比他更多的帮助他人吗?最后,你知道他是老板的儿子吗?哈哈

比较法其实就是找不同,我们应该从程序本身,程序运行环境(拿java来说:JDK版本、TOMCAT版本、lib包等等),操作系统,甚至浏览器等等多个角度去发现可能的不同。

比较法要依靠实践来判定,不要臆断!有时候你会说,“我全都试过了,你的代码我都抄的,还是不行”,但是也许是你武断的删掉了一句你认为无所谓的代码;有时候你会说,“为什么你的chrome可以,为什么我的就不行,同样是chrome,太诡异啦”,但是也许是你武断的认为浏览器的版本号无所谓,同样的还有JDK版本的问题。

总结一下比较法的使用:要实践,不要臆断。要全面,不要片面。

可是说易行难啊,其实有个简单的方法就是你把你想的需要确认不同的地方都列出来,一条条确认,不要怕列不全,多来几次,你会发现比较法真的很管用!


(5)有时候重新来一遍是最快的方法------重生法
重来一遍?这个算方法吗?我也觉得不算,可是有时候重新来一遍往往就能够解决问题。

你一定碰到过某个问题排查了好长好长时间,最后发现居然是js少了个括号,或者发现是变量名重复了........虽然现在工具能帮我们减少很多这样的错误了,可有时候还是会碰到类似的问题。要知道程序员的时间有多宝贵,整天被主管催进度,被经理压迫,搞得最后连找对象的时间都没哟啦,你说一个小时时间长还是不长???

如果你确认某个问题很简单,代码没几行,但就是结果不对,好,你可以新建一个文件,不要拷贝,代码重新来过,说不定就好了。错误的文件可以保存,等有时间的时候再来慢慢研究它,至少不会耽误项目进度。你要是老是死磕bug耽误项目进度,那你就老要比工资了。


(6)让问题简单化为来解决问题-----去干扰法

如果你喝了一瓶敌敌畏,又喝了一瓶百草枯,还嫌不解渴,又来了一瓶“鹤顶红”,结果你死了,请问哪一瓶让你死的?只知道你农药中毒,鬼才知道中的哪一瓶的毒啊,应该一瓶瓶喝才能确认啊.......

有时候程序中就会碰到类似的问题,我们大概确定了程序BUG的问题所在,但是这个时候发现可能存在多个原因导致这一问题,这个时候应当采取上面的“喝农药法”,每次只让一个原因产生作用,这样才能帮助我们更加准确的判断。比如你怀疑网络也可能产生影响,那你就把服务放在本地来测试,再比如你怀疑数据可能产生影响,那你就忽略掉数据访问过程直接返回模拟数据来测试。总之,要去除干扰,不要让多个你怀疑的原因同时作用于问题。

另外,环境上也需要简单化,如果你是做web开发的就会知道有时候tomcat启动一次就要花个几分钟,你不断调试,每次都要保存重启,要不要命不知道,找老婆的时间肯定是没有了。如果反复来个几次还找不到问题就要花点时间把服务精简一下,去除不需要的,重点留下你关注的程序就可以了。最好不要跟主管老是抱怨自己的机器配置低,程序员的设备当然要快,但是硬件的提速是有限的,你需要更多的思考。


(7)寻找别人的帮助,收集更多的解决思路-----乱棍法
有时候所有的方法都试过了,还是不行,也许昨天刚和女朋友分手,脑力实在不够了。可是,项目经理、开发经理、产品经理你们能不能不要催命了呢?答案一定是不行。
好吧,最后一招,乱棍法,俗话说“乱棍打死老师傅”嘛,让多个人帮你提出一些思路,思路就够了,大家都很忙,你也不要太依赖别人啦。大家的思路是更加开放分散的,所以很乱,收集到思路之后你一个个尝试就是了,这就是所谓的乱棍法。这个方法只适合你和女朋友分手之后用,自己的脑子已经彻底乱掉了(你懂的,没她不能活),这个时候别人的解决思路往往非常管用。


好了,写了这么多,我觉得有必要提出一个问题:为什么有些人总是比自己解决问题快,他们真的聪明吗?
我觉得聪明人肯定是有的,但是一个单位的你指望你比别人笨很多那也不现实,笨也不能作为自己少干活的理由啊。没有人想变傻变废吧,但是我倒是总结了一个16字真经可以帮助程序员们快速的废掉:【熟视无睹、充耳不闻、浅尝辄止、人云亦云。】

【瞎子】熟视无睹:自己天天在用但是一直都没有关注细节------能用就行了!
【聋子】充耳不闻:别人说过很多遍了自己从来没有上心过------管我鸟事?
【瘸子】浅尝辄止:让问题现象消失了就认为是彻底解决了------“实用主义”害死人啊
【傻子】人云亦云:别人随口说了一句自己就拿着当圣旨了------纸上得来终觉浅哦



1 0