菜鸡的思维，诡异的程序

害，前几天客户催得急，让我把设备的生产数据上传到他们的数据追溯平台，同时要求数据上传的数值型数据，后面的小数点不能太长。之前是七八位。但是数据管理的类里面的属性、字段多如牛毛，记录着设备生产过程中的各种数据，挨个挨个去赋值的地方改吧！不可能，太多了，于是，参考前辈的反射方式，我把全部double数据类型的数据都进行了处理，心里想美滋滋！

后来程序丢到设备里面，操作员发现，测试单个工站的CT变长了，我想，肯定是反射和数据上传花了时间，于是，又单独搞个线程去实现，心想，这样子稳稳妥妥了吧！

第二天，客户来找我，说昨晚测试了八百个产品，为什么后面两三百的数据没有上传？我一听就懵了，心想：“怎么可能嘞？你想挨锤？”。

后来打断点进去程序里面才发现，原来做数据上传的时候，有一个变量是作为数据累加，是string类型的数据，每次上传完毕都要清一清，我居然忘记了，后来和客户数据追溯平台的管理员问才知道，上传的数据量太大，平台是拒收的，已经超过4M了！

好家伙，真的好家伙，原来生产几百个产品，某个变量忘记清，真的可以累积的4M，心想，一个普普通通的string类型数据，还能累积到4M？一张图片都未必这么大，害，赶紧修了这个bug，程序编程的细节没注意，我真的好菜鸡啊！还好客户宽恕了我对于这件事的失误，客户万岁！客户是上帝！

昨晚还为了另一台设备，肝到了两点半才出车间的，事情是这样子的，这台设备一次性处理一百多个产品，而且中途将近两个小时不能停。但是有时候程序会卡死，导致处理过程中产生的数据没办法上传到数据追溯平台，所以只能重新处理，但是一次处理要花费将近2个小时，中途还不能停。这种错误客户怎么可能受得了嘞？

于是，昨晚十点多的时候，开始和家里面的工程师对接问题，他修了一版发我试试，试着试着就挂了：这个参数没有刷新，那个while循环没有进来，这个串口的回调没有反应.......

后来软件+硬件的排查，发现有两个设备居然用了同一个com口，这不是离谱吗？怎么可以这样子嘞？难道运用了虚拟串口？

既然是离谱，为什么之前还能用只是偶尔卡死，就很奇了，于是在电脑后面疯狂拔插，看看那两台设备对应的com口，发现不对劲，有一个com口死活不从设备管理器上面消失，我怀疑他不是USB转串口，所以拔插没有反应。

最后木得办法，因为快一点了，这台设备再不跑料，后面就要停线了，环环相扣。只能把程序恢复成之前的版本让客户跑料，但是刚刚在排查的时候，知道了com口的问题，于是修正了。希望卡机的真正原因，不是两台设备竞争使用一个com口，排查问题，感觉遇到了玄学啊！