歷經三週半的 STYLiSH 專案崩潰期，終於有些時間小喘，迎來三次的分組活動，包含 Firebase 操作、分組專題研討，以及本階段最大的重點「跨班協作（Co-work）」，我們開始跟其他班別的學員有更多互動機會，並用不到兩週的時間，一起完成 STYLiSH 專案的進階功能。

Firebase 練習

由於大前端班（包含「Front-End」、「iOS」與「Android」三個以呈現使用者介面為主軸的班別）並沒有建立自己的後端資料庫，我們使用 Google 旗下開發者工具 Firebase 提供的資料庫服務。School 安排了兩天給我們練習，但就跟前三週半的 STYLiSH 專案一樣，只給任務、沒有教學，對於第一次接觸這些服務的我們來說，又是一個痛苦的開始。

為了讓不同平臺之間都能讓使用者有相似的體驗，三個班的學員會跨班分組，每個功能在網頁版與手機版都要同步實現，但因為操作方法不同、要看的文件也不同，多數時候不同班別還是各自操作，到測試時才會一起驗證結果。

Firebase 的 Firestore Database 頁面

原本以為 STYLiSH 專案結束頭腦可以稍微放鬆一點，沒想到 Firebase 其實是更大的魔王。一邊看著 School 發下來的任務、一邊讀那些有看沒有懂的文件與教學文章，已經打結到無法思考的腦袋直接當機，想說問班上程度比較好的同學找些靈感，卻發現連學霸都在卡關，一路寫到將近晚上十點半、School 都要關門了才勉強寫出來，這時的我，真的好累、好累...

確診

駐點開始後第二週，我們曾經因有學員確診而全體遠距一天，因為遠距實在太痛苦，我暗中希望日後都再也不要遠距，沒想到下一次的遠距學習，竟然是因為自己確診...

寫完 Firebase 第一天作業後一直很不舒服，原本以為睡個覺起來就沒事了，但隔天起床後疲倦感完全沒有消失，還伴隨著喉嚨痛與咳嗽，怎麼感覺跟 Omicron 病毒造成的症狀有些相似？

我該不會確診了吧？不對呀...這幾週我的足跡超級單純，每天都是 School 跟家裡間兩點一線移動，移動過程也都有戴口罩。由於過往精神不佳時也會有類似症狀，我始終不認為自己真的中獎，但因為已經明顯咳嗽，為了避免同學起疑，還是在出門前用掉當時家裡唯一一包快篩做了檢測，想說先驗個陰性，如果到 School 因為咳嗽而被同學懷疑，可以拿著早上剛驗過、顯示一條線的快篩結果讓大家安心。

快篩結果最多要等十五分鐘才會顯示，可是如果等十五分鐘才出門，估計會趕不上車，這樣我要先出門再看結果嗎？但當檢體逐漸流動，代表測試區的 T 線立刻顯現，代表控制區的 C 線還沒有結果，稍微看了一下說明，這樣代表無效，我是不是就這樣白白浪費了家裡唯一一包快篩？過沒幾秒，C 線跟著出現，看來是不用趕車了，通知 School 後立刻跑到醫院做 PCR。

呈現陽性的快篩結果

PCR 結果當天晚上就出爐，果然是陽性，七天的居家隔離生活就此開始。所幸，確診前一天剛好沒跟同學同時段用餐，加上政府與 School 針對密切接觸者的定義與政策都放寬，多數同學都未受到影響，我也因為沒有發燒、精神尚佳，可以繼續跟著 School 進度走，比較痛苦的是，因為透過 Discord 傳遞訊息並不即時，跟組員的互動會有一定的時間差，加上 Firebase 第二天的任務難度非常高，作業寫不出來的痛苦，遠勝於新冠肺炎造成的身體不適。

與老闆對談～Jamie AMA

Firebase 的小組練習很快就告一段落，經歷這段比 STYLiSH 還令人頭痛的練習，我們與第 15 屆、Campus Program 第 1 屆學員、還有校務人員一同聆聽 AppWorks School 共同創辦人－林之晨（Jamie Lin）兩個小時的線上講座。如同這個階段的名稱「AMA (ask me anything)」，講座並沒有特定主題，主要是針對所有人在 Slido 上提出的問題做出回覆，並從中帶出自己的經驗分享。不得不說，能夠聽到大老闆的現身說法，不論是針對產業發展、學習方法、心態調整等，都有非常大的啟發。

