敏捷游戏开发——解放你的大脑

51testing

在游戏开发的过程中，经常需要面对频繁的需求改动，而改动的原因可能是策划的创意发生变化，也可能是游戏的功能需要扩展。需求的变动，是难以捕捉的，我们不能够未卜先知。这些变化，最终会降临到程序员的头上，没人喜欢变来变去，改来改去，人都是懒惰的。　　在修改的过程中，bug不可避免，于是整个程序的多处地方就有可能需要修改，然而并非人人都能够那么细心，所以程序就有可能因为一处修改而崩溃。这时候，有经验的同事就跟我们说，调试进去看看。
　　这很让人烦恼，不是么？忍受着狂占资源的调试器，机器暴卡，眼睛还得一动不动的盯着屏幕，为什么总要搞的人的大脑那么疲惫不堪。有没有什么好的方法让工作变的更轻松呢？答案是有的，我们来看看如何采用敏捷方法来应对它。
　　敏捷，顾名思义，有灵活轻快的意思。它是一种开发思想的转变。首先，敏捷开发欢迎变化。也就是说，当有人要你修改些程序的时候，你不是皱起眉头说，“又要改啊”。而是应该是很开心的问，“改哪里？”，要做到这一点。
　　第一，你的程序功能分的够细，也就是常说的要专注于自己的职责，这里有一条经典的原则，既单一职责原则。但事实上，职责的大或小，都是相对的。例如，一个市长的职责似乎比一个农民的要大，去绞尽脑汁的思考如何划分职责很不理智，结果往往是你自己一次次的否定自己的设计。正如一个人的工作做的好不好，不是自己说了算，而是别人说了算，也就是说，职责是建立在使用者的评价上的。
　　因此，程序的首要目标就是好用，始终已使用者的眼光去设计程序。比如，设计一种车，应该遵循这样的思路，我想要XX样的车，它有XX功能，能够满足我的XX需求。而不是，XX样的车，它有XX样功能。因为需求只有在需要使用它的地方上才有用，凭空构思的需求可能导致不足和浪费。在开发的时候，我们需要纸和笔，让自己的思路清晰。编写代码的时候，可以先顺着思路写伪代码，或者是采用测试驱动开发，不管如何，始终朝着使用的角度去做一个程序，就能够保证它恰倒好处，不大也不小。
　　第二，变化总会产生bug，bug不一定能避免，但应该能快速，准确的定位。当程序崩溃时你怎么办，“调试进去看一下”我的一个工作了7年的同事对我这样说，但我觉得这是迫不得已的方法，“调试进去”的情况一开始就应当避免。再完成了单一职责的划分后，bug的范围已经缩小了不少，但这依然不够。藕荷，是很难避免的，试想一下，你改变了A处，与它相关联的BCD处也可能发生变化，这种变化，必须被捕获到。所以应该尽可能的采用测试开发的方法，在一开始先编写单元测试，如果A发生了改变而影响到了B，那么B的单元测试是通不过的，也就能马上定位bug可能出现的地方。但这种良好的习惯很难坚持，因为大家都比较的懒，不妨试变化的频繁与否来定，经常发生变化的地方则测试驱动，较为稳定的地方则按传统的方式。
　　第三，多做少想。人的智慧来原于下意识，硬着头皮去想问题是很低效的。你投蓝的时候，没有在大脑里先做个抛物线运动的计算把？很多事情，我们考虑的太多了，于是程序员们一个个无精打采，用脑过度的样子（包括我自己），就是因为想的太多。多发挥下意识的力量，少用我们的主官意识去干扰头脑。写程序的时候，不妨尽量写快一点，一气呵成，不让脑子有空闲去胡思乱想。多想的一个重要原因是追求完美，总想把它做的最好，这种精神是可嘉的，但是这样去行动，却是愚蠢的，我们尚且不完美，有怎么能做的出完美的东西呢？凡事够用就好，
　　以上是本人一点点体会，限与水平有限和文字功底淡薄，脑子里想的东西挺多，写出来就只有这么一点了…… 有写的不对的地方请大家指正。
　　多年的心得：
　　1、简单的设计：任何时候都尽量不要使用复杂的设计，即使会带来少许效率的降低，只要能满足需求，比如对于几十个对象的排序，用冒泡就够了，没必要去写个快速排序。BUG数量会随着系统复杂度几何上升的。
　　2、要参与策划的设计：国内大部分策划的逻辑能力是比不上程序的，所以对于策划的设计你要尽量参与，各种不必要的复杂设计要和策划商量修正。
　　3、思定而动：动手前先好好设计设计，把整个体系结构都想好了再动手，可能的话要把未来的变化尽可能的考虑进去。磨刀不误砍柴工。
　　4、设计很重要：好的设计能极大地降低开发成本和维护成本，合理的划分系统，恰当的统一化设计，都能使你能方便的开发，并能使未来的维护工作变得简单。不过怎么才能做个好设计，这依赖于经验和自身能力。