luckyyyyy
一个BUG的反思
我自己一直有一个《剑网3》的开源项目叫菊花插件集，虽然目前由于工作原因已经不再维护，但是也算是个人花了较多精力的一个项目，目前也稳定运行服务于百万玩家。
这个项目是基于西山居《剑网3》游戏作为宿主，提供API的所制作的插件，我个人完成了绝大部分代码的编写，由于游戏一直在更新，所以也有些许维护成本，一直到最近，遇到的一件事让我有所反思，技术到底是什么？
绝大多数人是没有开源经验的，开源意味着你需要对这个项目全权负责，代码都是经过验证的，不管是代码规范还是结构，都应该是较优的，为了贡献者所提供的代码统一，你还需要制定一些规则，来保证项目多人协作后的一致性，但在西山居《剑网3》的KGUI项目中，并没有这种规定，大家都是自己按照自己的风格来编码，其造成的结果其实也比较显而易见，修复BUG需要阅读的成本过高，离职后部分代码片段几乎不可维护，但这丝毫并不影响《剑网3》这个项目的发展，玩家基数和运营数据也一直一路飙升。
最近我遇到的事情是因为一个API的变动，导致我的部分功能无法运行，我尝试做了修复，但最终发现是官方的编码导致的BUG，而非API变动，我开始尝试定位错误，但看到了类似下面这样的函数。
OutputItemTip(UI_OBJECT_ITEM_ONLY_ID, dwID, nil, nil, {x, y, w, h, bFixedTip}, bStaticTip, nil, nil, nil, nil, nil, nil, nTipPosType)
这导致我无法继续下去，因为阅读这一函数所消耗的时间，可能比我写这篇文章所花的时间还要长的多，最终我开始向官方求助，提醒他们哪一函数有BUG，让他们修改，但丝毫无反应，也许是他们也无能为力，我尝试换了一种方式，找出了使用相同函数的具体UI位置，他们终于开始着手修复，结果官方的修复让我大吃一惊，他们并不是去修改这个无法阅读的函数，而是直接在调用的地方加了几个无意义的参数。
其实这个函数的确是由于参数移位导致的BUG，但这种修复，也的确过于暴力，没办法我也只能紧随其后，写出了如下代码，意思是在参数数量等于3的时候，在第三个位置追加一个无意义的参数，使其长度变为4。
local KItemInfo = GetItemInfo(data[1], data[2])
if KItemInfo.nGenre == ITEM_GENRE.BOOK and #data == 3 then -- fix item box bug
table.insert(data, 3, 99999)
end
一开始我有点无法理解，但后来想想其实这么修复也不全无道理，因为对于这种无法阅读的函数所花费的时间，的确是应该想办法快速修复才是，但对这种方式，出于对技术的热衷，我个人并不认同，应该归根究底重写函数，但从整个项目角度来说，这的确无可厚非。
从项目角度来说，技术是服务于项目的，团队协作中，尽可能不让大家彼此浪费时间，虽然写这个超10个参数的同学的确有问题，但也应在保证项目能按时完成的前提下，再去试图优化和完善我们的代码，如果一开始就追求超高质量的项目，那么这个项目一定无法按时完成，我们应该在两者之间做适当的取舍。
如果是单纯做项目的话，为了工程进度代码方面不够优美是完全可以理解的 如果是若为一个平台接入方，是因为尽量避免这种代码的，(ps：吃过这种亏，后来各种填坑) 既然剑三作为一个平台这中直接加无效参数的做法是不是emmmm 有点不妥当？？？
