公司一程序员同事写的项目在客户那被客户发现了个问题，就是程序获取的第一个物料条码信息总是会丢失，然后就找到我们公司反映了这个问题。并且，客户号称之前都没有这个问题，这个问题是“突然出现的”！但是，这个程序员在休假，所以我就帮他看了这部分代码，然后我就发现了问题所在！
扫码逻辑
原来，这个程序获取条码的逻辑是这样的：
物料的条码是通过扫码枪扫的，但是，扫码枪可能会出现多次扫码的情况，于是，在程序中设置了一个逻辑，那就是当上次扫码的结果和这次扫码的结果一样的时候，就不处理这次的扫码结果。
这个程序员的逻辑本身是没有问题的，因为不会出现“跨条码重复”的情况，意思就是，相同的条码只会连续重复，不会隔几个不一样的条码以后，突然又出现之前曾经扫过的条码。
于是，他就写了一个全局变量，用来存每次扫码的结果，当有新的条码过来的时候，他再拿这个全局变量的值和新的条码值进行比较，如果一样的话，就不处理，否则就将条码记录上传至客户提供的数据接口，当然，后面还有很多其他逻辑，这不是重点。
重点在于，为什么每次程序启动以后获取的第一个物料条码总会丢失呢？
代码有Bug
上面说了，在新条码过来的时候，他写的代码首先会比对是否和上次扫描的条码是否一样，一样的话则不处理，如果不一样，会做一个动作，那就是将全局变量的值改为新的条码，然后再将条码信息上传至客户提供的数据接口，但问题也出现在这。
这个程序员犯了一个低级错误，那就是他可能是为了保险起见，所以改变全局变量值的动作是在请求接口以后，这样就能保证当请求接口失败的时候，再次扫码还是有效的，这个逻辑本身是比较谨慎的，无可挑剔。
但是他错就错在，调用客户提供的数据接口，条码的值用得却是全局变量的值！反正不知道他怎么想的，问题被我发现就出现在这！因为当程序启动的时候，全局变量的值还是个空字符串，当然会丢了！
这是我模拟的公司代码：
我估计这个Bug出现的原因是因为一开始给全局变量赋值是在请求接口以前，但是后面这个程序员想了一下，感觉放前面万一接口请求不成功，那么再次扫码就无效了。可他改了逻辑以后，却忘了改接口请求部分，导致出现了这个Bug。
估计连客户自己都没注意到，不光第一个物料条码的值是空的，而且，接下来的所有条码的值的顺序都往后移了一位，而实际上客户认为条码丢了，只不过是条码往后移了一位而已！
结语
找到了问题，写这个程序的程序员有责任，但是客户提供的上传条码的接口也有问题，因为条码接口在调用时，条码的值是空字符串，竟然也没报错，显示成功，这才是问题的根源，如果程序员在写这个接口的时候，模拟测试的时候接口直接报一个“条码不能为空”的错误，那么这个问题早就被发现了！
热门跟贴