一次摸不到头脑的debug，宏定义

前言

软件开发者debug程序是家常便饭，然而有时候也会遇到让你丈二和尚摸不着头脑的问题。你会在心中纳闷：“怎么会这样呢？”“这个地方我明明加了限制啊”“见鬼了吧，一样的步骤结果不一样？？” 有时候这些bug最终发现都是很简单的原因导致的，于是恍然大悟，原来是这样。虽然问题解决了，但是这并不能说明你有所成长，下次遇到这样的问题，你的思路用变化吗？还是说仍旧是check好几天，哀声遍野，然后恍然大悟？ 我想说的是，问题解决不重要，思考方式有所变化，下次能用更短的时间解决问题，才最为重要。 今天，我就遇到了这样一个让我受益匪浅的问题，来此分享一下。

问题

公司有两套产品，基本架构是一样的，所以很多的module是公用的，只有一小部分模块因为逻辑变化较大分成了单独的module，但是这些模块中仍有小部分代码是一样的功能。因此某些文件就出现了两份（这在大的产品中这很正常吧！），画了一个简单的图阐述一下：

而问题就这么出现了，简化来说是这样的： 产品Ａ和产品Ｂ接受共同的配置，标准的配置时两个产品都正常处理，并且对业务没有任何影响。 而测试人员配置了一个很长的字符串配置，两个产品都报错了（这是不合法的）。产品针对这个配置项的基本逻辑是：虽然你输入的不合法，我会警告你，但是我仍然会尝试去解析这个配置，不然会导致其他的配置无法生效。

而问题出现了，产品A和B都报错了，这是OK的。但是产品B却在后台上报了一个配置项解析错误的error，直接导致某个电话业务失败了；于此同时，产品A却一切正常。

好吧，我也知道是某个小差别引起的，幸好产品A是好的，对应着查吧！

捉虫历程

难道是这个字符串太长，两个产品最后读取到的字符串不一致，从而走向了不同的处理？ 打印一下读取到系统里时，这个字符串是什么样的（额，完全一样）：

产品A是好的，产品B不OK，说明两个产品某个步骤操作的时候有差别，问题在产品私有的的module，且在相同的那部分文件里(因为是处理同一个东西嘛）。 肯定是后来的产品开发特性的不同，使得一开始相同的文件出现了不一致，导致问题现象有问题。 查看一下处理流程吧，都是把上面的字符串放到下面这个函数进行处理，函数的第二个参数是一个out的返回值。解析正常，返回的是有效值；解析失败返回的是NULL. 额，函数调用几乎一模一样，没区别。

既然调用没问题，那应该是decode_value函数的具体实现不一样吧？ 额，除了去除了一点不支持的变量，没区别了。

好吧，我没辙了，要不把文件夹理所有文件都diff一遍吧？ 也完全一样，额，冷静一下。

原因

最后在他人协助下，终于发现问题： decode_value函数中有一段处理：

在这段处理中，对count加1，并做一个if判断，看上去没什么区别对吧？But，问题偏偏在这里，与count做判断的一个宏定义DL_MAX_STR_ELEMS有问题啊，DL_MAX_STR_ELEMS在产品A和产品B中定义的值不一样！！！

就是这个原因，导致一段很长的配置字符串，在产品A上没有超过100个字符，成功解析，二年产品B解析失败。

结论

感受颇多，最大的感受是，寻找bug，思路要变化。 如果两个产品或多个产品有着基本相同的处理，但最终结果不同，其原因获取不仅仅是多个处理或少个处理的问题。更大的可能是某些预定义的常量针对产品不同有不同的值，在if、switch和循环等地方走向了不同的处理。仅仅比较函数 code是否一致是没有用的，关键是check存在流程分流的地方是否走的是同一走向.