一、前言：
文超長，慎入。
跟著 Alpha camp 上課也是走到了尾聲，完成了結業推特專案。
從實際面來說，這次專案的目的是為了透過實作的過程再次熟練切版、Vue.js、Git flow、前後端合作等層面。另外也可以透過擁有一個協作專案來放在作品集裡頭。
本文主要說明專案內容、使用的工具、我負責的部分、遇到的問題、回饋等，總而言之是一個結案紀錄(?)，如果有這種東西存在的話。
二、專案說明：
專案內容簡單來說就是要實作出一個輕型的推特網站。基本的 User stories 包括但不限於讓使用者可以註冊、登入、登出、推文、留言、按讚、追蹤等等。
總開發時間規定是兩個禮拜，包括一個多禮拜的基本功能開發和大約四天的進階功能開發。
前端的部分，基本功能開發開始時就會給予設計稿、User stories、UIUX 檢查表等讓你知道應該開發的方向。進階功能開發的細部規格則是在基本功能開發期限結束後才會公布，主要為使用 socket.io 實作即時聊天功能和通知功能。
由於組員來自前端班和全端班，因此開發模式分成兩種：
- 前後分離 SPA：本組採用的開發模式。而我負責前端部分。
由兩位前端組員，我和 Dennis，使用 Vue.js 開發前端頁面；兩位後端組員，Ivy 和 Sherry，開發後端 API、建置資料庫。 - 全端開發：由三位全端班的組員使用 Express.js、handlebars 來開發。
三、開發工具：
不得不說後端組員們一整個把 PM 的角色做得很好。建立 trello 看板架構、聯絡開會等等，建立團隊聯絡基礎，省去了不少溝通問題，也能及時了解每個人的開發進度和困難。會議上我們主要使用 Zoom 和 Google Meet。
前端使用 Visual Studio 開發、 Vue-cli 建立 Vue.js 專案、Git 做版本控制，並在 Github 上建立 repo，將 webpack 打包好的檔案丟到 Github 上用 Github page 來呈現。
後端的部分我比較不清楚，但基本上應該是使用 Node.js、Express.js 開發 API、資料庫使用 MySQL，並將其部屬在 heroku 上。
四、前端分工說明：
最一開始和另一位前端組員分配工作的方式，主要是在分析完課程提供的設計稿後，把共用元件找出來，如 sidebar、推薦追蹤區等。接著盡量將相似的頁面，或共用較多元件的頁面交給同一個人來負責，以避免重工，浪費時間。
1. 負責範圍：
頁面的命名方式基本上依照設計稿上的名稱。
根據一開始的分工結果，我負責建立 Vue 專案架構，並完成註冊頁 (SignUp)、登入頁 (SignIn)、not found 頁、主頁面 (Main)、個別推文頁 (DeplyDetail) 等頁面；還有共用元件如 UserSidebar、RecommendedFollowers、TweetItem 等等的製作。不過後來因為另一位前端組員開發速度較慢，所以專案結束時的最終負責範圍如下。噢對，Clement 是我。
不得不說其實有點硬。畢竟基本功能的開發時間只有大約一個多禮拜。除了要依照設計稿還原 UI 之外，還要將後端設計好的 API 資料接起來，處理好各 Vue components 之間的資料流，最後還有一些預期外的火要救，十分緊張刺激。但也沒什麼時間想太多，先做就對了。
2. 功能方面：
這邊從功能面來整理一下幾個我開發的功能：
1. 使用者可以從主頁面推文、從側邊欄推文。
2. 使用者可以從主頁面看到所有使用者的推文資訊，包含推文者資料、推文內容、按讚數和留言數。
3. 使用者可以在主頁面對任何推文按讚、留言。
4. 使用者可以追蹤其他使用者。
5. 使用者可以修改個人資料：帳號、名稱、密碼、個人頁面封面圖片、大頭貼、自我介紹等。
6. 使用者可以透過點擊推文進入該推文頁面，查看所有留言、收到的讚數量。
7. 使用者可以在公開聊天室和所有在線使用者聊天，且訊息可以被保存。
8. 使用者可以和其他使用者在私人聊天室聊天，且訊息可以被保存。
9. 使用者可以查看所有使用者的使用者資訊頁，查看琪所有推文、回覆，和喜歡(按讚)的內容。
五、開發技術關鍵字與開發常見問題：
這邊紀錄一下開發時使用到的技術關鍵字(有大有小有深有淺)和開發時常碰到的問題，方便有心(想學習)人士上網自己 google。
技術關鍵字：
vue cli、vue component、vue props/emit、vue eventBus、vuex、localStorage、mapState、vue router、beforeEach、restful API、axios、async/await、socket.io、sessionStorage…
問題一：Cors
真的超常見，開發到一半後端來的資料就被擋著進不來。這主要是在打 API 向後端要資料的時候會遇到的問題。但依照我的理解這主要是後端需負責處理的問題，所以就很懶散的礙於時間壓力沒有深入研究，交給後端組員 carry。我之後會再好好研究。
問題二：資料命名差異，你說的 id是什麼 id？？？
這是我自己也常常遇到的問題，有時候花了不少時間在和後端做資料串接也是因為這個。許多資料會有類似的屬性，比如說使用者會有 id，推文自己也有 id，甚至回覆 (reply)也有一個 id，而且每一個都很重要缺一不可，在同一個頁面上也有可能全部都需要用上。所以 API 傳回來的一包 JSON 資料裡面可能就好多個 id，再加上前端頁面的 id 接口名字可能也不一樣，無形中增加資料串接的複雜度。
這次的開發過程算是自己解決了啦，雖然花了不少時間。不過我認為可能前後端在開發前應該先討論出一個共通的命名模式，這樣可以大幅減少前端的工作量。
問題三：未使用 CSS 預處理器
這次的專案沒有使用到 CSS 預處理器，我個人覺得比較可惜。但考量到前端組員可能沒學過然後專案規格裡面也沒有要求，所以後來就沒有採用。但其實我還蠻想在專案裡面用 SCSS 的，一來可以讓 CSS 架構寫起來比較明瞭，不會隔一天回來看就頭昏眼花；二來是我覺得在處理 CSS 的時候也會加速許多。
六、助教回饋：
這邊節錄部份助教給予的回饋，並且專注在前端的部分。其中有兩位助教給予了我們回饋，一位是本組的專屬助教 Ivan，另一位是結業工作坊的 Jiang 助教。
- Ivan 助教：
- 使用 loading 畫面填補拉取資了的時間差，提升使用者體驗。
- 在 vue.config.js 使用 UglifyJsPlugin 加上 drop_console: true 將 console.log 移除。
- assets 裡面的檔案可以依照哪些頁面會使用到，分開放置在每個subfolder。svg 與 CSS 檔案也是分開較好。養成良好的整理檔案與資料夾的習慣，將會使寫程式事半功倍。
- CSS 使用共同變數優化共用的樣式。
Ivan 助教的忠告：
一個作品前端並不一定是最重要的，但是如果連前端的畫面與操作都無法吸引到面試官，就算程式碼架構寫的再好，都很可能失去第一次面試的機會。也就是說門面(UI/UX)很重要，因為面試官都很忙，外在 okay 了對方才會想繼續看你們履歷的內在(程式碼)。
2. Jiang 助教：
- 整體在切版上是穩定的！只是在一些細節處理，如：RWD、背景圖的實作方式、如何確保大的版型不壓縮到組件等等，相對小的細節掌握要再多加強！
- repo 的資料夾架構很乾淨！但可以進一步去思考如何透過資料夾的拆分來拆得更好維護。
- 整體功能實作如果都單獨來看的話是都有實作出來的，但是可以看出再功能想像上面比較保守，其實可以針對設計稿上多去想想有哪些你可以做得更好的地方？
- 個人頁快速切換頁籤時有時會顯示出「無法取得使用者資訊，請稍後再試」的提示，可能在非同步處理上需要多加注意，如何能確保組件在發送 request 要使用者資訊前，都能拿到當前使用者的 userId，以避免在非同步的狀態下才取用而撈不到資料。
七、自評需改進的部分
- 撰寫技術文件：
這次比較可惜的部分是沒有好好撰寫技術文件。因為要負責處理一些共用元件的部分，而其內容牽涉到資料的串接，若是能夠將相關文件撰寫清楚，將可以大大降低前端組員在使用上的難度，否則將會花許多時間在了解若要使用該共用元件需要從後端拿什麼資料，以及資料拿回來後應該做什麼處理。(雖然說這次需要使用共用元件的頁面我後來都包了)
相較之下後端組員製作的 API 表和 socket.io 各個 event 的使用方式真的就很清楚，讓前端在使用上可以快速了解特定功能需要使用的路由、需要帶入 request body 的資料和格式等等，減少前後端溝通上的難度。 - 在指定檔案中撰寫共用樣式：
在協作專案中和其他人合作溝通真的很重要，確定了共同的方向再出發會減少很多不必要的困擾。在專案中會有一些 reset css 以及許多共用或重複使用的樣式，建議可以將其撰寫在全域使用的 CSS 檔案中(如： application.css)，並使用 :foot 設定 CSS 變數，避免重複撰寫在各個 component 當中。這是這次專案中另一個努力不夠的部分。
八、心路歷程：
會不會累？很累啊怎麼可能不會累，尤其是做挑戰功能的那幾天真的是挑燈夜戰，大家視訊就開起來 live coding，但我覺得做起來很爽。這次的推特專案可以說是從單打獨鬥自己練功變成加入公會打團戰的層級。一開始的學習模式都是自己摸索，但當然自己也清楚知道如果進入職場後不可能都是這樣。就算遇到這樣的公司的話 (一個 junior 前端包全端還沒人帶)，我也是不敢去。
這次專案可以和其他組員合作，學習和後端溝通甚至和其他前端溝通，我覺得都是很重要的課題。怎麼分配頁面、怎麼幫忙救火、怎麼請求別人幫忙救火、熟練 Git 使用、怎麼表達前端資料需求、怎麼和後端討論 API 到底是要前端多打幾個 request 到後端湊齊資料還是後端一個 API response 一次給足，這些都是在之前自學的時候比較難體會到卻又很重要的面向。
感謝各位組員。尤其是後端的 Ivy 和 Sherry 實在很凱瑞，各種 API 都盡量依照 UIUX 頁面需要呈現的資料來設計，相關文件都寫很得清楚，處理問題的速度也很快，甚至其實他們是跨時區的接力式開發，個人覺得是一次很棒的合作體驗。希望自己的能力也有勉強達到他們的認可，要不然如果我自己是後端，卻發現前端沒辦法完全呈現出自己的努力，那應該會覺得蠻可惜的。
