[[147407]]

標(biāo)題有些嚇人請(qǐng)不要害怕，不過(guò)這確實(shí)不是掃盲貼，需要一定的iOS開(kāi)發(fā)基礎(chǔ)。在我多年的碼農(nóng)生涯中絕大部分時(shí)間都是做的小項(xiàng)目，大一些的可能也就是百萬(wàn)行代碼的樣子，跟Windows系統(tǒng)幾千萬(wàn)行源碼比簡(jiǎn)直就是小巫見(jiàn)大巫。不過(guò)，一個(gè)iOS項(xiàng)目的源碼有數(shù)百萬(wàn)行算蠻大了。我想說(shuō)的是，人總是會(huì)成長(zhǎng)，會(huì)擔(dān)當(dāng)更大的責(zé)任接受更大的挑戰(zhàn)，終有一天組織會(huì)有重要任務(wù)交給你。不過(guò)軟件開(kāi)發(fā)不是一朝一夕，也不會(huì)有多么的轟轟烈烈，更多的是平淡中無(wú)數(shù)的細(xì)節(jié)處理。做大型項(xiàng)目未必就需要多么高深的技術(shù)，也許就是細(xì)節(jié)的科學(xué)處理與規(guī)范的管理。

首先說(shuō)說(shuō)編程語(yǔ)言的選擇，Objecive-C還是Swift？我還沒(méi)有在項(xiàng)目中使用Swift，因?yàn)槲艺f(shuō)服不了自己去用它，它的優(yōu)勢(shì)在哪里，你也不能強(qiáng)迫隊(duì)友去學(xué)習(xí)Swift。當(dāng)然，不用不代表不會(huì)，一入行就用Swift開(kāi)發(fā)無(wú)意義產(chǎn)品的人沒(méi)資格戴著有色眼鏡鄙視不會(huì)Swift的同行。你知道Objecive-C與Swift混編有多少坑嗎？你知道Swift也是跟Objecive-C共用一個(gè)Runtime環(huán)境嗎？你知道使用了Swift會(huì)使得ipa包大10多M嗎？Swift代表未來(lái)，Objecive-C是當(dāng)下。Swift能做的Objective-C都能做，比如Closure完全就可用Blocks來(lái)代替，Tuple完全可以用結(jié)構(gòu)體來(lái)代替。生產(chǎn)環(huán)境用Objective-C，業(yè)余觀望Swift，這就是我的態(tài)度。Raywenderlich已經(jīng)出了一堆Swift的教程，在前沿科技的使用上國(guó)內(nèi)總是慢一個(gè)節(jié)拍，很大程度上那堵墻阻礙了國(guó)內(nèi)IT從業(yè)者的發(fā)展，墻的開(kāi)發(fā)者（包括我的信息安全工程老師）終有一天會(huì)受到歷史的審判。

再來(lái)說(shuō)說(shuō)應(yīng)用架構(gòu)，真是成也MVC,敗也MVC。如果放任團(tuán)隊(duì)中的小朋友按他們所理解的MVC來(lái)開(kāi)發(fā)，一般情況下出現(xiàn)的惡果就是類之間高耦合，Controller胖得不像話簡(jiǎn)直就成了百寶箱......每一次的版本迭代都會(huì)痛苦不堪，若功能不多還能勉強(qiáng)維持功能多了勢(shì)必崩塌，就比如世博園中國(guó)館吧，再按比例多蓋5層試試看，呵呵。到頭來(lái)開(kāi)發(fā)人員實(shí)在受不了就只能選擇重構(gòu)要么跑路，后者更現(xiàn)實(shí)大家都懂，尤其是業(yè)務(wù)為王的企業(yè)里，代碼質(zhì)量算個(gè)屁只要能work，可是好的程序員都是有尊嚴(yán)的，deadline或是拍腦袋的政治任務(wù)通常會(huì)讓程序員疲于應(yīng)付，厭倦了也就該撤了。言歸正傳，既然MVC顯得臃腫，那就是瘦身唄。通常瘦身后的MVC在iOS界被叫成MVCS或MVVM,這2個(gè)當(dāng)然不是同一個(gè)東西，項(xiàng)目選用MVCS還是MVVM還是得看你的業(yè)務(wù)特性。MVCS與MVVM就那么***嗎？當(dāng)然不，MVCS要注意Service/Store的濫用，其中的數(shù)據(jù)是否會(huì)被不同的模塊污染。MVVM用得不好也會(huì)增加項(xiàng)目的維護(hù)難度，我說(shuō)的是View和ViewModel之間松散的綁定關(guān)系，在iOS開(kāi)發(fā)中一提到MVVM大家就想到ReactiveCocoa，其實(shí)沒(méi)有ReactiveCocoa也可以啊，只是ReactiveCocoa的好處多多，如代碼收斂不必寫得到處都是，其他好處自己去挖掘吧。

