前言
距離上一篇文章已經超過一個月了，這段時間完全都投入在畢業專案中(當然，該做消遣我還是照常做，Netflix一直是我紓壓的一大利器)，這兩周已開始做專案的最後收尾，在這邊紀錄一下這一個月來的點點滴滴，希望能提供給其他有意利用ac課程轉戰工程師的人參考看看。
關於AC畢業專案
在Alpha Camp的最後一學期，我們需要在畢業前提交一份多人協作專案，AC那邊給了我們三個大方向供我們選擇，分別是
- 電商平台
- 旅遊規劃網站
- CRM系統
這些主題都算是有打算要轉職的常見作品，每個專案主題都有一些指定的規格，像是需要滿足那些使用者故事、需要串接第三方API等要求，除此之外便沒有再多給我們其他的限制。從專案發想、ERD&Wireframe設計一直到功能全都讓我們自由發揮，儼然是個真正的軟體開發。
畢業專案簡介
我們的產品是一個美食訂餐平台，為了由於排隊人潮、物價昂貴等因素，每天煩惱用餐選擇的忙碌上班族而打造的訂餐平台，主打以實惠的價格，讓你享受不須排隊等候的優質午餐!
專案的詳細細節都已寫在專案頁面中，有興趣的話可以查看這裡。
坦白講我們在決定主題時花費了相當多的時間，雖然我們很快地就將範圍縮小至電商平台，但即便是電商平台也有太多太多不同的選擇，確實讓我們出現了不小的選擇障礙。
從打造類似Klook的旅遊電商、好學校Hahow的教育平台以及慈善群眾募資等，各式樣的點子不斷地併發，感覺真的很像學生時期參加創新創業競賽時的brainstorming階段，有一個小小的時間點我們甚至還妄想打造一個專為LGBT社群設計的旅遊平台。玲瑯滿目的點子讓我們有些手足無措，最後還是打算從自己生活方面去做聯想需要的產品，於是飲食這個點子就被提出來了。
現在食品外送服務興盛，但所有消費者的問題真的都被解決了嗎?餐廳是否也有除了與外送平台合作之外的選項呢? 剛好Mike曾經在美國的新創看過MealPal的服務，三人討論後都一致認為是個有趣的點子，於是便決定以MealPal為產品原型進行開發。
團隊成員簡介與分工
前面提到此畢業專案必須採用多人協作的方式，那就不得不提一下這次合作的兩位夥伴，少了他們我真不知道這麼龐大的架構我要怎麼完成。許多功能他們都完成的相當出采快速，很明顯都投入了大量的時間，這段時間我們交流的頻率之高讓人咋舌，真的很感謝他們為了這個專案如此費心。
Mike
- 負責所有前端功能開發，其中包含專案建置與新技術引用（Sass、Google Maps API）以及樣板和元件製作。
- 平台使用者介面（UI）與使用者體驗（UX）設計。
- Github 專案建置與主要分支管理–建立 PR 模板統一團隊規格，並協助審核後端 PR。
- 專案發想，並協同團隊確立規格（User Story, Wireframe, ERD Model與路由設計）。
- 與後端團隊協作串接第三方藍新金流服務。
- 與後端團隊團隊協作，規劃並串接平台 RESTful API 。
Mike是我從學期二就有著交流的好夥伴。他在學期中的作品總是有讓人眼睛為之一亮的設計，對於各種活動也是參與的相當積極。之後一起當了實習助教之後交流便更加密切，我從他身上學了很多東西，私底下也是個很聊得來的朋友，能認識他可說是我這幾個月來的一大收穫~!
在這次的畢業專案中，Mike負擔了極大的工作量卻仍完成得相當不錯，處理前端之餘也會參與我們針對後端問題的討論，是個非常優秀的幫手!
Tao
- 負責後端主要功能開發，包含餐廳、訂單、餐點、使用者訂閱以及餐廳菜單CRUD相應的功能開發。
- 負責專案分支管理，協助團隊後端PR 審核。
- 協同團隊確立專案規格（User Story, Wireframe, ERD Model與路由設計）。
- 協同團隊建立資料庫架構、種子資料與 Heroku 部署。
- 協同團隊完成串接第三方藍新金流服務。
Tao也是從學期二就一直有著交流的好同學，我不記得有哪一次AC的活動他是缺席的，在平台上也常常可見到他的身影，對於提問與回答他人問題總是不遺餘力， 一路上觀察下來真的可以充分感受到他成長的幅度相當驚人。這次的專案中Tao主要負責後端的大多數功能開發，其中包含平台功能、藍新金流串接以及後續的遠端部屬，後端的大小事都沒少他的份，在我進行其他功能開發時他也給了我一些協助與建議讓開發更加順利~!
Danny (I myself)
- 負責後端使用者驗證、專案模型建立、排程管理以及自動化測試相關開發。
- 負責專案分支管理，協助團隊前後端 PR 審核。
- 協同團隊確立專案規格（User Story, Wireframe, ERD Model與路由設計）
- 協同團隊建立資料庫架構、種子資料。
- 協助後端部分主要功能開發。
- 專案規格文件撰寫與規劃會議整理
過程中自然不是一帆風順的，以我的部分來說我在幾個部分處理得相當掙扎。
- ERD與資料模型
首先在決定了專案方向後，我和Tao便開始構思初步的模型設計並繪製ERD，本來以為模型的部分就會這樣塵埃落定，但沒想到接下來的開發過程中，為了達成一些功能(定位、距離計算、評論、訂閱狀態等)不得不多次修改原先的model設計，最後歷經了數次的調整後最終才變為以下的資料結構。
- 自動化測試與API文件撰寫
在我們先前的專案中並不需要自己撰寫測試案例，一旦自己動手寫的時候便會發現要考慮的東西之多，一時半刻真沒辦法全部釐清。即便一開始為了開發的順利，我們花了大把的時間討論每一個路由的回傳結果、格式與狀態碼，但後續在開發的過程不免又會蹦出新的需求，已不是原本預想的回傳結果可以滿足，這時候就不得不再次修改request test的部份。
同樣的在撰寫API文件時，等同於再一次的是手動測試所有的路由。由於希望在每個路由中加入所有可能的回傳結果作為範例，整個過程就像是再一次的撰寫各種test cases，其中也不乏因為這樣發現的bug而趕緊緊急修正。反反覆覆在測試這一塊我著實花了太多不要的時間，要是自己再熟練點我想整個專案開發的進度必定能再更順利一些。
若要我自己講，在這次專案中自己反倒比較接近PM而非工程師的角色。前期我做完 使用者驗證 、專案模型建立後，我花了很大量的時間去處理自動化測試的相關開發，由於他們兩位的工作量相當大，除了協助部分後端功能開發之外，我剩餘的時間反倒是都用來審視前後端的Pull requests以及撰寫專案相關的文件，像是使用者故事、API文件以及規劃會議紀錄等，都是些PM在幹的事情~!
不禁讓我回想起之前還在上班時夾在客戶與工程師之間的感受(笑)。
協作工具使用
這邊簡單介紹一下我們這次專案使用的一些協作工具，許多時候這些工具都讓我們彼此溝通更加方便快速!
Trello
Trello是款簡單好用的專案管理工具，特別是在協作時可以清楚的了解目前正在進行的開發與尚未完成的部分，讓團隊成員都可以快速的了解目前進度。
Zoom
zoom是一款免費、好用的視訊會議工具，唯一的缺點應該是多人會議時會有三十分鐘的時間限制，像我們這種免費用戶必須不斷地重開新會議才得以繼續討論。
Github
遠端協作時， github 的重要性應該不用多說了，多虧了git才能達成這樣複雜的協作。
最後自然就是我們的雲端google了，許多專案相關的文件我們會統一丟在遠端資料夾共同編輯管理。
專案開發時程&流程
我們在討論完專案基本架構後，大致將我們專案分為以下幾個開發階段。
- Phase 1 餐廳與訂閱方案展示
- Phase 2 會員註冊與相關驗證
- Phase 3 訂閱方案與第三方金流支付
- Phase 4 訂單成立
- Phase 5 CRM(使用者評論)
- Phase 6 後續功能開發、優化
並以此為基準規劃了以下的開發時程。
整個開發的過程我們參考了SCRUM敏捷開發流程，對於 SCRUM 不熟悉的朋友建議可以參考這篇文章，我認為寫得淺顯易懂!(什麼是Scrum？不是工程師也能懂的Scrum入門介紹！)
以標準敏捷開發為基礎，我們做了一些適合我們的調整，但基本上每一次的衝刺(sprint)我們都會經過以下過程。
- 每周一的規劃會議，其中包含目前進度與上周設立目標的比對、本周sprint內容、待完成項目與分工。
- 每隔兩天的一次的standing會議，彼此分享目前開發項目是否遇到什麼困難，若有需要則召開臨時會議討論，若一切順利也會選擇在slack上簡單的回報而不召開zoom會議。
- 每周日的進度確認，類似於Scrum中的反省會議，但由於彼此在slack上聯繫密切，同時也透過trello等工具掌握彼此進度，許多時候都將進度確認改至隔周的規劃會議進行。
專案開發心得
開發畢業專案的這幾周過得實在是非常快速，從一開始的茫然無措到一步步完成專案，真的非常感謝兩位夥伴的協助，在此先預祝他們未來都能找到理想的工作:P
自從開始做畢業專案後，心情似乎就沒有真正的放鬆過了。雖然偶爾還是會耍廢玩玩遊戲、看看Netflix，但心中總有一塊在懸著。擔心開發的進度、擔心功能做不出來、擔心專案完之後的求職，有太多太多的事情需要去煩惱，同時又不能忽略自我的進修，坦白說壓力真的挺大的，我印象中學期四開始之後我就沒有好好地睡過了，三不五時就會做個噩夢讓整晚睡不好，我印象比較深刻的就是當時在寫測試案例時，有夢到所有的測試都fail然後我找不出原因 (笑) 。
中間還遇到了電腦泡水、股票跳水以及感情危機種種問題，更是大大加深了我的焦慮程度。
好在兩位夥伴都相當可靠，我們彼此間也會分享一些焦慮、不安的情緒並彼此加油打氣。合作的過程我不敢說一帆風順，但至少我們都為了讓專案變得更好而努力，沒有人輕言放棄。這就是團隊的美妙之處，當你孤身一人時很容易會迷失方向，有時候我們都需要其他人拉一把才能回到正軌。
整個開發的過程中其實有蠻多體悟的，若要詳述我想這篇文章得分成上下冊才有辦法寫完了，這邊就列出幾個比較重要的體悟。這些體悟其實都不是什麼嶄新的發現，許多關於工程師的文章都會提到這些點，但經過這次的協作之後，我總算是能切身的了解到為什麼這些關鍵字句會一再的出現了。
技術硬實力絕不會是衡量工程師價值的唯一指標
我想這會是許多學習程式設計的新手會有的誤解-技術至上，就是語法練得滾瓜爛熟、熟悉一些套件&框架後，我就一定能做出好作品。若只是單人的作品，也許是吧! 但一旦進入到團隊協作，我必須說我認為技術能力並不是專案的成敗關鍵。
我不否認你需要一定的技術能力才能夠進行產品開發，但若是認為只要現有的技術能力夠高，就會直接反應在專案的完成度上，這就有些太天真了。原因在於專案開發時，有太多問題是光靠技術無法解決的。舉個例子來說
今天團隊在討論要加某個新功能，乍聽之下相當容易，於是你便開始埋頭苦幹，結果作出來後，其他人才跟你說功能並不符合原先的期待。這時候有很多種可能性，也許是自己誤解了團隊的意思、或是當時討論時沒有描述清楚、抑或是根本就不需要這樣的功能。
這樣的情況相信在軟體專案開發時並不算少見，剛好也讓我帶出下一個體悟。
2. 團隊與溝通的重要性
個人的能力極端的有限，我必須再次強調這一點。也許你自己已相當全能，可以同時完成前後端的設計與功能開發，但在有限的時間內，分工協作絕對會是更為理想的決定， 一個團隊中每個人都會有屬於自己的優勢，如何利用這些優勢便是每個團隊需要考慮的問題之一。良好的分工會大大的加速專案的開發，但同時也帶出了一些問題。
在我們的開發過程中，雖然已經高頻率的使用zoom&slack進行密集的討論與確認，但常常還是會出現誤解彼此意思、導致必須緊急展開討論，甚至是召開zoom會議等情況出現。原因就在於不管是語言還是文字，說者&聽者不見得會在同一個理解水平上，也就是說我認為理所當然的邏輯不見得能套用在其他人身上，也因此對於同一句話、同一段文字我們可能會有不同的解讀。在團隊協作時務必要把握幾個基本原則才能有效的溝通並避免不必要的衝突。
- 多次確認自己沒有誤解他人的意思 (e.g 用換句話說的方式再次確認)
- 避免預設他人立場(e.g 不要一昧認為對方解決問題的出發點與你相同)
- 避免過激的言行 (e.g 立即否定他人想法、指責對方的錯誤)
- 肯定對方的付出與想法 (e.g 適時的表達鼓勵與感謝)
3. 面對問題的態度matters
當在專案開發時，尤其對我們這種半路出家的人來說，陌生的技術、問題是我們永遠也無法避免的，這點我想對資深開發者也是一樣。實在有太多、太多的知識與技術等著我們去學習，這是窮盡一生也無法完全掌握的領域。我認為，當你遇到問題時你是怎麼樣的態度，決定了你作為工程師的高度。例如當你看到程式的bug時你是什麼樣的想法?暫時棄之不理或是積極尋找解答? 別人向你提出一個沒做過的新功能點子，你是果斷找理由拒絕還是找時間研究?
這些小地方都會很好的區別作為開發者，每個人的高度會到哪。之前在看一些工程師寫的文章時，有一句話我一直都很喜歡:能解決問題的不是工具，而是思考。如果你僅是一昧的利用工具去解決所有你遇到的問題，而沒有細究背後的原因，我想你正慢慢地朝「碼農」那一端靠近，而我相信這並不是任何人的初衷。
結語
協作專案與自己在玩一些小型的side project感覺完全不同，要考慮如何在有限的時間內做出一些取捨，像是功能的完整度或是code的精簡程度，打造一個MVP(最小可行性產品)比原先想像的困難多了。但我很慶幸能有這樣的體驗，我們常說需要一些實務經驗免得到職場上又得全部從頭學習，我想這樣的協作專案便是個很好的經驗，讓我們對於之後與他人合作開發有個初步的認知。至於學習嘛…妄想先學好所有會用到的東西這種想法也未免太天真不切實際了。不管你有多資深或有多菜，要成為一位好的工程師就不會有停止學習的那一天吧!
AC這段旅程也終於要結束了，9個月的時間一晃眼就過去，期許自己能好好運用這段時間的所學，為這個世界多帶來一些正向的改變! Go! Danny Fight~!
其他專案相關連結
Danny的學習紀錄 