原文： iOS「Swift|框架|模式|套用」 - 深入探討套用架構
先進社群： 「AI PM 人工智慧產品管理」
主理： Loi
架構設計是一個靈活的過程。剛開始的時候，不必著急有個最終答案，我們要有思想準備，無論是日常推進工作，還是面試中，都可能會根據新發現和結論調整內容。思考的越清晰詳細，交流就越順暢，我們的想法也能更準確地傳達出來。
架構設計作為套用工程落地的前置環節，是極為關鍵的一步，需要我們具備更多軟技能和以溝通為導向的能力。
與把握程式語言和技巧（如Swift）和精通研發框架（如Combine和Core Data）這些問題不同，在架構設計環節，需要我們更全面地考慮產品需求、後端、擴充套件性、分析和使用者體驗等因素，從而設計出一個完整的系統。
以iOS開發者為例，我們首先學習了Swift語言，並利用設計模式對其進行進一步構建。現在，我們已經來到了最高層——套用架構。
模擬「架構設計面試」
站在面試和招聘的角度，在招聘過程中，架構面試可能比其他環節更加重要，因為它基於溝通和滿足期望進行評估。因此，從理解受眾和面試官的角度出發，可以讓架構設計的環節更具實踐意義。
接下來，我們模擬一次完整的「架構設計面試」，深入思路，明確任務，開始實踐套用架構的設計。
第一步 深入思路
面試官希望我們從哪裏開始呢？到底期望我們做什麽？
關鍵點是什麽？
關鍵在於，面試官並不關心你的答案是否是最優的，或者你的答案是對是錯。 架構設計面試的重點在於另一方面——面試官想要觀察的是你的思考方式、解決問題的策略、如何權衡各種因素，以及你如何根據產品需求找到一個合適的解決方案。
面試問題舉例：「請設計iOS系統內建的訊息套用。」
顯然， 訊息界面（俗稱「聊天」）是這個套用的核心功能 。針對這個問題，我們需要逐一應對以下幾個挑戰：
1. 我們將使用哪些 UI元件 ？
2. 數據模型 是怎樣的？每條 訊息具體有哪些內容 ？
3. 我們需要哪些 API 端點？是否需要 分頁功能 ？如果不分頁，如何 處理無限數量的訊息 ？
4. 套用是否支持 離線使用 ？如果支持，怎麽實作？
5. 套用是否支持 發送附件 ？具體如何操作？
6. 如果要加入 群聊功能 ，怎麽實作？
7. 套用是否需要支持 即時更新 ？
這些問題只是面對這個任務時可能遇到的一部份，而且每個問題都相當復雜。
我們的目標就是找到這些問題的解決方案。
第二步 應對任務
很多人在面對架構設計面試時都會感到迷茫。並不是不知道如何設計一個套用，或者如何表達自己的觀點，而是不知道以下兩個關鍵點：
1. 應該從哪裏開始任務？
2. 架構設計應該達到什麽邊界？
搞清楚這兩個問題對於面試的熱身和最終引匯出優秀的解決方案至關重要。
我們就從任務的起點說起——理解和界定問題和範圍。
1）理解問題和範圍
遇到設計問題時，第一步是先停頓一下，深吸一口氣，努力搞懂面試官對我們的期待。很多候選人在這一步會遇到麻煩，因為他們意識到回答問題的時間很有限，於是就急匆匆地在白板上畫出框架。
但架構設計面試其實就像是現實生活中的一項任務。面試官希望我們在描述解決方案之前，能夠先徹底理解問題。
比如說，假設我們要設計一個類似iOS系統內建的訊息套用。我們可以向面試官提出以下幾個問題：
- 我們有UI線框圖嗎，還是需要我們自己制作？
- 我們需要設計多少個界面？
- 設計需要包含後端服務嗎？
- 這是一個跨平台套用（包括Android或Web），還是僅限iOS？
- 我們有給定的資料庫方案，還是需要我們自己規劃？
這些問題只是個起點，但它們能幫助我們弄清楚自己的任務。
一旦我們明白了問題本身和需要完成的任務，接下來就可以開始搜集產品需求了。
2）獲取產品需求
在架構設計面試中，我們不會像處理傳統開發任務那樣有一份詳細的產品需求文件（PRD）或與產品經理的啟動會議。相反， 我們必須透過深入理解產品需求並向面試官詢問更多資訊來完成這個任務。 事實上，這正是面試官想要考察我們的。
想象一下，面試就像是一個漆黑的迷宮，我們手持手電筒在其中探索，逐步發現更多的區域、房間和通道。有時候，甚至面試官也不知道我們會把面試引向何方。
回到設計訊息套用的任務，當我們開始設計這款套用時，可以考慮一些關鍵問題。以下是一些例子：
- 套用是否 支持離線閱讀和寫作 ？
- 是否需要 與裝置的聯系人功能整合 ？
- 套用是否 需要支持通知和即時聊天 ？
- 使用者是否 可以編輯或刪除訊息 ？
- 套用是否 需要支持橫螢幕模式 ？
這些問題並非無關緊要。它們對我們的設計和技術決策（technical decision）有著重要的影響。
例如：
- 需要 支持離線閱讀和寫作（ 離線支持對於我們理解資料來源的行為和同步機制至關重要 ）
- 需要 與裝置的聯系人功能整合（ 與裝置聯系人的整合會影響我們的數據模型 ）
- 需要支持通知和即時聊天（ 即時聊天定義了我們的網路方法 ）
- 可以編輯或刪除訊息（ 編輯和刪除功能則影響了我們如何將資訊同步回後端 ）
一開始不必問所有問題——有時候我們需要開始設計才能明白需要問什麽，但有一個良好的開端是很有幫助的。
那麽，我們應該如何開始設計呢？是畫線框圖嗎？還是定義實體？接下來，我們具體看看該如何做。
第三步 開始設計
設計環節是動態的，不是一成不變的。剛開始畫圖時，面試官並不期待我們就能給出最終答案。實際上，我們應該預料到，在面試過程中，隨著新資訊和新結論的出現，我們的設計方案可能需要進行調整。
清晰、詳細地展示我們的思考過程，不僅有助於我們與面試官更好地溝通，還能表達我們的設計理念。
1）在白板上繪制線框圖（wireframes）
我們不是專業的產品設計師，別人也不期望我們做到那個程度。但如何在白板上清晰地表達我們的設計思路，對於整個設計過程來說 非常關鍵 。「清晰的表達設計思路」，現在我們對此有了更深入的理解。
那麽，我們應該從哪裏開始呢？有些開發者喜歡從基本的UML圖開始，描述各種實體或類。但我個人認為，在套用架構方面，從線框圖開始會更合適。讓我們從訊息界面開始（參見圖 1）：
觀察圖5，我們可以清楚地看到，從使用者介面（UI）開始設計是一個明智的選擇。雖然在字型大小和布局方面我們不是專家（設計師水準），但這個線框圖仍能為我們提供許多有價值的資訊。
下面是一些觀察例項：
- 辨識不同實體 ：比如，昵稱和頭像代表了「聯系人」實體。列表顯示的是聯系人的最後一條訊息，這涉及到文本內容，所以我們可以確定還有一個新的實體——「訊息」。
- 列表按時間排序 ：這可能是我們需要進一步考慮的問題——我們是希望按照每個聯系人的最新訊息排序，還是給聯系人實體添加一個更新時間內容？這是一個典型的效能和簡潔性之間的權衡；我們應該和面試官就此進行討論。
- UI方面 ，這裏應該使用UITableView。但是，我們是希望一次性將所有訊息載入到表格檢視中，還是支持分頁載入？
- 設計模式選擇 ：我們需要決定采用哪種設計模式，MVC還是MVVM？我們應該根據套用規模、首屏體驗和使用者常見使用習慣來做出選擇。
在繼續之前，我要強調一點：沒有絕對的答案，只有不斷的權衡和思考。以上提出的這些問題，我並沒有直接給出答案，因為提出問題和聽面試官回答本身就是這個過程的一部份。這是我們展示自己理解並在灰區做出決策的機會。
所以，我們僅僅是用白板來繪制UI嗎？不一定——讓我們繼續探討。
2）添加實體與後端服務
我們已經明白一個套用遠不止UI那麽簡單。但是，只有一個螢幕夠用來開始設計套用的其他部份嗎？當然足夠！
讓我們開始添加實體（見圖2）：
在白板上畫出實體可能聽起來挺技術範兒的，但其實，這個過程就像畫線框圖一樣，能幫助我們挖掘套用的更多精彩細節。
比如說，我們提到了一個聯系人的頭像URL，這說明我們得開發一個圖片下載服務，還得實作個緩存機制。所以，這個圖片下載服務就可以加入到我們的白板草圖中。
就憑一個實體內容的單一實體，我們就已經有了這樣的成果！
但是，畫實體的關鍵在於我們要開始考慮它們之間的關系。我們有聯系人和訊息實體。但是，什麽決定了與聯系人的對話呢？也許我們得建立一個名叫訊息執行緒的新實體。如果我們有了訊息執行緒實體，那它應該有哪些內容呢？
在這個階段，事情會變得稍微復雜點，因為考慮實體之間的關聯會帶來更多問題——比如，我們是否支持群發訊息？這個答案將決定訊息執行緒和聯系人之間的關系型別。
把實體畫線上框圖旁邊，這個過程本身就是一個互動的過程，它幫助我們不斷最佳化設計。每一個決策都會帶來新的問題，促使我們做出更多的設計選擇。這也引導我們走向下一個任務：設計套用與後端的互動。
3）添加網路呼叫
現在我們有了基本的UI線框圖和實體，規劃套用如何與後端服務互動應該會更加順暢。記住，UI和實體還是我們套用開發初期的內容——現在我們更清楚地知道接下來要做什麽。不同的端點決定了使用者體驗和我們將要采用的設計模式，這是我們這一章節中學到的套用架構的關鍵。
接下來，我們來看看主螢幕需要哪些端點（endpoints）：
- GET/threads：獲取所有執行緒列表
- POST/thread：建立新的訊息執行緒
通常，處理資訊列表時，這兩個端點會作為設計的一部份。但還有其他一些問題需要考慮：
- 執行緒如何排序？是從伺服器獲取排序，還是根據特定內容排序？
- 我們需要分頁機制嗎？還是說我們可以一次性獲取所有執行緒，然後用增量更新同步？
- 我們在這個階段需要POST請求嗎？還是說我們只能在發送第一條訊息後才建立？
這些端點還能幫助我們定義套用架構。它們解決了關於UI層及其設計模式（如MVC/MVVM）的重要問題。同時，它們也幫助我們了解數據層和我們需要的一些不同服務。比如：
- 核心數據處理
- 圖片下載器
- 同步服務
- 網路服務及即時管理
如果我們繼續為其他螢幕添加更多端點，我們將會更深入地了解我們的套用，並獲得更多答案。
設計套用架構是一個不斷發現的過程。一開始，一切都是模糊的，溝通和尋找答案的過程非常關鍵。這就是為什麽我們下一個話題非常關鍵——與面試官的溝通。
4）與面試官的有效溝通
很多面試者錯誤地認為，在架構設計面試中，他們的主要目標是給出他們剛剛想到的最佳化解決方案。但實際上，面試官希望透過這個過程看到我們如何思考，並提供一個對可能出現的問題來說合理的解決方案。
因此，在這種面試中與面試官的有效溝通至關重要。我們的一些最關鍵的軟技能正是在這裏得到考驗的！
下面是一些幫助我們關註 重點的建議：
- 真正傾聽面試官 ：這聽起來很簡單，對吧？當然我們會聽面試官的話！但我的意思是，要真正地傾聽他們。首先，任務要求和範圍對於精確確定我們做什麽非常重要。此外，面試官會給我們一些有價值的提示，幫助我們實作目標。
- 如果你對自己的決定不確定，要向面試官澄清疑慮 。面試官需要看到我們能看到事情的灰色地帶，而不僅僅是黑白分明，這也是獲得線索或與面試官討論事情的方式。
- 保持自信 ：我知道這聽起來似乎與前面的點相矛盾，但它其實並不矛盾。當我們有疑慮時，我們需要向面試官溝通，但當我們對自己有信心時，我們必須展示出來。自信是這些面試中的一個關鍵因素。
- 大聲思考 ：我們知道我們想要透過設計實作什麽，甚至已經在白板上畫出來了。但對我們來說顯而易見的事情，對房間裏的另一個人來說不一定明顯。大聲思考可以幫助我們更清楚地解釋我們在做什麽，並幫助面試官理解我們剛剛設計出的出色架構。
- 使用正確的術語 ：在這本書中，我對使用的不同術語非常嚴格——方法與函式、設計模式與架構等。在這些面試中使用正確的術語至關重要，這不僅僅是為了顯得專業；它還使我們的解釋更容易讓面試官理解。並非所有面試官都對這一點嚴格——但這並不意味著我們不應該這樣做。
- 接受反饋 ：在面試過程中，面試官可能會提供反饋或建議。有時這是一個我們可以采取方向的線索，有時是因為我們超出了範圍。很多情況下，在這種情況下，候選人會失去自信，封閉自己，難以接受反饋。我們應該在設計面試中拋開自己的 ego（自負），並利用面試官的反饋來改進我們的答案。面試過程中的反饋並不意味著我們失敗——它意味著我們有機會提供更好的解決方案。
看起來我們正在接受如何溝通和表達自己的考驗，但這就是現實！面試官想看到我們在一起工作、討論設計問題、進行架構辯論的樣子。這就是我們的個性閃耀的時候。
總結
架構設計面試是招聘過程中最為關鍵的一環。它綜合了設計模式、架構設計、iOS使用者體驗，以及規劃、溝通和展示等關鍵的軟技能。
到此，我們應該已經掌握了一些關鍵步驟，能夠自信地面對面試。我們研究了SoC原則及其在iOS架構中的套用，包括函式的大小和命名。我們探討了套用的階層以及數據流動，甚至還舉了一個優秀的離線工作架構範例。最後，我們討論了架構設計面試的策略——如何應對以及如何與面試官溝通。
架構設計是一個靈活的過程。在架構設計環節，需要我們更全面地考慮產品需求、後端、擴充套件性、分析和使用者體驗等因素，從而設計出一個完整的系統。
參考：
【 The Ultimate iOS Interview Playbook】by Avi Tsadok,Released August 2023 Publisher(s): Packt Publishing, ISBN: 9781803246314
主文件 iOS「Swift|框架|模式|套用」
參考：【The Ultimate iOS Interview Playbook】
備註：參考材料供本人學習所用，譯成中文供團隊內部學習。如果對全世界的你們也有幫助，深感榮幸。
先進社群： 「AI PM 人工智慧產品管理」
主理：Loi