關(guān)于工程文件組織結(jié)構(gòu)，很多人是Controllers/Views/Models/Vender...這樣歸類，其實(shí)這有個(gè)問(wèn)題，比如你要找ControllerA的TableView用到的cellB類，你還要去Views里面一個(gè)個(gè)找，太痛苦了，就算search也還是苦畢竟不能所見(jiàn)即所得。我一般是按 Module來(lái)劃分，每個(gè)Module里面有Controllers/Views/Models/Stores/API這樣的分類，API是每一個(gè)接口的請(qǐng)求的封裝，供Store調(diào)用，得到的數(shù)據(jù)解析實(shí)例化為Model再通過(guò)block傳遞給Controller去刷新View，很繞嗎？使用RAC,Controller訂閱Store里創(chuàng)建的RACSignal也能做到，U can make a try。還有就是Helper與Utility，與業(yè)務(wù)無(wú)關(guān)，具有對(duì)象性質(zhì)，提供支持功能的代碼放到Helper，比如創(chuàng)建一個(gè)自定義對(duì)象的封裝。如果只是屬于函數(shù)或算法，不是對(duì)象而且很多地方能用到，就放到Utility，比如排序/加密算法。

工程文件組織結(jié)構(gòu)

關(guān)于網(wǎng)絡(luò)通信模塊的設(shè)計(jì)，我個(gè)人認(rèn)為應(yīng)該是每一個(gè)HTTP請(qǐng)求都應(yīng)該獨(dú)立互不干擾，就是你封裝的POST/GET方法都會(huì)創(chuàng)建一個(gè)臨時(shí)的對(duì)象，而長(zhǎng)連接一般只維持一個(gè)實(shí)例對(duì)象采用單例的方式創(chuàng)建。我會(huì)為每一個(gè)HTTP 接口請(qǐng)求創(chuàng)建一個(gè)API對(duì)象，在里面請(qǐng)求數(shù)據(jù)，當(dāng)然了為了避免請(qǐng)求代碼的重復(fù)編寫可以建立一個(gè)BASE API類，子類調(diào)用父類的請(qǐng)求方法就行了，不同的只是接口與參數(shù)。思想就是這樣，以后有時(shí)間再來(lái)講講API類的設(shè)計(jì)。

關(guān)于多線程，在iOS開(kāi)發(fā)中用得最多的就是GCD和NSOperation了，在大部分情況下GCD就夠用了。但是NSOperation也有它的優(yōu)勢(shì)，比如可以設(shè)置并發(fā)個(gè)數(shù)，可以設(shè)置線程間的依賴，可以暫停和恢復(fù)，比較靈活，多線程下載就經(jīng)常用它。面試中也經(jīng)常會(huì)問(wèn)GCD與NSOperation的區(qū)別，這個(gè)自己去查查，資料還是比較豐富的，底下也有篇關(guān)于NSOperation的參考鏈接。GCD雖然強(qiáng)大，可是還是有很多人瞎用，真替他們著急，隨便說(shuō)幾點(diǎn)：

1.濫用dispatch_after做定時(shí)器導(dǎo)致crash！不知道還有個(gè)東西叫dispatch_source_set_timer嗎？

倒計(jì)時(shí)

2.不要輕易用dispatch_sync，線程同步方法那么多為何你偏偏要愛(ài)上不該愛(ài)的它！尤其不要在dispatch_async里面用dispatch_sync，不要問(wèn)為什么，百度里面google一下！

3.dispatch_once也就創(chuàng)建單例的時(shí)候用用，不要瞎用。dispatch_once是整個(gè)app生命周期內(nèi)只執(zhí)行一次，不是對(duì)象生命周期內(nèi)只執(zhí)行一次，大哥！

4.什么！你居然不知道用GCD創(chuàng)建串行線程與并行線程！

串行

并行

