面試官自述：面向進階開發人員的iOS面試問題

標籤：iOS開發人員   程式員   iOS開發   面試題   

當您準備進行技術性iOS面試時，瞭解您可能會詢問哪些主題以及經驗豐富的iOS開發人員期望什麼是非常重要的。
這是許多矽谷公司用來衡量iOS候選人資曆水平的一系列問題。
這些問題涉及iOS開發的各個方面，旨在觸及對平台的廣泛理解。
畢竟，進階開發人員應該能夠從頭到尾地發布完整的iOS產品。
這絕不是一個詳盡的列表，但它可以協助您為即將到來的技術iOS面試做準備。

你需要放下自己的主觀判斷和最重要的東西
– 仔細聆聽。

1. 你使用的最新版本的iOS是什嗎？你喜歡什麼，為什嗎？
2. 什麼是iOS應用程式，您的代碼適合哪裡？
3. 你喜歡或不喜歡什麼Swift特性？為什嗎？
4. 記憶體管理在iOS上如何處理？
5. 你對單身人士有什麼瞭解？你會在哪裡使用一個，你不在哪裡？
6. 你能否解釋一下Delegate和KVO有什麼不同？
7. iOS應用中通常使用哪些設計模式？
8. 你知道除了常見的可可模式外還有哪些設計模式？
9. 你能否解釋並展示SOLID原則的例子？
10. 你有什麼選擇在iOS上實現儲存和持久性？
11. 你有什麼選擇在iOS上實現網路和HTTP？
12. 如何以及何時需要在iOS上序列化和映射資料？
13. 在iOS上布置UI有什麼選擇？
14. 你將如何最佳化動態大小的表或集合視圖的滾動效能？
15. 你將如何在iOS上執行非同步任務？
16. 你如何管理依賴關係？
17. 你如何在iOS上調試和設定檔？
18. 你有TDD經驗嗎？你如何在iOS上進行單元和UI測試？
19. 你編碼審查和/或配對計劃？

在下面的章節中，我們將討論每個問題，背後的原因，預期的答案，以及可能為面試官帶來危險的答案。

1.你使用的最新版本的iOS是什嗎？你喜歡什麼，為什嗎？
通常會詢問這個問題，以瞭解如何使用Swift和iOS平台上的最新iOS技術和開發進行聯絡。

預期的答案：
期望的是，你至少使用了最新的穩定iOS版本。但是如果你已經玩過或甚至更新了你的應用程式，那麼你會得到額外的分數。談論iOS 11令人興奮的新功能，以及為什麼你喜歡它們。讓團隊中的開發人員對最新的iOS技術充滿熱情是很好的。通常情況下，充滿好奇心的人可以使用新的功能提出有趣的新功能創意或想出創造性的解決方案。

注意：
如果候選人對當前穩定版本的iOS沒有太多的工作或對其不感興趣，這通常是一個不好的跡象。這意味著這個人很可能沒有及時瞭解iOS提供的最新技術，解決方案和功能，這很可能意味著這個人會錯過利用iOS系統的機會，或者更糟糕的是，他們不知道最新系統有一些新的缺陷。

2.什麼是iOS應用程式，您的代碼適合哪裡？
這是一個很大的圖片問題，可以通過這種或那種形式進行詢問，以評估您對iOS應用程式的理解以及您編寫的代碼適用於iOS系統的整體情況。

預期的答案：
可能會認為我們構建的應用程式是特殊的，因為它們涵蓋了一個獨特的用例。但是你典型的iOS應用程式只是一個巨大的，美化的運行迴圈。它等待使用者輸入並被外部訊號中斷，如撥打電話，推播通知，首頁按鈕按下以及其他應用程式生命週期事件。唯一的區別是，它不僅僅是一個簡單的郵件迴圈函數，每次使用者點擊應用程式圖示時都會啟動它，它具有更高的抽象層級，UIApplication並且AppDelegate是我們開發人員的工作內容。
您為編寫應用程式的商務邏輯而編寫的代碼的其餘部分放置在由主迴圈委託給我們的應用程式的“觸發點”中AppDelegate。這是非常多的。簡單。但是，為應用程式編寫的代碼可以像調用方法/函數一樣簡單，也可以像VIPER體繫結構一樣複雜。你用它做什麼是你的選擇。

