iOS 大型項目開發漫談

做者：CrespoXiao 受權本站轉載。

標題有些嚇人請不要懼怕，不過這確實不是掃盲貼，須要必定的iOS開發基礎。在我多年的碼農生涯中絕大部分時間都是作的小項目，大一些的可能也就是百萬行代碼的樣子，跟Windows系統幾千萬行源碼比簡直就是小巫見大巫。不過，一個iOS項目的源碼有數百萬行算蠻大了。我想說的是，人老是會成長，會擔當更大的責任接受更大的挑戰，終有一天組織會有重要任務交給你。不過軟件開發不是一朝一夕，也不會有多麼的轟轟烈烈，更多的是平淡中無數的細節處理。作大型項目未必就須要多麼高深的技術，也許就是細節的科學處理與規範的管理。

首先說說編程語言的選擇，Objecive-C仍是Swift？我尚未在項目中使用Swift，由於我說服不了本身去用它，它的優點在哪裏，你也不能強迫隊友去學習Swift。固然，不用不表明不會，一入行就用Swift開發無心義產品的人沒資格戴着有色眼鏡鄙視不會Swift的同行。你知道Objecive-C與Swift混編有多少坑嗎？你知道Swift也是跟Objecive-C共用一個Runtime環境嗎？你知道使用了Swift會使得ipa包大10多M嗎？Swift表明將來，Objecive-C是當下。Swift能作的Objective-C都能作，好比Closure徹底就可用Blocks來代替，Tuple徹底能夠用結構體來代替。生產環境用Objective-C，業餘觀望Swift，這就是個人態度。Raywenderlich已經出了一堆Swift的教程，在前沿科技的使用上國內老是慢一個節拍，很大程度上那堵牆阻礙了國內IT從業者的發展，牆的開發者（包括個人信息安全工程老師）終有一天會受到歷史的審判。

再來講說應用架構，真是成也MVC,敗也MVC。若是聽任團隊中的小朋友按他們所理解的MVC來開發，通常狀況下出現的惡果就是類之間高耦合，Controller胖得不像話簡直就成了百寶箱......每一次的版本迭代都會痛苦不堪，若功能很少還能勉強維持功能多了勢必崩塌，就好比世博園中國館吧，再按比例多蓋5層試試看，呵呵。到頭來開發人員實在受不了就只能選擇重構要麼跑路，後者更現實你們都懂，尤爲是業務爲王的企業裏，代碼質量算個屁只要能work，但是好的程序員都是有尊嚴的，deadline或是拍腦殼的政治任務一般會讓程序員疲於應付，厭倦了也就該撤了。言歸正傳，既然MVC顯得臃腫，那就是瘦身唄。一般瘦身後的MVC在iOS界被叫成MVCS或MVVM,這2個固然不是同一個東西，項目選用MVCS仍是MVVM仍是得看你的業務特性。MVCS與MVVM就那麼完美嗎？固然不，MVCS要注意Service/Store的濫用，其中的數據是否會被不一樣的模塊污染。MVVM用得很差也會增長項目的維護難度，我說的是View和ViewModel之間鬆散的綁定關係，在iOS開發中一提到MVVM你們就想到ReactiveCocoa，其實沒有ReactiveCocoa也能夠啊，只是ReactiveCocoa的好處多多，如代碼收斂沒必要寫獲得處都是，其餘好處本身去挖掘吧。

關於工程文件組織結構，不少人是Controllers/Views/Models/Vender...這樣歸類，其實這有個問題，好比你要找ControllerA的TableView用到的cellB類，你還要去Views裏面一個個找，太痛苦了，就算search也仍是苦畢竟不能所見即所得。我通常是按 Module來劃分，每一個Module裏面有Controllers/Views/Models/Stores/API這樣的分類，API是每個接口的請求的封裝，供Store調用，獲得的數據解析實例化爲Model再經過block傳遞給Controller去刷新View，很繞嗎？使用RAC,Controller訂閱Store裏建立的RACSignal也能作到，U can make a try。還有就是Helper與Utility，與業務無關，具備對象性質，提供支持功能的代碼放到Helper，好比建立一個自定義對象的封裝。若是隻是屬於函數或算法，不是對象並且不少地方能用到，就放到Utility，好比排序/加密算法。

工程文件組織結構

