進度條

什麼是前端工程師(Front end Developer)?要成為前端工程師要學習什麼樣的技術呢?

別人講還不如自己判斷,前因後果全部講出來,掌握根本原因就不怕剛學完就退流行!

作者: 進度條編輯群 更新日期:

此文章也有影片介紹,可以搭配影片一起學習!

01. 瀏覽器與網頁組成簡介,前端開發網頁是在做什麼 (所屬課程)

02. 我是新手 我該從HTML還是JavaScript開始學習 (所屬課程)


以下正式開始文章


【前端工程師】成為工程師界的顯學之一已經不是一兩天的事情了,現在的網站比起以前相對複雜很多,大型的網站都不是一個人可以完成的。大型的工程多半都是要切分出多個工作項目來實現的,比方說蓋房子,大型建設公司多半都由多個部門或是協力公司合作,畫設計圖、蓋房子、室內裝潢...等可能都由不同的人進行,最後再做整合。

 

所以真的以職務細分的話,「架設網站」其實可以區分出很多職務。每個職務做的事情不太一樣。但是讓不是這個領域的人記得所有的職務名稱不是一件容易的事。所以我們通常還是會有一個比較大範圍的統稱,比方說網路工程師 (Web developer) 來說,我們基本上切分成「前端」與「後端」,如果工作範圍兩邊都涉及,有些人就會稱它為「全端」。

 

"前端工程師"英文為 Front-end developer,直接翻譯為前端"開發者",一般比較少稱為 Front-end Programmer 或是 Engineer, 但是可以說 Front-end developer 是一個 Programmer (程式員或是程式設計師)。Front-end 因為常用的關係,也很常被寫成 Frontend。

根據一些英文的文章,有些人認為 Front-end developer 與 Front-end Engineer 是不同的,Engineer 代表的是更扎實的程式訓練,例如擁有資訊工程背景的學歷。不過根據筆者個人經驗,不是任何公司在發布職缺的時候都會想這麼多,尤其是人資體系的管理人員或是公司老闆,很多人並不真的那麼了解。所以在找尋英文職缺的時候還是可以兩個都搜尋看看。

 

 

就跟所有的工程項目一樣,架設網站在一開始沒有那麼複雜,所以在早期其實沒有所謂的前端(Front-end)與後端(Back-end)的區別,大家都是全端(Full-stack)工程師,不過即使當時有人開始這麼稱呼職位,也還不流通,所以可以一開始是沒有這些職缺的。

 

在 IE 還是霸主的年代的 Web 1.0 年代,JavaScript 的功能還沒有那麼齊全,在當時他比較像是讓你控制瀏覽器的腳本語言,而且JavaScript 語法當時也還沒有統一,因為就連瀏覽器本身也沒有「標準」。

 

很多同學可能從小考試到大,會認為考試就應該要有標準答案。但是商業社會是沒有標準答案的,誰拳頭大、誰市佔率高,誰就是「標準」。瀏覽器大戰一再被提出來並不是沒有原因的,因為贏的人很可能就成為了「標準」。當年網景 Netscape 的 Netscape Navigator 網景領航員 跟 微軟 IE 彼此都有自己的 JavaScript 語法,甚至 IE 並不稱自己的語法是 JavaScript 而是 JScript 。這方面細節就不提了,最後的結果就是網景被收購,部分人員資源成立 Mozilla 非營利專案,並且釋出 Firefox 瀏覽器(Mozilla 官方歷史),大家學習前端喜歡參考的 MDN 網站就是他們在維護的。

 

不過無論你怎麼解釋,至少在一開始,「前端」指的就是「瀏覽器 browser」。

 

 

瀏覽器顯示網頁並不像串流影片是完整的圖片去置換影格,例如一秒的影片其實可能是 30 張圖片去動作。網頁是文字,一開始的網頁是滿簡單的內容,就是一堆文字。在還沒有網路概念的年代,遠端連線就已經存在了,那個年代連 C 語言都是新東西。當時溝通的工具是「終端機(Terminal)」。

 

如果兩台電腦之間可以互相溝通,電腦除非有設定過不然平常都是閒置的,所以電腦之間彼此即使連線也什麼事情都不會發生。通常都是有一個「使用者(也就是你)」操作鍵盤、滑鼠等輸入裝置(input device)輸入指令才會觸發一系列的動作,有時候「指令」被包裝起來變成你只要點擊滑鼠就可以觸發。

 

