标题有些吓人请不要惧怕，不过这的确不是扫盲贴，需要必定的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改需要被程序员拍板砖的图，嘿！需要不稳定，就别开工，甘愿打酱油看博客。好了，啰嗦了这么多，有多少人会看到这儿呢？期望今后有空回头来增加些内容。具体网站