現代化 Web 開發技術學習分享

模組化一直以來都是網頁端一項很重要的處理，有效的模組化可讓程式碼進一步提升其閱讀性，以讓後續維護人員更快速的進入狀況，且利用模組可重用的特性，我們也不需要撰寫這麼多的重複代碼，載入即完成，可說是大幅提高了其開發效率。在 CSS 可使用 @import 來拆分模組，而 SCSS 同樣也是使用 @import 來拆分模組，兩者不同的地方在於 CSS 的 @import 會產生額外的 request，而 SCSS 主要利用其特殊的 partial 檔案形成模組化的效果，再不產生額外 request 下達到模組化目的。

在前面我們有提到可使用 @mixin 將發生重用的樣式給包裝起來，進而減少重複撰寫樣式的時間，但在這邊有一個問題是，此做法會造成編譯後的 CSS 發生樣式大量重複的問題，搞得檔案異常肥大，在較為嚴苛的環境下，此問題是不被允許的，建議的作法是使用 @entend 並搭配 placeholder 選擇器將重用樣式給綑綁起來，@extend 就類似於 @mixin，不同的地方在於 @extend 會將目標對象進行合併而不是載入，而 placeholder 選擇器主要用來創建重用對象，在不被編譯的狀態下給予 @extend 繼承用。

之前介紹 @mixin 時是以一般語言的函式做為參考進行操作，事實上 SCSS 有更符合函式定義的語法名為 @function，與 @mixin 不同的地方在於 @function 無法直接將 CSS 樣式加載至當前所在的 CSS 塊內，反而是透過 @return 將函式內處理的結果返回給呼叫的對象後續再進行相關處理，簡單來講就是 @mixin 負責包裝 CSS 樣式，而 @function 則是包裝需透過處理使之形成的有效對象，該如何透過 @function 進一步提升開發效率也就是本篇的重點。

傳統在撰寫樣式表上很常發生重工的現象，雖然說作用的對象是不同的，這指 CSS 選擇器作用的目標，但無法否認確實降低了我們的開發效率，最理想的做法應該是將會重用的樣式包裝成一個物件，每當有相同樣式的撰寫需求時，只需要取用這一個物件即可達到目的，而 Sass / SCSS 正好有提供像是 @mixin 的語句，用法就類似於 Vue.js 的 mixin，只不過將其撰寫內容更改為樣式而已，最後使用 @include 載入 mixin 即可完成取用動作，藉此達到減少重工發生可能的目的。

雖然說撰寫樣式表其複雜性遠遠低於一般的主流程式語言，但無法否認在某些時候我們確實需要更高效的做法來達到目的，迴圈處理就是個很好的例子，傳統 CSS 撰寫樣式必定是透過手動輸入的方式來完成，而 Sass / SCSS 提供了像是 @for、@each、@while 語句，讓我們透過迴圈的方式快速產出樣式，藉此達到高效開發的目的，其中也包含像是 @if、@else if 等條件判斷式，可根據其判斷輸出不同的樣式，讓我們在較複雜的情境依然能夠保持其樣式表的靈活度。

先前我們就有提到 Sass / SCSS 真正意義上的將樣式表變為了一門程式語言，即 SassScript，而身為程式語言，想當然就會有所謂的變數可以使用，這也是我跳坑的其中一個原因，你能想像樣式表居然能夠使用變數做撰寫嗎？這指的變數與其他語言差不多，同樣有分為字串、陣列、物件等型態可做使用，大幅提高了代碼的重用性，以後如有更改的需求，也只需針對變數做處理即可，改善傳統樣式表不易維護問題。

上一次我們已經將 SCSS 的編譯環境給建立好了，接下來讓我們正式進入到語法的章節，首先介紹的是 nesting 巢狀結構與父選擇器，巢狀結構是 Sass / SCSS 最具特色的功能之一，之前我們有提到傳統 CSS 可能會發生父對象重複撰寫的問題，為了避免汙染到其他樣式，我們必須明確地寫出父子對象的關係，搞到最後才發現浪費了許多時間，如果改使用 Sass / SCSS 中的巢狀結構語法並搭配父選擇器，不僅可解決此類問題，同時也能改善傳統樣式表可讀性低落的問題。

在之前介紹的各種前端工具中，都是使用 SCSS 最為樣式表的開發對象，原因很簡單，那就是它大幅加強了 CSS 對各種操作的支持，以往我們會認為 CSS 語法很單調，但也因為太單調，導致存在許多操作上的不便，現在我們有了 Sass / SCSS 等 CSS 預處理器可以選擇，真正意義上的將樣式表變為一門程式語言，可使用變數、函式、迴圈等程式語言基本就具備的功能達到撰寫樣式表的目的。此篇將從何謂 CSS 預處理器開始介紹，接著說明 Sass / SCSS 該如何透過相關工具使之編譯成 CSS 跑在瀏覽器上。

隨著專案越來越大，協作人員越來越多，衝突發生的機率也越來越高，訂定良好的團隊規範就顯得更為重要，Workflow 因此而誕生，常見的對象有 Git Flow、GitHub Flow 或 GitLab flow 等，主要都是被用來解決團隊間無規範可遵循造成衝突的問題，透過共同遵循的處理流程，達到有條理的進行團隊協作開發。此篇將介紹目前主流的 GitHub Flow 工作流程是如何運作，並透過實際演練說明它所能帶給團隊的好處。

目前我們都是在自己的遠端數據庫做操作，由於是自己的並不會遇到所謂的權限問題，但假如我們也想操作其他開發者的遠端數據庫呢？比如你正在使用的套件存在 Bug，而你剛好有能力修復，將專案克隆並修復後，你想把最新提交推至原作的遠端數據庫，這時就會遇到權限不足的問題，你可能透過 Email 請作者開權限給你，但你覺得他會理你嗎？通常這個過程我們都會使用 Fork 與 Pull Request 來完成，先將原作的數據庫 Fork 至帳號底下，待我們克隆並修復完成後，再透過 Pull Request 請求作者合併更新。