Twitter 團體協作體驗

前言

由於學期三的第六週課程就接著推特，而我本身還沒完全吸收完第六週課程，就直接上戰場來挑戰團隊協作，有點像是越等打怪，所以我在團隊協作裡事先與其他隊友達成推特協作的成品要有怎麼樣的完整性，在這裡我們決定以MVP的形式，不添加額外的架構、功能、易容易合作/理解的開發風格和架構為優先。另外我也得想辦法從中快速成為即戰力來為整個團隊給予助力。

開發結構

推特專案是以前後端分離的形式以及搭配資料來進行，其結構分別如下：

• 前端：使用 Vue 框架 + github page建立前端伺服器
• 後端：使用 Express 框架 + Node.js執行環境 + CORS + Heroku 部署API 伺服器
• 資料庫：使用sequelize作為MySQL的ORM

分工情況 && 角色

成員有John、Yu、雍澈、我(orion)，John、Yu負責前端開發，而雍澈和我負責後端開發，在團隊協作裡，我們會按照實際開發狀況來彼此間會擔當不同角色，比如PM、QA、實際開發者，不會指定一些人來擔當職務，所以在這樣的分工狀況，就更需要彼此間的督促、開會、相互幫忙。

過程：開始至Sprint #1

一開始，大家都相互決定要達成成品的完成度之共識，接著按照AC指定的Sprint#1所需要的規格、人員分工、進度分工、DOD來準備，準備期間真的是手忙腳亂的，尤其是大家都是從別的領域轉過來學習的，所以更加不熟悉準備什麼，好在夥伴們都會相互提醒、幫忙分擔工作，然後透過密集式的會議才勉強把這階段要的資料都備齊以及定義好規格。

備齊之後，就開始進行按照分工來開發，剛開始的後端開發由於我跟雍澈並不像其他同學能夠預先利用時間來準備，所以特別容易緊張，甚至要規定的功能都無法正常產出，而且雍澈那邊也須兼顧著工作，當然，這樣子的合作狀況是不行的，所以我們就用Trello 追蹤後續進度、使用Slack定期回報自己完成什麼事情、相互打氣聊天的形式進行、公開API文件給前端知道假資料如何做。

過程：Sprint #1後 至 Sprint #2

隨著我們改用Trello、Slack等工具來維持進度的追蹤以及相互打氣，我們的開發速度有逐漸提升，但那時候發現負責前端的夥伴實在太強大，已經把前端的切版都作完，只剩下我們這邊的API給的資料以及透過資料所要做的功能開發，這使後端的我們變得異常緊張，所以我們是在這種異常緊張的狀況進行，同時為了讓前端部分不會被後端的開發速度延宕，所幸Yu有提案說先把目前能提供的API部署在Heroku，讓他們能夠同時進行開發以及幫我們後端找出潛在的bug，不然不知道要花多久時間才能部署…..，當然的，這樣開發模式，會變成我跟雍澈得邊輪班除錯和開發或者邊保持待命邊開發其他功能，而且還得根據實際開發的結果來變動到API文件上的格式，並隨時通報自己變動了什麼。

接著就是輪到AC 所指定的Sprinit #2繳交作業，這部分比較像是回報目前開發狀況是如何以及如何安排後續的開發，所以沒像Sprint #1需要很多時間去做準備。

過程：Sprint #2後 至 Sprint #3

接著就是Sprint #2後 至 Sprint #3的期間，由於伺服器的提前部署，使得前後端能夠在第一時間串接，當然也免不了大量的bug修正和溝通，這時有隊友提議要不要在sprint #3進行showcase來提前讓評審先發現潛在問題，雖說就我而言，我蠻怕在那之前就還沒開發完畢，不過好在有夥伴幫忙分攤後端開發以及前端大大們那可怕的開發能力，讓推特初步功能也在sprint #3前就完成了。

Sprint #3後 至 繳交當天

經過最後一次的Sprint分享後，我們就做了最後一次的會議來驗收功能、小幅度地修正bug、寫readme、跑一遍readme的流程，並於最後繳交作業，所幸驗收結果是顯示只剩下bug要修正，所以對這些bug進行簡單的排序，看哪邊重要就先改，不重要就先跳過，接著做寫readme和驗證readme流程是否正確，過程中，還有一些前端的bug要修正，但為了怕前端夥伴需要後端來進行溝通，得要有個後端待命，但那時預計修正的時間會偏晚，所以就讓雍澈先睡來應付隔天的上班，我來負責守夜兼確定我們是否有按照DOD完成和尋找潛在bug，守夜到天亮，前端那邊就換班修bug，但後端也只剩下我一個人負責，所以我就堅持到前端隊友繳交成品後才睡覺。

成果

前端開發repo
後端開發repo
後端入口DEMO.
專案成品DEMO.
API 文件.

總結

這次協作體驗最難的地方是溝通、溝通、溝通，這很重要，所以講了三次，少了溝通，任何協作都無法完成，就結果來說，大家都做得不錯，彼此間都會為了通過而願意密集式溝通和合作，即使身兼全職工作，隊友也都會為了這個團隊盡量請假幫忙協作開發，就進度而言，除了第一個sprint有延宕開發進度以外，後續的協作隨著適應而進而改善許多，同時間還要感謝前端那邊的大大竟然能在短時間完成。XD

還能做的優化

根據這次的協作體驗下，後端還可以做的優化可以是這些：

1. 後端API 在前端發送大量請求下能夠正常執行
2. 部分API過於依賴資料庫的計算，這使得執行成本
3. 錯誤訊息的包裝可以自製一個error物件來打造更適合推特專案的物件，且能夠進一步縮減程式碼和提升功能性
4. 採用swagger 能夠讓API文件跟著實際執行結果而變動
5. 可將重複較高的功能以middleware形式來載入給其他路由