我的思维惯性

    云风最近的一篇文章讲到了Buff的实现，恰好这段时间我也一直在做这块，于是更加留了点心看云风的方案，可在看完之后，却发现原来我也一直处在思维的惯性中。

    在我的实现中，接口基本与云风提到的其同事的方案类似，也是Buff开始时执行一个效果，结束时执行相反的效果。浮点数误差的问题还未考虑，却先遇到了有些属性值有人为的上下限导致添加的数值与减去的数值不匹配的问题。

    后来想到了一个解决方法，却又与云风提到的保存基础值，每次Buff改动时重新计算当前数值的方案有些类似了。但是，在我们的实现里并不是去遍历所有的Buff来取属性追加值，而是每个属性附带多了两个数值，追加点数值和追加百分比值，Buff增加属性值时会把追加的数值累加到对应的位置，重新计算当前值的时候则根据基础值和这两个累加数值来计算。也就是说，每一项改改都保存有四个数值。

    现在看来，这一方案还是有其优势的。因为游戏中不光Buff会对玩家的属性做改变，同时还有装备、被动技能等也会。使用了这一方案后，所有的更改属性操作都有了一个统一的方法，而采用云风提到的Buff的apply方案的话，一个Buff的改动，不光需要遍历所有的Buff，还需要遍历当前装备列表，遍历被动或天赋技能列表，同理，其他的改动也要做此操作。当然，如果说要把所有对属性的改变都做成Buff以统一接口那也可以，方法总是有的，当然也一定还存在更好的。

    技术的分析是题外话，我想到的是当时为什么会这样去设计而不是另一种方案，为什么没有往云风提到的这个方案去想，或者其他的方案上去想。这也就是我的思维惯性吧，当拿到Buff的设计需求时，我的第一反应就是要给它实现一个开始时效果和一个结束时效果，以后的方案设计都是围绕着这两个实际的需求来展开的。

    当实现的过程中遇到了问题时，我也充分发扬了逢山开路遇水搭桥的蛮干精神，一路勇往直前，不曾回头，直到现在的方案出台，策划们也开始着手配置。中间我从未问过自己这个方案是否是最合适的，有没有更好的方案，中间的这些设计是否都合理，当然也从没有其他人对此表示过怀疑。当方案一步步推进，代码一行行增多时，更没有了回头看看的想法，心中所想的只有尽早把这个大摊子收拢吧。

    现在整个的设计实现都完成之后，得以有机会跳出来在高处望一望先前走过的路。感觉就如同看到一个小人在穿越一片迷宫，不停地东穿西跳，虽然干劲十足但方法未见得当，以至于在其中绕出了好几个大圈。

    这也是我感觉到的整个项目的情况，没有看到很好的规划，始终像是在头脑风暴一样，而且还是一个人的头脑风暴，拿到什么就做什么，想到什么方案了就开始往下写代码，等到看到问题了再想下一步该如何实现，遇到要与其他模块交互的时候再考虑接口的提供，没有一个整体感。当然这只是我个人的感受，题外话，一点牢骚而已。