我如何從合作程式專案中更認識自己
— 程式初學者首次面對與團隊共同寫程式之認真分享
自 2020 年八月中開始加入 ALPHA Camp 平台自學程式，一路學習下來迫使自己突破許多舒適圈，更進一步學習如何學習，想讓人生多一份生存技能，更想實現一個單純的夢想 — 虧探工程師電腦那螢幕中滿滿像亂碼到底是什麼。期待著自己的電腦不再單純只能用圖形介面，可以如同科幻電影般看著密密麻麻的程式碼，按個 Enter 鍵，接著會發生什麼大事一樣！或純粹想在咖啡店帥氣地寫著程式（這得等到疫情結束後才能實現了）！
到我今天在參加了學期三結業式之後開始寫這篇文章，正好是在 ALPHA Camp 自學滿半年。要完成其學期一到學期三的全端課程，最終大魔王 — 必須在兩週內與組員共同完成仿 Twitter 網頁程式（後簡稱 專案）。
組團隊
ALPHA Camp 是一個網路自學程式平台，它獨特採用「班級學期制」，特意營造有同班同期的概念，但實際上同學彼此的交流就如同網友般，純文字互動、彼此網路帳號代稱、大家不認識更從未見過面。而這次專案協作其中一項難處是要從網友同學裡，找到隊友一起組隊合作。
我和素昧平生兩位 Shaun 和 younchu 進行全端開發。Shaun 是擁有五年 full-stack 經驗的工程師。younchu 是一畢業就投入在生科實驗室工作的研究助理。更有趣的是我們三人分別身處在三個不同時區：Shaun 在澳洲、younchu 在台灣、我在紐約。想組名時試圖找出我們的連結點，這三個地區都圍繞著太平洋，進而聯想到環太平洋 — Pacific Rim，很開心初接觸的團員都贊同這團名，成為大家首項共識，也是個好的開始。
我們團隊在開發過程也發揮了跨時區優勢，幾乎整天二十四小時都有人在推進專案進度，不論是寫程式或 debug。如有必要語音討論，則需選在三時區交集的時間點，一旦提出時間大家都確認很迅速，除彼此配合度很高外，也因選擇不是太多。
專案目標
這次 Twitter 專案分為兩大項目標 — 指定功能和挑戰功能。
指定功能是使用 JavaScript、Node.js、HTML、CSS 寫出 Twitter 推文、回覆、喜愛推文、註冊使用者、管理者後台、編輯個人資料、查看其它用戶推文及推文動態、跟隨其它用戶…等，基本上是運用過去所學的衍生應用，完成基礎資料操作功能 CRUD 可創建、讀取、更新和刪除。
在指定功能繳交日當天下午，才會公佈挑戰功能詳細內容，而且只給予兩天半的時間。挑戰功能是要做出使用者公開聊天室、私人聊天室、儲存歷史訊息、通知新訊息和訂閱推播。這好比是場火盃的考驗，先是要通過基本門檻才有資格參加，也就是要先把過去作業都繳交、專案指定功能都完成才可進行挑戰功能，事前會給予些提示，只知道將會使用到 socket.io 工具進行線上聊天，但更詳細考驗的內容，只能等時間到才會統一公佈。該如何在短時間內使用新工具，這不但是測試實作能力，更考驗著小組的臨場反應、如何有效且快速進行溝通協調，儘管彼此僅是合作十多天的「網友」。
前置作業
我擁有幾年遠距跨時區工作經驗，對於不同時區和地區的團隊合作迎刃有餘，目前工作負責從找工廠、開發產品討論、安排訂單、追蹤生產到進貨排程、品質檢查追蹤管理、庫存追蹤到款項核對等，以上都是我一個人在紐約和分佈在不同地區的團隊們共同合作。
家人朋友看著我成天在家或在咖啡廳盯著電腦、有時在奇怪的時間視訊聊天（開會），不像是在上班（後疫情時代，應讓更多人開始瞭解遠距工作）。雖帶著豐富的經驗，但沒有做過與寫程式相關的遠距合作，難免讓我對於即將面對未知的團隊和合作內容既興奮又緊張！
我依過往經驗，隨即邀請組員採用 Slack、Trello、和 Zoom 三大現今遠距連繫及專案管理熱門的軟體。
協作工具使用規畫
Slack：主要溝通場所。我們討論程式功能、回報進度、聊天寒喧都主要在 Slack 上進行。Slack 做很多讓用戶方便討論、查找和遍覽訊息、避免發散式回覆而使討論失焦的設計。像每一則訊息可用 emoji 做即時地簡單回應，甚至能直接對該訊息進行回覆，成立新的一個 Thread ，讓整體討論區更乾淨（行數少），更可方便追蹤該則訊息的結論。Slack 可建立多個 Channel ，讓不同主題可在不同地方討論，因為我們人數少且討論主題單一集中於程式專案，所以僅設兩個主題區，一個是主要討論區、另一個是放工作分配和會議時間。
Zoom： 線上開會工具。口述即時討論目標作法和回答彼此問題，讓彼此有所共識。做螢幕分享討論程式碼也十分便捷。
Trello：程式開發流程管理工具。運用看板 Kanban 產品開發流程系統來管理專案開發進度。先將整個專案指定的使用者故事做成一張張 Trello 卡片，全部都放在待辦 To Do Board。確定要做這項卡片功能的人，可先加入這張卡，讓其它人知道這張卡會有人處理。從準備要做到測試完成，分幾個步驟做為幾個 Boards，當負責這張卡片的人完成這項功能，就移到相對應的 Board，其它組員也能同步理解，目前這項功能（卡片）的進度在哪階段。
實作階段
這裡參考 Bruce Tuckman 團隊成長五階段搭配說明。
團隊創建期 Forming
我們在開發前進行一次行前會議，第一次聽到大家的聲音，藉此機會試著瞭解大家對程式熟悉度及開發認知的程度，更重要的是確認好共同目標一致 — 完成指定規格及挑戰規格。
至於開發方式或誰想先做什麼部份，沒有太多想法，偏向有什麼任務就做什麼，我先整理出指定規格提供的設計稿和規格，將各個使用者故事及測試要求分別建立在 Trello 軟體中。請團隊中最有開發經驗的 Shaun，來擔任這次專案開發組長，進行功能開發順序調整和分配，並訂定目標時程，他也十分迅速準備開發前的環境部屬及主要畫面框架，幫助大家省很多時間可直接開始寫程式。
團隊激盪與規範期 Storming & Norming
一天寫程式的流程漸漸成型。
因為我們花很短時間將開發工具和順序討論好，大家都是學習全端開發上來，對專案完成目標及方式都有一定的認知，所以團隊沒有出現太大衝突，向心力和凝聚力很高，這也是我們能在時間內完成任務的主因之一。
我早上一睜眼會跟所有人打聲招呼，看未讀訊息先掌握組員們已做什麼，若有問題把握他們準備入睡前詢問，整理好交接事項後，分享列出我今天準備要做的任務。一方面是過去養成的習慣，一早整理並排序今日待辦事項，讓工作時可專注處理一件事，而不被其它待辦事困擾。另一方面主動分享，是希望組員們瞭解後可以放心去休息，或避免做到重覆的事。
我相信如果有人覺得這樣的溝通模式不錯，自然而然也會跟進。果然大家逐漸有個默契，開始互道早安、晚安、隨時回報當前進度，順利成形有效且正向和協的線上溝通氛圍。
列完待辦事項後，我會去手沖一杯咖啡，沉靜在短暫片刻的寧靜，磨豆機沙沙聲伴隨著咖啡香味。播放提振精神的音樂，與自己對話今天會是美好順利的一天，像是為接著衝刺寫程式熱身。就跟平常上班差不多模式，只是工作內容不同。
團隊執行期 Performing
Git 協作我們三個人各開自己的分支，功能做完後發佈 Pull Request，等其它組員檢查程式沒問題後，直接合併回 master。因為是分功能協作方式，一人負責使用者、一人負責推文、一人負責管理者和互動，這讓程式碼彼此衝突的機會很低，但缺點是各自寫法不大相同。
因為遠距離跨時區合作，這也是長年累積下來遠距工作所養成的習慣，要盡量減少大家為求確認而等待對方的時間，當我在發送 Pull Request，我會寫得清楚詳細，功能是什麼、連動到哪些 Trello 卡片等，這也可順便再複習和檢查一遍這個 Pull Request 完成什麼功能。
團隊調整期 Adjourning
挑戰功能時僅有兩天半時間要完成，還需要運用未碰過的新工具 socket.io，團隊的開發模式因應調整從分功能做全端，改為一人做畫面、一人做後端、一人做銜接。原本利用 Trello 追蹤專案開發流程進度，在協作挑戰功能時，因作業時間非常少，很難將功能細分寫入卡片，我們只列出大方向，讓開會時大家能有共識有哪些需完成的功能，後續沒有時間再取卡片、移動卡片到各個階段的 Board。
最大的改變主要是 socket.io 工具大家不太熟悉，還有新的開發方向、資料庫設計、前後端串聯都需要討論，我們線上開會次數更多，程式碼也加上更多註解。Git 協作也從原本各開分支最後再合併，變成三人同時在一個分支上作業，每完成一個功能，省略發 Pull Request 直接實測，以求加快開發速度。但在同一個分支上，作業程式碼衝突風險是很高，除了不同時區的優勢順理成章能減少重覆，更頻繁的溝通依舊非常重要，一切是為了讓後續程式碼合併順暢，且盡速完成各項功能。就跟打籃球時，隊友要不時喊聲，讓其它隊友掌握彼此的位置，大家配合來搶下分數。
開發方式改變、Git 協作方式改變、簡略 Trello 使用方式、減少發佈 Pull Request、開會次數增加，在線上交流次數更頻繁，隨時在確認及回覆我正在做什麼、誰 push 分支上去 Github、有誰要幫忙…等等。因應黑客松挑戰，團隊在開發即時做出的改變和調整，團隊拼全力衝刺和盡心配合，再再讓我們降低開發環境外不可控變素，永遠記得那刻，能將專案趕在時間內全數做完不可置信的感動，即便聽不到組員們的歡呼聲，我在螢幕前歡呼旋轉著、想像電影裡所有人興奮開香檳慶賀的畫面！
心情轉變
我發現在這實作專案這段時期，心情起伏上上下下，產出也感覺像是跟著心情波動，到底是否與心情呈現正相關？我簡單的回顧過去兩週大事件和平均產出與心情，用 0 到 10 自我評比。
產出：完成功能數量 & 重要程度 ÷ 一天寫程式的時間。沒有實際量化，憑印象回顧當日我花費寫程式 debug 整個時間中，完成多少對專案有進展的功能，且重要性越大算為更高數量。從 0 到 10 為低到高。
心情：初期著急不安怕寫錯或蓋掉別人寫的程式，還記得那心臟跳動超快每打一個字前都特別謹慎小心、擔心進度跟不上團隊、同時又興奮能與團隊一起為目標努力。實際上一天內心情有高有低，完成功能都會很高興，卡關時難免受挫，debug 過程若超過預期時間或比想像中困難，當下難過到懷疑人生都有發生過，所以不是一天都處於同樣的心情狀態，這指數也是憑最深印象，認為當日平均下來自我給分是 0 到 10 為難過到開心。
從圖表上看出，產出與心情是有點正相關可也不是絕對。像是專案剛開始第一天時產出很低，但心情是既興奮又緊張；有時產量雖高但因 debug 發現不應該有這種錯誤而讓心情不好。一進入黑客松挑戰階段，經歷了兩週產能穩定爬升，突然面對從未使用過的工具，不熟悉又寫很慢的狀態，產量瞬間劇降，心情更是直線掉落。即使隔天產出爬升，卻因時間壓力快寫不完的緊張，加上想寫更多的期待有落差，使得心情反向更低落。
整體最意外的發現：產出趨勢線由低往高處上斜，代表產出是一天天往上升，當下可能沒有發覺，專案結束後回頭來看，我瞭解到凡持續寫程式，產出是會逐漸成長進步！
從經驗中學習
程式中的備註代表期望功能，不代表可執行出的結果。
在我們學習程式的過程，90% 跟著教材做都會是如期望寫出程式，而為了往後複習方便，在程式碼同時寫下備註代表這段在做什麼功能，自然而然習慣備註就是筆記也是正確的思維、理所當然敘述與執行出的結果會相同。
在開發新專案與小組共同寫程式的過程，先下備註像為寫程式前打草稿，用白話讓自己先瞭解這段要做什麼，避免寫到一半忘記原先目的。留下備註也為了幫助組員更快理解這程式的邏輯。尤其挑戰階段對 socket.io 工具不熟悉，大家盡量寫程式的同時也寫更加詳細的註解。在彼此做 Code Review 時看得很順，再搭配備註加上沒有太常看別人程式碼的經驗，思考很輕易被帶著走，一切自然而然都覺得很合理。要先理解對方的邏輯再測試他的邏輯是否與備註相同，而不是只看程式碼，而看起來如同備註所說，就認同了這個寫法。結果跑程式突然出錯找不到問題在哪。
越晚部屬、越晚做測試，會有越多不可預料的意外發生。尤其時間越緊迫，越覺得花更多時間找錯誤和無止盡的 debug。
我們寫約八天時間，近九成主要功能都寫完了，原以為可以整整提早一個禮拜完成指定功能，但跑指定測試檔案，竟然全部不通過！這下才驚覺我們所設的路由和取用戶的 id 方法與測試大不相同，當下一度認為過去一個禮拜都白忙了，這麼多地方要如何修改呢？把這壞消息丟給團隊後，原本擔憂著是否會有誰要放棄或脫隊，沒想到大家馬上「站起來」勇於面對事實且不輕言放棄，最後團隊花了兩到三天時間為了測試檔做調整，不僅挺過來而且還能在期限前一天完成！
光是解決部屬到 Heroku 發生幾個不可預期的錯誤，讓專案完成時間比預期再晚兩天。我們在依照測試檔調整完都通過後，才部屬到 Heroku 上。本來是使用 MySQL，部屬到 Heroku 時想用 PostgreSQL，但沒碰到真的不知道，原來 PostgreSQL 和 MySQL 對於 Sequelize SQL 語法嚴謹度不同。這次經驗學到在剛開始開發時，也要確定好統一用哪一種資料庫，包括本機和遠端資料庫要一致，才好做後續測試及維護。所以即便花半天時間發現和解決部屬到 Heroku 使用 PostgreSQL，但考慮大家本機還是 MySQL，為相容性高避免任何不必要風險，隔天直接砍掉並重新部屬 Heroku，改裝 ClearDB 及程式碼修正回符合 MySQL 寫法。
原本更換圖片的功能沒問題，部屬 Heroku 後竟會出現問題，又是找很久原因和嘗試解決問題，原來是還要將空資料放到 Heroku 上，這種毫無根據看似不合理的解答，無法用線索邏輯去揣測的道理，在這次部屬 Heroku，原以為很簡單的任務，一小時內能搞定卻花了兩天。若是要花相同時間解決問題，我也寧願在事前先部屬，早發現早 debug，充裕從容心情總比急著像熱鍋上的螞蟻心情要好。
定義共同程式風格、Commit 寫法比想像中還重要。
一直以來只有自己在寫程式，可以很自由照著自己習慣熟悉的函式寫法、空格長度、結尾無分號、隨心所欲空行…等去撰寫，只要功能有順利成功運作就算沒事了，後續要回來再修改程式碼也不會太難懂。
多人共同在寫同一份程式專案，就如同在一個樂團裡，大家各自負責自己的樂器來合奏一首曲子，完全是依靠所有人遵守樂譜上的音符、節拍、升降、大小聲，來讓整個樂團完美演奏出這首曲子。在練習過程假設想在其中一小節做音量或節奏調整，也能快速在樂譜中找到相對位置做修改及註記。而樂團還能在任何時間依據相同樂譜，演奏出一模一樣的音樂。
這是為什麼要先理解什麼是變數、函式、語言怎麼寫，像看懂樂譜前要先知道各個音符的意思，更需要與團隊定義相同的程式風格寫法，像是樂團決定節奏速度、大小聲、輕聲的程度。在多人合作時，遵守共同協議的風格和程式語言，又為什麼要定義 HTTP RESTful、Commit、Controller 怎麼寫，主要為幫助彼此快速理解、討論、修正，讓程式順利進行、好閱讀、好維護。
學習程式技能是一種累積的過程，而且能使其它經驗結合的加乘效果。學會要與過去的自己檢討，不要常與他人比較。
經過這次專案協作，我更瞭解自己若身為一位程式工程師，與其它人合作會是怎樣的感覺。而且即便我是個程式新手，過去沒有寫程式合作經驗，依舊可以發揮其它如專案管理、人際溝通協調、遠距工作模式、工作態度、負責任等長處，這些原理不會因為工作內容而改變。
過往的教育制度往往使人輕易與他人比較，而在這次專案與有經驗的人合作，不免會陷入怎麼技不如人或速度不夠快之類等挫折，其實這是非常好的機會，能夠邊寫邊觀摩他人程式碼。自學程式時期，週週在努力趕上作業繳交期限，很少有多餘時間再細看或研究其他同學寫的程式碼，而在這專案檢閱組員們的程式碼，才知道原來理解他人的邏輯，也是學習程式中一件既有幫助且重要的事。
在整個學習過程中，很容易忘記小時候學講話、學英文、學鋼琴，全都是一開始什麼都不會啊！像現在能在眾人面前隨手彈奏一曲，好像一出生就認識Do Re Me、知道拍子怎麼數、左右手能自然彈出不同音符，竟忘卻當時學琴只要快上課就憂鬱、練琴練到痛哭、無法控制雙手感到絕望，那些迷茫難受痛苦！更不用談近幾年搬到美國，都快忘了當時連菜單要看很久，不敢跟服務生講話，甚至點個麥當勞都要先研究好餐點、在排隊時瘋狂練習等會怎麼說，到現在秒決定要吃的東西、利用 Drive-through 點餐，或要點各國各樣菜餚都能非常自在。
雖然現在的我還無法盡情流暢著寫著程式，總是眼睛瞪大著螢幕，抓著扭曲的臉龐，好似看 3D 圖一樣，看越久就能看出 bug，但倒頭來還是什麼也看不出錯在哪。單就這次專案協作，進步最快也很有成就感的 Git 指令，從什麼都不懂，過了一個禮拜就終於理解本地端和遠端原理，而且不用再翻找筆記直接寫開新分支、merge、rebase、push、git diff…等指令。技術方面只要肯學習、多練習，熟練度上升就能讓身體適應並且自然地執行出來。
持續提醒自己過去學任何事都是從零開始，專注在於自己已經學到什麼，還要學什麼，面對還有什麼不懂需要再加強。減少只是羨慕別人或認為技不如人而失望，要從成功人士身上學習他們如何思考，如何學習，甚至是遇到困難如何克服。
結語
人生第一次進行與其他人共同寫一份程式專案，付出很多心力和時間，也體會到什麼叫「抱著電腦睡覺」，睜眼閉眼都在電腦螢幕前敲程式碼看文件，天天睡覺時間很少，怕時間不夠用寫不完，更連做夢都在想著這段程式要怎麼寫，電腦更首次發出提醒說：「使用時間比上週多出 15% ！」
因為與隊員間的承諾，讓我激起鬥志，絕對要跟上團隊一同完成專案和達到目標。遠比之前自學時期，還要更投入、花費更多時間在程式上！回想兩個禮拜過程中有痛苦、有歡樂、有鬥志、也有憤怒。若想在短時間將精進程式技術和體驗心情三溫暖，很推薦嘗試參加一場黑客松。
非常感謝也很幸運地碰上兩位隊友都十分稱職！有經驗的 Shaun，在前期將切版畫面模組化，讓程式很好維護，在短時間判斷出團隊開發模式。他熟衽的 html 和 css，在排版上向他直接學習實作上如何應用。加上他能力強、積極又熱情，會主動協助隊員排除程式疑問。 younchu 不論在實作和合作上都展現負責任態度，盡全力細心檢查程式碼和各項功能運作邏輯無誤，是位讓人放心可依賴的好伙伴。
感謝藉由專案實作，助教們給予專業的評比指導！謝謝所有同期同學在群組內互相幫助解決問題、互相取暖分享心情感受，一同渡過不容易的學期三！
我很珍惜這次專案合作的機會，因此寫下這篇文章詳細記錄及分享。希望以後的我再回頭看時，能回想到當初首次合作寫程式的種種感受，那夢想成真、debug 痛苦到質疑人生、解決問題完成專案快樂…等。這真的是到目前為止學程式中最難得的一次經驗！
陪伴我兩週開發時間的物品：
語言：JavaScript、SQL
軟體：Node.js、Sequelize、VS code、MySQL Workbench、Notion、Typora
硬體：搭載Apple M1 晶片、首台無風扇、電力高達 18 小時的筆電 MacBook Air 2020 13"
遠距協作輔助軟體：Github、Trello、Slack、Zoom、LINE
咖啡豆：Rwanda Hyun Mountain Roasted by StumpTown
音樂：IU 所有歌曲輪聽，尤其到 Good Day 十分振奮人心。另外由同學推薦 Sebastián Yatra 歌手，發現 Fantasía 整張專輯，很適合這次寫專案時讓我心情保持愉悅。