注意：
通常開發人員會將iOS應用程式視為他們編寫的代碼以及實現的複雜複雜細節，這些都是真實的。但是如果你退後一步，看看大局，你可以看到iOS應用程式真的是什麼
一個運行迴圈。

3.你喜歡或不喜歡什麼Swift特性？為什嗎？
隨著最新的Swift更新，它一次又一次地證明這種語言是iOS開發的未來。這些日子裡，特別是經驗豐富的開發人員的期望是，您對Swift及其提供的功能非常熟悉。

預期的答案：
你可以談論強大的語言輸入和功能特點，以及你喜歡或不喜歡它們的原因。本身沒有正確或錯誤的答案，但期望是您熟悉語言及其提供的功能（泛型，協議，選項等）。此外，你應該能夠解釋和爭論，如果你喜歡或不喜歡這種語言的東西（我不喜歡可選的連結，因為它打破了德米特定律，例如）。

注意：
Swift正在成為iOS平台的主要穩定語言，所以現在忽略它是沒有意義的。

4.在iOS中如何處理記憶體管理？
記憶體管理在任何應用程式中都非常重要，特別是在具有記憶體和其他硬體和系統限制的iOS應用程式中。因此，這是以某種形式提出的問題之一。它涉及ARC，MRC，參考型別和實值型別。

預期的答案：
Swift使用自動引用計數（ARC）。這在Swift中與Objective-C中的概念相同。ARC會跟蹤對類執行個體的強引用，並在為常量，屬性和變數分配或取消分配類（參考型別）執行個體時相應地增加或減少引用計數。它將釋放引用計數降至零的對象所使用的記憶體。ARC不會增加或減少實值型別的引用計數，因為在分配時會複製這些值。預設情況下，如果不另外指定，則所有引用都將是強引用。

注意：
這是每個iOS開發人員必須知道的！記憶體流失和應用程式崩潰太常見了，原因是iOS應用程式記憶體管理不善。

5.你對Singletons有什麼瞭解？你會在哪裡使用一個，你不在哪裡？
Singleton是許多OOP語言中常用的設計模式，Cocoa認為它是“可可核心競爭力”之一。這個問題不時出現在面試中，用來衡量你對Singletons的體驗，或者看看你是否擁有背景不僅僅是iOS。

預期的答案：
Singletons是一個只返回一個和同一個執行個體的類，不管你請求了多少次。
有時被認為是反模式。使用時有許多缺點。兩個主要的是全域狀態/狀態和對象生命週期以及依賴注入。當你只有一個東西的執行個體時，直接在任何地方引用和使用它是非常誘人的，而不是將它注入到對象中。這會導致代碼中具體實現的不必要的耦合，而不是介面抽象。???“方便”另一個惡意副作用是全球狀態。很多時候，可以實現全域狀態共用，並扮演每個對象用來儲存某個狀態的“公用包”的角色。這導致不可預知的結果和錯誤和崩潰時，這種不受控制的狀態被覆蓋或被某人刪除。

注意：
儘管Singletons在一些語言/平台中被認為是好的，但他們實際上是一種應該不惜一切代價避免的反模式。

6.你能否解釋代表和KVO有什麼不同？
面對這個問題，面試官正在評估你對iOS中使用的各種訊息模式的瞭解。

預期的答案：
兩者都是在對象之間建立關係的方法。委託是一對一的關係，一個對象實現委託協議，另一個使用它並向它發送訊息，假設這些方法是由於接收方承諾遵守協議而實現的。KVO是一種多對多的關係，一個對象可以播放一條訊息，一個或多個其他對象可以聽到它並作出反應。KVO不依賴協議。KVO是響應式編程的第一步和基本模組（RxSwift，ReactiveCocoa等）

