仔细想了下模块划分，其实也不简单-量化

我们今天聊一聊研发的依赖问题。

一个App就是一堆git仓库+一堆逻辑的组合，就构成了完整的业务逻辑。

衡量模块划分的标准其实就是 “沟通量”。

换个词语：职责划分、代码边界。

---

常用的划分是功能划分

通过引入各种仓库，给我们的研发带来了边界

api 'jp.wasabeef:glide-transformations:4.0.1'
api "com.github.bumptech.glide:glide:${glide_version}"
//黄油刀
annotationProcessor "com.jakewharton:butterknife-compiler:$rootProject.butterknifeVersion"
api "com.jakewharton:butterknife:$rootProject.butterknifeVersion"

第三方库会明确的程序提供了什么功能，有个主入口。尽量将逻辑都包裹在内部。其主要的设计理念：职责明确出来。
通过编写一堆的interface来定义代码的能力。

这也引出了我们沟通的第一个问题：数据依赖
为了规矩数据依赖，接口定义需要充分考量。
如何定义接口定义是否合理？入参有哪些？

---

核心

• 减少团队沟通频率，提升沟通质量

涉及到3个指标