直接使用第三方库能够最大程度缩短开发时长，开发者很难抵挡着近在眼前的“短期红利”，但“魔法神奇库”也有可能阻碍程序排错。本文作者Ben Sandofsky曾领导Twitter iOS应用技术团队，他给出了挑选库时的几条原则。

如果今天能拿到50美元或1年后拿到100美元？你肯定选择前者；但五年后拿到50美元或6年后拿到100美元，你肯定选择后者。这真是不可思议，因为两种选择的时间差仍旧是1年而已。经济学家将这种现象称为双曲贴现（Hyperbolic Discounting），指在面临两种相似选择的情况下，人们往往倾向于更简洁及时的结果，暂且将其称之为“短期红利”吧。

在iOS App上加载第三方库曾是颇费周折的一件事，我们不禁停下脚步扪心自问：这一切真的值吗？后来CocoaPods（OS X 和 iOS 应用开发的第三方库管理工具）将加载过程缩减到秒，开发者就更难抵抗这近在眼前的“短期红利”了。

“短期红利”最吸引人之处在于省时，比如你的App需要一个REST API封装器，那么你是愿意用“魔法神奇库”只花1个小时搞定，还是花1天自食其力呢？

如果是创建原型，那么推荐使用现成的库。我让学生在初始阶段这么做，一来不想让繁琐的细节打击了他们的积极性，二来不想他们错过上交作业的最后期限。

但要开发一个数年屹立不倒的App就不是“一小时 vs 一天”的差别了，而是“100小时 vs 101小时”。这“魔法神奇库”适用于简单一致的API；而Production API牵扯到商业逻辑、边缘情况（edge case）和技术债务（technical debt）等等。产生式系统（production system）并不是十全十美的，“魔法神奇库”也可能阻碍程序排错。

此文无关库或CocoaPods本身，而是给你提个醒（见文章：“due diligence”）。一个团队吃饱了撑的才会花数周来寻找测试员测试代码；转而Google第三方库，选择搜索页面上第一条那个有10,000行代码的，也聪明不到哪儿去。

要知道库的成本并不是一劳永逸的。举个例子，苹果公司一向不怎么待见Core Data的“lock”方法，那要运行时下流行的Core Data封装器的最新版本怎么办？——可以先升级库，但填补5,774行代码空缺谈何容易？升级rename方法就意味着损害App。如果直接运行旧的Core Data，“lock”方法的顾虑也就不复存在了。

CocoaPods能解决依赖图（dependency graph）的问题，但应对不了API混乱（API churn）。如果你直接无视pod版本还能在半年后返回到原点（见文章：“return to the project after six months”），那真是个奇迹了。

总而言之，尽量别太依赖第三方库，能免则免。而且所幸你也用不了那么多。Cocoa网站背景引人注目，但它实际上是个一应俱全的框架，以创新方式提供动画、网络、持久化等App所需元素。

挑选一个库时，我秉持这几条原则。无法获得百分之百赞同是肯定的，但想反驳我，最好准备充分的理由。

1. 高级API避免使用abstraction。

iOS工程师在设计框架时，充分考虑了开发者自由发挥的“度”的问题。UIKit团队本来可以将UITableView进一步抽象，但他们知道要达到60FPS的速度，开发者必须考虑cell循环的问题。

总的来说，苹果公司为C语言提供低层API，为Objective-C提供高层API。如果需要一个简单的照片选择器，用UIImagePickerController，麻烦一点用AVFoundation。苹果公司也会犯错，比如iOS Keychain，还有复杂繁琐的Address Book API。前者已用封装器解决，后者已通过苹果的新Contacts.framework解决。

管理过程中，时不时出现的键盘会拖慢进程。重新布置所有Input View，把它们放在显而易见的位置。如果单纯把问题丢给库来解决，一旦遇到View Controller限制，那么abstraction就会漏洞百出，跟筛子似的。想想automaticallyAdjustsScrollViewInsets失败了多少次啊，它在UIKit里就是View Controller属性。

2. 别太把Boilerplate当一回事儿。

设定Core Data栈需要的20行代码，就好比巫师施法没有祭品一样让人匪夷所思。你可以使用一个Core Data封装器1行代码的Setup，但我的做法是直接复制粘贴样板文件。没错，复制粘贴而已。

初学编码时，别人就告诫你：“切忌重复”。但往往开发者非得浪费几百个小时为干巴巴的代码排错后，才突然明白原来自己一直在“重复”。

如果样板文件让你觉得天旋地转了，就将它重构进类方法吧。这也嫌麻烦的话，就创建一些模型对象（model object）。总而言是目标是迭代为领域模型（domain model）。苹果的框架只负80%的责是有原因的，剩下的20%得靠你了——因为毕竟是你自己的App。

3. 多多不一定益善。

在《代码大全（Code Complete）》一书中，Steve McConnell解释道：project的成本跟代码库规模并非线性扩展的关系。所以做小一点的project比较明智，这不足为奇。

AFNetworking这可能是最受欢迎的开源iOS库了，具有请求序列化、可达性监测以及安全保障等诸多特点。今年四月，研究者却发现了两个严重的安全漏洞，涉及2.1及以上版本用户，两个版本之间时间跨度长达一年。大多数App并不需要使用AFNetwork，为了降低安全风险肯定也不会用到“证书锁定（Certificate pinning）”。

4. 如果问题超出了熟知领域，推荐使用库。

千万不要走极端，自己不了解的东西出了问题，也是要承担责任的。为OAuth排错？还是省点力气吧，库虽然并非完美的解决方案，但它是更好的选择。曾经有人说：“要是库能解决问题，干嘛还费劲搞明白OAuth？”

iOS 5 Beta推出后，我的团队发现了苹果系统中OAuth库的漏洞。多文件上传（Multipart-upload）有问题，照片上传往往失败。那时候iOS 5 API是锁住的，而苹果看样子也没有及时修复问题的意思。所幸我们能善加利用OAuth，最终将苹果框架“糊弄了过去”，解决了问题。

没必要专门去了解OAuth，但是如果你的App用到了OAuth，那么了解至关重要。没有人会在乎是代码出了问题还是库出了问题。关键是——这是你的App，你难辞其咎。

翻译@张新慧     来源@csdn

文章链接：http://www.csdn.net/article/2015-09-15/2825703-when-to-avoid-libraries

原文链接：Medium