FID Overview

Future-Ready Interface Development，以下簡稱 FID。

FID 旨在確保軟體的前端工程介面在面對未來的挑戰和變化時仍然保持高度適應性和性能， 從而為用戶提供優質的體驗並促進軟體的長期成功。

這個指的前端工程涵蓋面向用戶的各種終端。

• 手機
• 平板
• 桌機
• 電視
• 汽車顯示
• 網頁

背景

設計師與前端

在 CSS 發布後 26+年，CSS 已經成為網頁設計的基礎，但是 CSS 的設計並不是為了網頁設計，而是為了文件設計。CSS 的設計理念是， 將文件的樣式與文件的內容分離，讓文件的內容與樣式可以獨立編輯，並且可以重複使用。

而我們也在漫長的發展過程中，漸漸分離出專業的 UI 和 UX 領域，還有在台灣比較少人提及的 UX 工程師和 UX 分析師等等，這些都是為了讓網頁設計更專業，更有效率。

在業界的前端和設計師都知道，前端和設計的溝通，一直都存在共識問題，尤其是在設計稿的溝通上，設計師總是會覺得前端沒有實現設計稿，而前端總是會覺得設計師沒有考慮到前端的實現問題。

前端和後端系統

面向用戶的一方，我們統稱前端，更多人會誤以為前端僅限於 UI，而這種觀念放在 20 年前，可能是正確的，基於當時的技術上還有很多限制，但是在現在，這種觀念已經不合時宜。

為什麼呢？因為我們能透過瀏覽器做的事情太多了，我們可以製作複雜的遊戲，製作複雜的應用程式，甚至可以製作複雜的編輯器，這些都是在 20 年前，我們無法想像的。

Javascript 的發展，讓前端的能力越來越強大，而且 Javascript 的發展速度也越來越快，這也是為什麼前端工程師的需求越來越高的原因。

功能轉移到前端

當我們需要在前端實作複雜且龐大的功能時，會需要詳細的規劃，良好的設計原則，以及有序的工程實作，這些都是為了讓前端能夠更有效率的開發，並且能夠更容易的維護。

業務需求和快速開發

當我們處於快速回應市場需求的時候，我們需要快速的開發的方法，並且需要確保開發的品質。這時候我們會處於兩難。

因為快速的東西，往往品質都不會太好，而品質好的東西，往往都不會太快，這是一個經典的三角形問題，而這個問題在軟體開發中，也是一直存在的問題。

但是如何我們把自己想像成一個快餐店，我們可以快速的提供食物，而且品質也不錯，這是怎麼做到的呢？

於是我們開始思考，如何將軟體開發的流程，變成快餐店的流程，這樣的流程，就是 FID。

目標

FID 的目的是為了在組織、多專案並併發、多人維護的情況下，利用有限的資源建立一個專屬該組織的前端工程系統，並且能夠快速的開發出產品，而且產品的品質也能夠有保證。

設計原則

這裡指的設計不是指「外觀」如何，而是他是如何運作的，這裡的設計是指「設計模式」，而不是「設計風格」，而 FID 的設計原則有以下五點：

• 抽象原則 Abstraction of Design: FID 將設計視為可抽象和通用的元素。它強調設計的結構和元素應該被抽象化，以便能夠在不同情境中重複使用，從而提高重用性和效率。這促進了前端介面的一致性和可維護性。
• 程式基礎 Implementation is the Foundation: 推動專案的基礎是基於工程實作而建立，工程師在設計中扮演著核心角色之一。
• 資料驅動 Data-Driven Interface: 畫面以資料導向作為基礎，設計應該根據資料來驅動介面的呈現和表現方式。
• 設計延伸 Design-Driven Implementation: 實作應該根據設計來驅動實作的方式，實作應該是設計的延伸，如我們熟悉的 Design system 和 Design token.
• 依賴管理 Dependency Management: 將功能和需求按照其特性分類，並且將其分離，以便能夠更好地管理和維護。

為何需要 FID

傳統開發流程

這是所有想要進入軟體產業的人最常問的問題之一，公司的開發流程是怎樣的呢？

不管我們搜尋還是聽公司的前輩介紹，我們大概都會聽到這樣的流程：

1. PM 規劃需求
2. 設計師設計設計稿
3. 前端工程師實作設計稿
4. QA 測試
5. 上線

詳盡一些的可能會再細分成各個節點，例如下圖

但如果你有在公司工作過，你會發現這個流程並不是這樣的，而是這樣的，如下圖:

不管是 PM、設計師、工程師、測試、都會陷入一個溝通循環中，這個循環會發生很多溝通問題，例如：

