type
status
date
slug
summary
tags
category
icon
password
这篇博客主要探讨代码模块划分的一些思考，基于我在 MeetPhoto、MeetMusic 应用中的个人实践。需要注意的是，这种模块划分的方式和原则，可能与大型应用项目的最佳实践有所不同，仅供读者参考。
模块化
复用
模块化一个重要的意义在于复用，就像框架是用来代码复用一样，如果模块编写的足够独立、简洁、安全、高效，即使是业务模块，也可以在不用项目中复用。例如我在 MeetMusic 和 MeetPhoto 两个 App 复用 biz-settings 模块。
从敏捷开发的角度看，敏捷可以是时间上（开发速度），也可以是空间上（最小可行或进行模块复用），一些公司除了主 App 外，还会推出极速版、探索版等，因为业务和 UI 风格一致，自然可以进行模块复用。比如在探索版上复用账号、主页、设置等模块，这样一个新的 App 只需新开发一个模块，最大程度上提高效率，降低成本。
不要重复你自己
DRY(Don't Repeat Yourself) 原则源自 《The Pargmatic Programmer:From Journeyman to Master》一书，起初，我以为这个原则只是避免重复编写相同的代码。后来，我逐渐意识到，不仅不应重复自己写过的代码，团队成员之间也应避免重复彼此的代码，甚至不应重复 GitHub 上已有的开源代码。更进一步地，如果某个功能、框架或应用已经有人实现，即使自己花时间也能做到，也应考虑避免拾人牙慧。
模块拆分原则
拆分原则：分层解耦、单一职责、易于维护与扩展。
- 业务模块：承载具体业务需求，业务模块之间尽可能解耦。
- 通用模块（功能模块）：包含其他模块经常使用的代码，减少冗余，理论上通用模块不依赖任何业务的数据结构。
- 服务模块（底层模块）：与 native 交互、独立运行的服务等，通常具有跨开发语言、跨进程的特性。