iOS 架构.png

一、好的架构漫谈

1.代码整齐，分类明确，没有common，没有core

• 不要让一个类或者一个模块做两种不同的事情，一方面不适合未来拓展，另一方面也造成分类困难

• 不要common，不要core：每个人认为的common和core不一样，同时软件是有生命的，会不断的迭代成长。如果有了common和core最后随着业务和需求的不断变更，一定会使得代码变得一团糟。

2.不要用文档，或者很少用文档就能让业务方上手

• 开发时间紧
• 需求多
• 尽可能的使我们的API名字可读性强

3.思路和方法要统一，尽量不要多元

• 方案要坚定，不要摇摆
• 记录方案的背景，概要设计，详细设计

4.没有横向依赖，万不得已不要出现跨层访问

• 横向依赖杜绝
• 跨层访问有时候无法避免：网络底层里面信号从2G变成了3G变成了4G，这是有可能需要跨层通知到View的。但这种情况不多，一旦出现就要想尽一切办法在本层搞定或者交给上层或者下层搞定，尽量不要出现跨层的情况。跨层访问同样增加耦合度，当某一层需要整体替换的时候，牵扯的面太广。

5.对业务该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件

• 限制：比如网络请求数据回调使用统一方式比如Delegate或者Block
• 灵活：如果是设计一个ABTest相关的API的时候，我们又希望增加它的灵活性，使得业务不光可以通过Target-Action的模式实现ABTest，也可以通过Block的方式实现。尽可能满足灵活性，减少业务方的使用成本

6.易测试，易拓展

• 易测试需要提高模块化程度，尽可能减少依赖关系，便于mock测试。
• 高度模块化容易拓展

7.保持一定量的超前性

• 产品需求：了解产品未来的发展方向
• 技术方案：组件化、动态化、跨平台

8.接口少，接口参数少

• 越少的接口越少的参数，就越能降低业务方的使用成本
• 满足业务方的充要条件

9.高性能

• 重要但是不是第一要素
• 苹果产品的性能已经足够好
• 不能因为优化性能影响稳定性

10.架构分层

• 按照业务分层：三层、四层。逻辑上有几层就恶意分为几次。每层具体做什么，叫什么没有特定的规范。这主要针对模块分类而言
• 按照数据流动：MVC、MVVM
• 业务分层&数据流动结合：
  三层架构：数据管理者、数据加工者、数据展示者
  笼统来说，软件只会有三层，每一层扮演一个角色。其他的第四、第五层一般都是这三层里面的其中之一分出来的，最后都能归纳为这三层中的某一层，所以三层描述比较普遍