注意：
一位經驗豐富的開發人員應該知道兩者之間的區別，以及哪一個應該用在另一個之上。
**

7. iOS應用中通常使用哪些設計模式？
   這個問題是各級職位面試的常見問題，也許除了初級職位之外。基本上這個想法是，在使用iOS平台時，作為開發人員您應該熟悉iOS上常用的技術，體繫結構和設計模式。
   
   預期的答案：
   構建iOS應用程式時的典型常用模式是Apple在Cocoa，Cocoa Touch，Objective-C和Swift文檔中倡導的模式。這些是每個iOS開發人員學習的模式。它們包括MVC，Singleton，Delegate和Observer。
   
   注意：
   當面試官提出這個問題時（採用這種或那種形式）面試官正在尋找除MVC以外的東西。由於MVC是一種前瞻性設計模式，因此期望每個iOS開發人員都知道它是什麼。但是，他們希望從您那裡聽到的是常用和可用的開箱即用功能。
   
   8.除了常見的可可模式外，你知道的設計模式是什嗎？
   面試官會在面試進階或建築師職位時詢問這個進階問題。期望的是，除了上一個問題中介紹的基本類型外，您還可以瞭解iOS應用中使用的更實用的設計模式。準備好回憶一堆四人幫和其他類似的模式。
   不幸的是，設計模式本身就是一個巨大的話題（它們在我的書中也有更好的介紹），所以在這裡我只給出一些我在iOS程式碼程式庫中常見的概述。
   
   預期的答案：**
   除了常用的MVC，Singleton，Delegate和Observer模式之外，還有許多其他應用程式完全適用於iOS應用程式：Factory Method，Adapter，Decorator，Command，Template等等。
   Factory Method用於替換類建構函式，抽象和隱藏對象初始化，以便可以在運行時確定類型，並隱藏並包含switch/if用於確定要執行個體化的物件類型的語句。
   適配器是一種設計模式，它可以協助您（如名稱所示）使一個對象的介面適應另一個對象的介面。當您嘗試修改無法更改為代碼的第三方代碼，或者需要使用具有不方便或不相容API的內容時，通常會使用此模式。
   裝飾者是另一個增強其功能的類的封裝。它封裝了你想要裝飾的東西，實現它的介面，並將發送給它的訊息委託給底層對象，或者增強它們或者提供它自己的實現。
   Command是一種設計模式，您可以在其中實現一個代表您想要執行的操作的對象。該操作可以擁有自己的狀態和邏輯來執行它所做的任務。這種設計模式的主要優點是可以隱藏使用者的操作的內部實現，您可以向其添加撤消/重做功能，並且可以在以後的時間點（或根本不執行）執行操作，而不是馬上建立操作。
   模板是一種設計模式，其中主要概念是有一個基類，概述了需要完成的演算法。基類有幾個抽象方法需要由其具體的子類來實現。這些方法被稱為鉤子方法。模板方法類的使用者僅使用實現演算法步驟的基類進行互動;?這些步驟的具體實現由子類提供。

注意：
當你剛剛開始使用iOS平台時，只堅持使用MVC，Singleton，Delegate和Observer模式是很好的，但對於需要深入到像Gang of Four OOP設計模式這樣更抽象和進階的東西的進階事物來說，它們非常有用，使您的程式碼程式庫更加靈活和可維護。

9.你能解釋並展示SOLID原則的例子嗎？
SOLID原則相對比較陳舊，但卻非常適用於任何語言的任何OOP程式碼程式庫。觀看一些關於這個話題的Bob叔叔的談話，以充分理解他們背後的曆史。
在YouTube上：物件導向和敏捷設計的Bob Martin SOLID原則。
不幸的是，SOLID原則本身就是一個巨大的話題（在我的書中它們也更好），所以在這裡我只給出它們的概述。

