利用敏捷软件开发原则重构游戏商店系统

            

利用敏捷软件开发原则重构游戏商店系统

 

【背景】功夫已经成功公测近3个月，庞大的代码量使得项目的维护成本呈现数量级的上升，修改BUG、添加新的功能、去除一些不再需要的功能等等修改，都需要不同程度的影响到其他多个模块的正常运行。在保证现有功能正常运行的情况下，如何使得维护的成本变得更低成为首要考虑的问题？

眼下策划提出需要增加一个物品合成分解的商店，正好借这个机会重构下现有的商店系统。

【原则】重构总是有风险的，《重构——改善既有代码的设计》一书中将重构的方方面面阐述的非常的清楚，这里不打算再重复。要改善现有设计，收益与敏捷软件开发的原则产生若干的灵感：1、单一职责原则SRP；2、开放封闭原则OCP；……更多的阐述参考《敏捷软件开发——原则、模式和实践》

【实践】

原有商店系统的设计缺陷分析：

1、  商店有class ShopSysMgr管理所有的NPC商店，每个不同的商店在这个class中创建实例，从优先使用组合的角度来看这似乎很合理，仔细看看，如果我现在需要增加一个新的商店，那么我需要建立一个新的商店class，而这个新的class的所有数据成员和操作方法都要重新书写，并且没有一个书写的规范，自由度高导致了原有代码没有得到重用……一切从零开始，实在无法忍受了，原来我们的工作都干了啥？

2、  不同商店之间肯定存在一定的共性，要不就不能叫做商店，我始终坚信这一点，《设计模式解析》一书中阐述到OOA的另外一个重要的点：封装变化点，我想大致是这样一种结构：

3、  目前的每个商店一个实例的问题导致了每个商店都保存了一份ShopBase的数据Copy，这也是不必要的冗余数据。

 

针对这些问题首先给物品合成分解商店写了一个测试用例：

   CompositeSys* pComSys=new CmopositeSys;

   //测试物品分解

   ASSERT(pComSys!=NULL);

   tagItemData data;

//分解物品

   pComSys->DecompositeItem(&data);

   //测试物品合成——武器

    pComSys->CompositeItemWeapon(&data,eShape,byLeave);

    //测试物品合成——防具

pComSys->CompositeItemEquip(&data,eType,bySex,byLeave);

是的看来这个类设计应该很简单，只需要三个关键的函数！

但是在原有的设计基础上要完整写一段实现该系统的代码，一个新的开始，实在懒得动手去写，基本上都是复制粘贴，太闹心的体力劳动！

短暂的思考之后我得到了下面的一个静态结构的重构方案：

看起来会好一些，ShopBase能将大多数的可重用的代码封装起来，如果合成分解商店没有特殊的要求的话，那么只需要实现和界面相关的CompositeWnd类了。

简单的画了下大致的商店交易流程图：

流程也很清晰，动手编写CompositeWnd代码了，只需要为每个不同的商店实现不同表现的界面。再增加新的商店就变得很容易了。

【总结】

1、重构随时发生，觉得不合理的地方或者是有点别扭的地方那就放手重构吧；

2、设计模式、敏捷软件开发并不是什么新的理论方法，而是前人经验的总结，不要刻意去要求使用什么什么高深的模式，一步一步来，熟悉了之后，到了那种场合改用那种模式，遵循什么原则，自然是顺手粘来的事。重视平时的积累吧。

 

 

---