這篇文章是我在 【前端工程師養成班】的團體專題製作紀錄。
在這個系列，我會分享工程師養成班的課程規劃、各技能的學習內容與實務應用，讓還沒走上這條路的人可以一探究竟，再決定是否要走上這條不歸路。
本篇是前端工程師養成班的團體專題製作紀錄的第二篇，團體專題製作是練習團隊開發流程的初體驗。
這系列記錄一個網站從需求蒐集彙整、多人開發、到專案驗收的過程，內容很多所以拆成三篇來寫，分別是【企劃階段】、【開發階段】、【驗收與求職】。
內容包含各階段的準備項目、重點整理，以及我個人的心路歷程 (碎碎念)
關於我 | 餐飲背景，在決定報名養成班之前，對工程師、寫程式一點概念都沒有，大學科系與數理、資工、資管完全零交集。
而上課的年紀，正是鄉民（酸民？）熱烈討論工程師應該要退休( 被淘汰 ) 的年紀。
這樣的背景，在半年的養成班苦讀後後成功轉職，目前在間不錯的接案公司做政府的案子，辦公室有大落地窗可以遠眺美麗華摩天輪與台北 101 ，過著朝九晚五、咖啡喝到飽、work life belance 的生活
團體專題在幹嘛？
網站開發的前端實習生
由養成班分組，一群人一起完成一個網頁作品
小組成員同時角色扮演客戶、ＰＭ、設計師、前端、後端的工作，在各種拉扯與爭執（？）中、一起練習擠出一個網頁作品
養成班規定的部分則是
- 網站須包含資料庫的串接（個人專題是把資料寫死在畫面上）
- 網站需可以跨裝置瀏覽（ ＲＷＤ）
- 成果展那天，要可以展示網站跟簡報給面試官看
我們班的狀況滿特別的，不是所有人都有參與團體專題。
一部分的人來上課只是為了學個新技能，沒有一定要藉此轉職或就業。
而投入團隊專題製作，代表接下來的學習會受影響，以及進入將近三個月、猶如大學考前衝刺班，保證睡眠不足的生活。
所以有人是在團隊專題分組時就表明不參與、有的是分組後直接消失、有的是在小組裡表明不寫 code、只參與討論
而我們班在第一次分組後，因為不參與的人太多，各方意見聲量太大，逼得養成班要大家協調，印象中前後調整過 2 次，才決定三個組別的小組成員
我很有幸被同組成員推舉為組長，（然後養成班表示組長不能換組 T-T ），在換組事件中，有幾位表達不想離開這組，至今回想起來還是有點感動（同學大多都知道我有多 hardcore，待我這組代表開發規定多，也比較辛苦ＸＤ）
為什麼要做團體專題？
做團隊專題的好處？
- 模擬多人開發，實習生的概念
- 練習基本的 git 版本控管功能
- 團隊溝通合作與解決衝突的經驗
- 練習學到的技術，同時累積網站作品
我可以自己找組員嗎？
不行。
就跟職場無法選擇同事一樣，你無法預先知道隊友是神是豬，而不管遇到哪種隊友，都得學會面對與處理，並練習與豬同行（？）
養成班是說他們是從個人專題的成果中，參考大家的程度平均分組的，但
世界上唯一公平的事，就是沒有事情是公平的
所以其實滿多人都覺得別組的成員比較誘人，包括我自己，多想跟 coding 大神、設計大神同一組啊！
當小廢物多幸福，能躺平誰想熬夜ＸＤ
團體專題不是養成班的表定進度嗎？為什麼會要熬夜？
在進入團體專題開發的階段，養成班還是有課程持續在進行
有的是團隊開發中，比較跟前端無關的技能。因為我們需要有作品，所以必須用最基本的程度、配合最簡單的方法，讓我們補足原本專案開發中，PM 與後端的任務。
有的是專案不一定會用到、但就業市場對前端的技能需求，像是前端框架。
我們的 Vue 的課程，就是跟團專一併進行的。
團體專題怎麼進行？
｜開發時間為期二個半月，一個月確認需求跟成品規格，一個半月寫程式
養成班安排了三階段報告、一次成果展，成果展同時會請有在招募前端的公司人資或團隊主管來看現場聽。
針對就業後的專案開發模擬，養成班安排了完整的流程，從企劃發想、功能討論、系統分析、資料庫設計、畫面設計、團隊分工到最後的成果展現，若完全依照養成班規劃的超硬流程、配上整段期間（三個月）每天睡 4 小時的心理準備，絕對可以做出一個還算滿意的網站作品。
從 4 月確定分組後，到最後成果發表為期 2 個半月的時間。
整個流程大致可分三階段
- 寫程式之前的企劃階段 ｜看這篇
- 寫程式的開發階段
- 驗收與求職
除了前端工程師，整個流程也涵蓋了就業後，許多不同的專案成員的分工，會以下面這種形式來條列
流程主題［ 職場角色 ］- 內容說明
寫程式之前的企劃階段
- 企劃討論［ 使用者 ］- 全組討論出有興趣、需要做資料串接的網站主題、會有哪些主要功能
- 線稿製作［ UIUX、網頁設計師 ］- 跟 【 個人專題 】一樣，規劃網站的版面配置
- 訂出前後台功能架構 ［ 使用者 vs PM、系統分析 ］- 決定主要功能，因為要串接資料庫，所以一定要有前後台、跟註冊登入功能
- 撰寫使用者案例［ PM 、系統分析 ］- 藉由這個過程，讓團隊聚焦在主要功能、不失焦在人性本貪婪的海量需求中
- 活動圖［ PM 、系統分析 ] - 白話文就是流程圖，將前面列出的網站主要功能，用流程圖呈現，像是不同使用者登入後會跳轉到什麼畫面、使用者選擇不同選項後，網站分別會給什麼回應、或是導向哪個頁面，都是在這個階段整理
- 首頁 mockup、logo 設計 5 個評選［ UIUX、網頁設計師 ］- 設計畫面、定義主要色系
- 開發分工［ PM ] - 分配哪些頁面誰負責
- 確定網站風格 [ UIUX、網頁設計師 ]
寫程式之的開發階段
- 建立資料庫 [ 後端 ]-schema 設計，建立資料庫，匯入資料
- 網頁切版 [ 前端 ]- HTML, CSS, JS 的階段，讓網站有個樣子
- 串接ＡＰＩ [ 前端 ]- 將網頁串到資料數，將畫面上的假資料，用資料庫的真資料取代
寫完程式之的驗收階段
- RWD 的 mockup 驗收 [ UIUX、網頁設計師、前端工程師 ]- 根據就業之後的開發經驗，使用者想的畫面通常是桌機，如果沒有配合的設計師先設計好跨裝置的畫面，就自己從桌機延伸出可行的 pad 或手機版，但如果是自己從頭設計，在一開始設計電腦版時，就會同時考量 RWD 的便利性，直接設計桌機、pad、手機在切版時，比較好好切換的排版。
- 網站驗收［ PM ]- 除了網頁本人以外，有時候會需要提供網頁操作或教學文件，以養成班的規劃，我們在這階段做的則是網站設計發想及網頁說明文件
本篇重點為開發階段的紀錄，也歡迎去企劃階段、驗收階段 看看，暸解團體專題開發的全貌
寫程式的開發階段
前面花了大約三週做網頁企劃，這階段則進入了實務上，前端的工作內容：依照設計稿跟文字需求，把程式碼寫出來
相較於一人開發，多人開發的注意事項包含
- 決定使用技術：團隊技術取決於技術水平最低的那個人、而不是最高的！
- 遵守開發規範，像是 CSS 的命名原則（避免樣式干擾）、資料夾、檔案的命名原則
- git（版控工具）的使用，如何減少程式碼的衝突，發生衝突該怎麼解
這階段大家會依照分工開始寫 code。
配合課程內容，我們模擬敏捷開發，每天下課後花 15 分鐘簡單回報各自的開發進度。
也可以提出自己開發遇到的問題，看其他人有沒有解，都無解再去問輔導老師。
同時方便追蹤專案的進度，若有人落後，可以即時調整分工。
並且在小組中再拆小小組，Ａ有問題先去問 Ｂ，Ｃ有問題先跟 Ｄ討論，一方面分散掉技術高手的負擔，另一方面發問者也不用擔心自己的問題太蠢，怕佔用大家時間而不敢發言。
最重要的是，可以在這個時間點，在有小老師的情況下，把各自的開發進度合併到開發分支，有衝突可以即時解
關於使用技術
小組當時有個特別聰明的人，他學習能力之好，在我們剛要學 SASS 時，他已經在網路上自學 tailwind，而且用在個人專題上了，養成班雖然強力反對（報告時都感覺快跟老師吵起來），但阻止無意義，因為來上課的大多數人其實也沒有這個能力ＸＤ
在老師要小組討論並決定是否把 SASS 用在團體專題時，（ 因為開發時才正開始教，怕有人學不會），聰明人卻在所有老師不在的時間，用力鼓吹大家使用 tailwind，表示 SASS 太囉唆，國外在流行 tailwind， SASS 要被淘汰了等等…
聰明人很有演說家的天份，班上同學跟小組成員不少被影響，在當時我自己都覺得 tailwind 聽起來好棒棒，但反思養成班就業導向，理論上不至於教非業界主流技術來壞自己招牌
但我一個產業門外漢如何判別業界主流技術？想起了人資好朋友 104
當時用技術名稱在 104 當關鍵字搜尋職務，把 CSS, SASS, tailwind 以及其他所有被聰明人公開批評過的技術全丟去 104 蒐一輪，那個數字落差現在想起來都還是很幽默，隔天就把技術與職務需求比例做成 excel 表同學分享，在那之後就再也沒人說要跟聰明人用一樣的技術了
事後想想，聰明人一直都是在國外工作，他的參考資料都是國外的，但會來養成班求轉職的我們，至少一開始的工作待在台灣的機率較高，或許他說的沒錯，但那個資訊卻不適合我們。
環境背景不同，造成資訊價值的極大的落差，自己判讀資訊的能力還是要有！
很慶幸當時沒有採納他的意見，因為他在團隊專題開始約莫 2 週後，就因為私人因素退出開發了
關於開發規範
團隊開發與個人開發最不一樣的地方，就是很多東西要共用，一不小心就會你蓋過我的、我蓋過你的，像是把 style 寫在 html 標籤上，會讓其他人的頁面全部破版。
印象很深要開發的時候剛好遇到一個連假，幾個老師叮嚀囑咐說先不要開發、好好休假，有些東西連假後教了再開始做比較好。
很多同學開開心心的偷吃步，放假回來之後小懊惱（至少我們這組是這樣，因為連假寫的幾乎全部重寫）
跟老師討論後，我趁連假先寫好團隊的開發規範，像是可以共用的樣式、資料、檔案、到 class 的命名邏輯
送上當時強迫症的菜雞開發規範（專案名稱叫 外 || 食，那 2 根除了程式語言中的或以外，也有筷子的意思（是說有人想知道嗎～））
關於版本控制 git
這塊的教學，是在團體專題開發時一併進行的。養成班的設計是現教現用大家比較能理解並學會
當時老師雖然苦口婆心的講，但無奈在聰明人洗腦式的公開演說下，很多人翹掉這系列的課，反正不聽課，程式碼一樣寫得出來
雖然實際職場的確不是所有人都有在用 git 版本控制，但對有在使用的團隊來說，這就跟呼吸一樣自然，不會反而很奇怪
總之在老師不斷恐嚇說以前學長姐沒有用 git 管理好分支，在要發表前一天某個小可愛一鍵把整個團隊的專案都蓋掉時，我們就決定這塊一定要隨時掌控
一開始是講好只要小組成員有進度，就把當天進度合併到主分支上，並且是在有技術高手在場的情況下操作，以免出現錯誤一緊張亂按一通（？）
幾次之後已經熟悉流程的人，就可以在自己開心得時候合併，沒信心的一樣在每天的會議後，找技術高手一起處理
雖然有點囉唆，但我們這組是在發表之前，都安安穩穩開發到最後的組別。其他不熟悉 git merge 的小組，就如老師所說、傳承了發表前分支大亂、程式碼被蓋掉的崩潰傳統。
老師在講，真的要聽
開發階段我們遇到什麼困難
開發最大難點，就是大家的程度落差
不意外的，每個人的學習曲線不一樣，有些人隨便學就會、有些人努力一下可以跟上、有些人則是用盡全力還不一定跟得上
我們無法預期分給資優生的功能，其實技術門檻比資優還要更高、也無法預期大家覺得或許比較簡單的功能，對於後段班同學來說、還是過於吃力
雖然說在最初分工時，就有先依照不同頁面的功能、依照組員的程度去分工，但怎麼說大家都還在學習中，光是顧好自己的開發進度跟白天新學到的技術就已經腦汁全乾的情況下，還要分擔其他組員負責功能可能無法完成的壓力。
以上種種，讓整個開發過程，對於功能的取捨有大量的拉扯，由於一開始就知道慾望無限（尤其是要滿足小組 6 人的無限想像），我一開始就扮演刪掉功能的黑臉角色，開發前白紙黑字讓大家有共識哪些功能是團隊的 60 分，哪些是 70, 80 分依此類推，同時標註這些功能可能的技術難度
而在每天的敏捷會議中，也可以很明顯地看出哪些 60 分的功能可能會來不及，判斷功能是否要刪掉、或是怎麼協調，讓前段班的組員除了自己負責的項目外，花時間協助較難的功能，都是當時開發辛苦的地方
養成班在開發階段提供的協助
養成班有一門課，叫做夜間輔導
最初看課表時完全無法理解，後來卻成為最搶手課程，有人甚至翹下午的課、晚上再回來上輔導課
所謂的夜間輔導，是由前幾期畢業的一位學長來當大家的解惑老師。
大家把自己的問題準備好，一個個抱著電腦去排隊發問
這堂課從個人專題的前幾週開始，第一堂課沒什麼人要問問題，老師無聊到在教室走來走去看有沒有人要跟他講話 ＸＤ，到第二堂課變得超熱門
一方面大家做作業開始卡關、另一方面又聽說老師可以 1 分鐘解決同學卡關 3 小時的問題、或是給一些實用的資源（像是 F12 網頁開發工具人要怎麼利用 ）
輔導老師對我們就像是神一樣的存在，什麼問題都可以解決
有時候是發現我們的寫法錯誤、有時候是我們想做的功能超出目前的程度，他會看情況協助，有時提供套件讓我們回去研究、或是直接寫一段程式碼大放送
而有時候就算自己沒問題，看他幫其他人解題，都會不小心獲得一些類似功能的開發靈感、或是學到新東西
像是 git 的 commit message，沒有在原本規劃的 git 課程中，就是他看到我們丟人現眼的 commit message，讓我們知道有些約定成俗的規範（然後在畢業一年半後的現在，還有同學不知道這些）
或是不認識的 css 語法，可以從 F12 中直接看到效果，再拿來使用，然後繼續不認識也沒關係
直到現在，跟同學聊到時，都還是會懷念，想要身邊有個這樣的貼身家教，能夠解決初學者不知道怎麼開口問的各種羞恥低能問題
p.s 期待炙手可熱的 ChatGPT ，有天成為超貼身家教
心得與結語
分工歸分工，任務都能完成最重要
我們是來學習成為前端工程師，所以在分組初期，就有公開討論有些不屬於前端工程師範疇的內容，大家想要共同完成（共同承擔減少練習前端的時間），還是如果想練習特定職務的任務可以喊聲認領
像是設計 logo或整體視覺，對設計沒興趣的組員完全不參與也沒關係，而超多人翹掉的系統分析，跟沒人想寫的簡報，我就自己全包認領
印象很深是開發階段，為了讓專案能夠持續推進，我好幾度把某些原本不是我的任務接過來做
第一次是組員自告奮用接下後端的工作，要負責設計關連式資料庫、畫出 schema、把資料匯入資料庫
關連式資料庫在上課時，有聽懂的同學就不在多數，自告奮勇的同學可能就不在此列
這部分的工作，後來是我加上老師，二人一口令他一動作的花了一個早上完成
最後一次則是 6 月初發現後台進度落後，跟專題老師一夜長談（？）之後，決定自己拿來做，捨棄原本自己頁面中，本來要優化的部分。與其最後作品有人 30 分、有人 80 分，我認為應該讓大家都至少 60 分過關，然後可以超越的組員就讓他們開心衝
寫到這裡，覺得自己在整個團體專案的心得，都是從 pm 角度出發，而不是前端
如果時光倒流，我應該會竭盡所能不要當組長（？）然後把煩惱專案進度與分工的精力，拿來加強自己的技術
開發階段不知不覺竟然突破 6500 字！
驗收階段就下一篇繼續吧 ～
如果喜歡我的文章，歡迎拍拍手讓我知道，更歡迎你追蹤並持續關注更多的分享。
我們下篇文章見！