我們執行指令當然是有目的,比方說輸入一些數字讓遠端的電腦幫我們算數學。電腦(computer) 這個字直接翻譯會是 「compute + er」也就是(數學)運算的人事物。

 

這些內容雖然很計算機概論,但主要是要讓大家先有「顧客端(Client side)」與「伺服器端  (Server side)」的概念。發送指令等待結果的就是顧客端,他是消費者,伺服器端就是運算的那台電腦。要注意,電腦連線不是只有網路連線的概念,不過我們這篇談到的都可以假定是網路連線。

 

即使是現在,你也是可以使用「終端機」對「伺服器」發送指令讓他回應你,但是你看到的回應就是一堆文字而已。

 

 

如果文字本身有帶有額外資訊,那我們就可以利用那些資訊做出更多的事情。比方說我們可以「自己定義格式」:  “你好 | 14px | red ”,就可以得到 14px 大小的「你好」。不過上面這種寫法在各大軟體裡面都不會實現我們想要的結果,除非是你自己寫的程式。無法正確得到想要的結果,我們一般就稱為「格式不支援」。

 

不過所謂的各大程式,就是大公司的程式、市佔率高的程式。所以在一開始,沒有國際化規定格式之前,各大公司都是定義自己的格式的。以結論來說,HTML 與 CSS 和 JavaScript 這樣的組合是最後的勝利者。他長得可能像下面這樣:

 

<html>
  <head></head>
  <body>
    <h1>你好</h1>
  </body>
</html>

 

這樣的格式如果在「終端機」裡面顯示就會是上面看到的純文字的樣子,因為他讀不懂格式所代表的意義。而「瀏覽器」就可以正常顯示。

 

 

前面雖然繞了一大圈,但是總結來說,前端工程師的工作就是圍繞著 HTML, CSSJavaScript 和「網頁瀏覽器 Web browser」。要解說它們的話基本上也是要照著相同的順序講解。

 

首先 HTML ,正如上面所說,網頁基本上就是文字畫面,所以你可以把編輯 HTML 想成編輯 Word,雖然寫法不太一樣,但是最初目的大同小異。

 

寫 Word 這樣的文章的時候一般你會至少有個標題、主要內文、圖片、列表、表格等資訊。如果用 HTML 來表達的話。可能會是下面這樣。

 

<h1>標題</h1>
<main>
    <p>段落一</p>
    <p>段落二</p>
</main>
<img src="圖片連結"/>

列表
<ul>
    <li>列表項目一</li>
    <li>列表項目一二</li>
</ul>

表格
<table>
   <tbody>
       <tr>
          <td>表格資料一</td>
          <td>表格資料二</td>
       </tr>
    </tbody>
</table>
 

 

寫完以後只要通過瀏覽器去顯示,大致上就會由上而下顯示你的內容。除了我們這樣的一個一個寫,在大部分的情況也可以把<標籤> 塞進其他的 <標籤> 裡面,例如你的文字段落想要配合圖片的話,你可以把 <img> 塞進 <main> 裡面。像這樣的寫法的話,就是所謂的「標記式語言 Markup language」(WIKI),標記式語言比較常見的就是我們現在討論的 HTML 與大名鼎鼎的 XML。儘管很多人認為 HTML並不包含「程式語言」的特性而不是 「程式語言」的一種,不過因為 HTML 就是 Hypertext Markup Language 的縮寫,所以在討論的時候還是以「語言」稱呼他會比較好。(雖然我們也認為它不能「運算」所以比較接近「格式」)

 

 

 

雖然 HTML 可以做基本的段落排列,但是沒辦法做到所謂的網頁排版,也就是說你的文字不會有顏色,也沒辦法設定文字大小,也沒辦法做到所謂的文字包覆圖片或是相反的設定控制。更不用說一些滑鼠滑上去會有不同顏色之類類似動畫的功能。所以 CSS 就誕生了!

 

CSS (WIKI, MDN) 你可以想成它是 HTML 的一個附屬產品,畢竟連終端機上面的文字都可以設定了(看那 PTT 精美的畫面, WIKI)。所以即使是現在,HTML 裡面也有 style 樣式這個 attribute 可以使用。例如我們想要文字變成紅色的。我們可以這樣寫:
 