School 沒公開當天 AMA 活動畫面，找個在 AppWorks 類似活動的錄影示意

分組專題研討 Topic Discussion

因應前面每天趕 STYLiSH 進度累積的許多技術債，這個星期是相對輕鬆的「分組報告」時間，每個人各自認領 School 提供的網際網路、CSS、JavaScript、React 相關面試常見問題，進行約 15 分鐘的口頭報告，報告結束後，每位組員會用便條紙寫下給其他人的簡單回饋。雖說每人在兩階段的報告各自都只需要認領一主題，但到真正要面試時，最好是全部都會，因為這些觀念真的非常重要，解釋起來也有一定的複雜度。

以「凸顯技術價值」為主軸

準備報告的同時，可以假想自己即將要進行一場「技術分享」。某些主題因為已經在先前的 STYLiSH 專案接觸過、大家相對熟悉，但也有一些目前多數人仍未觸及的題目，要用 15 分鐘的時間清楚說明就有一定難度。我的腦中不斷浮現 Huli 的〈當我們在學程式時，要學的到底是什麼？〉這篇文章，當中說到學習一項新技術時，可以思考下列五個問題：

1. 這個技術出現以前是什麼樣子？
2. 那時候碰到什麼樣的問題？
3. 這個技術的出現如何解決問題？
4. 所以這項技術應該如何使用？
5. 跟以前的解法比起來，差別在哪裡？有什麼優缺點？

於是在準備報告時，我的架構也以上述五個問題為出發點，除了單純解釋技術本身，更著重於「這項技術有什麼價值」，否則一項單純看起來很炫、卻毫無用武之地的技術，依舊不值得一提。

以我第二次報告的主題「何謂『事件傳遞（Event Propagation）』」為例，我不急於在一開始就解釋相關機制，而是先說明這個機制的用途：事件代理（Event Delegation），待大家感受到這個功能的好處後，再說明其背後的原理：事件捕獲與冒泡（Event Capturing & Bubbling），最後再說明這個機制的問題「事件傳遞到非目標 HTML 元素」，還有對應的解決方法「Event.stopPropagation()」。詳細介紹影片如下：

要在有限的時間內即刻聽懂並內化每位同學的報告內容具有一定難度，但在準備報告的過程中，至少對自己認領的主題會非常了解，畢竟要確認自己是不是真正懂了某個觀念，有沒有辦法「教人」是非常有效的檢視方法。

喘息期結束

因為這個階段比較偏個人進度，遠距進行並沒有太大的問題，我度過了自在的七天居家隔離生活，還能練習疫情期間備受重視的「線上報告」技能，但當我們進入下一階段的「跨班協作」，便立刻感受到遠距的不便。

讓人崩潰不已的遠距討論

跟其他組員一同進行「計畫會議（planning meeting）」時，我永遠只能透過螢幕看小小的字、在吵雜的背景音中試圖聽懂組員的說明，但更慘的是，組員有時會忘記我的存在！對於他們來說，我只是其中一部電腦的一個畫面，討論很熱絡時完全忘記電腦裡還有一個「人」是很正常的事，幸好其中一位同學在晚上有另外跟我通話說明，讓我能追上大家的討論進度。更慶幸的是，兩天前就快篩陰性的我，隔天就能解隔離、回 School 上課啦！如果是跨班協作時間遠距，估計每天都還要崩潰好幾輪。

跨班協作 Co-work

跨班協作是駐點教學中段的重頭戲，也是在 Firebase 練習之後，第二次跟不同班別的人合作，且後端、資料工程班的人也會一起加入，大家一同發想並實現前三週半 STYLiSH 電商網站的進階功能。網頁前端班的負責處理網頁畫面呈現、手機兩班負責各自作業系統的使用者介面與體驗、後端班負責處理 API 資料供前端與手機兩班使用、資料工程班的則負責爬其他電商網站資料，並完成商品推薦系統。在合作的過程中，我發現一個有趣的現象：

