作为一个饱经风霜的程序员,你一定早就习惯了游戏开发中的反复。记得刚来公司的时候就听师兄讲过一个故事:策划在国庆节前突然想模仿微信做一个红包系统,还没等他实现完毕,红包二期的案子就已经写好了。不巧,这个幸运的师兄碰巧要去同学聚会,就暂时没有做。等他请假2天回到公司的时候,惊奇地发现红包二期已经被推翻了,变成了红包三期,师兄长舒一口气,我想此刻他的内心是复杂的,甚至复杂到不能用代码表达~~

那我们的代码到底能不能经得起折腾呢?大概有两种类型的代码让我印象深刻:

1.复杂的继承

计算机专业出身的同学对面向对象编程一定不陌生,这基本上是所有学校的计算机必修课,其实它也对很多公司的游戏架构产生了深远的影响,在我们公司的代码库里,也有它的身影。在长期的维护中,这些本身设计良好的继承关系由于需求的变动不断改变着继承关系,最后的结果就是,出现了很深很深的继承,这样的代码很难维护,就像一个人很难一下说出自己应该如何称呼自己的爸爸的爸爸的爸爸的爸爸的儿子,一个需求的改变可能要求你理清这些类之间的关系,是要先调用父类的函数呢,还是先调用父类的父类的函数呢,还是重写它。你甚至会陷入一种旋涡,这样的设计很难让逻辑清晰。

2.单个文件包含多种功能以及特判

这个可以举一个实际的例子,游戏中有多种不同类型的战斗,在战斗的过程中,我需要显示血条、倒计时、连击数、方向盘、技能面板、伤害排行榜、暂停按钮、托管按钮等等等等。但是不巧,每一种战斗需要的内容是不一样的,比如排行榜只在组队模式下需要,而暂停按钮则不能在PK模式中显示,血条在PK模式要换另一种表现方式。一开始这对我们来说很简单,几个ifelse就可以轻松搞定,但是看看维护了一年之后的UI代码吧,3000行的代码和充斥着整个文件的20多种战斗的特判,没有人敢维护这块代码,因为它基本一改就会在别的关卡中出现BUG。

之前的代码大概是这个样子的,是不是感觉似曾相识呢。