我们都知道在开发环境下,程序运行失败导致崩溃闪退通常会有日志信息告诉我们哪里出错了,这样我们就可以快速定位问题。像这种问题都是初级的,即使没有错误日志信息,我们通过单步debug调试或自己加日志信息,看程序走到哪一步出错了,也能快速定位出来。 随着工作时间的积累,像空指针异常,数组越界等都很容易避免。而更多的是遇到业务逻辑错误,就是实际的运行效果跟你的预期不一致。这些虽然说在程序上没问题,能正常运行,但其实也是一种错误,而且是没有日志信息,更不存在显示哪一行了。 举几个场景说明一下,比如数据计算错误,比如手机页面列表内容复用错误,再比如手机键盘弹不出或隐藏不了,甚至是开发人员对需求的理解不一致导致做出来的效果不一样等等。我们可以对比发现,前面那种代码运行逻辑错误更多的是开发人员自己去发现并解决,而现在这种业务逻辑错误更多的是测试人员来发现。现在程序不报错了,更不会说哪儿有问题了,但这就是有问题,需要解决,这个时候往往需要花大量的时间来定位问题。 其实到这里就能说明程序员遇到很多问题,连运行失败都不会报,但还是得解决。最后还想补充一点,假若你对自己有要求,有一类问题,像运行不报错,和预期效果也一样,但你也得解决,这叫做性能优化。比如一个页面多请求了几次服务器,比如一个地方数据没必要刷新多次等等。 不管哪种问题,日常开发中都会遇到,也许真的会疯掉,但对于资深开发而言,还不至于程序运行失败没有日志而疯掉。 遇到这种情况,不能疯也不能崩溃,唯有冷静分析,才会找到问题所在。 对任何问题来说,定位到它的发生点,是解决的关键。能不能解决,是能力水平的使然。定位不到,要检讨分析问题的方法。 坦白地说,定位问题的思路和方法,解决问题的有效性和时效性,是衡量一个码农水平最直接的手段。 题主提到的问题,可以拆分成两种类型。 第一种是,糟糕的编码习惯把不同错误信息,都提示为"运行失败"。 第二种是源代码中没有显式"运行失败"字样的提示,错误是编译器或操作系统报出来的。 除了上述两种情况,还有运行不报错,但与预期结果不一致,更为复杂的情况。 把程序错误提示,大多数写成"运行失败"是低级错误,但是在工作中这种情况并不少见。常见的是复制粘贴类似代码之后,修改了业务逻辑,遗漏了报错信息。要是某个小伙伴有意为之的话,建议他直接选择退出码农界吧,这个职业真的不适合他。 编译器或者操作系统报错,工作中出现的频次不少。典型的有几种情况,指针失效 (野指针)、指针越界、除数为零、边界值等。举个非典型且大家很疑惑的例子,C或C++编码时,字符数组在使用前需初始化成空串。另外,假设一个字符数组要存储的数据长度是N,定义字符数组的长度至少是N+1,不然字符串结束符无处安放,从而出现不可预知错误。 上述两种情况有共同点,可复现。也就是只要使用相同的参数,必然得到相同的报错信息。借助编译器,debug运行一次,三五分钟就能定位到问题。 运行时不报错误,结果与自己预期的有出入,更让人头疼的是不可复现。这时你就会认为,能够报错的问题,还真是个小可爱呢。多线程并发执行,互斥没有处理好,容易发生这类问题。debug跟踪复现不出来,只能走查代码,梳理逻辑这一条路了。谁的孩子谁抱走,谁的代码谁来排查是最优解。 有着多年经验的程序员,在多线程编程领域处于懵懂状态是不争的事实。这也是区分科班码农和半路码农的一个重要指标。 最后小编总结一下。不会定位问题的码农,不是一个好产品。 图片来自网络,如有侵权,联系小编删掉。 分情况,是否是自己写的代码呢? 很多程序员都喜欢自己写代码,很讨厌去阅读别人的代码,写代码是一件非常有乐趣的事情,解决bug也是非常有乐趣的事情,debug更加是极具挑战性,特别是越难的bug(仅针对自己的代码) 1、自己写的代码(痛并开心) 呵呵,怎么可能,我的电脑上怎么是好的 哈哈,自己的锅自己总得背吧 淡定,自己写的,了如指掌 2、其他人的代码(崩溃) 心里跑过一万只....但还是得去处理,debug,在里面多些几行注释吧 写的是什么破代码,真的是要命 花时间审视这个蹩脚的代码,给我工时我也不愿意 然而,自己写的代码在其他人看来就是别人的代码,那个自己看别人的代码有什么区别呢 最后告诉大家,作为一个资深的程序员,阅读别人的代码是很有必要的,也是自己的生存之道,每个人都有每个人的风格,思路。每个人都不想混日子,都想解决问题,获取成就感,都想写好优秀的代码,都想成为大神,但是能力和态度决定了一切。 很正常,不会疯。我遇到过最不可思议的bug是windows操作系统的错误引起程序运行失败,怎么查都不出问题,将问题和源代码反映给Microsoft后也没明确回应,后来过将近一个月微软出了补丁,打完补丁就好了。 事实上很多bug都是不报哪里错了的,以前开发大型游戏多个程序员一起开发后端c++,什么内存溢出导致的bug查出来跟侦破一个高智商犯罪没啥差别,现场一点线索没有,只有伪造的现场,即便你能复现bug依然不知道问题在哪是谁引发的,你需要通过现象缩小范围,再通过近期外放功能,版本回退等逐步缩小包围圈,最后在这个小圈子里分析可能是那些代码引发的问题,曾经手下有一个bug引发了上百万的损失,定位了很久才找到原因。 程序运行失败时当然只能显示运行失败四个字啊…… 能显示具体是什么错误的话,就会预先写一段应对代码来处理。 这个假设是永远不会成立的 你觉得可能吗?那就不是一个合格的设计了。而且,报错也是程序员前辈们写的。 又不是没遇到过,只是定位麻烦一点而已,因为这就要疯,那还是不要搞这个了 看这个问题就知道是没做过程序的人提的。能报错的都是已知问题,程序员要查的错都是未知的问题。最难解决的问题就是偶尔出现一次的问题,那就要像侦探一样从蛛丝马迹的线索中分析出来问题所在。