<p style='color: red;'> 紅色的文字 </p>


結果如下
 

紅色的文字

 

當然,一開始 HTML 也是被期望實現很多功能,比方說:
 

<img src="圖片連結" width="圖片寬度" />


像這樣寫法去控制 "width" 寬度的功能,我們就稱這個 width 為 HTML 的 attribute (屬性)之一。

 

後來大概發現這樣寫不完,功能太多,所以就把這種控制 HTML 顯示的功能抽出來放進 style 裡面去控制。所以就可以改寫成:
 

<img src="圖片連結" style="width: 圖片寬度;" />

 

因為 style 裡面有多種設定,所以要用「名稱: 數值; 」的方式來設定,「分號 ; 」就是用來分開設定不讓他們連再一起的語法。

 

 

這樣大致上設定是沒有問題的,不過後來隨著工程師的創意與老闆的需求越來越高,真的完全用這種我們稱之為 inline 的寫法來寫的話,HTML 文檔會變成異常複雜難維護。現在當然也是有很多種解法,不過最常見的解決方式還是使用 css 獨立出來,利用 selector 綁定的寫法。例如常見的 class 綁定或是 ID 綁定。
 

我們可以把上面的紅色文字獨立出來變成 css class,綁定在 HTML attribute 上,例如:

 

<style>
.redColor {
   color: red;
}
</style>
<p class='redColor'>紅色文字</p>

 

紅色文字

 

也可以做的更複雜一些:

 

<style>
.bigRedColor {
   font-size: 36px;
   color: red;
}
</style>

<p class='bigRedColor'>紅色文字(大)</p>

 

紅色文字(大)

 

 

當然他還有各式各樣的花式玩法,也有一些進階的格式例如 SASS、LESS...等。因為如果想要做 RWD 響應式網頁或是更進一步的外觀框架例如 Bootstrap 的話,CSS 設定也是爆炸多,單用原生的語法並不是很好管理。另外一個更近一步的原因,就是 CSS 也沒有很明顯的運算概念。雖然 CSS 現在也可以做一些動畫,而且效能會比 JavaScript 好上不少。但是要把它當成商業邏輯程式來使用運算還是不太可能,畢竟已經有它的同事 JavaScript 在專攻這部分的。所以進階的 CSS 格式基本上都是讓 CSS 更好寫、更模組化。例如 SASS 的寫法就有 Mixin 的概念,讓一段 CSS 語法可以被 reuse (在使用),概念上跟一般程式語言寫 function 就很接近了。

 

 

SASS 出現的時候 LESS 已經火紅一陣子了,但是 SASS 一開始的語法並不像類 C語言,反而比較接近 Python 這樣用分行與空白的概念。當時候流行的 HAML(HTML), Markdown(HTML),  Coffee Script(JavaScript), YAML(XML) 其實都往這邊走,但是最後幾乎都還是輸給了「大括號 { }」,這樣
類C語言的特徵,尤其是 JavaScript 和 CSS 本身就使用 「大括號 { }」和「分號 ;」,所以後來 SASS 就推出了另外一種語法版本 SCSS,SCSS出現後,LESS 就逐漸式微,SCSS 在寫文章的此時已經成為了大哥一陣子。所以這邊建議大家,如果看到任何新的技術出現,如果跟原本的差異太大的話,它像煙火一般曇花一現的可能性很高,盡量找「加強版」概念的技術。


此外 SCSS 裡面雖然有很多語法也是直接使用跟類C 程式語言一樣的關鍵字,不過最大的差異在於 SCSS 並不直接被瀏覽器支援,所以要先把 SCSS 的語法轉換成一般 CSS 語法。因此無論 SCSS 寫得有多神奇,都不是在瀏覽器上執行,而是在轉換的「編譯器」執行。


例如 function 在一般的程式裡面,是在初始化階段先放在記憶體裡面,接下來在執行的 runtime 階段(運行階段)只要一直調用同一段程式即可,節省記憶體空間。但是 SCSS 因為要先轉換的關係,所以在 runtime 裡面是已經展開的 CSS 語法,並沒有節省記憶體空間。單純在維護管理上面好管理,擁有開發上面的方便性。

 

相關連結:

製作網站不能沒有談到的功能 - RWD響應式設計(自適應網頁)

[不是工程師] 物件導向設計原則(SOLID)很繞口?試試從模組化開發與測試來理解吧

 

 