預期的答案：
SOLID代表單一責任原則，開放/閉合原則，Liskov替代原則，介面隔離原則和依賴倒置原則。這些原則是相互支援的，並且是您可以為您的代碼採用的最佳通用設計方法之一。我們來看看它們中的每一個。
單一責任原則（SRP）是該組織最重要的原則。它指出，每個模組應該只有一個責任和理由要改變。SRP從小的具體和特定情況開始，例如只有一個目的的類和/或對象，僅用於一件事情。
開放/封閉原則（OCP）規定，您的模組應該開放用於擴充，但關閉以進行修改。這是聽起來很容易的事情之一，但當你開始思考它的含義時，很難把你的頭圍繞起來。實際上，這意味著在編寫代碼時，應該能夠通過繼承，多態和組合使用介面，抽象和依賴注入來實現對象的行為。
Liskov替代原則（LSP）指出，程式中的對象應該可以替換其子類型的執行個體，而不會改變該程式的正確性。這意味著當你從一個類或者一個抽象類別繼承或者實現一個介面（協議）時，你的對象應該是可替換的並且可以注入，無論你使用哪個介面或類。這個原則通常被稱為合約設計，或者在Swift社區中被稱為面向協議的編程。這個原則的主要資訊是，你不應該違反合約，即你的承諾所遵循的介面承諾履行，而通過繼承，這些子類可以用於以前使用超類的任何地方。
介面隔離原理（ISP）說許多客戶特定的介面比一個通用介面更好。它還規定，不應強迫任何客戶依賴和實施不使用的方法。這意味著，當你建立你的類實現的介面（協議）時，你應該爭取並依賴於抽象的特性，但是直到它變成一個浪費，你必須實現一堆方法，你的新類不會甚至使用。
依賴倒置原則（DIP）指出，“取決於抽象而不是結核”。展示這一原理的最好例子是依賴注入（DI）技術。通過依賴注入技術，當你建立一個對象時，你可以在其初始化或配置時提供並注入它的所有依賴關係，而不是讓對象為自己建立或擷取它的依賴關係。

注意：
固體原則是良好的物件導向設計的基礎。應用這些原則將協助您構建更好，更易維護的軟體。如果您正在申請進階iOS職位，建議您熟悉這些技巧。

10.您有什麼選擇來實現iOS上的儲存和持久性？
訪問者詢問這個問題，以瞭解您可以在iOS上儲存和儲存資料的工具和方式。

預期的答案：
一般來說，儲存資料的方式有以下幾種：從簡單到複雜：
記憶體數組，字典，集合和其他資料結構
NSUserDefaults的/鑰匙扣
檔案/磁碟儲存
核心資料，領域
SQLite的
記憶體數組，字典，集合和其他資料結構對於儲存資料或者不必持久化來說都是非常好的。
NSUserDefaults / Keychain是簡單的KVStore for Redis。一個是不安全的，另一個是安全的，分別。
檔案/磁碟儲存實際上是一種使用NSFileManager將資料片段（序列化或不存在）寫入磁碟的方法。
核心資料和領域是簡化資料庫工作的架構。
SQLite是一個關係型資料庫，當你需要實現複雜的查詢機制時，並且Core Data或Realm不會削減它。

注意：
您應該瞭解可以在iOS上儲存資料的不同方式及其優缺點。不要只限於自己習慣的一種解決方案（例如Core Data）。知道什麼時候比另一個更可取。

11.您有什麼選擇可以在iOS上實現網路和HTTP？
幾乎每個應用程式現在都在使用某種網路來從API和其他外部資源擷取資料。很多應用程式在沒有串連到互連網時都沒用。每個iOS開發人員都應該知道他們可以構建他們應用程式的服務/網路層。

預期的答案：
在iOS中有幾個選項來實現HTTP網路。你可以使用舊的NSURLSession，但除非你把它抽象出來，否則使用它可能會很艱巨。另一個選擇是圍繞它使用一個封裝庫。iOS上最流行的解決方案是Alamofire / AFNetworking。
進階開發人員應該記住，在iOS應用程式中構建網路層不僅意味著處理HTTP請求。它還意味著實現您的代碼與之相關的整套任務：HTTP網路，資料序列化和資料對應。

