我们机器视觉项目的程序包含，业务逻辑+图像处理，所以我们不单单调试图像处理部分，还要调试C#，界面，数据等等。我们必须保证程序稳定性，还要保证视觉检测的稳定性。

据说，有个机器视觉工程师因为现场客户把光源拆了，让他来现场重新调整光源位置，这位机器视觉工程师第二天就不来公司了，没有走任何辞职流程，果断收拾走人。

某天领导说，这个视觉检测简单，早点搞完。过了一段时间，你在调试，领导来一句，怎么还在调试。-摘录大多数不懂装懂，没事装逼类型领导语录。

兄弟们，有没有为自己拼过命，万万没想到为了几个像素波动拼过命，连续调试五个小时没有稳定下来，吃完夜宵，再看，像素波动稳定了。第二天跑起来一点问题没有。万万没想到第三天，不稳定了，原因是客户把照明灯关掉了。

机器视觉工程师在机器调试过程中毁灭自我，拉扯自我，撕裂自我，重塑自我，否定自我，肯定自我，重启自我

在我看来，这些是造成 bug 的原因，不是造成大部分时间在 debug 的主要原因。
大部分 debug 时间应该是花在 bug 复现 和 bug 定位，所以你可能可以写出不用 debug 的程序，但是不可能不需要测试，而且我觉得在写程序自己测试的那段时间不叫 debug ，通常一边写代码一边测试那段时间所发现的 bug 都可以迅速找到的，并且可以及时处理解决掉，甚至解决不了，也要去避免这种类型的bug。

那么程序debug原因有哪些？

0.每种编程语言自身都有bug，当你感觉对的时候，编程语言的体系根本不允许这样子去实现，你要在他规则下去写程序，但是它的这个规则往往就是最大的bug，规则本身就紊乱，所以编程者理解它规则的同时，还要去按照这个规则走下去，那么走下去的流程，每个人都不一样，因为每一个人理解的都不一样。

1.逻辑性错误，从一些小代码片段来说你可能没有问题。那么，经过一百个乱七八糟的跳转之后，你还能看出错误来么？晕了，找啊找，找了半天，定位到bug，各种方法尝试修改。
2.代码健壮度，同上，你不可能考虑到所有状况，因为很多状况出现的问题都不严重，无非是重试或者警告，那么有些状况在必须处理的前提下，你也是同样容易被忽略的。并不是说没有人愿意写出超级健壮的代码，而是，想那么多有什么用呢，万一不出错呢？
3.编写效率，你是在debug 的时候发现错误的概率高，还是在自己脑子里发现错误的效率高。大部分人都是前者，如果你在脑子里就发现了错误，也就轮不到Debug时候发现了，所以一般人的做法是，写完再说。
4.其实我并不知道这么写是为什么，但是我觉得这么写就是对的。这种，要么真对了，要么错的一塌糊涂，但是你不能说这是蒙的，至于对不对，debug会告诉你真相。
5.我们脑子里并没有计算机，所以你永远不知道结果。

图像处理debug的原因有哪些？

机器视觉需要反复调试的原因有以下几点：
图像集的质量不同，需要针对不同的图像集进行调试；
算法的参数设置不同，需要不断调整参数以达到最优效果；
硬件设备的差异，需要根据不同的硬件设备进行适配；
环境的变化，比如光照、角度等因素会影响机器视觉的效果，需要进行相应的调整。
因此，机器视觉需要反复调试才能达到最佳效果。