重构我们的Flash客户端

原文来之：http://hi.baidu.com/mr%5Fziqiang/blog/item/5565c013ad1b930b5baf5347.html

 

重构是需要勇气和抗压能力的,因为一些原因让我下决心来完成客户端的重构。

1、需求基本都定型了。

2、以前的代码像团乱麻，全部通过关键的全局变量紧密耦合，牵一发动全身。

3、培养的两个人相继离开，让我开始反思如何让人员流动对项目影响最小。

4、以前的东西想到哪做到哪，根本没有任何架构可言。各种代码注释不清，换一个人基本没法改。

5、UI面上冗余数据太多，可没人敢删东西。

6、很多逻辑已经实现，在重构中可以节省考虑逻辑的时间。

我想很多开发Flash项目的公司或者团队都有着同样的问题，一开始策划不明确，数据结构来回改。一边需要建立基础引擎，一边需要准备随时修改，最重要的是工期还在天天逼着你。很多时候我们也就以先实现再说了。

这样的做法并没有问题，不过我们需要有一个人随时关注我们的改变，一旦需求成型我们应当如何迅速形成架构，建立标准和规范。

Flash网游的客户端架构其实并不算复杂，一个典型的MVC结构可以描述完。接下来就是如何来为MVC定义。

模型其实是最好设计的，但是他和我们的策划息息相关，策划不明确我们的模型事件就不好确定。

视图的实现比较简单，不过Flash里面的组件实在太难用了，根本就不是为游戏开发准备的，ASWing由于不是很熟悉我们没有采用。现在的做法是从编码命名上来做规范，使用黑羽的建议，所有AS文件中有关fla素材的内容全部使用"__"双下划线开头，并且所有的UI类都必须有一个initView方法将素材和私有变量关联。这样即使以后需要换肤，只要按照继续按照这个规则。我们仍可以很快实现。

控制层的规划是最不好做的，控制层负责了服务器指令和客户交互等等事情。我现在还在对控制层修改。

提一下通讯层和协议设定：通讯层不算复杂只负责接收数据把各个解析出来的完整数据包丢出来，通过事件让某个控制器接收就行了。通讯层的独立的优点几乎不用说了，什么时候想加密解密或者干点其他的修改就靠他了。

协议设定其实也没啥规定，不过我的做法基本是完全跟着模型(M)走，一个协议只负责一种模型的数据，如果一个操作会对两个模型数据变化，那么就走两个协议，谁也不挨着谁。这样控制器的工作也会单纯一些，谁的就是谁的都别抢。

最后说一下如何控制人员的问题对项目的影响，当然就是一个成型架构+代码工人的模式了。

过些日子发一点用EA软件重构系统的心得和图片。