iOS 开发高手课
戴铭
前滴滴出行技术专家
42934 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 47 讲
用户故事 (1讲)
iOS 开发高手课
15
15
1.0x
00:00/00:00
登录|注册

04 | 项目大了人员多了,架构怎么设计更合理?

每个业务由一个专门的团队来负责开发
基建团队负责业务无关的基础功能组件和业务相关通用业务组件的开发
选择合适的粒度,组件是一种适中的粒度
遵循 SOLID 原则
作为开发者,需要了解所在项目的整体架构,思考架构上哪些地方是不够好需要改进的
好的架构需要在一定的规范内同时支持高灵活度
架构的设计需要及早发现开发的痛点,进行有针对性的改良
通过案例分享展示中间者架构的优势
易于扩展,易于维护
中间者统一管理组件间的调用关系
多团队之间如何分工
模块粒度的划分是架构设计中非常关键的一步
需要考虑模块粒度如何划分、如何分层,以及多团队如何协作
经过架构整治,业务解耦,通用功能下沉,每个业务都是一个独立的 Git 仓库,每个业务都能够生成一个 Pod 库,最后再集成到一起
代码集中在一个仓库,导致沟通和等待时间浪费
总结
中间者架构
苹果官方推荐的 App 开发模式是 MVC,但在大型项目中需要考虑其他设计模式如 MVP、MVVM、MVCS
MVC 架构在大型项目中扛不住
项目规模大了以后,客户端团队也被按照不同业务拆分到了不同的地方
怎么设计一个能够支持大型 iOS 工程的架构

该思维导图由 AI 生成,仅供参考

