直接使用第三方庫能夠最大程度縮短開發(fā)時(shí)長(zhǎng)，開發(fā)者很難抵擋著近在眼前的“短期紅利”，但“魔法神奇庫”也有可能阻礙程序排錯(cuò)。本文作者Ben Sandofsky曾領(lǐng)導(dǎo)Twitter iOS應(yīng)用技術(shù)團(tuán)隊(duì)，他給出了挑選庫時(shí)的幾條原則。

如果今天能拿到50美元或1年后拿到100美元？你肯定選擇前者；但五年后拿到50美元或6年后拿到100美元，你肯定選擇后者。這真是不可思議，因?yàn)閮煞N選擇的時(shí)間差仍舊是1年而已。經(jīng)濟(jì)學(xué)家將這種現(xiàn)象稱為雙曲貼現(xiàn)（Hyperbolic Discounting），指在面臨兩種相似選擇的情況下，人們往往傾向于更簡(jiǎn)潔及時(shí)的結(jié)果，暫且將其稱之為“短期紅利”吧。

在iOS App上加載第三方庫曾是頗費(fèi)周折的一件事，我們不禁停下腳步捫心自問：這一切真的值嗎？后來CocoaPods（OS X 和 iOS 應(yīng)用開發(fā)的第三方庫管理工具）將加載過程縮減到秒，開發(fā)者就更難抵抗這近在眼前的“短期紅利”了。

“短期紅利”最吸引人之處在于省時(shí)，比如你的App需要一個(gè)REST API封裝器，那么你是愿意用“魔法神奇庫”只花1個(gè)小時(shí)搞定，還是花1天自食其力呢？

如果是創(chuàng)建原型，那么推薦使用現(xiàn)成的庫。我讓學(xué)生在初始階段這么做，一來不想讓繁瑣的細(xì)節(jié)打擊了他們的積極性，二來不想他們錯(cuò)過上交作業(yè)的最后期限。

但要開發(fā)一個(gè)數(shù)年屹立不倒的App就不是“一小時(shí) vs 一天”的差別了，而是“100小時(shí) vs 101小時(shí)”。這“魔法神奇庫”適用于簡(jiǎn)單一致的API；而Production API牽扯到商業(yè)邏輯、邊緣情況（edge case）和技術(shù)債務(wù)（technical debt）等等。產(chǎn)生式系統(tǒng)（production system）并不是十全十美的，“魔法神奇庫”也可能阻礙程序排錯(cuò)。

此文無關(guān)庫或CocoaPods本身，而是給你提個(gè)醒（見文章：“due diligence”）。一個(gè)團(tuán)隊(duì)吃飽了撐的才會(huì)花數(shù)周來尋找測(cè)試員測(cè)試代碼；轉(zhuǎn)而Google第三方庫，選擇搜索頁面上第一條那個(gè)有10,000行代碼的，也聰明不到哪兒去。

要知道庫的成本并不是一勞永逸的。舉個(gè)例子，蘋果公司一向不怎么待見Core Data的“l(fā)ock”方法，那要運(yùn)行時(shí)下流行的Core Data封裝器的最新版本怎么辦？——可以先升級(jí)庫，但填補(bǔ)5,774行代碼空缺談何容易？升級(jí)rename方法就意味著損害App。如果直接運(yùn)行舊的Core Data，“l(fā)ock”方法的顧慮也就不復(fù)存在了。

CocoaPods能解決依賴圖（dependency graph）的問題，但應(yīng)對(duì)不了API混亂（API churn）。如果你直接無視pod版本還能在半年后返回到原點(diǎn)（見文章：“return to the project after six months”），那真是個(gè)奇跡了。

總而言之，盡量別太依賴第三方庫，能免則免。而且所幸你也用不了那么多。Cocoa網(wǎng)站背景引人注目，但它實(shí)際上是個(gè)一應(yīng)俱全的框架，以創(chuàng)新方式提供動(dòng)畫、網(wǎng)絡(luò)、持久化等App所需元素。

挑選一個(gè)庫時(shí)，我秉持這幾條原則。無法獲得百分之百贊同是肯定的，但想反駁我，最好準(zhǔn)備充分的理由。

1. 高級(jí)API避免使用abstraction。

