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

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

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

全部留言(111)

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

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

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

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

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

    作者回复: 是的

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

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

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

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

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

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

    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 不会有影响。微信小程序架构也是类似,这里的灵活是指的这个。

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

    作者回复: 协议式编程

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

    作者回复: 赞

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

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

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