接下來就要講前端工程最重要的要素了: JavaScript

 

現在其實「前端工程師」、「視覺設計」或是「網頁設計師」都有可能會需要 JavaScript 這項技能。就職務上面其實沒有什麼優劣,不過有不少「前端工程師」一開始就是因為沒有「美感」所以才往「工程和架構」方面專精,也有很多專攻設計的設計師不會 JavaScript 也可以領年薪百萬以上。當然,也沒有人說「美感」與「程式邏輯」不能兼具。

 

但是可以講的就是,無論是「設計師」方向還是「工程師」方向,專業上要學的都很多。以現實面來說,目前「工程師」名目的職缺薪水通常會比較高,面試也比較朝計算機相關議題來考試,此職位的應徵者如果專業技能合格,同時又有美感的話,會讓老闆覺得賺到了。

 

不過很多小型公司其實沒有辦法把工作拆分的太開,畢竟預算人手有限,所以都要做的可能性很高。

 

 

在講 JavaScript 之前,先回頭講一下比較完整的網頁設計步驟:

 

1. 業主有個想法,想要架設一個網站做某件事情,例如銷售、或是廣告。

2. 設計師依照業主的想法,畫出了畫面,並且業主同意製作。

3. 工程師依照設計畫面利用 HTML CSS 實做出網頁。

4. 工程師依照設計利用 JavaScript 實作出畫面的互動,加強使用者體驗。

(此步驟忽略後端相關內容)

 

 

當然,這邊2, 3, 4 點提到的設計師與工程師可以是同一個人,也就是傳說中的一條龍概念(你就是那條龍)。此外,可以跟大家分享的是,理論上做那麼多事薪水應該比較高,但事實上就是因為預算不夠才讓你做那麼多事,所以理論跟事實常常是相反的。
 

不過你可以想成,大致上「前端工程師」至少要包含 3 與 4 點的工作項目。

 

 

 

 

 

JavaScript 一開始的時候並沒有那麼複雜,至少一直到 jQuery 時代都算是很好理解。要理解 JavaScript ,就要先回到瀏覽器的功能。

 

JavaScript 在前端的運用,主要是做兩件事情,控制 DOM 與控制 BOM。這兩個詞看起來很酷炫,但說白了就是操作「HTML文檔」與操作「瀏覽器功能」兩件事。

 

DOM 全名 Document Object Model,初學者可以把 Object 當成 Model 當成贅詞。因為 JavaScript 是物件導向的程式語言,所以無論要操作什麼其實都是 Object 物件概念, 而 Model 就是個名詞,模型。什麼什麼模型是程式界很喜歡的命名方式。

 

DOM 中這三個字最重要的就是 Document 這個字,要理解這個字其實也不難,因為完整的 HTML 文檔其實長成這個樣子:

 

<!DOCTYPE html>
<html>
  中間是....你前面看到的那些標籤。
</html>

 

其中 DOCTYPE 是 Document type (檔案種類)的意思,所以 HTML 就是一種 Document 。因此 DOM 指的就是瀏覽器開放給開發者控制 HTML 文檔的 API 罷了。

 

 

而 BOM 全名 Browser Object Model,依照前面的解釋,重要的就是 Browser。要解釋 BOM 之前一定要理解的是 Browser 就是一支桌面程式。如果你自己照著微軟的技術手冊開發桌面程式,你一定會碰到類似 file open(檔案開啟),play music(播放音樂)...等功能。而 Browser 是一支完整的程式,所以其實他也有做這些功能。如果我們想要控制它的這些功能,就只有他提供給我們控制的方法,不然我們絕對無能為力,畢竟跟作業系統又多隔了一層。

 

所以這邊大家應該都猜到了,BOM 就是讓我們控制的 API 函式庫的集合總稱。BOM 中包含 DOM,畢竟文檔控制也是瀏覽器功能,不算太意外。

 

 

 

前端真的成為一個職位,基本上應該是從 AJAX 熱門起來開始,反過來說,前端工程師基本上就是要大量處理 AJAX 問題。

 

AJAX 全名 Asynchronous JavaScript and XML,非同步JavaScript 與 XML 檔。要解釋這個就要先解釋一下 backend 後端 與 XML 還有 HTML 動態網頁之間的關係。

 

