前言

我們在做系統設計或系統設計的面試中，常常會有一些固定的步驟，像是討論需求、設計架構、設計 API 等步驟，GreatFrontEnd 的開發者幫我們整理了一套 framework / pattern 循序漸進地針對設計每個環節做討論，也就是 RADIO framework

什麼是 RADIO framework?

1. Requirements Exploration: 徹底的了解需求與決定範疇
   (Understand the problem thoroughly and determine the scope by asking a number of clarifying questions).

2. Architecture/High-level Design: 決定關鍵的 component 與他們之間如何作用
   (Identify the key components of the product and how they are related to each other).

3. Data Model: 描述不同的資料個體，他們的欄位跟屬於哪個 component
   (Describe the various data entities, the fields they contain and which component(s) they belong to).

4. Interface Definition (API): 定義 component 之間的介面，API 之間的功能、參數與回應
   (Define the interface (API) between components in the product, functionality of each API, their parameters and responses).

5. Optimizations and Deep Dive: 討論可能優化的機會與特定的關注領域
   (Discuss about possible optimization opportunities and specific areas of interest when building the product).

Requirement exploration

• 目標：藉由問問題徹底的了解需求 & 決定 scope
• 時間：不要超過 15%

你需要藉由更深入 & 清楚的了解問題模糊的部分
把你的 interviewer 當作 product manager 來問
有些問題甚至是不需要 engineering 就可以解決的

推薦問題：

1. 我們最需要重視的 use cases 為何？

想像你被要求要 "設計 Facebook"，Facebook 是一個大平台，有

• 新聞訊息流 (New Feeds)
• 個人檔案 (Profiles)
• 朋友群 (Friends)
• Groups
• Stories

你應該 focus 在哪個層面？
面試官已經內心有答案了，但想要你去藉由提問找出來，
通常會 Focus 在產品上最特別的地方，
像 Facebook 就是 new feeds 的部分，還有 new feeds 的分頁，產生一個新的貼文，
像 Youtube 就是觀看體驗

2. 功能性的需求有哪些？ 非功能性的有哪些？

• 功能性需求 (Functional requirements)：
  一些基本的需求，產品沒有這些功能就無法運作

• 非功能性需求 (Non-functional requirements)：
  產品的改善，但對產品來說不是必要的，包括：

  • 效能
  • 擴展性 (scalability)：多少項目在這頁可以被展示
  • UX

推薦做法：

• 一開始列出你可能認爲的需求，然後取得回饋並跟 interviewer 對齊需求
  (Take the initiative to list out what you think are requirements and get feedback and alignment from the interviewer)

你的設計，至少需要做到滿足所有的 functional requirements，
當你完成了 functional 部分，再往 non-functional requirements 下去探討

3. 哪些是 core features？哪些是 nice-to-have？

雖然我們知道了有哪些 funtional requirements，但一個大 feature 可能有非常多個小 features 所組成，舉例來說：
當建立一個新的 Facebook posts，我們要支援哪種格式？
除了 text-based posts，那 user 可以上傳圖片嗎？ 可以上傳影片嗎？ 產生投票？ 打卡 (check in location) 等

在進到下一個 feature 前，我們要釐清 core features，並對此做設計

4. 其他問題

• 需要支援哪些設備/平台？
• 需要支援離線狀態嗎？
• 誰是產品的主要 users？
• 效能需求有哪些？(這些問題通常落在 non-functional requirements)

Architecture / High-level Design

• 目標：了解產品的關鍵 components，還有他們之間的關聯

• 時間：約佔 20% 會議時間

• 記住 focus 在 clien-side architecture

• 在 frontend design 常見的高階元件/模組如下：

  • Server：我們可以把 Server 當作一個黑箱，並且藉由 HTTP/Websocket 吐出一些 APIs
  • View：使用者可以看到的部分
  • Controller：處理 user 的互動，且將 data 轉換成 View
  • Model / Client store：資料存在的部分

當在定義元件時，可以考慮的問題如下：

• Separation of Concerns
• 運算應該發生在哪個時機？：
  • 像 filter items 要做在 client side？ 還是 server side？

![[Pasted image 20240908002026.png | 500]]

• Server：提供 Feed data & 提供 HTTP api
• Controller：控制資料流 & 對 Server 請求網路服務
• Client store：保存整個 application 的資料，在 New feeds 中，大部分的資料都是從 Server 來的
• Feed UI：包含 Feeds 列表 & Post composer UI
  • Feeds list
  • Post composer UI

Data model

• 目的：描述不同的資料個體、欄位，和他們屬於哪個 component
• 時間：約佔 10% 的會議時間

大致上分為

• Server-originated data
• Client-only data

