重构心得
最近一直在做有关技能和战斗相关的代码整理，也史无前例血泪交加的进行了3次重构，程序员果然是一群与众不同的群体，如此的乐于推翻自己过往的工作，却又乐此不疲。
但是话说回来，每一次的重构都带来的意想不到的效果，虽然说中途会遇到一些小问题，但是大体上来说，重构带来的好处是非常多的，特别适合项目前期探索阶段。
战斗技能的脚本系统
一般游戏都免不了需要接触战斗系统，战斗无非就是单位/技能/Buff/飞行物/事件这些模块而已。而这其中的核心就是技能。 最开始做的一版架构下，每一个技能都由脚本进行处理，通过技能表直接映射到技能文件，新加一个技能新写一个脚本文件，这样的好处是，技能逻辑可以做的非常灵活，而且调试也比较方便，直接在相应的技能中output或者断点就好了。
第二次重构
不过上述做法缺点也是很明显的，新加一个技能必须重新新一些一个脚本。虽然可以通过模版的方式减少后续的操作，但是追求完美的程序是不会止步于此（闲的蛋疼）的，考虑到多数技能可能只是中途的某些元素不一样，其实多数流程大体上都差不多（造成伤害，搜索单位，移动目标，显示特效，播放动作，等等），那么我们是不是可以将这些元素独立出来，并提供一个可以配置的机制，这样任何一个技能只是基础元素的组合，程序只需要维护一个个的基础元素就好。这样就形成了第二次重构的思路基础。具体设计上，我们独立出来了一个效果的概念，技能可以拥有多个效果，效果可以主动施放的时候触发，也可以被动监听事件的时候触发，效果内部是一个个的基础元素，我们称之为操作，操作附带条件，这样一个效果内就形成了一个简单的逻辑，技能施放本质上就是走效果内部的逻辑流程。工作中实际情况是，重构结束后技能应用配置上也确实达到了预期的效果，程序员不用再维护一个个的技能了，确实蛮爽的，但是需要着重注意的一点是，对基础元素的设计一定要慎重，我们现在光是伤害就有5种基础的操作，没办法，需求就是要支持不同类型。所以基础元素的设计一定要根据具体的游戏需求来。
第三次重构
最开始的设计上，逻辑和显示是一一对应的，完全的所见即所得，游戏中进行到了什么步骤，比如回合制中等待玩家操作，单位A移动中这些情况下，逻辑也是完全处于这个状态的，这种设计的好处是在于，所见即所得，调试清晰，缺点也非常的明显，就是逻辑和显示存在耦合。举个例子就是施放技能，当显示复杂一些的时候，逻辑甚至需要去读取某一个模型的执行时间来决定逻辑自身需要协程式的卡住多久，这种设计下实现逻辑会非常复杂，特别是逻辑存在各种各样事件的时候。这个需求促使了我们进行了第三次重构。首先我们分析，由于我们自己是一个回合制游戏，游戏中并不存在过多的玩家操作，甚至可以非常简化，即轮到玩家的操作，施放一下技能，后续的逻辑（直到下一轮之前）都是确定的。那么我们可以这样设计：玩家操作后（主要是技能施放），逻辑就开始进行运算，在一帧之内将所有的结果都计算完毕，亦即逻辑已经停留在了下一回合阶段，在这个过程中逻辑会输出一系列的显示流，通知显示进行处理。显示层根据显示流来进行一个个具体表现的处理，诸如显示单位，播放动作，播放特效等等。这样的好处是，将复杂的表现和清晰的逻辑分开，表现层只关心自己的表现，而逻辑可以更清晰的处理自己最终输出数据的结果，分离的算是比较完美。这种设计的复杂度会更多的交给表现，甚至是表现需要负责进行表现的排序处理等等。不过这种设计带来的好处实在是太多了，过往我们需要做诸如游戏开始后整个逻辑屏幕抖动一下/播放各种特效后游戏才真正开始这样的效果，是需要修改逻辑的，现在逻辑已经完全不关心这个了，全部交给表现来处理，可以做很多丰富的效果。
总结
总而言之，对于产品来说，好的游戏都是磨出来的，而对于程序来说，好的设计也都是重构出来的。 与君共勉！！！
