代码BUG之曲线救国

清明节放假前工作最后一天，协助同事解决了一个BUG，这个BUG对于所属的程序而言，可以说不是痛不痒，完全不影响使用，只是看起来有点变扭而已。然而， 对我而言， 解决这个问题的思路却是比较有代表性的，颇有一种曲线救国的味道。

 

事情大概是这个样子的。有需求部门反应，我们部门负责的某个项目的页面上数据显示有问题。有10条数据，每页显示4条，那么正常情况下第1页应该显示4条，第2页4条，第3页2条。因为某一处代码抽风，现在数据被显示成了第1页4条，第2页3条，第3页3条。尽管不是什么大问题，但是我们写代码做产品向来秉承着精益求精的作风，只要是个问题， 就算再小，也要修正。然后， 一帮程序员手忙脚乱的想抓住这个BUG消灭之。为什么是一帮程序员？修个BUG用的着这么大动干戈吗？大家有所不知， 因为这个BUG的当事人是一位萌妹子，大家帮忙出主意修BUG是不假，但是去揩个油那也是真的。一阵忙活之后， 问题出在哪里是找到了，却没法子下手改。因为这个项目依赖一个第三方分页显示插件，程序本身的逻辑没有问题，问题出在这个插件里面。去修改这个第三方插件的BUG显然不太现实，靠谱的解决方法就是把这个插件给换了，但是项目的代码跟交互和这个插件结合的非常紧密， 哪能说换就换，再说当时已经是晚上七点了，这一搞非得到凌晨不可，因此，大家都像泄了气的皮球，无可奈何，这都放假了还出这档子事，明天还要去给祖宗上坟呢，加班和对先人不敬，到底应该选哪个呢？心塞塞呀！

 

本来这种闲事我是不太喜欢管的，但是因为这个妹子明天必需要回家，车票买好了， 所以要把这个问题解决就必须在今天晚上， 让一个妹子加班到凌晨，我有些于心不忍， 一个如花似玉的小姑娘， 半夜一个人回家， 要是碰到坏人， 场面不敢想象。 于是我也上前去凑热闹了，说不定能帮上忙呢。

 

了解了问题来龙去脉后，发现这个问题在自己的技术认知范围内的确没有靠谱的解决方案，除非修复插件BUG或将插件替换，但是这两种方案都不是短时间内可以完成的。我闭上眼睛思考，既然是个BUG ，那肯定不是必现的，如果不去触发这个BUG ，那也算是把问题解决了。我脑子中灵光一闪，似乎抓到了一丝线索。我开始调式程序，总共10条数据

 

设为每页显示4条，显示结果为4条3条3条

 

设为每页显示3条，显示结果为3条3条2条2条

 

设为每页显示2条，显示结果为2条2条2条2条2条，一切正常， 没有触发BUG

 

我找到了规律，不触发BUG的情况是数据总条数必须能被每一页显示条数整除，这也就意味着，每页4条不能变，那只要把数据总条数变为12就可以。为验证我猜想， 我在原有的基础上加了2条数据， 测试运行， 原来的BUG消失了， 分页显示变的正常了。找到解决方案，接下来的事情就简单了， 只要让数据总数保持为4的倍数，再加上一些收尾的工作，问题完美解决， 整个过程花了不到10分钟的时间。

 

插件的BUG还在那里，根本没有被修复，但是用户反馈的问题却修好了，能用的舒服，程序员也不用加班了，两全其美。事后我仔细思考，我没应用什么别人不会的高大上技术，只是转变了一下思路，就轻松巧妙的将问题解决了，很有一种四两拨千斤的感觉。那是不是也可以把这种解决问题的思路推广到其它方面呢？

 

回忆过去，我以前也经常以这种思路在解决问题，只是过程与成果并没有显得非常的尖锐和突出。

 