Server-originated data

通常是：

• 需要被多人看見
• 需要被不同 device 看見
• 範例：
  • user data (name, profile picture)
  • user-generated data (feed posts, comments)

Client-only data

• 通常被認知為 state，主要分成兩種：
  • Data to be persisted：通常是 user inputs，需要被送到 DB 裡
  • 短暫的資料 (Ephemeral data)：瀏覽器關掉也沒關係的資料，通常像是：
    • form validation state
    • current tab
    • section 是否被展開？

Data model Example

以 new feeds 來說

Interface API

• 目標：定義 components 之間的 interface，不同 API 之間的功能，他們的參數和回應
• 時間：會議時間的 15%

不管是 Client-Server 或 Client components 之間的 APIs，都有以下 3 個相同的地方：

Server-Client

以 New feeds 的例子來說，server API 提供 client 去拿到最新的 posts

Parameters

{
	"size": 10,
	"cursor": "=dXNlcjpXMDdRQ1JQQTQ"
}

Response

{
  "pagination": {
    "size": 10,
    "next_cursor": "=dXNlcjpVMEc5V0ZYTlo"
  },
  "results": [
    {
      "id": "123",
      "author": {
        "id": "456",
        "name": "John Doe"
      },
      "content": "Hello world",
      "image": "https://www.example.com/feed-images.jpg",
      "reactions": {
        "likes": 20,
        "haha": 15
      },
      "created_time": 1620639583
    }
    // ... More posts.
  ]
}

Client-Client API example

跟 Server-client api 差不多，主要差在是藉由 javascript function 溝通，或監聽的 events，最重要的部分為

1. API 的功能
2. 參數
3. 回傳值

API for UI component System design

React 組件之間的溝通界面：

1. 溝通媒介（Communication Medium）

• React Component（組件）: 在 React 中，組件（Component）是溝通的主體。父組件和子組件之間通過組件來傳遞數據和功能。在這個層級上，組件就像是 API 的溝通路徑（Server-Client 的 HTTP path 或 Client-Client 的 JavaScript function）。

2. 參數（Parameters）

• Props（屬性）: 組件之間通過 props 傳遞數據，這與 Server-Client 的 HTTP GET/POST 參數和 Client-Client 的函數參數類似。父組件通過 props 向子組件傳遞狀態、數據和回調函數，子組件接收這些 props 並在內部使用。

3. 回傳值（Return Value）

• JSX 結構: React 組件的回傳值通常是 JSX 結構，它代表了元件的渲染輸出，這與 API 返回的 JSON 類似，都是最終的結果輸出。
• Callback 函數的結果: 當父組件通過 props 傳遞回調函數給子組件時，子組件可以在某些事件觸發時調用這些函數，這類回調函數的返回值可以視為子組件向父組件的反饋，類似於 HTTP API 的響應結果或函數調用的返回值。

具體範例：

1. 溝通媒介（Component）：

   • 父組件 ParentComponent 通過組件 <ChildComponent /> 與子組件溝通，這個溝通過程類似於 Server-Client 的 API 路徑（例如 /get-data），React 組件之間的溝通是通過組件本身進行的。

2. 參數（Props）：

   • 父組件傳遞數據給子組件，例如：

function ParentComponent() {
  return <ChildComponent message="Hello, world!" />;
}

• 這裡的 message 就像 API 的參數一樣，是由父組件傳遞給子組件的參數。

3. 回傳值（JSX 和 Callback 函數）：

   • 子組件渲染出來的 JSX 結構就是其回傳值，它是 UI 的表現層。

   • 如果父組件傳遞了一個回調函數，例如：

function ParentComponent() {
  const handleClick = () => alert('Button clicked!');
  return <ChildComponent onClick={handleClick} />;
}

• 子組件可以在合適的時候調用 onClick 回調函數，這就像 API 的回傳值一樣，子組件通過這種方式回傳數據或觸發父組件的某些行為。

Optimization and Deep Dive

• 目標：討論可能優化的機會 & 對於產品特別有興趣的區塊
• 時間：會議的 40%

沒有特定的方式來進行，但有兩種方向可以進行：

1. 專注在 product 的重要方面：

   • eCommerce site：performance optimzation
   • collaborative editor：race conditions & concurrent modifications

2. 專注在你的強項：

   • 精通 accessibility：大談 accessibility
   • 精通 performance：大談 performance，如何讓使用者有奶油般的滑順體驗

常見的 Optimization / Deep dive areas

• Performance
• User Experience
• Network
• Accessibility (a11y)
• Multilingual Support
• Multi-device Support
• Security

結論

參考資源

• The RADIO framework - GreatFrontEnd