大项目、多人、多团队架构思考
粒度模块划分问题
首先，项目规模变大之后，模块划分必须遵循一定的原则。如果模块划分不规范清晰，就很容易导致代码耦合严重的问题，进而加大重构的难度，主要表现在：
- 业务需求不断，业务开发不能停。重新划分模块的工作量越大成本越高，重构以及技术改进的需求难度也就越大
- 老业务代码年久失修，没有注释，修改起来需要重新梳理的逻辑关系就会越冗长复杂，耗时长
所以需要搞清楚模块的粒度划分原则，定一个标准出来
针对iOS这种面向对象编程开发模式来说，应该遵循以下五个原则，即是SOLID原则
- 单一功能原则：对象功能要单一，不要在一个对象添加很多的功能
- 开闭原则：扩展是开放的，修改是封闭的
- 里式替换原则：子类对象是可以代替基类对象的
- 接口隔离原则：接口的用途要单一，不要在一个接口上根据不同的入参实现多个功能
- 依赖翻转原则：方法依赖应该抽象，不要依赖实例。 最后选择合适的粒度，大项目的模块粒度过大和过小都不合适
其中，组件是可以组装的，独立的业务单元，具有高内聚低耦合的特性，是比较适中的粒度。iOS开发中的组件，不是单纯的UI控件，也不是一个Viewcontroller这种大UI功能的集合，一个粒度太小一个粒度又太大。iOS组件应该是包含UI控件、相关多个小功能的合集，是一种适中的粒度模块。
组件逻辑关系的梳理和改造
组件解耦不是说要求每个组件之间都没有耦合，组件之间也需要由上下层的依赖关系，组件的上下关系梳理清楚了就会更容易维护和管理，我一般都会分为不超过三个层级；
- 底层可以是与业务无关的基础组件，比如网络和储存之类；
- 中间层组件一般是通用的业务组件，比如账号、埋点、支付等等；
- 最上层是迭代的业务组件，更新频率最高。
这样设计的三层结构，有利于多个团队分别开发和维护，团队A和B，开发的时候有通用的功能，账号，埋点和主页等等，也有各自的业务功能模块，这样每一个功能都是一个组件。
如此新创建的团队C就能非常轻松地使用团队A和B开发的通用组件，团队之间新开发的组件也可以互相通用。
多团队之间如何分工
代码层面上可以通过组件化解决大项目和多人，多团队架构的问题，但是架构问题还涉及到人员结构的架构，或者当公司的APP多了之后，相应的团队就多了，进而需要一个合理的团队结构：
- 首先，需要专门的基建团队，负责业务无关的基础功能 组件和业务通用业务组件的开发；
- 然后每个业务都有一个专门的团队负责开发，业务可以按照耦合度来划分，耦合度最高的业务可以单独划分一个业务团队；
- 基建团队人员应该是流动的，否则个部分之间隔阂度太高，分工边界过于明显，会可能出现基建团队埋头苦干，做得过多，做得不够或是功能不好用的问题，造成严重的资源浪费，这也是工作中会遇到的问题。
我眼中的好架构
组件化是解决项目大，人员多的一种很好的手段，在任何的公司和团队里都没有歧义。组件间的关系协调却没有固定的标准，协调的优劣，成为了衡量架构优劣的一个基本标准。所以再实践中，一般分成了协议式和中间者两种架构的设计方案。
协议式架构设计主要采用的是协议式编程的思路：在编译层面使用协议定义规范，实现在不同的地方从而实现达到分布式管理和维护组件的目的。这总方式也遵循了依赖翻转原则，是一种很好的面向对象变成的实践。
但是缺点有二：
- 由于协式编程缺少统一调度层，导致难集中管理，特别是项目规模变大，团队变多的情况下，架构管控会显得越来越重要；
- 协议式编程接口的定义过于规范，从而使得架构灵活性能不高。当需要引入一个新的设计模式的时候会发现很难融入到现有的架构里面，缺乏架构的统一性。
另一种常用的架构是中间者架构。它采用中间者统一管理的方式，进而控制APP的整个生命周期中间组件的调用关系。同时，iOS对于组件间扣得设计也需要保持一致性，方便中间者统一调用。
拆分的组件都会依赖中间者，组件之间不存在互相依赖关系，所以组件之间 的通讯更容易管理了，中间者也能够轻松添加新的设计模式，使得架构更加容易扩展。