關(guān)于多團(tuán)隊(duì)協(xié)作，如果項(xiàng)目用分模塊的方式進(jìn)行開(kāi)發(fā)，CocoaPods無(wú)疑是個(gè)非常好的工具。相對(duì)獨(dú)立的模塊盡量打成私有pod，這樣，公共平臺(tái)把整個(gè)項(xiàng)目的框架打好，其他的業(yè)務(wù)部門只需要自己建立一個(gè)私有pod，使用公共平臺(tái)打好的那些私有pod獨(dú)立開(kāi)發(fā)調(diào)試就好，而不必時(shí)時(shí)提交代碼到主工程，這樣的話會(huì)非常麻煩，比如代碼merge沖突，證書沖突，會(huì)瘋掉的。當(dāng)模塊開(kāi)發(fā)完畢再提交到主工程就好了。當(dāng)然私有pod打多了也麻煩，私有pod依賴更多的私有pod在添加文件到target的時(shí)候會(huì)很痛苦，Xcode默認(rèn)是target全部選上的，要跟Apple反饋一下希望他們會(huì)解決。

關(guān)于數(shù)據(jù)持久化，最重要的就是保持?jǐn)?shù)據(jù)源的一致。還有一個(gè)比較重要的就是APP升級(jí)之后的向前兼容，那種你一升級(jí)app啟動(dòng)崩潰的問(wèn)題，多半是新版本的數(shù)據(jù)結(jié)構(gòu)發(fā)生變化，不支持老版本產(chǎn)生的數(shù)據(jù)或者設(shè)置等。我一直偏愛(ài)sqlite，用得最多的就是FMDB，對(duì)CoreData無(wú)愛(ài)。要知道蘋果自己的app NEWS用的就是FMDB啊，我還記得有人問(wèn)facebook的工程師“為啥你們的app速度慢呢”，“because we use core data!”。有個(gè)開(kāi)源庫(kù)MagicRecord，對(duì)CoreData的深度封裝，我用過(guò)，其實(shí)也還不錯(cuò)。

另外，單元測(cè)試真的有必要嗎？單元測(cè)試可以使邏輯清晰化，當(dāng)你僅僅閱讀單元測(cè)試代碼的話，你會(huì)發(fā)現(xiàn)它們寫的好像編程教科書里的偽代碼。當(dāng)TDD的時(shí)候，這一點(diǎn)尤其有用。通過(guò)寫單元測(cè)試，你可以很快的把邏輯梳理清楚，然后用代碼來(lái)實(shí)現(xiàn)它。單元測(cè)試可以降低代碼的耦合度。我們知道，耦合度高的代碼很難做單元測(cè)試，反過(guò)來(lái)，如果你必須做單元測(cè)試，你是不會(huì)把代碼寫的耦合度很高的。單元測(cè)試可以讓你知道你對(duì)代碼的修改是否影響到了原來(lái)就有的功能，但是這也是所有的回歸測(cè)試都可以做的。單元測(cè)試的特點(diǎn)在于：它測(cè)試的東西足夠小從而在代碼重構(gòu)后仍能復(fù)用。單元測(cè)試是唯一一個(gè)可能使覆蓋率達(dá)到100%的測(cè)試。單元測(cè)試開(kāi)始難，持續(xù)做的話會(huì)越來(lái)越容易，因?yàn)殡y主要是因?yàn)榄h(huán)境的搭建和樁函數(shù)的缺失。單元測(cè)試很容易定位Bug，它好像在你的程序中打了無(wú)數(shù)的斷點(diǎn)。單元測(cè)試很費(fèi)時(shí)間，不過(guò)，后續(xù)改Bug更費(fèi)時(shí)間。

講了這么多，***說(shuō)說(shuō)需求吧。我認(rèn)為在需求評(píng)審時(shí)應(yīng)該盡量拋出細(xì)節(jié)問(wèn)題給pm，他們不懂技術(shù)，如果需求不確定就盲目開(kāi)發(fā)，然后中途再改需求，這是很傷士氣的，尤其是涉及到架構(gòu)的修改，這讓我想到那張pm改需求被程序員拍板磚的圖，嘿！需求不穩(wěn)定，就別動(dòng)工，寧愿打醬油看博客。好了，啰嗦了這么多，有多少人會(huì)看到這里呢？希望以后有空回頭來(lái)增加些內(nèi)容。