今天闲聊一下可持续性架构设计的秘诀,总共八个字:概念拆解,重组改造。
说到新开发一个技术工程,很多同学会引用需求拆解的思路,自顶向下拆解子需求,做对应的层次模块设计,然后直接按照拆解结果分模块编码。依照这样的思路,虽然最终架构形态比较符合预期,但不一定能够保障长线迭代。这是因为,技术实现始终是自底向上,而不是自顶向下的,如果说在拆解过程中,思考深度不够,没有触及到底层概念的粒度,那么技术实现的结果,必然是失去可扩展性——上层隐含的底层概念跟需求强绑定,导致底层功能无法拆分出来,不能适配更多场景,最终不断堆积,就产生了技术债。
这个问题需要如何解决?举一个游戏领域的例子。以客户端自动化测试为例,我们期望的一个效果,是要通过客户端自动化测试工具,可以代替人力做游戏场景遍历,解决遍历冒烟测试耗时的问题。为了解决这个问题,可以简单做子问题拆解: