[技术讨论]网络软件开发的bug分析与公司开发管理问题之12306

本文是第一篇，也是包括前言部分，全文可能会伤害一些公司的码农兄弟们，但是，请见谅，这确实是各位公司的现状和事实，而且没有拿到截图的或者忘记截图的，我都不敢发。毕竟要以事实为依据么！

1. 引言
本文中会举例分析国内各公司网络软件中的bug情况和基于这些bug可以分析得到的这些公司的开发管理状况。本文中的数据取自2007-2012年网络上运行的各种游戏和软件系统，还有一些数据并没有到发布的状态，所以，后期会补充从2005到2012年一些游戏数据情况分析的文字出来。
笔者用过的网络系统和软件数量并不够多，有些的bug发现了也没能及时保留下来，还有些bug属于无关痛痒的，下面只是一些保留下来的问题，并且代表着一些漏洞或者风险的bug。
2. 12306
2.1 改签票款计算错误
先从最简单的看起，这个也是大家可能都会疏忽，甚至可能在这里丢过钱的，12306出现的改签票款的计算错误。
两张6.5/张的火车票改签成2张13/张的火车票，居然出现了如下的计算结果图。

上图略小，可能看不清楚，下面用局部图来表示。

可以看到退还的票款是6.5，不是正常的退票13块，也就是说，2张6.5的票，要么计算成一张退票，要么故意黑掉了一张的退票费，反正12306到目前的退票都是不清不楚的，查证的时候人家就是一句话退过了，自己去找银行。
于是我退出，重新进行改签，这次的结果如下图所示。

详细局部图如下。

这次的计算就正确了。
前后十几秒左右的时间，却出现了两种不同的结果。
我不知道有多少人因为没有注意这一点而损失了自己的钱，12306为什么会这样呢？

从代码层面考虑，同一个过程的代码执行应该只可能得到一个结果，上面我的操作过程中应该不会涉及到系统更新的问题，那就是说，在这里实际上应该是执行了两个方法过程。或者说，有两个计算退票款的方法在执行中，第一次执行的是错误的方法，第二次执行了正确的方法，那就进一步说明，这里应该有一个判断在执行，确定到底执行哪一个退票方法。
到这里，我们已经无法继续分析，因为下一步的分析应该是去检查代码中对应的部分，进行bug的修正和分析了。
2.2 买票的判断逻辑缺陷
因为订票订不到从北京到宁德的，于是抢到了一张北京到温州南。

然后就想是否可以直接买一下温州南到宁德的车票，查询的结果是这趟车从温州南到宁德还有很多座位，于是下单，最后提示如下图所示。

也就是说，在12306的分析中是用身份证号码和车次作为关键词进行重复订票查询的，并没有增加车上的行程作为判断条件，因此算是一个判断条件缺失，造成了上面这种本来应该可以购买，因为并不违背铁道部的买票规定的票，却实际上无法购买。

看完本文是不是有一种想要去查一下过去退票和改签的退款信息的冲动呢？
后记，请期待下一篇 阿里