注意：
現在，AFNetworking和Alamofire是iOS上進行HTTP網路的事實標準，每個開發人員都應該知道如何使用它們。同時，它們都基於Apple架構，並且知道NSURLSession的內部細節也是有益的。

12.如何以及何時需要在iOS上序列化和映射資料？
資料序列化是構建iOS應用程式時需要執行的常見任務。訪問者問這個問題，看看你是否認識到它適合的情況，並且知道你需要執行資料處理的任務，無論它是網路還是儲存資料。

預期的答案：
有兩種最常見的情況，您需要在iOS應用程式中序列化和映射資料：在網路層中接收或發送資料（如JSON或XML或其他內容），以及在儲存層中持久化或檢索模型（NSData，NSManagedObject等）。
每當您收到來自後端API的JSON或XML或任何其他類型的響應時，您最有可能以JSON或二進位或其他“不方便”的格式擷取它。為了能夠處理收到的資料，您需要做的第一件事就是將其序列化為應用程式理解的內容。在最簡單和最基本的層次上，它將是包含來自該響應的其他字典，數組和基元的字典或對象數組。NSJSONSerialization負責處理這個（並且很快的Codable協議）。下一步是將這些資料對應到應用程式的領域模型中。那些將是您的應用程式的其餘部分使用的模型對象。您可以手動執行，也可以使用諸如Mantle或SwiftyJSON之類的庫。資料流和序列化/映射如下：binary data- >?json- >?NSDictionary/NSArray- >?your domain model objects。
同樣，在儲存層中，您需要序列化資料並將資料對應到自訂網域模型對象和儲存理解的格式。用於讀取資料的“映射”鏈如下所示：db- >?raw data format- >?custom domain models，並且用於這樣寫：custom domain models- >?raw data format- >?db。你可以在這裡使用NSManagedObject或NSCoding協議來實現這一點。

注意：
這裡的主要注意並沒有意識到在使用iOS應用程式的網路和儲存層時需要進行這些資料操作。事情不會“自動地”發生，也不會與原始NSDictionaries合適並可維護。

13.在iOS上布置UI的選項有哪些？
當你需要在iOS上解決不同的UI問題時，瞭解你在螢幕上布局的選項至關重要。這個問題有助于衡量你對如何在螢幕上放置和對齊視圖的知識。在回答這個問題時，你至少應該提到CGRect架構和AutoLayout，但是在iOS上提及其他選項比如ComponentKit和其他Flexbox和React實現將是非常好的。

預期的答案：
在螢幕上布置視圖的前往選項是很好的舊CGRect架構和AutoLayout。架構以及自動調整大小的遮罩在iOS 6之前已被使用，並且今天不是首選。由於很難計算各種裝置的精確座標和視圖大小，因此幀太容易出錯並且難以使用。
自iOS 6開始，我們推出了AutoLayout，這是目前最流行的解決方案，也是Apple喜歡的解決方案。AutoLayout是一種技術，可以用聲明的方式定義視圖之間的關係，稱為約束，讓架構計算UI元素的精確架構和位置。
還有其他用於布置視圖的選項，比如ASDK（Texture），ComponentKit和LayoutKit，這些選項或多或少都受React的啟發。例如，當您需要構建高度動態且快速的表格視圖和集合視圖時，這些替代方法在某些情況下很好。AutoLayout並不總是完美的，知道有其他選項總是好的。

注意：
至少沒有提及AutoLayout，Frames的臭名昭著的難以得到的事實肯定會成為面試官的一面紅旗。現在沒有一個理智的人會做CGRect架構計算，除非它是絕對必要的（例如，當你做一些瘋狂的繪畫時）。

14.如何最佳化動態大小的表或集合視圖的滾動效能？
與UITableView問題一起在面試中有時會問到的一個重要問題是關於表視圖滾動效能的問題。