所謂的動態網頁,並不是大家所想的那樣,要飛來飛去的動畫才叫動態網頁。而是只要每次進入網頁都有可能發生變化,其實就可以叫做動態網頁。靜態網頁就是任何人在任何時間進入看它,它都長得一樣。最簡單的想法就是,如果一個網站你登入和不登入看到的內容有任何些許的不一樣,那他就是動態網頁。

(就算他只有 Hi, xxx 歡迎回來,之類的文字)

 

如果要詳細解說這些,有點麻煩,所以還請各位到下面的相關文章暸解一下。以結論來講,就是靠「資料庫」與「後端程式」達成。後端程式會根據使用者送過來的訊息產生不同的內容送到前端去。所以早期沒有前後端分別就是因為這樣,如果前端是由後端來寫,那不是表示「後端工程師」要先做好這個 HTML 畫面?不然後端沒有東西可以傳啊!

 

 

 

後端回傳的步驟主要為(MVC 架構)

1. 從資料庫撈資料 (Model)

2. 整理資料 (Controller)

3. 利用資料繪出 HTML 內容

 

但是當 AJAX 概念出現後,就不一樣了。AJAX 的概念是,前端 JavaScript 程式透過 Browser BOM 發出 HTTP request 跟後端要資料,後端回給前端什麼都可以,可以直接回應一串已經組好的 HTML 資料,也可以單純回應組成 HTML 前從資料庫獲得的那些「純資料」。因為 JavaScript 可以控制 DOM, 也就是他拿到資料後,可以組出跟後端以前組出來一模一樣的 HTML 程式。

 

 

通過這樣的技術,後端就解放了,不需要再去跟 HTML CSS JavaScript 糾纏,可以花更多時間去跟「作業系統」和「程式架構」發展愛恨情仇。所以後端與前端的工作會變成。

 

1. 前端BOM發出拿資料要求

2. 後端從資料庫撈資料 (Model)

3. 後端整理資料 (Controller)

4. 後端發出純資料 (XML 或是 JSON)

5. 前端BOM接收資料

6. 前端利用DOM和資料繪出畫面

 

工作項目這樣就拆開了,所以前端工程師是一定會碰到 AJAX 的,而且也會碰上 Web API 相關議題,畢竟第 4 點取得資料就是靠 Web API。AJAX 發展初期是 XML 資料形式最火熱的時代,不過後來大家發現一般的 key-value 結構其實就很好用了,並且更省傳輸空間,比較小。在JavaScript 中,Object 就是 key-value 的形式,但是http 傳輸必須要是文字型態,所以就把 JavaScript Object 轉換成文字型態,這就是 JSON,全名 JavaScript Object Notation (WIKI),Notation 是簡譜、符號的意思,所以可以想成是用符號(文字)的來表達 JavaScript Object 的形式。

 

 

 

 

講了這麼多,卻還沒講前端三大架構?

 

別急,現在就要講,順便連 jQuery 一起講。

 


早期在 jQuery 稱霸的年代,正處於 IE 與 Chrome 霸主地位交換的前期,jQuery 之所以熱門,就是因為 jQuery 在各大瀏覽器的相容性很高。 jQuery 1.x版,即使是寫這篇文章的現在都還是有一定的市佔率。當時瀏覽器發展很快,新語法在舊瀏覽器無法使用。但是如果使用 jQuery 的話,一套 jQuery 語法基本上就支援大多數主流的瀏覽器版本。jQuery 雖然有大量自己定義的語法函式庫,但本質上還是 JavaScript,所以不需要做編譯轉換,使用起來相當方便。

 

後來 Chrome 霸主地位穩固以後,支援 IE 這件事不再那麼重要。加上 JavaScript 自身也不斷的改進,增加語法。慢慢的把 jQuery 的優點也容進去後。jQuery 的優點就變成了缺點。

 

jQuery 能用同一套程式碼支援多版本的瀏覽器,實作上內部需要一直判斷當前的狀況,所以導致他很多情況比原生的 JavaScript 要來得慢上數倍。加上 AJAX 、使用者體驗(UX)、網頁動畫的要求越來越高,太慢的速度會在根本上限制高互動的前端需求。並且 AJAX 的非同步運用讓前端開始出現資料不同步的問題。

 