1. 前端班表示：我們只有把畫面刻出來串資料而已，好廢。
2. 後端班表示：我們只是把前端要用的 API 寫出來而已，好廢。
3. 資料班表示：我們只有上網抓資料跑模型而已，好廢。

大家都覺得自己做的很簡單、很廢，但事實上，對於不同班別的人來說，自己在做的事情一點也不簡單，而且每個角色都很重要，缺乏任何一者都會讓進階功能難以實現。

敏捷開發初體驗

協作過程仿造真正的職場環境，以「敏捷（Agile）開發」的「Scrum」方法進行，每天早上都會有類似「站立會議（stand up meeting）」的小組討論時間，讓所有成員能夠同步（sync）各自的進度，說明已經完成的進度、當日預計進行的進度，還有當下遇到的困難，導師們每天也會到各組花約五~十分鐘了解進度。

這段期間最重要的能力就是「溝通」，如何理解別人的需求、精確表達自己的想法，遠比展現技術能力來得重要。不僅跨班別的溝通會因彼此熟悉的領域不同而要耗費時間相互理解，同班同學也要花時間確認彼此的任務劃分，並決定由誰管裡主要版本、合併其他組員發的 PR，以類似 Git Flow 流程進行開發。

以 Trello 管理、追蹤專案各項目進度

每個組別提出的進階功能其實都非常類似，多半有「最愛清單」、「相關商品推薦」、「商品評論」、「小遊戲」、「禮券」、「客服聊天室」等，比較特別的有「直播間」、類似 Tinder 的「左滑右滑」，還有「拍照測量衣服尺寸」等，有些功能可以自己手刻、有些要額外使用套件，但不管是用什麼方式實現，把功能做出來的那一刻，真的有滿滿的成就感，原來那些完全沒碰過、曾經認為難度很高的功能，以現在的能力而言，是有辦法實現的，這都要感謝前三週半 STYLiSH 專案的魔鬼訓練，讓我們養成自己尋找解決方法的習慣。

「包裝」也很重要

跨班協作的尾聲是類似「展示會議（demo meeting）」的小組報告，導師群與學員會於報告結束後，各自票選自己最喜歡的專案作品。

跨班協作環節的「展示會議（demo meeting）」

我在專題中負責的功能相對容易實現、操作起來也不複雜，因此全組二十分鐘的報告時間，只被分配到一分鐘，於是我心想：既然內容本身亮點不大，那就做好「包裝」吧！於是，在報告的前一晚，我不斷構思講稿架構、揣摩語氣，最終報告時，把下列講稿用類似購物臺會出現的口吻唸完：

點開商品詳細頁面之後，可以發現這件商品的名稱是 OOOO 印花T恤，照片上有個紅圈寫著 SALE，告訴大家「趕快買！趕快買！」如果你喜歡這件商品，可以在右上角點個愛心，這個愛心不是按讚，而是收藏進最愛清單，因為資料會直接傳到後端，因此重新整理之後，紅心依舊存在，如果要移出最愛清單，只要再點一次就可以了。

往下滑可以發現過往顧客針對這件商品的評價，一次顯示三則，按「查看更多」再顯示三則，直到所有評價都顯示在畫面上為止。每個評價都帶有星星，所有評價星星數的平均會顯示在頁面最上方。要回到畫面最上方，不用滾動滑鼠，只要點擊右下角的「TOP」，就能一秒回到這裡，可以看到這件商品的平均星星數是四顆星。

看完商品的詳細資訊，接著看到最下面的商品推薦系統，可以右滑、左滑，看到喜歡的商品，只要把鼠標移到照片上方，就會顯示該件商品名稱，再點進去，就能抵達該件商品的詳細資訊頁面。

因為已經練到在外面過馬路都能順暢背出來，這一分鐘內完全不會有任何的思考時間，更不會出現「然後」、「這樣子」等贅字，再適時搭配停頓與操作演示，現場的反應還不錯。

我不禁想到前幾天在程人頻道播客節目第 128 集中，聽到 Alice 提及「包裝」的重要性。很多人明明有很好的實回顧與反思力，但卻因為缺乏包裝，而難以凸顯自身亮點，因此，在持續精進技術之餘，也要加強「包裝」的能力，把報告當成一場秀，讓聽眾彷彿進入一段故事情節，因為沉醉於我們分享的內容，完全忘記過了多少時間。