預期的答案：
滾動效能是UITableViews的一個重大問題，往往很難得到正確的結果。主要困難是細胞高度計算。當使用者滾動時，每個下一個單元需要計算其內容，然後才能顯示高度。如果你做手動的架構視圖布局，那麼它更高效能，但挑戰是讓高度和大小的計算恰到好處。如果你使用AutoLayout，那麼挑戰就是設定所有的約束。但即使AutoLayout本身可能需要一些時間來計算單元高度，並且您的滾動效能會受到影響。
滾動效能問題的潛在解決方案可能是
自己計算細胞高度
保留一個原型儲存格，填充內容並用於計算儲存格高度
或者，您可以採取完全激進的方法，即使用不同的技術，如ASDK（紋理）。ASDK（紋理）專門用於具有動態內容大小的列表視圖，並經過最佳化，可在後台線程中計算單元高度，從而使其具有超高效能。

15.你會如何在iOS上執行非同步任務？
現在，多線程是任何用戶端，面向使用者的應用程式的重要組成部分。這個問題可以在網路環境中提出，也可以作為一個關於GCD或非同步開發的獨立問題。

預期的答案：
現在，iOS上的非同步任務的解決方案是NSOperations和GCD塊。Grand Central Dispatch是一種技術，它可以處理多個後台隊列，後台隊列又可以確定後台線程處理工作。最重要的是，這是從你身上抽象出來的，所以你不必擔心它。NSOperation是GCD之上的物件導向抽象，允許您執行更複雜的非同步作業，但是您可以使用GCD執行的NSOperations獲得的所有內容。許多Cocoa架構使用GCD和/或NSOperations（例如NSURLSession）。
使用第三方庫的協助還有其他方法可以處理非同步工作。最顯著的是Promises（PromiseKit），RxSwift和ReactiveCocoa。RxSwift和ReactiveCocoa特別擅長建模時間和工作的非同步性質，需要在後台完成並線上程間進行協調。

注意：
每個iOS開發人員應該瞭解的關於非同步工作的基礎知識是GCD和NSOperations。RxSwift和Promises是進階概念，但進階開發人員也應該瞭解它們。

16.你如何管理依賴關係？
依賴關係管理是每個iOS項目的一項重要任務。這個問題被要求衡量你對這個問題的理解以及如何解決這個問題。

預期的答案：
幾年前，我們在iOS上沒有任何依賴管理器，必須將第三方代碼複製粘貼並拖放到我們的項目中或使用git子模組。隨著我們的程式碼程式庫和依賴性增長，所有這些方法很快就被證明是無法管理的。
現在我們有其他的依賴管理者可以選擇：CocoaPods，Carthage和Swift Package Manager（SPM）。到目前為止，最強大和最強大的是CocoaPods。它是建立在Ruby Bundler寶石的精神之上的，並且是一個Ruby寶石本身。它的工作方式是安裝gem，在項目的根目錄下建立Podfile，聲明要使用的pods（庫）並運行pod install。而已。

注意：
每個iOS開發人員都應該明白，為什麼將多個第三方庫複製粘貼到程式碼程式庫中會導致維護噩夢，因為多個庫可能依賴於另一個庫的兩個不同版本，導致不匹配，編譯和運行時問題等等。

17.你如何在iOS上調試和設定檔？
沒有人寫出完美的代碼，偶爾開發人員需要調試他們的代碼和設定檔應用程式，以尋找效能和記憶體流失等問題。

預期的答案：
我們可以在iOS應用程式中做到這一點，永遠都有很好的NSLog成就感print。還有可以使用Xcode設定的斷點。為了執行單個程式碼片段，您可以使用XCTest的measureBlock。
您可以使用儀器進行更進階的調試和分析。Instruments是一款分析工具，可協助您分析應用程式並在運行時發現記憶體流失和效能問題。

18.你有TDD經驗嗎？你如何在iOS上進行單元和UI測試？
儘管從曆史上看，iOS社區在TDD方面並不算大，但由於工具的改進和來自其他社區（如Ruby）的影響力，現在變得越來越受歡迎，而Ruby等其他社區很早就接受了TDD。

