上位機軟件運行到一半，自己把自己給刪了，這是發生在我們正在做內測的一款設備的上位機上發生的事情，影響還不小，因為很多配置都在軟件根目錄上，隨著軟件被刪，配置文件跟著也丟了，要知道，光調機器的參數，我們就調了半個多月，因為沒有備份，意味著所有參數都得重新來，此時項目經理氣得臉都綠了！事情到底是怎么回事呢？

事情的起因是我們在給一臺設備做測試的時候，上位機程序突然一下就閃崩了，還好同事之中有一個人眼疾手快，立馬拍了急停按鈕，不然正在運動的設備很有可能撞機。

不知道發生了什么事情，再次啟動上位機軟件，發現報了一堆錯，然后找到上位機根目錄，發現軟件目錄被刪得干干凈凈的，除了軟件本身的exe文件，還殘留著幾個其他依賴項的包在里面，所有重要的東西都沒有了！

抱有一絲僥幸心理，我們查看了下電腦回收站，想著看看有沒有可能被刪的文件在回收站里面還能找到，結果回收站里面啥也沒有！

一波激起千層浪，這個事情大著呢！因為我們正在調試這臺設備，很多設備參數都是慢慢調出來的，比如說運動控制伺服的的點位信息，光調試就得調試好幾天，而像這些動態配置的地方有很多處，隨著軟件被刪，全部丟失了！這下意味著所有非固定參數都得重新調，這擱誰誰不惱火？

這其中最著急的就是項目經理，因為設備馬上就要交付了，本身時間就不夠，這下延遲交付是肯定的了！

最開始，我們以為上位機電腦里面裝了殺毒軟件，是殺毒軟件把上位機程序當病毒給查殺了，但是殺毒軟件很快就被排除了嫌疑，因為上位機壓根就沒有裝殺毒軟件，而且所有防護和防火墻都是關著的。

而此時，主上位機程序員又編譯了一個軟件版本放到了上位機電腦上，一運行，上位機程序竟然又閃崩了！

是不是很惱火？當時我們主上位機程序員氣得都跳起來了！

但是，奇怪的是，在主上位機程序員自己的電腦上卻不會出現閃崩的情況，所以，大家一直以為上位機電腦有問題，可左查右查就是查不出哪里有問題。

最后，主上位機程序員直接把代碼同步到了上位機電腦里面，然后直接在IDE上運行，在調試模式下，很快就發現了問題所在。

原來，是上位機軟件自己把自己給刪了！

事情到底是怎么發生的呢？

原來，另一個上位機程序員的代碼里面有這么一段邏輯，大概的意思就是某個功能需要在軟件根目錄里面根據設備編號生成文件夾，然后文件夾里面會放一些緩存文件，當邏輯走完以后，再把文件夾里面的緩存文件刪掉！

這個程序員考慮的也很仔細，就是如果程序沒走完，那么可能緩存文件就會冗余在這個根據設備編號生成的文件夾內，因此，在軟件啟動的時候，他會首先判斷這個文件夾存在不存在，如果存在，則刪除文件夾里面的內容。

本身，這個邏輯已經算是比較嚴謹的了，挑不出什么毛病出來，但是，恰恰就是這個挑不出毛病的邏輯，讓軟件自己把自己給刪了！

他的想法很簡單，軟件啟動時根據設備編號查看軟件根目錄是否有根據設備編號生成的文件夾，有則刪除文件夾內容，沒有則什么都不做。

本身這個邏輯天衣無縫，但是，這里面有個問題，那就是設備編號不存在怎么辦？

一般來說，我們怎么去拼接需要刪除的文件夾地址呢？是不是“軟件根目錄/”+“設備編號”？

此時，如果，設備編號存在的話，那么目錄將指向軟件根目錄下面的二級目錄，但是，如果設備編號不存在，目錄將指向軟件根目錄！

看到這里，相信您也猜到了，導致軟件把自己刪了的原因，就是設備編號不存在！

最后問題解決了，這個程序員的思維沒有問題，但是，在拼接需要刪除緩存的目錄時，需要先判斷下設備編號是否為空字符串才行！

至于為什么之前沒發現這個問題，那是因為之前的確設備編號是存在的，因此程序一直都沒有出現問題，直到我們中途換了一個硬件，這個設備編號就沒有了。

這個程序員免不了被大家一頓說，還好問題是在測試機上出現的，萬一在正式生產環境下出現這個問題，事情就大了！

說到底，引發這個大問題的原因其實就是一個小問題，但是，有時候一個小問題往往會貫穿整個流程，所以，代碼還是需要考慮周全才是！