標(biāo)題有些嚇人請不要害怕则拷，不過這確實不是掃盲貼贡蓖，需要一定的iOS開發(fā)基礎(chǔ)。在我多年的碼農(nóng)生涯中絕大部分時間都是做的小項目煌茬，大一些的可能也就是百萬行代碼的樣子斥铺，跟Windows系統(tǒng)幾千萬行源碼比簡直就是小巫見大巫。不過宣旱，一個iOS項目的源碼有數(shù)百萬行算蠻大了仅父。我想說的是叛薯，人總是會成長，會擔(dān)當(dāng)更大的責(zé)任接受更大的挑戰(zhàn)笙纤，終有一天組織會有重要任務(wù)交給你耗溜。不過軟件開發(fā)不是一朝一夕，也不會有多么的轟轟烈烈省容，更多的是平淡中無數(shù)的細(xì)節(jié)處理抖拴。做大型項目未必就需要多么高深的技術(shù)，也許就是細(xì)節(jié)的科學(xué)處理與規(guī)范的管理腥椒。
首先說說編程語言的選擇阿宅，Objecive-C還是Swift？我還沒有在項目中使用Swift笼蛛，因為我說服不了自己去用它洒放，它的優(yōu)勢在哪里，你也不能強(qiáng)迫隊友去學(xué)習(xí)Swift滨砍。當(dāng)然往湿，不用不代表不會，一入行就用Swift開發(fā)無意義產(chǎn)品的人沒資格戴著有色眼鏡鄙視不會Swift的同行惋戏。你知道Objecive-C與Swift混編有多少坑嗎领追？你知道Swift也是跟Objecive-C共用一個Runtime環(huán)境嗎？你知道使用了Swift會使得ipa包大10多M嗎响逢？Swift代表未來绒窑，Objecive-C是當(dāng)下。Swift能做的Objective-C都能做舔亭，比如Closure完全就可用Blocks來代替些膨，Tuple完全可以用結(jié)構(gòu)體來代替。生產(chǎn)環(huán)境用Objective-C钦铺，業(yè)余觀望Swift傀蓉，這就是我的態(tài)度。Raywenderlich已經(jīng)出了一堆Swift的教程职抡，在前沿科技的使用上國內(nèi)總是慢一個節(jié)拍葬燎，很大程度上那堵墻阻礙了國內(nèi)IT從業(yè)者的發(fā)展，墻的開發(fā)者（包括我的信息安全工程老師）終有一天會受到歷史的審判缚甩。
再來說說應(yīng)用架構(gòu)谱净，真是成也MVC,敗也MVC。如果放任團(tuán)隊中的小朋友按他們所理解的MVC來開發(fā)擅威，一般情況下出現(xiàn)的惡果就是類之間高耦合壕探，Controller胖得不像話簡直就成了百寶箱......每一次的版本迭代都會痛苦不堪，若功能不多還能勉強(qiáng)維持功能多了勢必崩塌郊丛，就比如世博園中國館吧李请，再按比例多蓋5層試試看瞧筛，呵呵。到頭來開發(fā)人員實在受不了就只能選擇重構(gòu)要么跑路导盅，后者更現(xiàn)實大家都懂较幌，尤其是業(yè)務(wù)為王的企業(yè)里，代碼質(zhì)量算個屁只要能work白翻，可是好的程序員都是有尊嚴(yán)的乍炉，deadline或是拍腦袋的政治任務(wù)通常會讓程序員疲于應(yīng)付，厭倦了也就該撤了滤馍。言歸正傳岛琼，既然MVC顯得臃腫，那就是瘦身唄巢株。通常瘦身后的MVC在iOS界被叫成MVCS或MVVM,這2個當(dāng)然不是同一個東西槐瑞，項目選用MVCS還是MVVM還是得看你的業(yè)務(wù)特性。MVCS與MVVM就那么完美嗎阁苞？當(dāng)然不随珠，MVCS要注意Service/Store的濫用，其中的數(shù)據(jù)是否會被不同的模塊污染猬错。MVVM用得不好也會增加項目的維護(hù)難度，我說的是View和ViewModel之間松散的綁定關(guān)系茸歧，在iOS開發(fā)中一提到MVVM大家就想到ReactiveCocoa倦炒，其實沒有ReactiveCocoa也可以啊，只是ReactiveCocoa的好處多多软瞎，如代碼收斂不必寫得到處都是逢唤，其他好處自己去挖掘吧。
關(guān)于工程文件組織結(jié)構(gòu)涤浇，很多人是Controllers/Views/Models/Vender...這樣歸類鳖藕，其實這有個問題，比如你要找ControllerA的TableView用到的cellB類只锭，你還要去Views里面一個個找著恩，太痛苦了，就算search也還是苦畢竟不能所見即所得蜻展。我一般是按 Module來劃分喉誊，每個Module里面有Controllers/Views/Models/Stores/API這樣的分類，API是每一個接口的請求的封裝纵顾，供Store調(diào)用伍茄，得到的數(shù)據(jù)解析實例化為Model再通過block傳遞給Controller去刷新View，很繞嗎施逾？使用RAC,Controller訂閱Store里創(chuàng)建的RACSignal也能做到敷矫，U can make a try例获。還有就是Helper與Utility，與業(yè)務(wù)無關(guān)曹仗，具有對象性質(zhì)榨汤，提供支持功能的代碼放到Helper，比如創(chuàng)建一個自定義對象的封裝整葡。如果只是屬于函數(shù)或算法件余，不是對象而且很多地方能用到，就放到Utility遭居，比如排序/加密算法啼器。
關(guān)于網(wǎng)絡(luò)通信模塊的設(shè)計，我個人認(rèn)為應(yīng)該是每一個HTTP請求都應(yīng)該獨(dú)立互不干擾俱萍，就是你封裝的POST/GET方法都會創(chuàng)建一個臨時的對象端壳，而長連接一般只維持一個實例對象采用單例的方式創(chuàng)建。我會為每一個HTTP 接口請求創(chuàng)建一個API對象枪蘑，在里面請求數(shù)據(jù)损谦，當(dāng)然了為了避免請求代碼的重復(fù)編寫可以建立一個BASE API類，子類調(diào)用父類的請求方法就行了岳颇，不同的只是接口與參數(shù)照捡。思想就是這樣，以后有時間再來講講API類的設(shè)計话侧。
關(guān)于多線程栗精，在iOS開發(fā)中用得最多的就是GCD和NSOperation了，在大部分情況下GCD就夠用了瞻鹏。但是NSOperation也有它的優(yōu)勢悲立，比如可以設(shè)置并發(fā)個數(shù)，可以設(shè)置線程間的依賴新博，可以暫停和恢復(fù)薪夕，比較靈活，多線程下載就經(jīng)常用它赫悄。面試中也經(jīng)常會問GCD與NSOperation的區(qū)別原献，這個自己去查查，資料還是比較豐富的埂淮，底下也有篇關(guān)于NSOperation的參考鏈接嚼贡。GCD雖然強(qiáng)大，可是還是有很多人瞎用同诫，真替他們著急粤策，隨便說幾點(diǎn)：
1.濫用dispatch_after做定時器導(dǎo)致crash！不知道還有個東西叫dispatch_source_set_timer嗎误窖？
2.不要輕易用dispatch_sync叮盘，線程同步方法那么多為何你偏偏要愛上不該愛的它秩贰！尤其不要在dispatch_async里面用dispatch_sync，不要問為什么柔吼，百度里面google一下毒费！
3.dispatch_once也就創(chuàng)建單例的時候用用，不要瞎用愈魏。dispatch_once是整個app生命周期內(nèi)只執(zhí)行一次觅玻，不是對象生命周期內(nèi)只執(zhí)行一次，大哥培漏！
4.什么溪厘！你居然不知道用GCD創(chuàng)建串行線程與并行線程！
關(guān)于多團(tuán)隊協(xié)作牌柄，如果項目用分模塊的方式進(jìn)行開發(fā)畸悬，CocoaPods無疑是個非常好的工具。相對獨(dú)立的模塊盡量打成私有pod珊佣，這樣蹋宦，公共平臺把整個項目的框架打好，其他的業(yè)務(wù)部門只需要自己建立一個私有pod咒锻，使用公共平臺打好的那些私有pod獨(dú)立開發(fā)調(diào)試就好冷冗，而不必時時提交代碼到主工程，這樣的話會非常麻煩惑艇，比如代碼merge沖突蒿辙，證書沖突，會瘋掉的敦捧。當(dāng)模塊開發(fā)完畢再提交到主工程就好了。當(dāng)然私有pod打多了也麻煩碰镜，私有pod依賴更多的私有pod在添加文件到target的時候會很痛苦兢卵，Xcode默認(rèn)是target全部選上的，要跟Apple反饋一下希望他們會解決绪颖。（*Development Pods*里面添加文件需要選擇target秽荤，默認(rèn)都是選中的，而我們只需要添加到1個target里面去柠横，依賴太多別的庫就會有很多target窃款。不過沒關(guān)系，不用取消選擇牍氛。添加完文件后執(zhí)行一下pod install/pod update就行了晨继，不用糾結(jié)那些選中的target。）
關(guān)于數(shù)據(jù)持久化搬俊，最重要的就是保持?jǐn)?shù)據(jù)源的一致紊扬。還有一個比較重要的就是APP升級之后的向前兼容蜒茄，那種你一升級app啟動崩潰的問題，多半是新版本的數(shù)據(jù)結(jié)構(gòu)發(fā)生變化餐屎，不支持老版本產(chǎn)生的數(shù)據(jù)或者設(shè)置等檀葛。我一直偏愛sqlite，用得最多的就是FMDB腹缩，對CoreData無愛屿聋。要知道蘋果自己的app NEWS用的就是FMDB啊，我還記得有人問facebook的工程師“為啥你們的app速度慢呢”藏鹊，“because we use core data!”润讥。有個開源庫MagicRecord，對CoreData的深度封裝伙判，我用過象对，其實也還不錯。
另外宴抚，單元測試真的有必要嗎勒魔？單元測試可以使邏輯清晰化，當(dāng)你僅僅閱讀單元測試代碼的話菇曲，你會發(fā)現(xiàn)它們寫的好像編程教科書里的偽代碼冠绢。當(dāng)TDD的時候，這一點(diǎn)尤其有用常潮。通過寫單元測試弟胀，你可以很快的把邏輯梳理清楚，然后用代碼來實現(xiàn)它喊式。單元測試可以降低代碼的耦合度孵户。我們知道，耦合度高的代碼很難做單元測試岔留，反過來夏哭，如果你必須做單元測試，你是不會把代碼寫的耦合度很高的献联。單元測試可以讓你知道你對代碼的修改是否影響到了原來就有的功能竖配，但是這也是所有的回歸測試都可以做的。單元測試的特點(diǎn)在于：它測試的東西足夠小從而在代碼重構(gòu)后仍能復(fù)用里逆。單元測試是唯一一個可能使覆蓋率達(dá)到100%的測試进胯。單元測試開始難，持續(xù)做的話會越來越容易原押，因為難主要是因為環(huán)境的搭建和樁函數(shù)的缺失胁镐。單元測試很容易定位Bug，它好像在你的程序中打了無數(shù)的斷點(diǎn)。單元測試很費(fèi)時間希停，不過烁巫，后續(xù)改Bug更費(fèi)時間。
講了這么多宠能，最后說說需求吧亚隙。我認(rèn)為在需求評審時應(yīng)該盡量拋出細(xì)節(jié)問題給pm，他們不懂技術(shù)违崇，如果需求不確定就盲目開發(fā)循捺，然后中途再改需求潜索，這是很傷士氣的题诵，尤其是涉及到架構(gòu)的修改梢睛，這讓我想到那張pm改需求被程序員拍板磚的圖，嘿伴箩！需求不穩(wěn)定入愧，就別動工，寧愿打醬油看博客嗤谚。好了棺蛛，啰嗦了這么多，有多少人會看到這里呢巩步？希望以后有空回頭來增加些內(nèi)容旁赊。
更多請參考：
