今天闲聊一下可持续性架构设计的秘诀，总共八个字：概念拆解，重组改造。
说到新开发一个技术工程，很多同学会引用需求拆解的思路，自顶向下拆解子需求，做对应的层次模块设计，然后直接按照拆解结果分模块编码。依照这样的思路，虽然最终架构形态比较符合预期，但不一定能够保障长线迭代。这是因为，技术实现始终是自底向上，而不是自顶向下的，如果说在拆解过程中，思考深度不够，没有触及到底层概念的粒度，那么技术实现的结果，必然是失去可扩展性——上层隐含的底层概念跟需求强绑定，导致底层功能无法拆分出来，不能适配更多场景，最终不断堆积，就产生了技术债。
这个问题需要如何解决？举一个游戏领域的例子。以客户端自动化测试为例，我们期望的一个效果，是要通过客户端自动化测试工具，可以代替人力做游戏场景遍历，解决遍历冒烟测试耗时的问题。为了解决这个问题，可以简单做子问题拆解：
- 自动化的设备？安卓设备。
- 自动化的驱动方式？UI+Lua脚本驱动。
- 要做自动化的业务模块？副本、大世界寻宝和寻路系统。
- 用例的触发方式？本地PC上人工执行。
因此，我们不难设计一个简单的自动化测试框架，里面包含设备连接、UI/脚本驱动、用例管理以及CMD执行四个模块。框架层实现这些就完事，之后就可以专注编写每个场景的流程逻辑了。游戏测试业界，也基本止步于此。
这样的一个框架，能够支撑的了更多自动化用例的维护么？答案是不能。究其原因，就是框架在设计时，仅仅考虑了需求效果，做了浅层的问题拆解，而没有考虑技术实现的依赖关系，做深层次的基础概念拆解。如果框架只有这些功能，那么写出来的自动化用例代码必然是又臭又长，难以维护。
代码冗长的问题怎么解决？需要抽取共性，做更细粒度的模块化。共性在哪里？有两个点。首先是玩家操作，比如传送到世界的某个坐标，和某个物件交互，进入退出某个UI状态，这些操作是很多自动化用例都共有的，所以可以单独提出来。其次是行为模式，比如打主线任务和支线副本，都遵循一套行为模式——接一个任务，完成一个任务，再判断整个任务流程是否结束。这些行为模式可以抽象成单独的类，实际执行只需要关注特定入参，不需要每次都编码整个流程，这样就能够有效减少用例代码量。
通过抽象玩家操作和行为模式，不仅可以有效提升编码效率，而且也能够降低维护成本。这便是自动化测试框架提升品质的要点。
概念拆解，重组改造，其核心要思考的便是，如何在自顶向下的需求拆解和自底向上的技术实现之间，不断优化这个“最大公约数”。需求是不可控的，技术实现是可控的，就和打麻将一样，我们永远无法确认下一个进张一定是什么牌，但组牌的权利一定永远掌握在我们自己手中。因此，为了让技术实现能够更具备可持续性，我们才需要把所有概念打碎，理顺概念之间的依赖和层次关系，再根据灵活组合不同的概念体系，以达到不同需求预期的效果。除了向着预期的牌型组牌之外，也要兼顾其它牌型的可能性，把牌打活。这样做技术设计，就可以应对频繁的需求变更，不至于积重难返。