从10号线（牡丹园）地铁指示台的bug看到程序员背后的工作

        今天，晚上9点下班回住的地方，和同事一起走到10号线地铁（牡丹园站）里面，看见地铁地面上有个机子，这时候地铁还没有来，于是乎我俩就走到了地铁的指示机前，是触屏的，但是不支持多点触控，点了一点，感觉还可以！有一些方便大家的提示，比如：地铁出口附近的公交车有哪些？但是没有详细的哪一个公交车具体经过的站牌是哪些？有地铁的最早发车时间和最晚发车时间表，就在看这个的时候，发现了一个bug，13号线开往西直门的全程末班车的时间有一个居然是13:10分，感觉不太对劲，地铁怎么可能在13:10分停运呢、于是乎我就上网查地铁运营时间表！

                                            地铁乘客信息查询系统

                                                   红色标出的是错误的时间表

    公司网址：http://www.sgs.com.cn/news_show.asp?id=1414&channel=5&classid=5

                       网上查询正确的结果如下：

                 希望贵公司发现此bug，赶紧处理！

       看到回龙观这一行，发现时间是23:10。

       哎! ---->bug啊！这么严重的bug，数据库中插入的值肯定输入错误了，这个测试怎么测试的呢！开发人员的测试呢?QA的审批？等等！

       一系列的问题都暴露出来了！软件的开发周期是多久，开发人员的测试，测试人员的系统测试，这些测试案例怎么写的？？种种因素导致了以上的错误，其实生活中我们难免出错！但怎么才能避免产品出现这么显而易见的错误呢？

        现在的软件行业都是抱着“短，平，快”的效率发展，很少人原因多花钱在测试身上，都是找一些刚毕业的做测试，开发也是一个人顶3个人用！软件行业的“高”起点收入下背后往往是一些苦逼的程序员在不停的加班，做事没有章法，别管用什么方法，老大只看结果。往往小公司都是这么干的。---->还所谓的敏捷开发。再来看看一些大的公司，华为，提交一个bug，要找3-4个人review，而且被review的人必须每行代码都必须讲清楚。否则就不允许提交---->入库。修改100行代码要写风险方案评估等等。这些看似浪费时间，降低我们的开发效率。但其实这种方法才是真正意义上的减少重复错误的出现。一些小的开发公司，往往忽略这些，每天的bug都忙着解不过来，哪有什么时间写风险评估？比如一些公司会开展分模块开发，往往都是每一个人单挑一个模块的大梁，在review的时候，往往别人都看不懂（甚至不熟悉他的模块的情况下），就匆匆签字提交，只是会负责任地问一声“验了吗？”往往在这种高压的工作环境下，人出错的概率会大一些。然后我们会重复解决一些已经解决的bug，一些bug是因为我们以为解决了，但是会引起另一个（甚至好几个bug）。我就遇到这种事！中国程序员的命运有部分就是是这么悲惨的！

        提点意见：注意总结，提交代码尽量把这个问题搞清楚，下次在出什么问题，能很快定位到什么地方！和同事多交流，这样知识是流动的，会像一条条河流流向一个方向形成大海一样。准备一个本子，写下自己每天解决的bug，然后每隔一个月对比一下，看哪些是重复的问题？养成一个良好的习惯----多写注释！尤其在关键的地方。