預期的答案：
TDD是一種技術和學科，在您編寫使其通過的產品代碼之前，您首先編寫失敗的測試。這些測試將推動您的產品代碼的實施和設計，協助您僅編寫通過測試實施所必需的代碼，不多也不少。這門學科起初可能令人望而生畏，你沒有立即看到這種方法的收益，但如果堅持下去，它可以協助你從長遠來看加快步伐。它在協助你重構和修改代碼方面特別有效，因為在任何時候你都有測試的安全網告訴你是否有什麼東西壞了，或者在你改變的時候一切仍然正常。
最近，Apple對XCTest架構進行了改進，以使測試更輕鬆。他們在Xcode的UI測試中也做了很多改進，現在我們有了一個很好的編程介面來與我們的應用進行互動並查詢我們在螢幕上看到的東西。或者，你可以使用像KIF這樣的架構。
關於單元測試，還有幾種選擇，但是最流行的兩個選項是XCTest和Quick和Nimble。
XCTest是由Apple構建的xUnit測試架構。這是他們推薦使用的，並且它與Xcode的整合度最高。
Quick是一種類RSpec的BDD架構，可協助您根據行為而不是“測試”來描述您的規格/測試.RSpec的粉絲喜歡它。
Nimble是一個匹配器庫，可以與XCTest或Quick一起使用，在您的測試/規格中聲明期望值。

注意：
越來越多的團隊和公司都接受TDD，它已經成為iOS開發過程中的重要組成部分。如果你不想被拋在後面，那就試試它，並學習如何測試你的代碼。

19.你是否編碼審查和/或配對計劃？
儘管有很多應用程式是由獨立程式開發人員構建的，但應用程式的複雜性卻不斷增加，要求Team Dev在其上開展工作。在團隊中工作在代碼維護，協作和知識共用方面提出了不同的挑戰。

預期的答案：
結對程式設計是兩個開發人員在同一台機器上一起完成相同任務的實踐（希望不共用相同的螢幕和鍵盤並擁有兩套自己的）。目標是在代碼產生的地方促進協作，討論，代碼審查和QA。這個過程使知識轉移和架構討論成為常見的日常事務，防止人們在代碼的某個部分（當該人離開或生病時會發生什麼事）發生孤島危險並成為“專家”。它還提高了代碼品質，因為兩組眼睛在編寫代碼時正在查看代碼。這個過程同時發生在兩個開發人員身上，有時被稱為同步。
結對程式設計並不適合每個人，如果人物的個性不匹配，這可能是一個耗盡的過程。但它是軟體開發中最有效協作技術之一。
代碼審查是一個類似的協作和知識轉移過程，但與配對編程不同，它不是同時發生的，因此它是非同步。通過代碼審查，在開發人員編寫一段代碼或一個功能後，團隊中的其他人可以查看它。審查人員檢查代碼是否有意義，並建議變更和重構以改進它。這開啟了關於代碼的線上或離線討論，這非常棒。將關於該代碼的知識傳遞給其他隊友，並協助儘早發現錯誤並設計氣味。
程式碼檢閱是一種較少涉及的協作類型，與對編程所獲得的結果大致相同。它也是一種同情的練習，你在其他人的工作上給予他人反饋。

結論
本文中涉及的問題涉及iOS開發人員應該瞭解的廣泛主題。這絕不是一個完整的清單。這些問題基於我為本書所做的研究，即我發布的“iOS訪談指南”。本書接近採訪準備作為iOS主題的全面概述，並關注每個iOS應用程式。它將問題分解成以下幾組：UI相關問題（UIView，AutoLayout等），儲存問題（持久性，使用者預設值，核心資料等），網路（HTTP，NSURLSession，Alamofire等），以及設計模式和架構問題（MVC，MVVM，SOLID等）。

面試官自述：面向進階開發人員的iOS面試問題