本文出处:http://blog.csdn.net/zyb164530322
声明: 本文可以不经作者同意, 任意复制, 转载, 但任何对本文的引用都请保留文章开始前三行的作者, 出处以及声明信息. 谢谢.
一、新的开始(2个月)
2010年底,我开始来到新的公司上班,刚来到的时候,项目组里的成员都是刚接触Flex的,像我这样的居然也当起主力来了,这和我之前所想的要加入到正规的成熟的Flex开发团队里的想法完全不一样了,但是我当时却没有这个念头,而是抱着莫大的信心和勇往无前的尝试心里接下了一个个的任务,在试用期的两个月里,我主要是承担各种工具的开发,由于工具的目的是使用,并不要求架构,所以我疯狂写代码。我感觉我写的代码比我之前一年多的代码量还多,做的东西也多很多,差不多写了四五千行,是磨练代码感的时期。虽然还是用的面向过程的思想,但终于对AS3语言进入熟悉阶段。
二、初步面向对象的掌握(2个月)
试用期时,我觉得自己的这两个月实在是表现优异,应该获得提前转正的待遇,结果没有,有点小郁闷,不过很快又专注到新的工作中。接下来一边完善各种工具,一边开始真正游戏的逻辑开发,大家分模块开始写游戏逻辑。经过疯狂的代码积累,我终于发现当代码量到达一定程度后(五千行),面向过程的项目将不堪重负,难以更改,简直就是一坨屎。于是我开始使用之前一直不太懂的Robotlegs+as3Signal来重构项目,经过一次次的尝试,终于在半懂不懂的情况下将工具重构了,虽然臃肿了很多、依样画的葫芦,可是总算使得项目分工明确、更改便捷。另外一边开始接触到正式的大型ARPG页游的模块开发,主要还是去适应引擎,调用引擎提供的接口和功能,由于在UI方面我也只是之前有过摸索的经验,并没有正式的经验,所以也是在向同事的学习以及使用他们的UI底层来实现的游戏模块界面,在这个过程中,也终于尝试了一个视图一个类的过程,可以说这段时间我的理解就是:多分几个类,根据功能和逻辑分散各个类,使得他们单一,并且用了部分单例以解决整天找不到引用的问题,同时由于对引擎的心跳机制不够了解,而使用自己比较熟悉的as3Signal。另外值得一提的是在推荐使用FDT失败后(因为某些BUG无法解决),对FB使用进入了熟悉和精通的阶段。后期开始使用Flex来快速构建AIR等工具。
三、效率?稳定?(2个月)
在接下来的两个月,游戏进入上线阶段,这个时间由于功能的大量堆积、测试人员的贫乏、发版流程的不规范,导致BUG不断,我秉持着一向以来的快速开发精神,在代码快速累积的时候,也产生了BUG快速累积的问题,通常我提交版本数量是最多的,但是引起的BUG也是最多的,因为我而重新发版的次数也是最多的。同时在代码走读的时候,也被大家发现了我的写法不规范、缺乏有效设计,在被多次的提醒和批评后,我不断地思考产生BUG的原因,一方面提出建议规范流程,一方面控制自己的躁动,多花些时间在设计和考虑周全上。
三、正式面向对象的感悟(至今)
接下来,这段时间我开始一点点近距离接触一个游戏的架构,结合之前各个工具的目的,终于清楚一个游戏的引擎需要哪部分,如何设计使得调用起来方便和高效,从而更好地让自己去写逻辑、去调试、去扩展,最终去完成任务。于是,游戏有条不紊地充实着功能。进而由于对这些设计的觉悟,开始重拾一直没看的《设计模式》,在看了几个设计模式后,领悟所谓的设计模式就是:“解耦,内敛。”所谓解耦就是类和类不是通过直接调用来产生关系,而是使用中间类接口或者消息等来产生关系,从而减少代码混杂和牵一发动全身的风险。所谓内敛就是类的功能尽量单一和微小,尽量少持有引用。同时思考一个项目的整个开发流程,映射到一个模块的开发流程,根据《人月神话》,将目光转移一部分到设计和测试上面来。当有一天,需要给一个还未重构过的工具增加功能的时候,发现要重构的话,如果不使用框架,会多很多冗余代码,而所谓的MVC框架,单单一个功能就值得我去用它了:单例总是要写很多代码,如:
public classs Test
{
private static var m_instance:Test;
public static function GetInstance():Test
{if(m_instance==null){m_instance=new Test();}return m_instance;
}
}
而使用一些框架则不需要,于是,我决定明天使用框架重构那个工具,作出神一样的工具来。
如果说工具和游戏单一模块通常都是自己在阅读和维护,不太需要注重接口和设计,那么制作第三方类库就不是这么回事了,由于类库要提供给其他项目组使用,于是就要考虑使用的方便和对底层实现的透明程度,于是我又一次狠狠地设计了一番,虽然没用到太多“设计模式”,但好歹看起来还像那么回事。