项目发展到现在已经有一年的时间了，在这一年里，我们的crash free一直都保持的很好(99.5%+)。随着功能的不断增加，已经老代码的缺乏维护，逐渐陷入一个难以维护的地步，所以需要进一步去改善目前的架构，所以这里谈谈以前的架构和未来将要改善的一些方式。
开始
最开始的阶段是完全的MVC，这种结构下最明显的问题就是massive controller。当然我们也遇到了这个问题。
此时我们要解决的问题主要有两点：
- 庞大的数据量，超长的页面，以及数据列表间的不同组合
- 不同页面相同数据列表的复用
好在在开始的时候我们就根据我们项目的一些特殊性进行了思考，以及尝试的几种组件化方案。所以在1.1的时候已经明确并且解决了这个问题。
C-MVCs
在美学的表现层组件化之路文章中描述了我们使用DDComponent拆分组件化的方式。
这一次解决了单个页面的多功能模块拆分问题，增加了复用性，也奠定了未来半年的稳定开发基础。
c_mvcs.png
组件统一化
随着时间的推移，组件越来越多，导致同一种资源（比如User）拥有多种不同的component，每个人不同地方都使用了不同的代码，导致维护越来越困难。
所以需要将同一种类型的组件进行统一化和规范化。将目前所使用的组件分为特例组件和通用组件，并尽量在这两个范围内取用。同时每个组件都是经过几轮黑盒测试的，所以基本上不太可能出现bug。
但是这样依然会有问题，在目前应用调整的期间，很多组件都需要重写，重写的质量就很依赖个人了，那么我们统一后的组件依然难以保持很高的质量和通用性。
单元测试
虽然经过上述几次的改善，目前已经没有太大问题。但其中的隐患一直没有被消除，而且在功能的大量增加和人员的变动，这种隐患就更加明显了。所以想要在我们的逻辑层加上单元测试。
关于实现方式之前的文章已经讨论过了，思路就是拆分Controller层，基本上是采用MVP，是否需要辅助Re方案还要继续观察。
c.png
那么最后我们的结构理想中应该是这样
c_mvcs_mvps.png
这样我们将一整个ViewController拆分为多个子组件，子组件保持可测性。
这是目前我们需要去改进的。
模块化
相信，经过上述的改善之后，我们的应用应该会趋于一个比较稳定的时期。那时的功能也会比现在多很多，那么就需要模块化管理，这是后话了，在一段时间内应该还到达不了如此量级。
网友评论