期中小組專案驗收：Simple Twitter簡易社群網站開發
9 min readMay 19, 2020
(註1：本文為ALPHA Camp舊版全端網路開發學期四：業界專案實戰課程心得的一部分，2020上半年筆者修習此課程後有所調整，和現今課程內容有所差異，目前改為學期三的全端課程部分)
(註2：此文章是以修課期間相對應學期四期中的basecamp回報貼文、挑戰題的決策脈絡與ORID 學習週記內容為主，再將記錄改寫補充而成)
Github連結(專案介紹與原始碼):
https://github.com/duaifzn/simple-twitter-express-starter
Heroku連結(應用程式預覽，因免費版限制須稍等):https://twitter2020.herokuapp.com/
一、開發第一週的Check -in回報：
- 下週團隊預計開發的重點有哪些？
完成挑戰題
UI優化
修復bugs
自動化測試全數pass - 經過了一週的開發，團隊感覺如何？
協作的感覺與獨立開發很不一樣，分工合作感覺很不錯，
能有人協助分攤功能開發，不用事必躬親，合併master即可驗收總進度；
但更需要團隊的「默契」，可能因是第一次經驗，覺得效率有待加強 - 開發過程中有什麼地方卡住了？
a. 當進入使用者的頁面，或是在首頁點unlike，即執行userController上的動作，伺服器記憶體可能會爆掉，出現”FATAL ERROR: Ineffective markcompacts near heap limit Allocation failed JavaScript heap out of memory”錯誤而當掉；經詢問同組只有我遇到這個錯誤，不曉得是個人電腦配置，還是seeder資料量的問題(全新帳號無問題)，目前仍無法完全解決……(註：換效能較高的電腦開發後無遇到此問題)
b. 對於web socket 理論了解，但不清楚程式碼怎麼運作 - 有任何需要幫助的地方嗎？
a. 希望能協助釐清記憶體爆掉的錯誤，因網路上搜尋到的方法無法解決，希望能確認為程式碼、資料庫或個人開發環境的問題
b. web socket，例如選用的套件、撰寫的方式等仍在摸索中，希望能多些指引 - 本週你們完成了哪些 user stories？
完成基本規格(註：即簡單的註冊登入/登出、推特發文、推文瀏覽與回應、標示追蹤帳戶與喜歡推文、編輯個人資訊) - 預計何時和助教約tech hour？已經約的話可以分享你們 tech hour的收穫？
3/22 19:30–20–15線上會議
二、開發第二~三週的主要任務：實作聊天室
指定功能：即時聊天
基本資訊
- 規格說明: 加入聊天室(包含與所有上線者公開群聊與個別私訊)
- PR 網址：https://github.com/duaifzn/simple-twitter-express-starter/pull/28
- 頁面連結：https://twitter2020.herokuapp.com/chat
- 你在實作中的角色：經全組分工後，獨立開發完成與維護修改此項功能
思考脈絡
- 為什麼選擇這個作法 (看了哪些材料、想了哪些問題)
一開始想說先做出可以公開傳訊息的聊天室概念比較簡單，便先上網找一個原始碼與說明較易理解的範本抓下來研究，理解其邏輯與寫法後逐步修改成自己想要的樣子，先以群聊功能為雛形。
多次查閱官方文檔與瀏覽其他範例後，認為將私訊功能做在同一頁面比較好處理，先花好幾天想辦法在既有框架插入私訊，才從room的概念想到為每位使用者開「自己的房間」，用額外函式寫出二人私訊的功能；完成主要任務後，想起過去使用即時通訊軟體的經驗，也順手加入超連結轉換、版面與訊息欄位的RWD支援等，使整體完成度大大提高。
簡言之，算是先把他人的成品消化後，用自己對聊天室的概念查詢語法後加以「魔改」。 - 為什麼選擇這個工具
先上npm查詢”websocket”時，就有發現ws與socket.io二大選項，一度猶豫到底該用哪個；後來經過開發第二周助教解說與同學反應，前者是較純粹的websocket應用，後者還包含其他技術，且具有舊版瀏覽器相容設定，且相關教學文章較多，再加上剛好前面提過的主要參考範例就是用socket.io，便順理成章的繼續以後者開發。
而到後面配置版面時，由於已知bootstrap只能針對螢幕寬度的變化自動調整，經助教建議後便採用CSS的media query，針對不同寬度與高度區間設定訊息欄位的高度，以讓畫面在各類常見裝置與大小都能將輸入欄維持在底層且不掉出，就像坊間即時通訊軟體只會在訊息欄中捲動瀏覽，有新訊息同時維持住整體畫面高度。 - 在有限時間內選擇優先處理的是什麼，為什麼是這個？
進入挑戰功能的開發周後，首要目標便是盡快做出基礎功能，然後再改出更多延伸功能至完整，因此我最先去搜尋一個可以直接模仿的案例，再修改前後端代碼以符合個人風格。
完成基礎群聊後，我的優先目標便轉到加入私訊功能，起初也是想從其他案例拆出相關代碼來用，但因為無法直接從案例理解作法，各種查詢與嘗試卡了好幾天，剛好拖到原定期限的周日向助教提問，先得到一篇在stackoverflow上的問答做為參考。
反覆閱讀後，發現自己對socket.io的各項語法實在不夠熟悉，便把目標改為研讀官方文檔，比對後才明白要嘗試room的語法，成功後參考原群聊寫法邏輯加速完成私訊功能。
另外，由於後來有等待其他人修復挑戰功能的時間，我才用這額外時間完成聊天室整體頁面與訊息欄高度的RWD與其他UI/UX調校，讓功能趨於完整。 - 選擇目前不處理的是什麼？為什麼這樣決定？
最區別於其他組的，是沒有做出對個別使用者的私訊畫面，及用使用者名稱作為私訊對象的依據：由於起初做的是群體聊天室，若要以最簡單的方式加入私訊功能，就是像zoom在同一頁面可以選擇要傳訊息的對象，可以免去設計額外版面與對應的前後端JS程式碼；至於為何是輸入傳訊對象的id，而非輸入、查詢或拉選使用者名稱，主要是考量用戶數量不多，且實際上id才有唯一性的辨識效果(名稱可以重複或類似)，再加上直接輸入以外的選項做法有點複雜。
此外，對話介面與輸入欄位效果我原先沒打算仔細編修，僅因為有等待其他挑戰功能的時間才加入我覺得即時通訊應該要有的基本要素，如介面中自己與他人或群聊與私訊的差別凸顯(bootstrap)，以及輸入電話、電子郵件地址或網址應該要有超連結的效果(regex)，這些效果的技術難度與時間不難掌握；相較之下，更為精美的介面，或是支援輸入段落、影像、貼圖、檔案等功能，因為個別項目的實作經考量都是不小的坑，實在沒時間與心力去一一完成，讓基本通訊功能完整即可。 - 其他任何能幫助 senior 判斷品質/風險的有用資訊
這邊主要補述之前沒提過的聊天室功能相關規格細節：
1. websocket(ws)前後端的連線方式
因起初參考的範例是將網站本體路由與即時通訊分成二個伺服器各自運作，也就是佔二個port，在本機時便用concurrently這npm套件以便雙開伺服器；然而，直接佈署到heroku時會面臨只能免費用一個port的問題，解決方法除了課金(註：付費使用該功能)外，我只想到將伺服器整合為一個，或是將websocket伺服器另外佈署成專案再連過去。
由於實在研究不出整併還能連線的作法，只好採用另外佈署的方案，但卻在二者皆佈署上線後，先後於heroku後端與瀏覽器前端發現連到ws伺服器後無法回傳訊息的情況，經助教建議與瀏覽訊息後，改採連到wss與升級不安全請求並用的方式才解決連線問題。
2. 輸入欄位
將通訊功能從只有群聊加入私訊後，我在欄位左邊加上核取方塊區別二者，即打勾發的才是私訊。 由於私訊的邏輯較為複雜，我設定為勾選私訊後，必須要先輸入對方id(限制為整數)，否則先將文字欄位鎖住，輸入id後才啟用開放輸入文字；而輸入id後若取消勾選，代表要改發群聊，便設定會清掉以輸入的id，以免因指定過id會發成私訊。
其他共通部分，主要是因應是否輸入文字改變提示，以及只開放用enter鍵送出節省版面。
3. 訊息處理
主要是會對發出的訊息類別、對象從前後端稍作轉換。 除了自己的訊息一律在右側、他人的在左側來區分，如果是群聊，只會有基本的發言者、內容、時間；私訊的話，還會加上私訊的標示與傳送的對象。 還有，對象也會做額外處理，自己發的會以「我」來自稱而非名稱，且別人的名稱只有在對方有上線時才會顯示──如果傳給不在線上列表(可能離線或無此帳戶)的對象，後端會自動回覆警告訊息，表示訊息未送達，且對方名稱只顯示為id，以做出區別。
三、開發第四週的ORID 學習週記：
- Objective: 學做了什麼？完成了什麼？
實際體會多人協作開發的流程與經驗，和另外二位組員一起完成”simple twitter”專案的基礎與挑戰功能，並修復已知的錯誤與優化UI\UX體驗。 - Reflective: 經歷學習，你的感覺如何？為什麼？如果有好的感覺，如何延續？如果有不好的感覺，如何改善？
協作開發根據分工與溝通的模式，會有很大的差異，這次因為偏向分工後各自完成進度再合併，大部分的時候感覺其實與單人開發很像，重點還是在於獨立完成負責的功能；但也很明顯能感覺到不是一個人在開發，不用全部自己來，可以省心力集中在個人進度。 - Interpretive: 在開發當中，你個人或小組最大的學習體會是什麼？有什麼問題還沒有被解決？
小組合作有不少好處，可以減少工作負荷，出問題有真人可以問，也有互相督促進度與分享資訊的好處；但他人參與開發也會帶來變數，除了不能獨自變更任務，遇到狀況時也有向主動其他人說明的義務，才能維持共同開發的共識。 共識需要預先的討論，而這次因為是首次協作經驗相對缺乏，起初的分工並沒考慮到先後順序與完成度，造成等待進度與品質不一的情況。 - Decisional: 你下一階段的學習打算做什麼？（解決什麼未完成的問題？改變學習方式？完成哪些挑戰等等）
如果還有下次的多人協作，我會希望組員之間的分工不是只有認領各自要完成的功能而已，而是要約個時間即時討論（例如線上語音會議），讓更多細節有機會被討論到，像是優先完成哪些以免其他還不能做，或是完成是指東西能動還是完整體驗等，甚至是額外優化要作到什麼程度，有先討論好的話比較能平均分配，不然只能靠有人主動承擔，既使順利完成也對分工模式不健康。 - 有什麼話想跟 AC (ALPHA Camp團隊簡稱)說？
覺得期中開發的時程預計二周實在不夠用，開發挑戰功能時因為面對全新的概念，得花不少時間找各方資料嘗試與修改，一週內不見得能完成，就算完成也沒時間把各項體驗與錯誤修好，感覺至少三週才能確保小組專案的品質。
