全端小菜鳥-Simple Twitter專案實作

Simple Twitter 發文

終於到AC的最後兩週的課程：simple推特專案實作！！
往年AC都會利用此專案來讓學員們來實際體驗工作後共同開發的感覺，相信很多人為了做到這個專案也是期待已久。我本身對於可以完成大型論壇或具備交流功能的web app十分感興趣，因此也趕緊將前面的課程多複習得多複習，補上的補上，讓自己到時可以對專案做出更多的貢獻！

我們3人小組採全端開發的模式進行，感謝Kou與Hazel推舉由之前有PM經驗的我擔任小組長，究竟PM擔任工程師是加分還是扣分呢，讓我們繼續看下去～～

黑客松挑戰：socket.io的即時通訊

PM視角分工 VS 工程師視角分工

從PM視角來看，我通常都會喜歡讓大家在same page的情況進行專案開發，
一來可以減少溝通上的成本，二來因為一定會有突然人力不夠的問題，統一戰線的方式可以方便大家互相隨時支援，像一支球隊，夥伴們即時補位
所以在開專案啟動會議，除了跟大家說明如何進行專案以外，也會統一大家的做法和回報機制（就像是建立網路協定一樣）

這次專案也不例外～～在會議前有考慮到說，雖然AC課程內有包含Agile和kanban的方式，但在短時間內每個人不一定都很熟悉這套方法，且Kou因工作的緣故無法全職投入進來開發，能投入的時間和進度會比較難掌握，因此我們確認好ERD和路由後，並討論要採用敏捷中哪些比適合的方式來進行開發：

1. Daily Scrum：每天固定在slack回報今天的進度，不論做多做少
2. 保持敏捷精神：主動找問題，維持彈性，隨時了解夥伴的狀況，互相幫忙
3. 設定check point：每隔2–3天統一確認一次目前進度和狀況，即時調整
4. 類kanban的認領模式：依據AC給的設計稿和User Story，我們用頁面來區分需要做的任務，並透過daily scrum了解彼此的情況，如果先完成勾選的頁面，給彼此確認過後，便可繼續挑剩下未完成的部分繼續做

Simple twitter初期的分工表