1. PM 規劃需求，但是設計師沒有考慮到前端的實作問題，導致前端無法實作，或是前端實作的方式和設計師的想法不同。
2. 設計師因為需求的變更，導致設計稿的變更，但是前端已經實作了，導致前端需要重寫。
3. 每一次迭代都和上一次的迭代有差異，導致前端需要重寫。
4. 前端實作的方式和設計師的想法不同，導致設計師需要重寫設計稿。
5. 驗收標準不明確，導致每個節點無法溝通，產出和預期不同。
6. 這樣的流程並無法優化
7. 浪費大量的時間再溝通上

站在組織的立場，最後一句話的威力是相當驚人的，當然出現問題了，自然就會有人跳出來解決，於是我們導入了其他開發方法，例如敏捷。

敏捷開發

敏捷開發是一種軟體開發的方法論，它強調的是「快速回饋」，而不是「快速交付」，這是敏捷開發和傳統開發的最大差異。

白話一點說，就是當我們在開發一個產品的時候，我們很需要馬上就知道市場對這項產品或功能的反應，依照這個反應，我們可以馬上做出調整，而不是等到產品開發完成後，才發現市場不需要這個產品或功能。

所以在開發流程上，做出了一些細微的改變，為了延續前面的例子，我們可以將流程改成這樣，如下圖（下圖可能不是標準的敏捷開發的示意圖，因為可能不會有設計師或測試這些角色）：

如果團隊中的成員都是資深的工程師，這樣的流程是可以運作的，但是如果團隊中有新人，或是沒有經驗的人，這樣的流程就會有問題，例如：

1. 新人不知道如何實作，導致無法實作。
2. 無法判斷所需資源和預估風險。
3. 技術能力無法進行快迭代
4. 在資訊量不完整的情況下，無法做出正確的決策。

不是方法的問題

在某種程度上，敏捷開發指出了關鍵性的問題和修改，也就是將大家的專注力放在解決問題上，而且資訊都是透明的，加速了溝通的速度。

在這種情況下，工程師能依照資訊和判斷做出「適當」的開發範圍，並依照這個範圍做出「適當」的開發時間，這樣的流程是可以運作的。

但問題就在於，這一切都必須依賴在一個「可靠且懂得規劃和設計的工程師」，如果沒有這樣的工程師，這樣的流程就會失敗，反而會不斷累積技術債，累積的速度跟 Sprint 一樣快。

因為在追求結果和效率的同時，我們忽略了一個重要的問題，那就是「如何讓團隊中的每個人都能做出適當的決策」。

要做到這一點，以目前來看，就只能靠大家的「自動自發」了？

FID

如果再問大家一次，「請問貴公司的開發流程是怎樣」

我猜大家的答案依然還是和第一張圖一樣，而事實上，確實也沒有錯，只是緯度上的問題，我們可以將開發流程分成兩個維度：

1. 大部分認為，開發流程是一個 X 抽時間的流程，例如：
   1. 一個月 PM 寫規劃書
   2. 一個月設計師出設計稿
   3. 一個月工程師開發
   4. 一個月測試

好像每個人都在等待上一個工序完成後，才能開始下一個工序，這樣的流程，我們稱之為「時間維度」。

第二個維度，就是「功能維度」，也就是我們在開發的時候，會將功能分成一個個的小功能，然後依照這些小環節來做開發和溝通，這樣的流程，我們稱之為「功能維度」。

當你將這個圖想像一下水平的時候，就會發現，這個圖和第一張圖是一樣的，只是維度不同而已，這也是為什麼大家都會認為開發流程是一個 X 抽時間的流程。

但在開發時候，又好像要一直回去跟別人討論，然後抱怨之前的作業沒做好。

恰好「敏捷開發」可以將這種問題很大幅度的減少，因為當你仔細觀察，其實以上的開發圖，也可以分成很多個 Sprint，然後每一個 Sprint 確認的範圍，就是一個個的小進度。

是敏捷開發的變形？不是

說到這裡，大家可能已經有點概念，這個方法就是「敏捷開發」的變形，但其實不是，因為這個方法的核心，是「功能維度」，而不是「時間維度」。

如果 FID 做的好，我們甚至能將開發上線的時間做到極端的時間內。

例如說「一天上線，而且保證高品質和穩定」

FID 的核心

其實這並不是什麼新鮮事，在軟體開發每個環節上，都有類似的方法，大家追求的目的都只有以下共同點：

1. 低學習成本
2. 高兼容性
3. 高可讀性
4. 穩定性
5. 高效率

例如本站的範例和網站的 infra 就完全不需要任何的學習成本，只要會寫 JS 就可以了，而且也不需要任何的 infra 知識，因為一切都已經在背後幫你處理好了。

在軟體開發中，希望產品開發也能有一套類似的方法，讓大家都能夠快速的上手，並且能夠快速的開發出產品，而且產品的品質也能夠有保證。

下一章來講解如何實作 FID