如昨天預告的一樣，今天來介紹元件化開發的技術背景，它是什麼、為什麼重要，最後再講一下元件的開發流程。

首先，「元件化開發」是由於前後端分離跟前端框架的興起而達成的。

這邊的前端框架主要是指 單頁式應用（ Single Page Application ) 的框架，幫前端把 HTML, CSS 和 JS 整合在一起，同步處理許多其他的問題方便開發，想知道更多的話可以看我之前在 Medium 寫的文章：前端框架第 0 課：學習框架前該知道的事（偷業配）。

為什麼前後端能分離？

以往前後端分離之前，每個頁面都是由後端即時吐 HTML 給瀏覽器的，但隨著網頁技術的發展、高互動性網站的大量需求，前端框架隨之出現，在框架這邊實作了單一 HTML 就可以渲染所有畫面的機制，後端往後只要吐一份有引用框架程式碼的 HTML 給瀏覽器就好，讓前後端正式分離。

而前端透過框架來處理畫面，後端只需要開出 API 來讓前端去接資料就好。

前後端分離跟元件化開發有什麼關係？

前後端分離後，讓前端可以很單純地按造自己想要的方式去實作畫面。

前端框架其實就只是在幫我們去整合前端獨自開發時，都會所需要的一系列工具而誕生的。

而「元件」則是前端框架中的一項重要概念。

什麼是元件化開發？

在這裏提一下「元件」的定義：「可複用、各自獨立的 UI，如 Button」。

在元件化開發時，我們所追求的是一個能開箱即用 ( out-of-the-box ) 的 UI 元件，因此 UI 元件本身除了畫面之外，功能也需要健全（使用者事件處理、動畫 和 一些基本情境）。

把網站中會需要的元素都切成一個個的 UI 元件後，接下來不論是繼續開發還是團隊合作上，都是在組裝這些 UI 元件 並接上後端資料跟處理商業邏輯。

UI 元件組裝的狀況是指一個 UI 元件可以與其他 UI 元件組在一起，形成一個有更複雜或更適合專案情境的大 UI 元件。

