中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

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

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

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

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

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

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

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

1. 高級API避免使用abstraction。

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

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

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

2. 別太把Boilerplate當一回事兒。

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

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

如果樣板文件讓你覺得天旋地轉(zhuǎn)了，就將它重構(gòu)進類方法吧。這也嫌麻煩的話，就創(chuàng)建一些模型對象（model object）?？偠允悄繕耸堑鸀轭I域模型（domain model）。蘋果的框架只負80%的責是有原因的，剩下的20%得靠你了——因為畢竟是你自己的App。

3. 多多不一定益善。

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

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

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

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

iOS 5 Beta推出后，我的團隊發(fā)現(xiàn)了蘋果系統(tǒng)中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