05｜项目诊断与改进：如何进行组件化分析和设计？
Sharing 1.0：案例诊断
代码结构
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何进行组件化分析和设计，以及如何进行项目诊断与改进。作者首先对Sharing 1.0的代码结构和工程管理进行了诊断，指出了单体架构的代码组织方式存在的问题，以及团队缺乏统一的分支模型和工程管理方式。接着，作者提出了改进建议，包括以业务维度来组织代码、采用组件化架构等。在对Sharing 2.0的改进设计中，作者重点介绍了组件化架构的设计，包括组件划分的方法和步骤，以及对Sharing项目进行的组件全景梳理。通过对业务、功能和技术三种组件类型的划分，作者展示了如何将代码组织成独立、松耦合的组件，以实现系统的组合和复用。文章内容丰富，涵盖了项目诊断与改进的多个方面，为读者提供了深入的技术指导和实践经验。文章还介绍了新的架构设计，包括业务层、框架层和基础组件层的组合，以及纵向和横向规则的约束原则。通过本文，读者可以了解到遗留系统常见的架构和工程问题，以及如何进行组件化架构设计，为项目的架构重构提供了有益的参考。
《大型 Android 系统重构实战》，新⼈⾸单¥59
全部留言(4)
- 最新
- 精选
peter置顶请教老师几个问题： Q1：分层时，每层只能是同一类的组件吧。 比如业务层，该层只能是业务组件，不能包含功能组件和技术组件，对吧。 Q2：Sharing这个项目有源码吗？ Q3：按技术维度划分，如果有架构约束和规范，也可以采用，是吗？ 文中有“遗留系统常见的代码组织方式是按技术维度来组织，如果缺少规范和架构约束，非常容易出现代码随意依赖、耦合度高的问题”，从这句话看，如果按技术维度划分，也可以，但前提是要有比较好的架构约束和规范，对吗？ Q4：在具体操作层面，在AS下为每个组件创建项目或module，然后打包成aar或so，在最终的集成项目中引用这些aar或so，是这样吗？ Q5：集成方式中有一种apk,一个项目可以引用一个apk吗？（不清楚此时是如何具体操作的）作者回复: Hi, peter。 Q1：一般情况下一个分层里面是同一类的组件。 Q2：有的（https://github.com/junbin1011/Sharing），后面随着课程推进会持续往这个仓库里面推送相关代码。 Q3：可以。采用什么架构应该结合团队和产品的规模及需求来定。 Q4：后续的持续交付篇会有相关的介绍，你提到的是其中的一种方式。 Q5：在一些插件化的架构中会有插件是以APK的形式，目前组件化架构主要采用的是aar的形式。 期待再次收到你的留言🤝
2023-02-20归属地：北京3
开飞机的老舒克请教老师个问题，就是如果登录、用户信息这些都封装在业务层的用户组件中，但是其他业务组件想使用这里面的功能或者信息的时候是需要在功能组件层提供路由支持吗？例如我在消息组件中需要更具登录态做一些操作之类的功能时，需要和用户组件通信，请问有什么好的通信方式吗？作者回复: Hi，您好。在后续的解耦重构篇会有专门的介绍，期待一起完成专栏的学习🤝。
2023-02-28归属地：北京
迷途的羔羊首页有4个tab，个人中心，和三个其它类型界面，按照这4个界面分4个业务组件可以吗？其它界面按照业务属性归到这四个里面作者回复: Hi，虽然客户端的优势就是通常产品的设计都会将相对内聚的功能组合在一个页面上，方便用户操作。但具体如何划分业务组件还是得根据业务设计来，不一定是几个tab就是几个组件，我们可以拉上产品一起进行一次页面及组件全景梳理。
2023-02-23归属地：上海
Justin怪不得大公司都要分的很细，做好一个大型app不容易作者回复: Hi，Justin。大也是从小不断演化而来了。如果你的产品现在的规模和复杂度还没有这么高或者产品才刚刚开始，没有这么多的问题。那么更应该抓住这个时机，学习如何避免让自己的产品变成一个遗留系统。 期待一起完成专栏的学习🤝。
2023-02-21归属地：上海