我們機器視覺項目的程序包含，業務邏輯+圖像處理，所以我們不單單調試圖像處理部分，還要調試C#，界面，數據等等。我們必須保證程序穩定性，還要保證視覺檢測的穩定性。

據說，有個機器視覺工程師因為現場客戶把光源拆了，讓他來現場重新調整光源位置，這位機器視覺工程師第二天就不來公司了，沒有走任何辭職流程，果斷收拾走人。

某天領導說，這個視覺檢測簡單，早點搞完。過了一段時間，你在調試，領導來一句，怎么還在調試。-摘錄大多數不懂裝懂，沒事裝逼類型領導語錄。

兄弟們，有沒有為自己拼過命，萬萬沒想到為了幾個像素波動拼過命，連續調試五個小時沒有穩定下來，吃完夜宵，再看，像素波動穩定了。第二天跑起來一點問題沒有。萬萬沒想到第三天，不穩定了，原因是客戶把照明燈關掉了。

機器視覺工程師在機器調試過程中毀滅自我，拉扯自我，撕裂自我，重塑自我，否定自我，肯定自我，重啟自我

在我看來，這些是造成 bug 的原因，不是造成大部分時間在 debug 的主要原因。

大部分 debug 時間應該是花在 bug 復現 和 bug 定位，所以你可能可以寫出不用 debug 的程序，但是不可能不需要測試，而且我覺得在寫程序自己測試的那段時間不叫 debug ，通常一邊寫代碼一邊測試那段時間所發現的 bug 都可以迅速找到的，并且可以及時處理解決掉，甚至解決不了，也要去避免這種類型的bug。

那么程序debug原因有哪些？

1.每種編程語言自身都有bug，當你感覺對的時候，編程語言的體系根本不允許這樣子去實現，你要在他規則下去寫程序，但是它的這個規則往往就是最大的bug，規則本身就紊亂，所以編程者理解它規則的同時，還要去按照這個規則走下去，那么走下去的流程，每個人都不一樣，因為每一個人理解的都不一樣。

2.邏輯性錯誤，從一些小代碼片段來說你可能沒有問題。那么，經過一百個亂七八糟的跳轉之后，你還能看出錯誤來么？暈了，找啊找，找了半天，定位到bug，各種方法嘗試修改。

3.代碼健壯度，同上，你不可能考慮到所有狀況，因為很多狀況出現的問題都不嚴重，無非是重試或者警告，那么有些狀況在必須處理的前提下，你也是同樣容易被忽略的。并不是說沒有人愿意寫出超級健壯的代碼，而是，想那么多有什么用呢，萬一不出錯呢？

4.編寫效率，你是在debug 的時候發現錯誤的概率高，還是在自己腦子里發現錯誤的效率高。大部分人都是前者，如果你在腦子里就發現了錯誤，也就輪不到Debug時候發現了，所以一般人的做法是，寫完再說。

5.其實我并不知道這么寫是為什么，但是我覺得這么寫就是對的。這種，要么真對了，要么錯的一塌糊涂，但是你不能說這是蒙的，至于對不對，debug會告訴你真相。

6.我們腦子里并沒有計算機，所以你永遠不知道結果。

圖像處理debug的原因有哪些？

機器視覺需要反復調試的原因有以下幾點：

圖像集的質量不同，需要針對不同的圖像集進行調試；

算法的參數設置不同，需要不斷調整參數以達到最優效果；

硬件設備的差異，需要根據不同的硬件設備進行適配；

環境的變化，比如光照、角度等因素會影響機器視覺的效果，需要進行相應的調整。

因此，機器視覺需要反復調試才能達到最佳效果。