以下討論內(nèi)容都基于這個方案
問題:沒法使用closing issues via commit messages怎么辦枝冀？
1.測試人員不能準(zhǔn)確知道bug需要發(fā)給哪個業(yè)務(wù)組件或是哪個弱業(yè)務(wù)組件罢洲，甚至有時候這個bug是基礎(chǔ)功能組件造成的桑谍。
2.因為原因1齐唆，所以導(dǎo)致測試人員需要把bug統(tǒng)一發(fā)給主App的git project遣铝。根據(jù)我們的CI流程拧烦，我們沒有辦法把某個業(yè)務(wù)組件的信息(比如某個commit里的message是：Fix#213)通過提merge request的方式帶給主App忘闻。
解決
這個問題并沒有很好的解決。修復(fù)bug還是需要手動關(guān)閉issues恋博。幸好的是齐佳，測試人員會即時通過郵件收到。
問題：發(fā)版效率低怎么辦债沮？
1.package這一步要編譯多個Architecture炼吴，造成CI流程耗時。
2.發(fā)版lint這一步需要Test/Lint源碼/Lint二進(jìn)制疫衩，造成CI流程耗時硅蹦。
3.會同時有多個庫需要跑CI。有些只是例行的Test，有些是走發(fā)版流程童芹，有些是其他App的CI涮瞻。尤其是在周五，大家都準(zhǔn)備今天發(fā)個版回家假褪，都集中在了一起署咽。這種情況造成排隊，需要等待長時間嗜价。
4.git runner數(shù)量少艇抠，造成排隊。也無法充分利用gitlab runner的pipelines并行操作久锥。
解決
1.首先是盡量多搞幾臺runner家淤。比如嘗試使用docker？發(fā)動大家把機(jī)器都做成runner瑟由。
2.減化流程絮重。發(fā)版lint這一步可以不考慮Test，因為平時dev分支普通commit都會觸發(fā)Test歹苦。當(dāng)merge到master發(fā)版時其實可以不用Test青伤。也可以考慮不lint二進(jìn)制，實際情況告訴我們殴瘦，一般報錯或警告都是源碼部分狠角，二進(jìn)制沒有什么問題。
3.package時依賴庫盡量使用二進(jìn)制庫蚪腋。
4.避免周五大家都發(fā)版丰歌。平時能發(fā)版就發(fā)版。
問題：一旦某個偏底層的庫升級main版本號屉凯，而又不得不使用它時立帖；依賴它的所有庫都要發(fā)版，工作量大怎辦悠砚？
造成這個問題的原因是API不兼容或有重大重構(gòu)晓勇。而且還會在發(fā)版效率低這個問題上雪上加霜。
解決
必須發(fā)版灌旧，這個是沒辦法的绑咱。
1.在設(shè)計之初，充分考慮和驗證枢泰，盡量避免這種情況出現(xiàn)羡玛。
2.如果是重大重構(gòu)問題，必須盡量保證API向前兼容宗苍，做好充分地測試。
3.盡量避免“不得不使用它”這種情況。
問題：一旦某個偏底層的庫升級main版本號讳窟，誰來推動和通知大家把依賴它的庫也升級让歼？
這個問題在小團(tuán)隊中是不存在的，大家吼一聲就行了丽啡。剩下的都是體力活谋右。
但如果是大團(tuán)隊，多團(tuán)隊补箍，異地改执，多公司這種情況。就很難辦了坑雅。
解決
盡量不要辈挂，盡量不要，盡量不要裹粤。重要的事情說三遍终蒂。
問題：自己改自己的，還是大家一起改遥诉？
我發(fā)現(xiàn)我依賴的一個基礎(chǔ)功能組件有一個bug導(dǎo)致了我這個業(yè)務(wù)組件有一個bug拇泣。但這個基礎(chǔ)功能組件不是我維護(hù)的。我是提一個merge request呢矮锈，還是直接把它去改了霉翔？提merge reqeust效率低，可能維護(hù)者在其他Team苞笨，在異地债朵，沒有上班，正在忙等等猫缭。自己去改效率高葱弟，但是風(fēng)險高。我也不確定會不會搞掛其他東西猜丹，如果沒有測試那更是不敢改芝加。感覺也不符合規(guī)矩。
大多數(shù)情況下不是bug射窒，而是需求滿足不了藏杖。我需要加新需求。
無論是重用的資源或是重用的代碼脉顿，它們最終都會變成一個組件蝌麸。而這個組件目的就是給大家服務(wù)的。到底是大家一起改艾疟，還是有專人維護(hù)来吩？
解決
沒有解決方案敢辩。
我們小團(tuán)隊對于這個問題目前不是很棘手。大家都有權(quán)限去改組件弟疆，只要你走正常發(fā)版流程戚长。
問題：業(yè)務(wù)不能準(zhǔn)確劃分。你中有我怠苔，我中有你怎么辦同廉？
一開始我們太單純了，認(rèn)為業(yè)務(wù)一就是一柑司，二就是二迫肖。就算業(yè)務(wù)出現(xiàn)交叉，也只是A業(yè)務(wù)的AViewContrller需要push B業(yè)務(wù)的BViewController而已攒驰。其實不然蟆湖！
比如首頁。首頁是這個App的第一個頁面讼育，每個重要的業(yè)務(wù)組件都希望在首頁占有一席之地帐姻。那這些業(yè)務(wù)的UI和logic寫在哪里呢？寫在PBHomePageBusinessModule里面奶段？不是說好要解耦的么饥瓷，這樣不就耦合在一起了？
那分散在各個業(yè)務(wù)組建里面痹籍，又如何集成到PBHomePageBusinessModule里面呢铆。既解耦，又能正常工作呢蹲缠？
解決
現(xiàn)在有PBTradeBusinessModule棺克、PBLotteryBusinessModule、PBHomePageBusinessModule這三個業(yè)務(wù)組件线定。大家都依賴一個基礎(chǔ)功能組件娜谊，里面提供一個基類YTXInjectedIntoVCManager。大家都知道這個基類斤讥。
PBTradeBusinessModule提供一個Object Method返回一個YTXInjectedIntoVCManager子類實現(xiàn)纱皆。
PBLotteryBusinessModule提供一個Object Method返回一個YTXInjectedIntoVCManager子類實現(xiàn)。
PBHomePageBusinessModule會通過URL獲取兩個YTXInjectedIntoVCManager注入到自己的ViewController里芭商。
YTXInjectedIntoVCManager里面提供一個rootView表示UI部分派草。再定義協(xié)商一些方法，讓PBHomePageBusinessModule的ViewController調(diào)用铛楣；使用delegate反向傳遞信息近迁。
這樣的好處是即避免了耦合，也避免了知道太多業(yè)務(wù)的細(xì)節(jié)（行為/UI）簸州。
比如
#pragma mark - 自生行為
- (void)updateUI:(nullable NSDictionary *) dict;//更新UI
- (void)updateData:(nullable NSDictionary *) dict;//更新數(shù)據(jù)
#pragma mark - 對應(yīng)VC生命周期
- (void)viewDidLoad;
- (void)viewWillAppear:(BOOL)animated;
- (void)viewDidAppear:(BOOL)animated;
- (void)viewWillDisappear:(BOOL)animated;
- (void)viewDidDisappear:(BOOL)animated;
