©2016-2024 Matools All rights reserved,
粤ICP备17059708号
首先，面试官问道这个问题的目的肯定是想从侧面了解你对技术的理解，或者说我解决问题的思路。那么说，我们回答这个问题也要从这点着手。我是这样总结的。
在我的编程生涯中，我总结出了几点：
1. 良好的编程习惯是对有效率编程最大的帮助。
2. 调试能力的高低是最能反映一个程序员水平的素质。
那我就分享一些我对调试的理解。我记得有一次项目中需要将一个Ubuntu下的Qt代码移植到VS里面，整体的过程都进行的比较顺利，但是在最后进行性能测试的时候，发现效率相差有近百倍。怎么办呢？调试第一点，就是定位问题。在下手之前，我有下列疑问：
1. 效率低，常见的是多线程阻塞导致。我这里有多线程读写图片，所以是有这个可能。
2. 但是，这个架构在Ubuntu下没有出现问题，不存在两者性能悬殊这么大！
基于这些疑问，我将调试重点放在多线程读取图片部分，最后也的确定位到问题是在多线程里面用OpenCV的imread读取图片消耗的时间巨大。难道问题是Windows下的OpenCV库出现了问题？那么是什么问题呢，代码在Ubuntu下经过了测试，换个平台，差距如此大。这个中间，我动过各种歪脑筋，什么看OpenCV的源码，对多线程流程调试等等，花费了几天时间，最后是一个偶然的机会再论坛里面看到有人讨论到VS下Debug模式和Release模式性能差异的问题，我才惊醒，这就是关键，最后用Release模式调用相对于的Release库，果然解决了问题。
这是一个很简单的VS使用的问题，但是当时我的日常使用多是Qt，初次接触VS，并没有考虑到这个问题，导致浪费了相当长的时间。但是，事后我进行了反思总结，我认为出现本次事件的关键并非是我对VS不熟，而是我分析问题的流程不够科学。Debug就像是警察判案，先要分析作案现场，然后通过各种现象得到一个嫌疑人名单，之后一个一个去排除，最终定位作案人员。这当然是最理想的判案路径，但是，如果所有的嫌疑人都被排除了，怎么办？如果，都被排除了，那么说，有两点：
1. 你的作案现场分析的不够细致，遗漏了一些信息。
2. 你根据现场信息得出的嫌疑人名单遗漏了某些人。
接下来应该做的是重新分析问题，确定问题分析很完善了后，下一步很关键，放大你的作案现场。从刑侦的角度看，凶手可能存在多个案发现场，也有可能我们目前看到的不是第一现场。回到编程这里来，首先怀疑多线程然后找到读写图片慢的现象，接下来怀疑是否是OpenCV源码有问题，这个可能性实在是小概率事件，且大致的看了源码后也未有发现异常，接下来应该扩大案发现场：
* 是否是其他代码区域有问题？
* 不会，这个读写差异的大小就基本上等于整个工程反映的差异大小了
*
如果代码没问题，编程环境的差异呢？那么可以重点关注VS和Qt的差异，从这里出发，不难就可以找到在VS下Debug模式和Release模式性能差异的状况。
以上，虽然是一个很简单的问题，但是基本能够反映我对调试的理解，也可以算是我从事编程到现在总结的一些内功心法了。调试的过程，本质上也就是一个猜想->定位->放大猜想->定位
这样一个循环迭代的过程。简易的示意图如下：
说句题外话，有人会觉得怀疑OpenCV的代码有误是否有必要，我想说，当然有必要，OpenCV也是人写的，当然有出错的可能，而且我也的确碰到过。我在使用某一个版本的OpenCV时发现其设置摄像头分辨率的函数不生效，但是仅限于那个版本，冥思苦想后，最终发现是因为这个版本的设置分辨率的函数没有实现。
热门工具 换一换