例如：多選選項 (Checkbox) 可以跟輸入框 (Input) 整合成一個 被點選後會跑出輸入框的複合元件 ( CheckboxInput ）。

（這部分一樣會在 Day 06 的 Atomic Design 介紹更詳細！）

一個 UI 元件會包含它的樣式和功能等等所有東西，使用的人可以再按照這個元件開出來的屬性對其進行客製化，而完全不用去理會內部實作邏輯，提升了開發速度的同時也減少了對整份程式碼的認知負擔。

更具體一點說，元件化開發就是在「拆分功能，封裝元件，獨立維護」。

元件化開發為什麼很重要？

「大事化小，小事化無。」（Ｘ

「把大頁面拆成小區塊，小區塊再拆成一個個的元件。」（Ｏ

它為什麼很重要其實就跟上面提到元件化開發的本質一樣：

1. 拆分功能：不用一下子就把整個複雜頁面寫出來
2. 封裝元件：可複用、可組裝成更複雜的元件或畫面
3. 獨立維護：方便單元測試，從元件開始確保 Code 的穩定度

元件的開發流程

SOP 基本上是這樣：先定義規格 （Spec），再實作介面（interface），最後實作元件 (Component)，以下會照順序來介紹這三個階段在做什麼。

規格

規格基本上就是指你的元件要開發到什麼樣的程度、會有哪些可能的使用情境，想要因應怎樣的需求。

如果規格沒在事先定義好的話，會讓實作的工程師不知道這個元件應該要有哪些功能，元件有部分是大家公認會有的功能，但也有很多是根據使用情境才會產生的功能，像是 Tabs 的右邊要不要有其他的功能鍵等等。

總之就是：定義好規格，才不會使後續在使用時才衍生太多額外需求，進而需要反覆回來修改。

雖然不可能一次到位，但確實可以減輕許多來來回回的流程。

更重要的是可以預防以下兩個問題：

一、元件的自由度或是彈性不一

這點簡單來說就是我們能對元件客製化到什麼程度，這也會直接影響到使用時的麻煩程度。

像是複合式的元件，我們是需要連能使用的元件都先定義好，還是就開一個介面給使用者使用，前者就是使用起來很方便，只要指定一些元素傳進去就好，而後者則是需要每次都重寫很多次子元素。

二、元件本身的複雜度不一

因應元件的彈性不一致，彈性越高的，元件的實作複雜度就越低，有些實作的成本會是在使用時體現，但若彈性很低，也就意味著我們事先對元件做了更多的處理，那麼使用時就能很方便少寫很多程式碼，也因此彈性就跟複雜度成反本，彈性越高的元件可以越不複雜，越低的處理越多事就會變越複雜，進而可能會影響到效能或使用上的不直覺。

介面

這邊先引用一下維基百科對介面的定義：「程式編寫或設計的方法論中作為程式元件功能的抽象化」。

這句話看起來很拗口，但其實就是你希望元件提供你的功能、也可以說是元件的 API，以 Button 來說，你會希望它可以點擊 (onClick)、非同步操作時可以提供載入的狀態 (Loading)、有按鈕名稱 (Label) 等等。

而介面對使用者來說就是一個黑盒子，使用者只要知道這個元件的介面是什麼，就能知道這個元件能做到哪些事情了。

先定義好介面，後續實作就只是再一一實現使用介面所預期的結果，如：disabled 要改變 CSS 跟 無效化元件。

同時，也會有許多 Component 都有類似的功能，這時候其實就能把共通的功能抽出來做成一個介面，後續的 Component 就都可以在這個介面的基礎下再進行更多的封裝，最常見的就是表單元件，至少會有當前的值 (value) 跟改變值的行為 (onChange)，再來是識別用的 id、name，或是輸入錯誤的提示 (error message) 等等。

介面的部分會在 Day 12 開始的 UML 篇章跟大家介紹得更仔細。

規格跟介面都介紹完後，我們可以看到只有最後的元件實作環節會跟你使用的框架 （React、Vue、Angular） 語法有關，所以雖然本系列實作的環節會用 React 來寫，但基本上影響的程度不會到很大，至少需求跟架構都能在進入到實作前釐清。

元件實作

主要就是把定義好的介面一一實作出來，在 HTML 定義元件呈現的架構、CSS 去寫樣式，並需要處理各種情境的變化（像是 disabled 顏色要變淡）、而 JS 和 框架的語法來撰寫互動邏輯和資料流的管理。

其實就是比較純粹地在寫 Code 啦，但如果前面的規格和需求步驟沒有確實，在實作時就會要一直來來回回確認很多東西，其實對於整個開發體驗（Developer Exprience）來說是很糟糕的。

如果你聽完還很模糊的話沒關係，在這先有個概念，等到 Day 21 實戰演練系列開始時搭配程式碼再回來看就會更有感囉！

上述講完規格、需求和實作在做什麼之後，更細一點來講流程會是這樣：

1. 由設 計師 和 PM 根據專案可能會應用到的功能與情境來定義出規格
2. 工程師審視這些規格，看有沒有更好更有效率的作法，主要是避免為了某些不重要的功能花了太多時間開發，後續使用跟維護上也會衍生很多成本
3. 規格確認好後才開始思考跟定義元件的介面
4. 介面定義好後，才會真的開始進入實作

如果想知道更多軟體開發流程的細節，可以參考

軟體業到底在幹嘛？軟體業開發流程、各職能大揭密！ 或 Software Development Process: How to Pick The Process That’s Right For You ，但實際上還是很看公司本身的體質，來決定採取怎樣的開發流程哩！

小結

今天一樣是打底的過程，讓我們理解當今前端是如何能做到元件化開發的一些背景，像是前後端分離、應映前端框架而生的元件概念，以及對於元件化開發這一概念的解釋。

整個元件化開發的概念基本上其實就是很常用到的東西要整合起來，遵循 DRY ( Don't Repeat Yourself ) 的原則，而對於前端來說，很常用到的就是各種 UI 元件了。

後半開發流程的部分則是給個概念，之後介紹完介面跟一些實作後再回來看效果會更好。

明天會介紹的是 UI 元件的分類系統，並會透過現行幾個比較完整的 UI 元件庫來介紹，敬請期待囉！