我們機(jī)器視覺項(xiàng)目的程序包含，業(yè)務(wù)邏輯+圖像處理，所以我們不單單調(diào)試圖像處理部分，還要調(diào)試C#，界面，數(shù)據(jù)等等。我們必須保證程序穩(wěn)定性，還要保證視覺檢測的穩(wěn)定性。

據(jù)說，有個(gè)機(jī)器視覺工程師因?yàn)楝F(xiàn)場客戶把光源拆了，讓他來現(xiàn)場重新調(diào)整光源位置，這位機(jī)器視覺工程師第二天就不來公司了，沒有走任何辭職流程，果斷收拾走人。

某天領(lǐng)導(dǎo)說，這個(gè)視覺檢測簡單，早點(diǎn)搞完。過了一段時(shí)間，你在調(diào)試，領(lǐng)導(dǎo)來一句，怎么還在調(diào)試。-摘錄大多數(shù)不懂裝懂，沒事裝逼類型領(lǐng)導(dǎo)語錄。

兄弟們，有沒有為自己拼過命，萬萬沒想到為了幾個(gè)像素波動拼過命，連續(xù)調(diào)試五個(gè)小時(shí)沒有穩(wěn)定下來，吃完夜宵，再看，像素波動穩(wěn)定了。第二天跑起來一點(diǎn)問題沒有。萬萬沒想到第三天，不穩(wěn)定了，原因是客戶把照明燈關(guān)掉了。

機(jī)器視覺工程師在機(jī)器調(diào)試過程中毀滅自我，拉扯自我，撕裂自我，重塑自我，否定自我，肯定自我，重啟自我

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

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

那么程序debug原因有哪些？

1.每種編程語言自身都有bug，當(dāng)你感覺對的時(shí)候，編程語言的體系根本不允許這樣子去實(shí)現(xiàn)，你要在他規(guī)則下去寫程序，但是它的這個(gè)規(guī)則往往就是最大的bug，規(guī)則本身就紊亂，所以編程者理解它規(guī)則的同時(shí)，還要去按照這個(gè)規(guī)則走下去，那么走下去的流程，每個(gè)人都不一樣，因?yàn)槊恳粋€(gè)人理解的都不一樣。

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

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

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

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

6.我們腦子里并沒有計(jì)算機(jī)，所以你永遠(yuǎn)不知道結(jié)果。

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

機(jī)器視覺需要反復(fù)調(diào)試的原因有以下幾點(diǎn)：

圖像集的質(zhì)量不同，需要針對不同的圖像集進(jìn)行調(diào)試；

算法的參數(shù)設(shè)置不同，需要不斷調(diào)整參數(shù)以達(dá)到最優(yōu)效果；

硬件設(shè)備的差異，需要根據(jù)不同的硬件設(shè)備進(jìn)行適配；

環(huán)境的變化，比如光照、角度等因素會影響機(jī)器視覺的效果，需要進(jìn)行相應(yīng)的調(diào)整。

因此，機(jī)器視覺需要反復(fù)調(diào)試才能達(dá)到最佳效果。