iOS工程師在設(shè)計(jì)框架時(shí)，充分考慮了開發(fā)者自由發(fā)揮的“度”的問題。UIKit團(tuán)隊(duì)本來可以將UITableView進(jìn)一步抽象，但他們知道要達(dá)到60FPS的速度，開發(fā)者必須考慮cell循環(huán)的問題。

總的來說，蘋果公司為C語言提供低層API，為Objective-C提供高層API。如果需要一個(gè)簡(jiǎn)單的照片選擇器，用UIImagePickerController，麻煩一點(diǎn)用AVFoundation。蘋果公司也會(huì)犯錯(cuò)，比如iOS Keychain，還有復(fù)雜繁瑣的Address Book API。前者已用封裝器解決，后者已通過蘋果的新Contacts.framework解決。

管理過程中，時(shí)不時(shí)出現(xiàn)的鍵盤會(huì)拖慢進(jìn)程。重新布置所有Input View，把它們放在顯而易見的位置。如果單純把問題丟給庫來解決，一旦遇到View Controller限制，那么abstraction就會(huì)漏洞百出，跟篩子似的。想想automaticallyAdjustsScrollViewInsets失敗了多少次啊，它在UIKit里就是View Controller屬性。

2. 別太把Boilerplate當(dāng)一回事兒。

設(shè)定Core Data棧需要的20行代碼，就好比巫師施法沒有祭品一樣讓人匪夷所思。你可以使用一個(gè)Core Data封裝器1行代碼的Setup，但我的做法是直接復(fù)制粘貼樣板文件。沒錯(cuò)，復(fù)制粘貼而已。

初學(xué)編碼時(shí)，別人就告誡你：“切忌重復(fù)”。但往往開發(fā)者非得浪費(fèi)幾百個(gè)小時(shí)為干巴巴的代碼排錯(cuò)后，才突然明白原來自己一直在“重復(fù)”。

如果樣板文件讓你覺得天旋地轉(zhuǎn)了，就將它重構(gòu)進(jìn)類方法吧。這也嫌麻煩的話，就創(chuàng)建一些模型對(duì)象（model object）?？偠允悄繕?biāo)是迭代為領(lǐng)域模型（domain model）。蘋果的框架只負(fù)80%的責(zé)是有原因的，剩下的20%得靠你了——因?yàn)楫吘故悄阕约旱腁pp。

3. 多多不一定益善。

在《代碼大全（Code Complete）》一書中，Steve McConnell解釋道：project的成本跟代碼庫規(guī)模并非線性擴(kuò)展的關(guān)系。所以做小一點(diǎn)的project比較明智，這不足為奇。

AFNetworking這可能是最受歡迎的開源iOS庫了，具有請(qǐng)求序列化、可達(dá)性監(jiān)測(cè)以及安全保障等諸多特點(diǎn)。今年四月，研究者卻發(fā)現(xiàn)了兩個(gè)嚴(yán)重的安全漏洞，涉及2.1及以上版本用戶，兩個(gè)版本之間時(shí)間跨度長(zhǎng)達(dá)一年。大多數(shù)App并不需要使用AFNetwork，為了降低安全風(fēng)險(xiǎn)肯定也不會(huì)用到“證書鎖定（Certificate pinning）”。

4. 如果問題超出了熟知領(lǐng)域，推薦使用庫。

千萬不要走極端，自己不了解的東西出了問題，也是要承擔(dān)責(zé)任的。為OAuth排錯(cuò)？還是省點(diǎn)力氣吧，庫雖然并非完美的解決方案，但它是更好的選擇。曾經(jīng)有人說：“要是庫能解決問題，干嘛還費(fèi)勁搞明白OAuth？”

iOS 5 Beta推出后，我的團(tuán)隊(duì)發(fā)現(xiàn)了蘋果系統(tǒng)中OAuth庫的漏洞。多文件上傳（Multipart-upload）有問題，照片上傳往往失敗。那時(shí)候iOS 5 API是鎖住的，而蘋果看樣子也沒有及時(shí)修復(fù)問題的意思。所幸我們能善加利用OAuth，最終將蘋果框架“糊弄了過去”，解決了問題。

沒必要專門去了解OAuth，但是如果你的App用到了OAuth，那么了解至關(guān)重要。沒有人會(huì)在乎是代碼出了問題還是庫出了問題。關(guān)鍵是——這是你的App，你難辭其咎。

翻譯@張新慧 ? ? 來源@csdn

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

原文鏈接：Medium