之前，我的一个网站被恶意攻击者注入垃圾信息，整个网站满屏不堪入目的内容。我迫切需要解决这个问题，但网站的源代码在家中电脑上，我没有办法通过修改程序漏洞解决问题。现在手头唯一拥有的是数据库操作权限，但是把数据删了，恶意程序立马又注入新的，治标不治本啊。正愁眉不展间， 脑中灵光一闪， 方案出来了， 我可以在那个被注入表上加一个before触发器， 触发器的程序检测被写入的记录， 假如是来自恶意攻击的数据，就执行回滚操作，不让数据写入表中。花了十分钟写了十几行SQL，问题解决。程序的BUG还在那里，注入者的机器人程序还在不停的攻击，但是管他呢，我的最终目的达到，用什么方法根本不重要。邓爷爷都说过：能抓老鼠的就是好猫

 

还有一次，碰到一个不靠谱的需求，需求方发给我一个网站，说对这个网站不满意，让我改上面的功能。网站源代码没有，网站服务器权限没有，总之是什么都没有，完完全全是一个别人家的网站，让我改上面的功能，这尼玛任性的可不是一点点，真把程序员当神仙了。换作别人，估计一巴掌就把需求给搧回去了。但偏偏是我，真就把这个问题给解决。你们是不是以为我把人家网站的服务器给黑了，把代码down下来，改成自己想要的样子。当然不是，我是一个法律意识很强的程序员，不会干这种蠢事。我的做法是为那个网站开发一个chrome浏览器插件，插件里面有想要的功能。只要用户装上这个插件，每当访问这个网站，插件功能就被激活，供用户使用。可以把这个插件想象成游戏的外挂，只是功能没那么复杂。

 

上面讲的这些便是软件开发中湾道超车，曲线救国的做法。我对于程序开发理解是，写程序就是解决问题，问题摆在那里，不哭不闹不动不跳，因为在我眼里它就是死的。而解决问题的方法却是活的，只要愿意去发掘，就会有无数种， 而且这无数种方法中，优劣好差各不相同，程序员要做的就是在这么多方法中选择一种最合适的。通常情况的问题，程序员并不用为选哪一种方法而纠结，因数解决问题的方法就像电梯里的美女，一眼就能看的到，连选的力气都能省掉。然而， 在极端情况下， 解决问的方法匮乏， 而且都是歪瓜裂枣， 要找到合适的真的不容易 。在这种情况下，光靠脑子灵活眼光独到还不够，程序员需要能在这些烂方法中找到一种最好的，然后驾驭之。会找好方法和驾驭这个被找到的方法，这是两种能力，相互依赖，相辅相成，如能掌握并融会贯通，那么程序员的战斗力将会被发挥到极至。

 

我自己也在一直朝这个方向努力，所以我解决问题的指导方针是，用php不行我用java，用nodejs不行我用go；用电脑网页不行我用windows客户端，用手机网页不行我用手机原生应用；目标是解决问题，至于解决问题用什么方法，我从来不会被某一种技术给绑死。很多同学认为， 学这么多语言这么多技术有什么用， 有的语言技术已经如万能仙丹一般， 没有什么问题不能解决的， 如Java。 然而， 我觉得掌握多种技术带来的好处并不仅仅是掌握技术的本身， 更重要的好处在于解决问题时不会受到局限，说的直白一点就是会有更多的方案可供选择，可供选择的方法多了，那自然就有更大的可能选择一种更好的方案，这便是前面说的两种能力中寻找方法的能力。然而，光会寻找方法还不够，还需要能驾驭这种方法，这便是一个深度问题了，想必所有程序员都知道，浮于表面的学习某样技术，意义不大，打嘴炮吹牛逼的程序员会被人看不起，只有真正能解决问题的程序员才值得尊敬。因此，如能做到这两点，你解决问的方法在别人眼里就是神奇的不可思议。

 

最重要的是，这种方式持续久了，解决问题的思维习惯就会发生变化，思维习惯的变化致使考虑问题的方式变的不同，考虑问题的方式变的不同致使解决问的方法变的不同，解决问题的方法变的不同致使解决问题得到效果变的不同。从此， 你便是别的程序员眼中的超人。