關於網絡通訊模塊的設計，我我的認爲應該是每個HTTP請求都應該獨立互不干擾，就是你封裝的POST/GET方法都會建立一個臨時的對象，而長鏈接通常只維持一個實例對象採用單例的方式建立。我會爲每個HTTP 接口請求建立一個API對象，在裏面請求數據，固然了爲了不請求代碼的重複編寫能夠創建一個BASE API類，子類調用父類的請求方法就好了，不一樣的只是接口與參數。思想就是這樣，之後有時間再來說講API類的設計。

關於多線程，在iOS開發中用得最多的就是GCD和NSOperation了，在大部分狀況下GCD就夠用了。可是NSOperation也有它的優點，好比能夠設置併發個數，能夠設置線程間的依賴，能夠暫停和恢復，比較靈活，多線程下載就常常用它。面試中也常常會問GCD與NSOperation的區別，這個本身去查查，資料仍是比較豐富的，底下也有篇關於NSOperation的參考連接。GCD雖然強大，但是仍是有不少人瞎用，真替他們着急，隨便說幾點：

1.濫用dispatch_after作定時器致使crash！不知道還有個東西叫dispatch_source_set_timer嗎？

倒計時

2.不要輕易用dispatch_sync，線程同步方法那麼多爲什麼你恰恰要愛上不應愛的它！尤爲不要在dispatch_async裏面用dispatch_sync，不要問爲何，百度裏面google一下！

3.dispatch_once也就建立單例的時候用用，不要瞎用。dispatch_once是整個app生命週期內只執行一次，不是對象生命週期內只執行一次，大哥！

4.什麼！你竟然不知道用GCD建立串行線程與並行線程！

串行

並行

關於多團隊協做，若是項目用分模塊的方式進行開發，CocoaPods無疑是個很是好的工具。相對獨立的模塊儘可能打成私有pod，這樣，公共平臺把整個項目的框架打好，其餘的業務部門只須要本身創建一個私有pod，使用公共平臺打好的那些私有pod獨立開發調試就好，而沒必要時時提交代碼到主工程，這樣的話會很是麻煩，好比代碼merge衝突，證書衝突，會瘋掉的。當模塊開發完畢再提交到主工程就行了。固然私有pod打多了也麻煩，私有pod依賴更多的私有pod在添加文件到target的時候會很痛苦，Xcode默認是target所有選上的，要跟Apple反饋一下但願他們會解決。

關於數據持久化，最重要的就是保持數據源的一致。還有一個比較重要的就是APP升級以後的向前兼容，那種你一升級app啓動崩潰的問題，多半是新版本的數據結構發生變化，不支持老版本產生的數據或者設置等。我一直偏心sqlite，用得最多的就是FMDB，對CoreData無愛。要知道蘋果本身的app NEWS用的就是FMDB啊，我還記得有人問facebook的工程師「爲啥大家的app速度慢呢」，「because we use core data!」。有個開源庫MagicRecord，對CoreData的深度封裝，我用過，其實也還不錯。

另外，單元測試真的有必要嗎？單元測試可使邏輯清晰化，當你僅僅閱讀單元測試代碼的話，你會發現它們寫的好像編程教科書裏的僞代碼。當TDD的時候，這一點尤爲有用。經過寫單元測試，你能夠很快的把邏輯梳理清楚，而後用代碼來實現它。單元測試能夠下降代碼的耦合度。咱們知道，耦合度高的代碼很難作單元測試，反過來，若是你必須作單元測試，你是不會把代碼寫的耦合度很高的。單元測試可讓你知道你對代碼的修改是否影響到了原來就有的功能，可是這也是全部的迴歸測試均可以作的。單元測試的特色在於：它測試的東西足夠小從而在代碼重構後仍能複用。單元測試是惟一一個可能使覆蓋率達到100%的測試。單元測試開始難，持續作的話會愈來愈容易，由於難主要是由於環境的搭建和樁函數的缺失。單元測試很容易定位Bug，它好像在你的程序中打了無數的斷點。單元測試很費時間，不過，後續改Bug更費時間。

講了這麼多，最後說說需求吧。我認爲在需求評審時應該儘可能拋出細節問題給pm，他們不懂技術，若是需求不肯定就盲目開發，而後中途再改需求，這是很傷士氣的，尤爲是涉及到架構的修改，這讓我想到那張pm改需求被程序員拍板磚的圖，嘿！需求不穩定，就別動工，寧願打醬油看博客。好了，囉嗦了這麼多，有多少人會看到這裏呢？但願之後有空回頭來增長些內容。