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改需求被程序员拍板砖的图，嘿！需求不稳定，就别动工，宁愿打酱油看博客。好了，啰嗦了这么多，有多少人会看到这里呢？但愿之后有空回头来增长些内容。