Twitterf開發反思部落格

前期組隊:

一開始忽略了這個環節。  最後一個禮拜參加了Zoom的會議才知道要組隊， 以及怎麼組隊。

這個時候大多數的人都已經有組了， 原本想到的幾個口袋名單也去別人口袋了(哭啊)

所以組隊蒐集隊友花了不少心力。

反思:

活動訊息很重要, 參加活動絕對不是人到就好.

很多規則，時程，前置作業，凡舉周邊的情報都要用心了解一下

時間花在前期準備是比較有效率的

工作分配:

對前端要怎麼分配雖有概念，但是規定自己絕對不要去表達或是去建議前端組員的想法。

我自己理解Twitter專案的目的是讓每個學員體會團隊協作其中，好的一面以及不好的一面。

AC的組員大多人都很好、很友善。但是過度的manipulating儘管專案進度會比較穩定，但是反而會犧牲掉組員練習的機會。

後來發現這樣做產生成本比預期的高，哈哈

後端部分因為餐廳論壇專案跟架構已經有跡可循，所以分工起來大家都很有共識

具體分工我分配在每個sprint階段

 

Sprint# 1  系統分析  (要交一堆文件)

我個人是負責 acceptance criteria, DoD, API 文件規格與哪邊用哪支.

系統分析好重要。這次的經驗挺珍貴的。

從需求 => 規格 => 系統分析 => break down到每個環節要怎麼執行以及怎麼執行

很有趣，很像以前產品開發的時候在看廠商做bussiness development的感覺

(要看這個廠商懂不懂, 會不會, 以及願意投入多少資源, 以及執行團隊跟設施這些)

反思:

秉持著大家都要練習到的想法，跟組員做了同樣的工作。

本來想著出來可以互相參考，但是因為出發點不一樣(不然就是我沒說清楚)，導致出來的東西不容易合併。而且時間也有限，最後就直接拿其中一份交出去。

有點給人莊孝維的感覺，所以總之就是:  嘖... 不要太自以為。

Sprint# 2  正式開發啦 ~

我的部分:

Express架構 -> Dummy data讓前端可以先套套看 -> Heroku架設 -> User request -> admin request 

以及隨時修改前端需求。

我的部分本來打算盡快先讓前端有API可以串, 那怕是dummy data也好。

所以跟前端溝通好會先做哪幾頁後: 先做這幾頁的dummy API, 再做那些那些。

但是後來做著做著發現其實做dummy data也很花時間 (自己key JSON key到懷疑生人)。

所以做完了前面幾支之後想說還不如直接做，花的時間也不會差多少。

所以等哲哲那邊把models跟User部分種子資料完成後就轉做登入功能了

誰知道...

恐怖的事情才要發生...

恐怖事件1

測試檔案要求的規格跟sprint# 1討論好的API輸出格式不一樣

舉例來說

原本計畫是回傳一個名叫data的物件, 裡面有status: ''success" 以及 users: [{user1}, { user2}, ... ]

但是這樣的格式測試檔會抓不到它預期的.  所以API輸出格式以及之前做的Dummy Data需要改.

其實也就是前端再串接的時候改一下就好，但是如果這個是在公司，估計要被大做文章了。

又改!  這樣進度會有問題喔... 蛤~我已經送去給客戶確認了捏~

想到就怕

恐怖事件2

CORS

這個最恐怖了。其實一開始再串dummy Data的時候有前端有反應過出現這個錯誤。

上網搜尋了一下怎麼處理，前端那邊也很反應可以。

直到sprint #2 要demo的前一天，前端這邊要使用佈署在GitHub Page的伺服器測試時。

又CORS啦~~

見鬼啦 ~  

之後就是不斷的上網找解法來套，然後請前端測試。然後都不行。

所以sprint# 2 demo 胎死腹中.  

後來才知道methdo: [GET, POST, PUT, PATCH, DELETE] 是不夠的，

雖然問了chatGPT它都回我說這樣是可以解決CORS錯誤的, 但是就是不行阿!

還有一個OPTIONS要加進去。就算你後端孤陋寡聞你不信... 唉...

反思: 

API輸出格式與測試檔相關部分，因為這次寫測試的人不參與討論與修改

所以也就這樣吧。 

CORS不僅要盡早提供東西給別人測試，自己也要要求有東西盡早可以測。

確保完成的進度是有效的。

Sprint# 3

Sprint #3 後端這邊就沒有既定的任務了。多半就是看產品還有哪些地方需要修改，輸出格式怎麼改前端可以輕鬆一點。或是有錯誤的地方趕快修正

反思: 

好累，到了後期反而有點彈性疲乏了。 一開始還是不要太超時工作，避免下半場突如其來有變故反而沒有心力去處理。