程序員在代碼里面“埋炸彈”這件事情其實已經屢見不鮮了，所謂“炸彈”其實就是比較嚴重的BUG，而我們公司最近新上的一個項目就遇到了這種事情，負責這個項目某個模塊的程序員竟然一不小心埋了一個特大的“炸彈”，最后老板連夜讓公司財務給程序員買機票，說什么也要在這個“炸彈”爆炸前把問題給處理掉，到底發生了什么事情呢？

先說下這個程序員老A吧，老A在運動控制領域其實已經深耕多年了，但是不代表他就不會出現比較嚴重的錯誤！

老A負責的這個模塊實際上是一個運動控制模塊，模塊主要任務就是通過程序來操縱軸到指定位置進行生產，您可以把客戶那邊需要生產的東西看作“棋盤”，老A需要做的就是把“棋子”準確得放到“棋盤”的每一個格子上。

但是，理想很豐滿，現實很骨感，客戶在實際生產過程中，“棋子”其實很難做到100%準確落到格子的正中心，所以，老A還需要做一件事情，就是根據客戶那邊視覺系統的檢測結果，對每次“棋子”的落點進行校正處理。

具體的做法，就是每次在“落子”之前，都要檢查上一次“棋子”落的位置，然后跟“棋盤”標準點的位置進行比較，然后進行校正。

簡單描述整個系統的運行過程，大致就如上所說，但是實際上這個校正邏輯是非常復雜的，需要配合算法來實現，而老A埋的“炸彈”其實就是在算法代碼里！

其實，這個“炸彈”理解起來并不復雜，這需要從校正邏輯說起。

校正邏輯非常復雜，為了便于理解，我們直接跳過中間過程，看看邏輯最終需要實現的目的，而這個目的，就是要讓軸在每一次生產完一個產品后都往某一個方向偏移一點，直至每個“棋子”的落點都離“格子”盡量得近位置為止。但是，在這個過程中，可能往單一方向移動，會出現判斷錯誤的情況，因此，當移動特定次數以后，“棋子”的落點依然不標準，反而和標準點的距離越拉越大的時候，需要往反方向移動，以此類推。

老A的邏輯就是這樣的，我們原定的方案是每次生產完一個產品，把軸往左邊偏移指定的距離，一共移動10次，如果10次偏移完以后，檢測結果還是不好的，那么就反過來，把軸往右邊偏移10次。

在代碼里面，處理起來也很簡單，就是每次生產完的時候，往數據庫存一個移動次數的值，再存一個方向的值，當次數大于等于10的時候，把次數清零，把方向值反過來即可。

那么，老A到底埋了一個怎樣的“炸彈”，要讓老板連夜組織人手去處理這個問題呢？

問題就出在移動次數上，簡單地說，老A其實在代碼里面判斷得很嚴謹，但是最終在存儲移動次數時卻沒存儲成功，這是咋回事呢？

道理其實很簡單，那就是老A在存儲移動次數時，走得是更新數據庫表的邏輯，但是這個移動次數表字段是后加的，而更新前需要將表數據先查出來，然后逐個字段更新，但是在數據庫更新語句里并沒有把這個字段的更新語句給加上去，最終導致這個字段的值始終都為0！

這會導致什么問題呢？那就是老A代碼中的對于偏移次數的判斷就失效了，這會導致軸會一直往一個方向偏移，最終“撞機”！

在運動控制領域，“撞機”是個很嚴重的問題，運動軸一般只在指定區域里作業，軸如果超過一定的區域限制，那么就會產生很嚴重的后果。

那么“撞機”怎么理解呢？其實我們可以把運動軸看作一條船，船只能在水域行駛，“撞機”就好比船撞到了岸邊或者已經駛上了岸，這肯定是不被允許的。

我們也可以想象一下，兩個都在工作的機械臂如果撞到了一起，會產生什么后果吧！所以“撞機”在很多情況下，后果非常嚴重。

當然了，為了防止“撞機”出現，設備在設計之初就已經設計了“防撞”功能，會增加一定的限位措施，還是以船舉例子，您可以把限位措施看作有人在岸邊擺上了一層輪胎或者氣墊，當船要撞上岸邊時，這些輪胎或者氣墊可以給船起到緩沖作用，對船起到保護作用，此時船只要正確駛離岸邊即可。

但是，老A的代碼里面偏移次數這個變量的失效，當發生第一次“撞機”以后，設備會進行報警，但因為每次偏移都往一個方向偏移，因此，即使報警取消了，設備下一次還會“撞機”報警，最終導致設備無法進行正常生產。

好在客戶那邊到現在沒有反饋設備有“撞機”的情況出現，就說明老A的那段有問題的代碼還沒被觸發，說明客戶生產情況良好。但是，如果一旦出現某次檢測結果不好，觸發了老A的那段代碼邏輯，這個隱患就會出現，所以，這個問題不能等！

結語

后來，老A趕了最早的飛機飛到客戶那里，隨便扯了個謊把程序給更新了，這個事情到現在老A都心有余悸，如果真的出現“撞機”的情況，用老A自己的話說：“真怕晚節不保了！”。

不過說起來，老A埋的這個“炸彈”其實還是挺低級的，只要仔細測試檢查就可以測試出來，也從側面證明了，不管是多么資深的程序員，也是會寫出低級錯誤的代碼的！不出事，就是最大的幸運了！讓我們引以為戒！