软件运行到一半，突然把自己给删了？原来是程序员判断失误所致！

上位机软件运行到一半，自己把自己给删了，这是发生在我们正在做内测的一款设备的上位机上发生的事情，影响还不小，因为很多配置都在软件根目录上，随着软件被删，配置文件跟着也丢了，要知道，光调机器的参数，我们就调了半个多月，因为没有备份，意味着所有参数都得重新来，此时项目经理气得脸都绿了！事情到底是怎么回事呢？

事情的起因是我们在给一台设备做测试的时候，上位机程序突然一下就闪崩了，还好同事之中有一个人眼疾手快，立马拍了急停按钮，不然正在运动的设备很有可能撞机。

不知道发生了什么事情，再次启动上位机软件，发现报了一堆错，然后找到上位机根目录，发现软件目录被删得干干净净的，除了软件本身的exe文件，还残留着几个其他依赖项的包在里面，所有重要的东西都没有了！

抱有一丝侥幸心理，我们查看了下电脑回收站，想着看看有没有可能被删的文件在回收站里面还能找到，结果回收站里面啥也没有！

一波激起千层浪，这个事情大着呢！因为我们正在调试这台设备，很多设备参数都是慢慢调出来的，比如说运动控制伺服的的点位信息，光调试就得调试好几天，而像这些动态配置的地方有很多处，随着软件被删，全部丢失了！这下意味着所有非固定参数都得重新调，这搁谁谁不恼火？

这其中最着急的就是项目经理，因为设备马上就要交付了，本身时间就不够，这下延迟交付是肯定的了！

最开始，我们以为上位机电脑里面装了杀毒软件，是杀毒软件把上位机程序当病毒给查杀了，但是杀毒软件很快就被排除了嫌疑，因为上位机压根就没有装杀毒软件，而且所有防护和防火墙都是关着的。

而此时，主上位机程序员又编译了一个软件版本放到了上位机电脑上，一运行，上位机程序竟然又闪崩了！

是不是很恼火？当时我们主上位机程序员气得都跳起来了！

但是，奇怪的是，在主上位机程序员自己的电脑上却不会出现闪崩的情况，所以，大家一直以为上位机电脑有问题，可左查右查就是查不出哪里有问题。

最后，主上位机程序员直接把代码同步到了上位机电脑里面，然后直接在IDE上运行，在调试模式下，很快就发现了问题所在。

原来，是上位机软件自己把自己给删了！

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

原来，另一个上位机程序员的代码里面有这么一段逻辑，大概的意思就是某个功能需要在软件根目录里面根据设备编号生成文件夹，然后文件夹里面会放一些缓存文件，当逻辑走完以后，再把文件夹里面的缓存文件删掉！

这个程序员考虑的也很仔细，就是如果程序没走完，那么可能缓存文件就会冗余在这个根据设备编号生成的文件夹内，因此，在软件启动的时候，他会首先判断这个文件夹存在不存在，如果存在，则删除文件夹里面的内容。

本身，这个逻辑已经算是比较严谨的了，挑不出什么毛病出来，但是，恰恰就是这个挑不出毛病的逻辑，让软件自己把自己给删了！

他的想法很简单，软件启动时根据设备编号查看软件根目录是否有根据设备编号生成的文件夹，有则删除文件夹内容，没有则什么都不做。

本身这个逻辑天衣无缝，但是，这里面有个问题，那就是设备编号不存在怎么办？

一般来说，我们怎么去拼接需要删除的文件夹地址呢？是不是“软件根目录/”+“设备编号”？

此时，如果，设备编号存在的话，那么目录将指向软件根目录下面的二级目录，但是，如果设备编号不存在，目录将指向软件根目录！

看到这里，相信您也猜到了，导致软件把自己删了的原因，就是设备编号不存在！

最后问题解决了，这个程序员的思维没有问题，但是，在拼接需要删除缓存的目录时，需要先判断下设备编号是否为空字符串才行！

至于为什么之前没发现这个问题，那是因为之前的确设备编号是存在的，因此程序一直都没有出现问题，直到我们中途换了一个硬件，这个设备编号就没有了。

这个程序员免不了被大家一顿说，还好问题是在测试机上出现的，万一在正式生产环境下出现这个问题，事情就大了！

说到底，引发这个大问题的原因其实就是一个小问题，但是，有时候一个小问题往往会贯穿整个流程，所以，代码还是需要考虑周全才是！