你好,我是戴铭。今天,我要跟你说说怎么设计一个能够支持大型 iOS 工程的架构。
记得以前所在的团队,规模大了以后,客户端团队也被按照不同业务拆分到了不同的地方。当时,所有的代码都集中在一个仓库,团队里面一百多号人,只要有一个人提交错了,那么所有要更新代码的人都得等到修复后提交。这样一天下来,整个团队的沟通和互相等待都浪费了大量时间。同时,开发完成要进行测试时,由于代码相互耦合、归属不清,也影响到了问题排查的效率,并增加了沟通时间。
后来,我们痛定思痛,花了很大力气去进行架构整治,将业务完全解耦,将通用功能下沉,每个业务都是一个独立的 Git 仓库,每个业务都能够生成一个 Pod 库,最后再集成到一起。这样经过架构整治以后,也就没再出现过先前的窘境,开发效率也得到了极大的提升。由此可见,合理的架构是多么得重要。
其实,这并不是个例。当业务需求量和团队规模达到一定程度后,任何一款 App 都需要考虑架构设计的合理性。
而谈到架构治理,就需要将老业务、老代码按照新的架构设计模式进行重构。所以,架构重构考虑得越晚,重构起来就越困难,快速迭代的需求开发和漫长的重构之间的矛盾,如同在飞行的飞机上换引擎。及早考虑架构设计就显得尤为重要。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了大型 iOS 工程的架构设计问题,从作者亲身经历出发,提出了传统的 MVC 架构在大型项目中的不足,并探讨了模块粒度划分、分层设计和多团队协作等关键问题。强调了遵循 SOLID 原则和选择合适的模块粒度对于架构设计的重要性,同时介绍了组件化的概念及实施方法。文章还分享了在团队分工上的见解,强调了团队分工要灵活,围绕具体业务进行功能模块提炼,以解决重复建设的问题。作者还详细介绍了协议式和中间者两种架构设计方案,并重点推荐了中间者架构模式,强调了其易管控和易扩展性,使得整体架构能够长期保持稳健与活力。总的来说,本文为读者提供了宝贵的经验和建议,涵盖了架构设计的方方面面,具有一定的借鉴意义。文章通过案例分享和小结,强调了架构设计的重要性和灵活性,鼓励读者在日常工作中不仅要关注具体业务开发,还要对整体架构有清晰的认识和思考,以提升自身的技术视野和解决问题的能力。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《iOS 开发高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(111)

  • 最新
  • 精选
  • Sasori
    协议化的方式有两个好处,一是可以明确知道组件提供了哪些服务,二是组件一旦修改了接口会立刻引发编译错误,而CTMediator会推迟到运行时。

    作者回复: 是的,CTMediator会在运行时进行管控。其实在中间者那一层加上记录,还能够进行运行时代码覆盖率统计

    2019-03-19
    2
    17
  • 曾剑南
    老师,这里面讲到了架构方面的知识,有什么入门的资料可以推荐一下吗

    作者回复: 入门我推荐阮一峰老师的《软件架构入门》http://www.ruanyifeng.com/blog/2016/09/software-architecture.html

    2019-03-19
    16
  • wang
    组件化架构的目的主要是解耦各个具体业务模块的耦合,而在业务模块的内部也还是需要用到像MVC、MVP、MVVM这些设计模式。 大神,我的理解是没错吧

    作者回复: 是的

    2019-03-19
    3
    10
  • Geek_2844bd
    swift项目架构解藕有什么好的推荐吗

    作者回复: CTMediator 也能用在 Swift 上 https://github.com/ModulizationDemo/SwfitDemo

    2019-03-19
    4
  • 流氓兔
    现在负责的是一个很小的项目,用的还是普通的MVC模式,是否也需要改变架构,就是说,在小型项目中(没有变成大项目的可能性),使用中间者架构会不会更麻烦了

    作者回复: 小型项目其实是可以用中间者架构的,也是为了做大做准备

    2019-03-19
    4
  • Hello灬麦德姆
    戴明老师,我对这个有些疑问,接口隔离原则:接口的用途要单一,不要在一个接口上根据不同入参实现多个功能。假如我需要实现功能,显示或隐藏一个试图,那我是应该写两个方法,一个是func show()一个是func hide()吗,这个隐藏或显示功能应该算一个功能还是两个功能呢?或者说刨根问底,这个功能划分到什么程度呢?

    作者回复: 显示和隐藏都是针对某个视图的展示用,属于相通功能。如果要把视图是否能点击同时当作参数传入控制,就属于两个功能了

    2019-08-14
    3
  • Boomm
    协议式编程接口定义模式过于规范,从而使得架构的灵活性不够高。 老师好,我理解目前主流的协议式编程基本是ModuleManager+Protocol—Class注册的方式. 即组件将提供的服务以Protocol为key, protocol—impl为value,注册到Manager中. 这样调用方不直接依赖组件,只依赖组件提供的Protocol即可. 我认为这里和CT一个很大的不同是调用方除了Manager(中间者)还需要依赖对应的Protocol才能发现服务,而CT只依赖中间者. 但是对于老师提到的Protocol方式过于规范导致灵活性降低,有一点疑惑. Protocol方式如果组件提供的接口有变更,需要修改protocol和对应的impl,而CT同样需要修改CTMediator+组件X这个分类,这里不灵活具体体现在哪里呢? 恳请戴老师解惑!

    作者回复: VSCode 支持开发者开发插件,那么他设计的插件这套架构就是灵活的,多一个插件和少一个插件对于整个 VSCode 不会有影响。微信小程序架构也是类似,这里的灵活是指的这个。

    2019-04-12
    2
    2
  • 几缕阳光
    依赖反转原则:方法应该依赖抽象,不要依赖实例。 这句话应该怎么理解?我有点懵哦,希望大神能举个栗子。

    作者回复: 协议式编程

    2019-04-05
    2
  • Geforceyu
    自己写了一个模块化解耦方案的DEMO,请大佬过过目 https://github.com/Geforceyu/FisherMan

    作者回复: 赞

    2019-03-28
    2
  • 执意为莱
    戴老师,从开是到现在一直是一个人开发,对于组件化或者架构一窍不通,该如何下手呢?

    作者回复: 参与开源项目积累大型项目经验

    2019-03-27
    2
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部