美文网首页iOS备忘录
iOS App组件化开发实践之需要思考的问题

iOS App组件化开发实践之需要思考的问题

作者: 曹俊_413f | 来源:发表于2017-05-19 11:29 被阅读84次

    以下讨论内容都基于这个方案

    问题:没法使用closing issues via commit messages怎么办?

    1.测试人员不能准确知道bug需要发给哪个业务组件或是哪个弱业务组件,甚至有时候这个bug是基础功能组件造成的。
    2.因为原因1,所以导致测试人员需要把bug统一发给主App的git project。根据我们的CI流程,我们没有办法把某个业务组件的信息(比如某个commit里的message是:Fix#213)通过提merge request的方式带给主App。

    解决

    这个问题并没有很好的解决。修复bug还是需要手动关闭issues。幸好的是,测试人员会即时通过邮件收到。

    问题:发版效率低怎么办?

    1.package这一步要编译多个Architecture,造成CI流程耗时。
    2.发版lint这一步需要Test/Lint源码/Lint二进制,造成CI流程耗时。
    3.会同时有多个库需要跑CI。有些只是例行的Test,有些是走发版流程,有些是其他App的CI。尤其是在周五,大家都准备今天发个版回家,都集中在了一起。这种情况造成排队,需要等待长时间。
    4.git runner数量少,造成排队。也无法充分利用gitlab runner的pipelines并行操作。

    解决

    1.首先是尽量多搞几台runner。比如尝试使用docker?发动大家把机器都做成runner。
    2.减化流程。发版lint这一步可以不考虑Test,因为平时dev分支普通commit都会触发Test。当merge到master发版时其实可以不用Test。也可以考虑不lint二进制,实际情况告诉我们,一般报错或警告都是源码部分,二进制没有什么问题。
    3.package时依赖库尽量使用二进制库。
    4.避免周五大家都发版。平时能发版就发版。

    问题:一旦某个偏底层的库升级main版本号,而又不得不使用它时;依赖它的所有库都要发版,工作量大怎办?

    造成这个问题的原因是API不兼容或有重大重构。而且还会在发版效率低这个问题上雪上加霜。

    解决

    必须发版,这个是没办法的。

    1.在设计之初,充分考虑和验证,尽量避免这种情况出现。
    2.如果是重大重构问题,必须尽量保证API向前兼容,做好充分地测试。
    3.尽量避免“不得不使用它”这种情况。

    问题:一旦某个偏底层的库升级main版本号,谁来推动和通知大家把依赖它的库也升级?

    这个问题在小团队中是不存在的,大家吼一声就行了。剩下的都是体力活。

    但如果是大团队,多团队,异地,多公司这种情况。就很难办了。

    解决

    尽量不要,尽量不要,尽量不要。重要的事情说三遍。

    问题:自己改自己的,还是大家一起改?

    我发现我依赖的一个基础功能组件有一个bug导致了我这个业务组件有一个bug。但这个基础功能组件不是我维护的。我是提一个merge request呢,还是直接把它去改了?提merge reqeust效率低,可能维护者在其他Team,在异地,没有上班,正在忙等等。自己去改效率高,但是风险高。我也不确定会不会搞挂其他东西,如果没有测试那更是不敢改。感觉也不符合规矩。

    大多数情况下不是bug,而是需求满足不了。我需要加新需求。

    无论是重用的资源或是重用的代码,它们最终都会变成一个组件。而这个组件目的就是给大家服务的。到底是大家一起改,还是有专人维护?

    解决

    没有解决方案。

    我们小团队对于这个问题目前不是很棘手。大家都有权限去改组件,只要你走正常发版流程。

    问题:业务不能准确划分。你中有我,我中有你怎么办?

    一开始我们太单纯了,认为业务一就是一,二就是二。就算业务出现交叉,也只是A业务的AViewContrller需要push B业务的BViewController而已。其实不然!

    比如首页。首页是这个App的第一个页面,每个重要的业务组件都希望在首页占有一席之地。那这些业务的UI和logic写在哪里呢?写在PBHomePageBusinessModule里面?不是说好要解耦的么,这样不就耦合在一起了?

    那分散在各个业务组建里面,又如何集成到PBHomePageBusinessModule里面。既解耦,又能正常工作呢?

    解决

    现在有PBTradeBusinessModule、PBLotteryBusinessModule、PBHomePageBusinessModule这三个业务组件。大家都依赖一个基础功能组件,里面提供一个基类YTXInjectedIntoVCManager。大家都知道这个基类。

    PBTradeBusinessModule提供一个Object Method返回一个YTXInjectedIntoVCManager子类实现。
    PBLotteryBusinessModule提供一个Object Method返回一个YTXInjectedIntoVCManager子类实现。

    PBHomePageBusinessModule会通过URL获取两个YTXInjectedIntoVCManager注入到自己的ViewController里。

    YTXInjectedIntoVCManager里面提供一个rootView表示UI部分。再定义协商一些方法,让PBHomePageBusinessModule的ViewController调用;使用delegate反向传递信息。

    这样的好处是即避免了耦合,也避免了知道太多业务的细节(行为/UI)。

    比如

    #pragma mark - 自生行为
    
    - (void)updateUI:(nullable NSDictionary *) dict;//更新UI
    
    - (void)updateData:(nullable NSDictionary *) dict;//更新数据
    
    #pragma mark - 对应VC生命周期
    
    - (void)viewDidLoad;
    
    - (void)viewWillAppear:(BOOL)animated;
    
    - (void)viewDidAppear:(BOOL)animated;
    
    - (void)viewWillDisappear:(BOOL)animated;
    
    - (void)viewDidDisappear:(BOOL)animated;
    

    相关文章

      网友评论

        本文标题:iOS App组件化开发实践之需要思考的问题

        本文链接:https://www.haomeiwen.com/subject/tkhyxxtx.html