Simple Twitter專案(JWT登入憑證、MYSQL、前後分離協作、Git、Code Review、Scrum流程) [ Alpha Camp學期三後端 ]
專案介紹：後端專案連結
複刻Twitter的簡易版功能。除了複習這學期所學，這個專案最主要在體驗前後分離協作及如何在時間壓力下走完Scrum流程。
以往在Alpha Camp的學習雖然助教、同學環繞、有問題能即時詢問討論，但所有專案或作業都是一人獨力完成，這是個難得的機會能在學習階段就體驗團隊協作時與前端溝通理解如何互相配合彼此的工作與理解對方方便的資料、與後端夥伴Git協作怎麼避免不必要的conflict與如何分工和互相cover。
擔任角色與完成項目
在前後分離組裡擔任後端工程師角色，在此專案中負責：
- 共用檔案設置、資料庫Model建置、種子資料建置、本地端Model unit test、遠端travis自動化測試
為了避免不必要的conflict，在Scrum流程第一階段工作分配上決定unit test測試檔中，我負責完成與資料庫有關的建置並通過測試，另一組員負責與路由設定有關的RESTful API規劃。除了資料庫，有許多共同檔案的建置也由我一併完成。
(GitHub repo設置、README.md撰寫、Heroku repo設置、第一條給前端測試連線用API產出、資料庫Model建置並確定符合unit test要求、種子資料建置、登入認證錯誤處理相關檔案建置、確認後端專案完成後符合自動化測試要求) - 協作路由coding與API Doc
在Scrum第二階段工作分配上，我負責與user-controller所有路由，另一組員負責其他所有路由。由於我進度較快，reply-controller路由也一併由我完成。 - 協作 refactor、debug
在Scrum第三階段，由於在前兩階段大量的code review，發現彼此除了coding邏輯、方式、風格不同外，也發現API產出的資料結構和類似狀況時錯誤訊息不同。討論過後決定要統一資料結構與錯誤訊息，避免造成前端的困擾。
這一階段也是再次檢查所有的API是否有問題，並交付給前端組員使用，發現問題立即調整。 - git指令
由於多數組員對於git指令皆不熟悉，在專案開始前我先製作大部分這個專案會用到的指令清單。也由於我個人進度較快，在組員有git指令相關問題、前端gh-pages建置問題時，由我這裡即時提供指令步驟與觀念釐清。
專案中特別練習技術與套件
- 使用MYSQL建置關聯性資料庫，並使用sequelize操作資料庫
- 使用passport及其相關local、jwt策略進行身分認證
- 使用dotenv設定統一放置環境變數，並以.gitignore隱藏避免個人設定外洩
- 使用bcryptjs密碼雜湊，增加資訊安全性
- 使用cross-env，處理不同作業系統使用不同指令問題
- 使用cors，處理前後端專案不同網域問題
- 使用faker，產生種子資料中部分假資料
- 使用imgur，處理圖片上傳
專案中遇到過的技術問題
- Travis自動化測試
在本地端所有unit tests全數通過，travis測試結果未通過，有意義的錯誤碼如下：
判斷：
應該是在passport.js檔案中將JWT_SECRET存在.env檔案裡，又以安全機密考量未上傳至github上。
想法：
有好幾種方式都可以解決這個error，
1. 直接不secret直接設定固定字串在passport.js
2. .env不隱藏直接上傳github
3. 在passport.js寫條件式，讓環境是travis時給他一個JWT_SECRET字串，其他時候隱藏在.env裡
4. 在travis.yml裡多設定一組執行時travis專用的JWT_SECRET
最終做法：
因為覺得直接暴露"SECRET"就沒有把他取名secret的意義所以選項1、2不考慮。
選項3、4選擇上覺得應該讓主程式乾淨一點，既然都有額外的travis.yml負責travis測試，應該盡量把travis有關的條件都放在travis.yml裡。
最終是採用選項4，在travis.yml裡多設定一組執行時travis專用的JWT_SECRET。 - 資料庫效率
在user-controller中getUsers這條路由在多了Followship和Like的種子資料建置後就出現時好時壞的情況，有意義的錯誤訊息如下：
判斷：
應該是一次性Join太多table，當followship和like有資料後就跑不動了。
想法：
原先的做法是一次性將所有資料撈出，在Sever端再過濾篩出需要的資料欄位，於是有幾種方式可以使用，
1. 用attributes的exclude把本來就要處理掉的欄位在資料庫這就先處理
2. 用MYSQL原生語法先行過濾處理資料
3. 用sequelize.fn、sequelize aggregate 等增進資料處理效能
4. 再度確認前端是否真的需要這麼多需要資料 😂
最終做法：
基於時間緊迫還未完全熟悉原生語法與sequelize.fn、sequelize aggregate ，這次先用選項1、4處理這條路由。專案完成後可再回頭refactor。
協作過程中的收穫和學習
- 經歷過程：
與後端組員協作中，遇到了工作分工、意見不同、作業系統不同、git指令不熟產生的conflict、...等各種狀況。但好在同為後端學習歷程相似，在技術能力上比較容易互相理解與討論。在專案開始之初有過很多次的衝突，但在建立每天隨時溝通討論下，很快就能順利進展完成後端專案。
與前端組員協作中發生了比較嚴重的問題。因為完全不理解前端的工作，所以對於前端的進度掌握和發生甚麼問題感覺不知道如何參與或協助，於是專案開始後大部分時候都是採前後端各自為政、每日各自提報進度和問題。到了專案尾聲要Demo時才驚覺前端進度落後與發生了甚麼問題。
在專案的最後，還是請了外援協助卡住的問題觀念釐清和debug，並在連續兩天兩夜的拚搏中產生最後作品。 - 檢討與學習
在團隊中本來就不可能每個組員都擁有一樣的能力總是各有強弱，所以在協作中頻繁的溝通顯得尤為重要，不僅僅是即時的工作分配調度，即時的問題反應更是重要！在這次專案中發現在與後端組員的協作有事半功倍的感覺，源於每日極度頻繁的溝通討論，即使曾有多次的意見不同的衝突，但都能即時的解決問題達成共識。而與前端發生的問題，若是能在專案開始與進行中每天都有5~10分鐘會議了解一下狀況，應該就不會到了專案尾聲才發現錯手不及的狀況，即使多數狀況後端沒辦法直接解決，但也可以早一點找外援或請求導師協助，不會讓外援和導師陪我們熬了那麼多天夜 😂。
留言
張貼留言