例如會員登入後,理論上應該整個畫面都改變成跟該會員有關的畫面,但是用傳統 DOM 更新的話,很容易就會有遺漏。因此後來就有很多前端架構出現要解決這個問題。雖然這個問題在當時算是新的問題。但其實非同步議題是非常古老的議題,所以一開始沒有像 jQuery 一樣的霸主。


 

三大前端框架開始成形的第一股風潮的,就是如日中天的 Google 的親兒子,AngularJS (WIKI)。不過後來 AngularJS 在進行第二版的時候產生了分歧,最後出現了 Angular (不帶 JS),而且與第一版 AngularJS 不相容。這讓後起之秀  Facebook 推出的 React.js 有了絕佳的機會。不過當時的風氣就像是一年流行一個框架,所以 React.js 很快的變成市占率最高的框架不久,Vue.js 也隔空出現。不過後來幾年倒是沒有同樣強勁的挑戰者出現,就維持了三足鼎立至少到了寫文章的當下。

 

 

 

對於新手來說,如果是現在要找到個還不錯的前端工作,基本上都至少要三選一。這邊因為各家支持者都滿多的,所以只大概找幾個點分享給大家。

 

2021年三大前端框架以「全球」市佔率來說,React 目前依然是最高的,但是單就亞洲或是更小範圍的東亞(包含台灣)來說的話,Vue.js 是跟 React 不分千秋甚至超過的。畢竟 Vue.js 的作者是中國人,如果亞洲最大的經濟體與其合作夥伴都偏好使用它,加上Vue.js 確實很好用,且是以個人名義進行的專案,亞洲市佔率如此的高也是必然。Angular 目前已全體來講相對小眾,但是如果你走的是微軟體系和 TypeScript 的話,Angular 佔的比例又不能忽視了。

 

先說,因為筆者對 Angular 和 Vue.js 並不像 React 那麼的熟悉。所以一定會有偏頗(畢竟心中已有定見才選擇 React)。但沒有人說不能都學,所以還是要看個人選擇,很多前端開發者其實都不只會一種。三個架構除了一些歷史原因外,其實寫起來調性與理念也不太一樣,如果對選擇感到迷惘的話,不妨直接寫寫看喔!

 

 

 

此外前面有提到 JavaScript 也有改版的問題,現在 JavaScript 也是每年 ES6、ES7、ES8 這樣逐步推出。新的 JavaScript 標準一樣在舊的瀏覽器會有不支援的問題。因此現在主流的方式就是使用 Babel 先把語法編譯成支援度最高的 ES5 版本。有點像是前面提到的 SASS 轉回 CSS 的感覺。再加上其他的前端資源也有類似的需求,因此又多了 Webpack 這樣的打包軟體。所以目前「前端工程師」要會的低標大概是:

 

1. HTML (非常重要)

2. CSS (非常重要)

3. JavaScript ES5 (非常重要) 

4. 熟練 AJAX 與 Web API (非常重要) 

5. JavaScript ES6 、Babel 與 Webpack (重要)

6. SCSS (還算重要)

7. React.js、Vue.js、Angular 選一個 (還算重要)

8. jQuery (某些工作需要)

9. Git (工作需要,但有些公司認為這很容易上手所以不會進來再學即可)。

 

其他沒提到的不是不重要,而是要看公司與職位需求,畢竟每家公司每個團隊都有不同的選擇。

 

 

最後,最重要的寫在最後面。很多時候公司面試找人不見得能完全找到符合的人選,此外這個業界大多也認為,比起找個工具熟手的平庸人才,還不如找到個聰明人進來讓他,工具一邊工作一邊熟練就好。所以很多公司面試的時候可能不會直接面試三大框架,反而重視考比較多基礎的 JavaScript 、CSS 與網路概念。因此與其煩惱選擇小火龍、傑尼龜還是皮卡丘,先打好基礎才是最重要的喔!

 

最後還是老王賣瓜一下,如有對前端有興趣的話,可以參加我們的線上課程喔!

前端相關的初學者課程有:

 

任何人都可以學會的:

HTML, CSS, JavaScript, jQuery 網頁從零開始

 

稍微難一點,但也是從頭教起的:

ES6,ReactJS與Webpack,前端JavaScript全攻略

 

當然如果很有決心,也可以參考我們的組合課程:

前端 JavaScript 初中階組合 + 版本管理

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

圖文系列教學: 不是工程師也可以看得懂的程式名詞解說!

Small logo

進度條編輯群

進度條編輯團隊