前言： 這是許多矽谷公司用來衡量iOS候選人資歷水平的一系列問題。 這些問題涉及iOS開發的各個方面，旨在觸及對平臺的廣泛理解。 畢竟，高級開發人員應該能夠從頭到尾地發佈完整的iOS產品。 這絕不是一個詳盡的列表，但它可以幫助你為即將到來的技術iOS面試做準備。 目錄 你使用的最新版本的iOS是什麼 ...
前言：
這是許多矽谷公司用來衡量iOS候選人資歷水平的一系列問題。
這些問題涉及iOS開發的各個方面，旨在觸及對平臺的廣泛理解。
畢竟，高級開發人員應該能夠從頭到尾地發佈完整的iOS產品。
這絕不是一個詳盡的列表，但它可以幫助你為即將到來的技術iOS面試做準備。
目錄
你使用的最新版本的iOS是什麼？你喜歡什麼，為什麼？
什麼是iOS應用程式，您的代碼適合哪裡？
你喜歡或不喜歡什麼Swift特性？為什麼？
記憶體管理在iOS上如何處理？
你對單身人士有什麼瞭解？你會在哪裡使用一個，你不在哪裡？
你能否解釋一下Delegate和KVO有什麼不同？
iOS應用中通常使用哪些設計模式？
你知道除了常見的可可模式外還有哪些設計模式？
你能否解釋並展示SOLID原則的例子？
你有什麼選擇在iOS上實現存儲和持久性？
你有什麼選擇在iOS上實現網路和HTTP？
如何以及何時需要在iOS上序列化和映射數據？
在iOS上佈置UI有什麼選擇？
你將如何優化動態大小的表或集合視圖的滾動性能？
你將如何在iOS上執行非同步任務？
你如何管理依賴關係？
你如何在iOS上調試和配置文件？
你有TDD經驗嗎？你如何在iOS上進行單元和UI測試？
你編碼審查和/或配對計劃？
在下麵的章節中，我們將討論每個問題，背後的原因，預期的答案，以及可能為面試官帶來危險的答案。
1.你使用的最新版本的iOS是什麼？你喜歡什麼，為什麼？
通常會詢問這個問題，以瞭解如何使用Swift和iOS平臺上的最新iOS技術和開發進行聯繫。
預期的答案：
期望的是，你至少使用了最新的穩定iOS版本。但是如果你已經玩過或甚至更新了你的應用程式，那麼你會得到額外的分數。談論iOS令人興奮的新功能，以及為什麼你喜歡它們。讓團隊中的開發人員對最新的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在一些語言/平臺中被認為是好的，但他們實際上是一種應該不惜一切代價避免的反模式。
這是我的iOS開發交流群：519832104不管你是小白還是大牛歡迎入駐，可以一起分享經驗，討論技術，共同學習成長！
另附上一份各好友收集的大廠面試題，需要iOS開發學習資料、面試真題，進群即可自行下載！
點擊此處，立即與iOS大牛交流學習
6.你能否解釋代表和KVO有什麼不同？
面對這個問題，面試官正在評估你對iOS中使用的各種消息模式的瞭解。
預期的答案：
兩者都是在對象之間建立關係的方法。委托是一對一的關係，一個對象實現委托協議，另一個使用它並向它發送消息，假設這些方法是由於接收方承諾遵守協議而實現的。KVO是一種多對多的關係，一個對象可以播放一條消息，一個或多個其他對象可以聽到它並作出反應。KVO不依賴協議。KVO是響應式編程的第一步和基本模塊（RxSwift，ReactiveCocoa等）
註意：
一位經驗豐富的開發人員應該知道兩者之間的區別，以及哪一個應該用在另一個之上。
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是簡單的鍵值存儲。一個是不安全的，另一個是安全的，分別。
文件/磁碟存儲實際上是一種使用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.你是否編碼審查和/或配對計劃？
儘管有很多應用程式是由獨立開發人員構建的，但應用程式的複雜性卻不斷增加，要求開發團隊在其上開展工作。在團隊中工作在代碼維護，協作和知識共用方面提出了不同的挑戰。
預期的答案：
結對編程是兩個開發人員在同一臺機器上一起完成相同任務的實踐（希望不共用相同的屏幕和鍵盤並擁有兩套自己的）。目標是在代碼生成的地方促進協作，討論，代碼審查和QA。這個過程使知識轉移和架構討論成為常見的日常事務，防止人們在代碼的某個部分（當該人離開或生病時會發生什麼事）發生孤島危險併成為“專家”。它還提高了代碼質量，因為兩組眼睛在編寫代碼時正在查看代碼。這個過程同時發生在兩個開發人員身上，有時被稱為同步。
結對編程並不適合每個人，如果人物的個性不匹配，這可能是一個耗盡的過程。但它是軟體開發中最有效的協作技術之一。
代碼審查是一個類似的協作和知識轉移過程，但與配對編程不同，它不是同時發生的，因此它是非同步的。通過代碼審查，在開發人員編寫一段代碼或一個功能後，團隊中的其他人可以查看它。審查人員檢查代碼是否有意義，並建議進行更改和重構以改進它。這開啟了關於代碼的線上或離線討論，這非常棒。將關於該代碼的知識傳遞給其他隊友，並幫助儘早發現錯誤並設計氣味。
代碼評審是一種較少涉及的協作類型，與對編程所獲得的結果大致相同。它也是一種同情的練習，你在其他人的工作上給予他人反饋。
這是我的iOS開發交流群：519832104不管你是小白還是大牛歡迎入駐，可以一起分享經驗，討論技術，共同學習成長！
另附上一份各好友收集的大廠面試題，需要iOS開發學習資料、面試真題，進群即可自行下載！
點擊此處，立即與iOS大牛交流學習
歡迎關註 我的簡書 查看更多好文章
