前Twitter iOS技术团队负责人:使用第三方库的四大准则

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

disanf

如果今天能拿到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

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中