如果從上述PM視角來說，似乎沒有太大的問題，因為敏捷中Sprint所講求的交付物是可驗收的功能(頁面），在時間比較急迫的情況下，可以確保有一定可以操作的功能和頁面來進行驗收

上面的規劃似乎很美好～～但是，人生最厲害就是這個But！專案開始前大家都覺得，利用頁面來分工似乎是個好方法。但是在實作時，從工程師視角來看，反而有個令人討厭的問題：

「重工！」

為何會有這現象呢？不是頁面都分得好好的嗎？是不是當初漏掉考慮了什麼？
我們這組在第一個check point開會時，不經對自己發出了這靈魂三問，後來根據我們回報彼此的狀況和開發的進度，才發現有以下問題：

1. 每個頁面一定都有重複的功能：舉例來說，前後台都有要顯示使用者，以及相關推文的部分，以功能上來說是重複的。因此當時沒考慮到誰要負責寫哪些controller的情況下，就會產生重工，從工程師的角度是蠻浪費（時間）的行為
2. 不同頁面有可以共同使用個元素：像是在推文首頁，或是追蹤者頁面，都有共同顯示的sidebar或是登入登出按鈕，其實可以事前先分工好，即可避免我做了，你也做了情況

所幸我們在專案不久後就發現這個情況，因此便用彼此擅長的事情重新調整分工，在頁面的基礎下再加上誰負責哪個controller和頁面的元素，由於我是直接加入2–3課程，前端還有一些坑待補，因此畫面優化的部分主要靠Hazel和Kou，我則是多做後端的部分，並多研究測試檔的部分（感謝有他們的幫忙ＸＤ，才有精美的畫面）
到了第二個check point時，我們透過測試計畫表來確認，基本上已經完成8成以上的指定功能

Simple Twitter的測試計畫表

我負責的部分

在專案進行中，我主要負責的是整體使用者的推文、回覆、喜歡和不喜歡等頁面和功能開發，以及隨時確認夥伴開發的情況，和review夥伴上傳到github的pull request～
老實說，這次是我第一次工程師多於PM的開發經驗，我還蠻享受這次的挑戰，也很欣賞Hazel review code和協助debug的能力，也在旁邊偷學了幾招XD
我也常常透過review Kou 切版和CSS的部分，多學幾招前端的小技巧，因為她常常要輪班，且上班到很晚，有時一方面佩服她可以為了專案很拼，又可以繼續維持白天的工作；一方面也擔心她會不會太疲勞，不過所幸大家最後一起完成了專案，希望有天我們team真的可以一起喝一杯XD

雖然前面看起來進度很順利，但在最後幾天時，我們太晚意識到要完全按照測試檔去開發……
因此後面Hazel和Kou在優化頁面時，我將model和相關的controller修改成可以通過大部分的測試，由於時間因素，留下少部分測試並未通過

這也讓我們學到，以後在專案啟動前，必須先跑一次測試檔，並依造其跑出來的結果，來列出具體開發的重點和順序

能順利結案的小秘訣：讓自己保持彈性，和一顆包容的心

之前在上PMP時，對課本中有一句話非常有印象：「專案的成功，才是專案經理的成功」，在專案開始前一直認為PM是一個專案能否成功的最大因素，但在實際自己開發後，對此想法有些改觀

雖然PM的協調和規劃對於專案有著不可或缺的影響力，但是我認為develop team能否有彈性，和保持一顆包容的心也會左右是否能好好team work的關鍵
因為每個人都有自己的時區，以及擅長和不擅長的事情，我們這組可以很好的通過，是因為大家將注意力專注在彼此擅長的事情，和包容彼此不擅長的部分，因此可以很好的合作下去

即使像上面發生了測試檔不通過的事情，我們不怪罪對方，而是將重點放在如何解決問題。

PS：「有問題，就解決」，這句話應該是內建在每個工程師的T-shirt上，沒有的話我先來印一件XDD

黑客松挑戰賽：利用socket.io打造即時通訊功能

由於我們這組搞混黑客松的時間，因此在時限內只有完成初步功能，但是由於還是很想試試看做出類似wootalk那種即時聊天的感覺，後續有花一週多左右的時間來閱讀文件和常識範例。

我負責的部分是：如何讓使用者在進出公開聊天室時，顯示上線或下線訊息，比較細的規格描述如下：

• 使用者進入公開聊天室時，訊息窗會跳出XXX上線了的提示訊息，離開時會顯示下限訊息
• 左方的上線使用者列表會一同更新在線上的使用者，並依據登入和登出的狀況來增減使用者列表，以及上方上線使用者的數字
• 以上功能可以即時顯示

如何透過socket來獲取登入訊息困擾我蠻久的，下面是整理當時思考脈絡：

如何知道使用者登入了？：

上述規格描述最關鍵的部分是：如何知道是哪個使用者進入到這個頁面，因此在實作前便先搜尋”socket.io” “session”和”passport”這幾個關鍵字，最初的想法是socket中有寫到如何從session中取得使用者登入資訊，並透過用這個來判斷，目前是哪個user切換到這個頁面

實作中遇到的困難：

1. 如何將socket的程式統一整理到socketController中，並取得session資料：因為在文件中，大部分socket是直接寫在app.js中，但這樣會造成沒辦法很好的關注點分離；本來session的寫法也沒有跟socket串接，因此也無法透過socket取得session資料

• 解法：後來參考官方文件，利用以下方式來跟session綁定，並使用socket.request.session.passport.user來取得使用者的資料

io.use((socket, next) => { sessionMiddleware(socket.request, socket.request.res, next) })

• 並用類似讓route也可以使用passport和app的方法，將io傳入socketController，實現關注點分離

const io = require('socket.io')(server) require('./controllers/socketController')(io)

2. 使用者登入時，無法透過handlebar埋入的id來通知上線訊息：本來想透過在公開聊天室的handlebar中埋入id，並透過getElement的方式來啟動寫在socketController中login的程式，但後來試了幾次都無法成功

• 解法：後來頓悟了socket.io其實就像是在打網球，如果要讓訊息或互動可以即時顯示，只要在公開頁hbs的script中，用socket.emit來傳出登入消息，並將登入後的動作反應寫在socketController，便可以解決登入顯示的問題

3. 使用者登出時，disconnect的data並沒有回傳值：因為使用者離線，需要自動將其從userlist刪除，且同步回傳系統訊息到聊天室，但因為disconnect並不會有data的值，因此一開始找不到方式可以將離開的使用者剔出列表

• 解法：後來發現也可以用socket.request.session.passport.user來判斷要離開的使用者，離線前用io.emit將使用者離開的資訊回傳到hbs中的script，完成使用者下線的傳球機制
• 但如果使用者沒有正確的關閉網頁，session中沒有使用者的資料會報錯，因此用下列的條件判斷來避免error產生

const idFromSession = socket.request.session.passport ? socket.request.session.passport.user : null

黑客松的感想：

一開始並不是太熟script的使用方法，以及socket.io的監聽和回傳機制，果然最快上手文件的方式就是邊看邊做。並大量搜尋過去的人用socket.io做功能時遇到的問題案例，可以加速排錯和舉一反三的功效，更快上手此工具

Simple Twitter的結語

很感謝AC能提供這次有趣的機會，讓一起學習的夥伴能組成專案小組進行開發，有實際挑戰過後發現真的整個人有蛻變，不會再是那個只用PM的角度來看整個專案開發的小毛頭了（因為以後要被需求追著跑TT

也很謝謝一起team work的夥伴，有你們一起開發真好！！祝大家都轉職成功XD