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

   <p>以下讨论内容都基于这个方案</p>    <h2><strong>问题:没法使用 closing issues via commit messages 怎么办？</strong></h2>    <p>1.测试人员不能准确知道bug需要发给哪个业务组件或是哪个弱业务组件，甚至有时候这个bug是基础功能组件造成的。</p>    <p>2.因为原因1，所以导致测试人员需要把bug统一发给主App的git project。根据我们的CI流程，我们没有办法把某个业务组件的信息(比如某个commit里的message是：Fix#213)通过提merge request的方式带给主App。</p>    <h3><strong>解决</strong></h3>    <p>这个问题并没有很好的解决。修复bug还是需要手动关闭issues。幸好的是，测试人员会即时通过邮件收到。</p>    <h2><strong>问题：发版效率低怎么办？</strong></h2>    <p>1.package这一步要编译多个Architecture，造成CI流程耗时。</p>    <p>2.发版lint这一步需要Test/Lint源码/Lint二进制，造成CI流程耗时。</p>    <p>3.会同时有多个库需要跑CI。有些只是例行的Test，有些是走发版流程，有些是其他App的CI。尤其是在周五，大家都准备今天发个版回家，都集中在了一起。这种情况造成排队，需要等待长时间。</p>    <p>4.git runner数量少，造成排队。也无法充分利用gitlab runner的pipelines并行操作。</p>    <h3><strong>解决</strong></h3>    <p>1.首先是尽量多搞几台runner。比如尝试使用docker？发动大家把机器都做成runner。</p>    <p>2.减化流程。发版lint这一步可以不考虑Test，因为平时dev分支普通commit都会触发Test。当merge到master发版时其实可以不用Test。也可以考虑不lint二进制，实际情况告诉我们，一般报错或警告都是源码部分，二进制没有什么问题。</p>    <p>3.package时依赖库尽量使用二进制库。</p>    <p>4.避免周五大家都发版。平时能发版就发版。</p>    <p>问题：一旦某个偏底层的库升级main版本号，而又不得不使用它时；依赖它的所有库都要发版，工作量大怎办？</p>    <p>造成这个问题的原因是API不兼容或有重大重构。而且还会在发版效率低这个问题上雪上加霜。</p>    <h3><strong>解决</strong></h3>    <p>必须发版，这个是没办法的。</p>    <p>1.在设计之初，充分考虑和验证，尽量避免这种情况出现。</p>    <p>2.如果是重大重构问题，必须尽量保证API向前兼容，做好充分地测试。</p>    <p>3.尽量避免“不得不使用它”这种情况。</p>    <h2><strong>问题：一旦某个偏底层的库升级main版本号，谁来推动和通知大家把依赖它的库也升级？</strong></h2>    <p>这个问题在小团队中是不存在的，大家吼一声就行了。剩下的都是体力活。</p>    <p>但如果是大团队，多团队，异地，多公司这种情况。就很难办了。</p>    <h3><strong>解决</strong></h3>    <p>尽量不要，尽量不要，尽量不要。重要的事情说三遍。</p>    <h2><strong>问题：自己改自己的，还是大家一起改？</strong></h2>    <p>我发现我依赖的一个基础功能组件有一个bug导致了我这个业务组件有一个bug。但这个基础功能组件不是我维护的。我是提一个merge request呢，还是直接把它去改了？提merge reqeust效率低，可能维护者在其他Team，在异地，没有上班，正在忙等等。自己去改效率高，但是风险高。我也不确定会不会搞挂其他东西，如果没有测试那更是不敢改。感觉也不符合规矩。</p>    <p>大多数情况下不是bug，而是需求满足不了。我需要加新需求。</p>    <p>无论是重用的资源或是重用的代码，它们最终都会变成一个组件。而这个组件目的就是给大家服务的。到底是大家一起改，还是有专人维护？</p>    <h3><strong>解决</strong></h3>    <p>没有解决方案。</p>    <p>我们小团队对于这个问题目前不是很棘手。大家都有权限去改组件，只要你走正常发版流程。</p>    <h2><strong>问题：业务不能准确划分。你中有我，我中有你怎么办？</strong></h2>    <p>一开始我们太单纯了，认为业务一就是一，二就是二。就算业务出现交叉，也只是A业务的AViewContrller需要push B业务的BViewController而已。其实不然！</p>    <p>比如首页。首页是这个App的第一个页面，每个重要的业务组件都希望在首页占有一席之地。那这些业务的UI和logic写在哪里呢？写在PBHomePageBusinessModule里面？不是说好要解耦的么，这样不就耦合在一起了？</p>    <p>那分散在各个业务组建里面，又如何集成到PBHomePageBusinessModule里面。既解耦，又能正常工作呢？</p>    <h3><strong>解决</strong></h3>    <p>现在有PBTradeBusinessModule、PBLotteryBusinessModule、PBHomePageBusinessModule这三个业务组件。大家都依赖一个基础功能组件，里面提供一个基类YTXInjectedIntoVCManager。大家都知道这个基类。</p>    <p>PBTradeBusinessModule提供一个Object Method返回一个YTXInjectedIntoVCManager子类实现。</p>    <p>PBLotteryBusinessModule提供一个Object Method返回一个YTXInjectedIntoVCManager子类实现。</p>    <p>PBHomePageBusinessModule会通过URL获取两个YTXInjectedIntoVCManager注入到自己的ViewController里。</p>    <p>YTXInjectedIntoVCManager里面提供一个rootView表示UI部分。再定义协商一些方法，让PBHomePageBusinessModule的ViewController调用；使用delegate反向传递信息。</p>    <p>这样的好处是即避免了耦合，也避免了知道太多业务的细节（行为/UI）。</p>    <p>比如</p>    <pre>  <code class="language-objectivec">#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;</code></pre>    <p> </p>    <p>来自：http://www.yiqixiabigao.com/ios-appzu-jian-hua-kai-fa-shi-jian-zhi-bu-neng-hu-shi-de-wen-ti/</p>    <p> </p>