回顧與反思

跨班協作的最後一個環節是「回顧會議（retrospective meeting）」，導師讓每個人思考自己在專案開發過程中，是扮演推動者、追隨者、反對者或旁觀者的角色。在此之外，會議最重要的是反思自己在這段時間「做得好的」與「可以更好的」項目，針對「可以更好的」部分，下次可以採取什麼具體行動改善。

「回顧會議（retrospective meeting）」討論看板

以我個人而言，本次做得最好的應該是上個段落提及的「口頭發表」環節，雖僅一分鐘的時間，但足以讓所有人留下深刻印象，還在報告結束後聽到後端班同學說「聽完我都想買了」；至於「可以更好的」部分，則是多著重技術基本功，尤其是 React 與用 Git 操作版本控制，先把最基礎的東西學紮實，再去玩 socket.io、Tailwind CSS 等花樣，最好也要補足後端資料庫基本觀念，跟後端成員進行討論時，比較能在同一個頻率上。

心得

來 School 上課前，我曾經做過兩份工作，第一份是在芬蘭羅瓦涅米當極地導遊，工作內容雖酷、也帶回很多很棒的回憶，但累積的技能並無法套用在其他工作場域；第二份則是擔任旅遊新創品牌企劃，但待了將近一年後再上網看其他職缺，卻發現一件非常恐怖的事實：一般公司普遍採用的專案開發流程，我居然未能從現有工作累積相關經驗、還完全看不懂相關職缺的能力要求！先前到其他軟體相關產業的新創團隊面試時，連「利害關係人（stakeholder）」是什麼都不清楚，最後以看著面試官面無表情地搖頭結束這場面試。

去年應徵 School 前，我曾聆聽 Hahow 的「產品團隊協作與開發秘辛」線上直播，搭配其他文章與短片說明，終於開始對「瀑布開發」、「敏捷開發」有了初步概念，但要從「有概念」到「有經驗」是不可能自己在家完成的，勢必得透過工作累積，但我已經不是社會新鮮人，要像一張白紙出去，說服公司一邊發薪水給我、一邊讓我從零開始學，顯得有些不切實際。還好，有 AppWorks School！

在 School 最重要的資產～練習協作

記得當初在面試時，面試官在最開始就問我「相比於其他程式培訓單位，你會選擇 AppWorks School 的原因是什麼？」，我二話不說就回答「 小組協作」。現今要學任何程式技術與觀念，Udemy、Udacity、HiSKIO 等線上平臺非常多，但工作時更重要的「團隊協作」經驗，卻是不管買了多少線上課程都無法累積的。因為 School 在開始駐點學習後，幾乎不會有任何「教學」環節，每一項任務都要與同學大量請教、溝通才能完成，這不僅有助於培訓期間拉近全班、甚至跨班同學之間的距離，還在無形中累積非常大量的軟體開發溝通經驗。

小組內各班組員討論 API 中

跨班協作的時間只有不到兩週，相當於許多專案一個「短衝（sprint）」的時長，若與完整的「Scrum」流程比較，可發現這次比較像是「體驗」，尚未有明確的敏捷教練（scrum master, SM）、產品負責人（product owner, PO）角色；另因團隊成員並沒有資深、資淺之分，大家還不太會看彼此的程式碼，加上時程上也不允許，未有彼此審視程式碼的「代碼審查（code review）」環節；更不用說分支的管理多半僅侷限在「develop」與「feature」兩者，Git Flow 裡的「master」、「release」與產品上線後才會出現的「hotfix」分支都未曾使用。

「個人專案」新挑戰

駐點集訓已經到了一半，即將進入最關鍵的「個人專案」環節，要思考新專案的「使用者故事（user story）」、設計「用戶流程圖（user flow）」與「線框圖（wireframe）」，以週為單位進行「短衝（sprint）」。對於未曾經歷過這些專案開發流程的我而言，要一次接觸這麼多新觀念，難免還是有些不安，但換個角度想，School 讓我在正式進入職場前就體驗這些流程，不是很珍貴的機會嗎？好好把握可以讓自己成長的各個關卡，跟著 School 安排的步調前進吧！

駐點集訓到一半了！（取自 School 簡報）