大项目、多人、多团队架构思考
组件之间的逻辑关系
大项目、多人、多团队架构思考
首先，项目规模变大后，模块划分必须遵循一定的原则。如果模块划分规则不规范、不清晰，就会导致代码耦合严重的问题，并加大架构重构的难度。这些问题主要表现在：
- 业务需求不断，业务开发不能停。重新划分模块的工作量越大，成本越高，重构技改需求排上日程的难度也就越大。
- 老业务代码年久失修，没有注释，修改起来需要重新梳理逻辑和关系，耗时长。
其次，我们需要搞清楚模块的粒度采用什么标准进行划分，也就是要遵循的原则是什么。
对于 iOS 这种面向对象编程的开发模式来说，我们应该遵循以下五个原则，即 SOLID 原则。
- 单一功能原则：对象功能要单一，不要在一个对象里添加很多功能。
- 开闭原则：扩展是开放的，修改是封闭的。
- 里氏替换原则：子类对象是可以替代基类对象的。
- 接口隔离原则：接口的用途要单一，不要在一个接口上根据不同入参实现多个功能。
- 依赖反转原则：方法应该依赖抽象，不要依赖实例。iOS 开发就是高层业务方法依赖于协议。
最后，我们需要选择合适的粒度。切记，大型项目的模块粒度过大或者过小都不合适。其中，组件可以认为是可组装的、独立的业务单元，具有高内聚，低耦合的特性，是一种比较适中的粒度。
组件之间的逻辑关系
- 底层可以是与业务无关的基础组件，比如网络和存储等；
- 中间层一般是通用的业务组件，比如账号、埋点、支付、购物车等；
- 最上层是迭代业务组件，更新频率最高。
这样的三层结构，尤其有利于多个团队分别开发维护。比如，一开始有两个业务团队 A 和 B，他们在开发时既有通用的功能、账号、埋点、个人页等，也有专有的业务功能模块，每个功能都是一个组件。
这样，新创建的业务团队 C，就能非常轻松地使用团队 A 和 B 开发出的通用组件。而且，如果两个业务团队有相同功能时，对相应的功能组件进行简单改造后，也能同时适用于两个业务团队。
但是，我认为不用把所有的功能都做成组件，只有那些会被多个业务或者团队使用的功能模块才需要做成组件。因为，改造成组件也是需要时间成本的，很少有公司愿意完全停下业务去进行重构，而一旦决定某业务功能模块要改成组件，就要抓住机会，严格按照 SOLID 原则去改造组件，因为返工和再优化的机会可能不会再有。