# GIT團隊實戰博客
- 項目要求
- 組長博客
遇到的困難及解決辦法
組員1（組長）：王彬
遇到的困難?
- 在團隊任務分工的時候沒有充分照顧到所有人，導致隊員們的工作量不均。
- 現場編程時間不夠
解決辦法
- 在此對組員們表示抱歉，由於缺乏經驗導致這樣的情況發生
- 下課後爆肝完成任務
組員2：趙暢
收獲：通過這次抽獎系統的作業，獲得了更多有關新建數據庫、向數據庫導入數據、數據接口設計、後臺處理邏輯、頁面設計、前後端交互的經驗。這有助於我alpha沖刺的進一步開發。
遇到的困難?
（馬後炮才一句話不夠說啊）說實話在課堂上的三個半小時，沒做出什麽事情來。總結了一下可能有下述原因：1.教室人多太吵，腦子裏太雜亂了。2.由於熟練度不夠，會碰到很多報錯，仍沒有到達“創造階段”，還需要花很多時間解決報錯問題。3.小組人數太多，其實PM也很為難，拿到一個題目，把它分成9個部分，讓人人都有事情做，考慮到大家又都不是熟練工，水平層次不齊（也就是還需要花時間學習新知識、花時間處理報錯，而不能直接上手寫代碼），是真的很難，基本上是不可能的。4.組內人數太多，導致大家交流的成本也很高，經常這裏拋出一個問題那裏不清楚一個接口，在交流中時間很快就溜走了。所以三個多小時，我基本上就寫了點建表這樣的簡單邏輯，臨下課時還把數據庫搞崩了。下課的時候我就在心裏默默的吐槽，這作業是三個多小時能搞出來的東西？？吃中午飯的時候都是頭暈眼花的。睡了個午覺，三點鐘我搬電腦跑到PM的宿舍，理邏輯、碼代碼。下午我把數據庫重新搭建好，負責處理數據的C哥也搞定了把數據發過來了，總算可以開始寫後臺邏輯了。晚上王源也過來了，三人一直做到鄰近deadline終於弄出了初版。
回頭想想為什麽早上的三個小時之內做不完，其實不是因為題目太難，首先個人方面，還是因為自己熟練度不夠導致出一些低級錯誤，要花很多精力去排錯。團隊方面，小組人數太多，分工不合理（或者說根本沒辦法合理分工）。出現了這種狀況：早上有的成員問：“我現在該做什麽？”但卻得不到PM或者其他隊員的回復，只能尷尬地坐在原地自閉。其實當時我也知情的，但當時我被數據庫的報錯弄得焦頭爛額，大腦裏實在沒有內存再去想“我應該給我的隊友分配什麽工作”這樣的問題。到了下午，deadline在即，我只得爆肝把作業完成。少數幾個人出了大部分的力，部分組員體驗不好。對此我感到很抱歉……
其他的技術上的困難解決了之後都不是困難。我們小組內有形成自己的技術文檔方便共享學習和快速查找解決方案。
- 解決辦法
（真正的馬後炮）如果把這個編程實踐放在alpha之前的那一段比較空閑的時間，大家都多花點時間熟悉語言/框架，也許效果會好一些？
組員3：胡展瑞
遇到的困難?
- 前端界面在laravel框架下如何調用css文件
- 前端界面顯示不一致
- 感覺自己劃水占比較多
解決辦法
- 放在public/css
- 使用相同瀏覽器（chrome）
組員4：李恒達
遇到的困難?
- 網頁前端0了解，現學現用
- html、css的語言現學用，短時間內只做出了簡陋的頁面且漏洞百出，也給後端
的隊友們添了不少麻煩，很抱歉。
解決辦法
- 上“菜鳥教程”，走一步看一步的學與用。
- 遇到不懂的地方問隊友。
（馬後炮）說不上愛別說話，就任由的菜。
組員5：林煌偉
遇到的困難?
- 與後端接口交互不明確，導致前端界面代碼一直修改
- 對代碼不夠熟悉，時間不夠，界面過於簡陋
解決辦法
- 邊做邊修改代碼
- 積極與後端隊員溝通
組員6：陳誌煒
遇到的困難?
- txt文件中隱藏的坑較多 直接用記事本或者atom打開看不出有換行，結果是存在換行的，CRLF、LF是混合的，賬號的格式有（XXXX） 還有少部分
, 格式比較混亂，處理起來比較困難。
解決辦法
- 一開始是按行讀取，發現問題後,改成用正則一行一行匹，匹配出內容以及消息的信息，把格式問題一個個處理掉。然後同時過濾掉系統消息，匿名消息的賬號。
組員7：陳文垚
遇到的困難?
- 不知道如何在HTML頁面上GET到後端服務器的數據並展示到前端頁面? ??
- 對HTML有些陌生，寫的界面堪稱醜陋，對不住我的隊友
解決辦法
- 找博客找資源學習，但是尚未成功學會......??
- 現學現用，和隊友進行討論一起設計??
組員8：佘嶽昕
遇到的困難?
就是實戰的時候分工不明確詢問數次無果導致我幹坐了一早上非常尷尬吧 不過給予團隊理解 大家都很忙有自己的事要做? 我自己也是有問題的 慢慢一起成長吧
解決辦法
- 繼續學習之前未完成的教程，課後研究附加題部分
組員9：王源
遇到的困難?
- 熟練度不夠出現了很多的低級錯誤
- 接口和功能需求的交流花費了些時間
解決辦法
- 和趙暢一同梳理邏輯和編寫代碼
- 下課後爆肝
事先設計的函數模塊及分工
項目思維導圖：
接口設計：
前端：
接口一：POST請求包含（抽獎關鍵詞、活動文案、選取的聊天記錄時間段、獲獎人數、是否過濾平時未發言用戶、是否進行深度過濾、獎品）
接口二：根據後端返回的中獎名單json將結果渲染到前端頁面中
後端：
- 接口一：根據前端用戶制定的抽獎規則對數據庫中聊天記錄進行篩選並選出中獎用戶名單，結果以json返回前端
組員職責分工
| 姓名 | 分工 |
|---|---|
| 王彬 | 任務劃分、接口制定 |
| 趙暢 | 聊天記錄導入數據庫、後端業務邏輯實現、項目部署到雲 |
| 李恒達 | 結果展示頁面設計、結果展示頁面設計 |
| 胡展瑞 | 界面UI設計、前端代碼合並 |
| 王源 | 抽獎算法設計實現 |
| 佘嶽昕 | 後端業務邏輯實現 |
| 陳誌煒 | 結構化聊天記錄並進行清洗、將聊天記錄轉換為.csv文件 |
| 陳文垚 | 發送規則接口實現、結果展示頁面設計 |
| 林煌偉 | 抽獎規則界面設計、結果展示頁面設計 |
程序運行環境
項目是基於laravel框架搭建的web端服務，已經部署到騰訊雲上。老師和助教可以直接訪問http://193.112.6.8
程序運行截圖 & GUI界面
- 抽獎系統首頁
- 點擊開始抽獎按鈕來到規則制定頁
- 填入相應抽獎規則
- 如果缺少必要參數，或者填寫不合理，系統會進行相應提示
- 抽獎結果公布
基礎功能實現列表
| 功能需求 | 是否實現 | 實現效果 |
|---|---|---|
| 設置參與抽獎關鍵詞 | 實現 | 支持單個或多個關鍵詞的制定 |
| 抽獎活動文案 | 實現 | 可以將抽獎文案展示到抽獎結果頁面 |
| 抽獎發言時段 | 實現 | 支持從某一時間段的用戶發言記錄中 |
| 抽獎過濾規則 | 實現 | 可以根據用戶發言記錄數進行過濾 |
| 抽獎結果公布時間 | 部分實現 | 用戶可以自定抽獎公布時間 |
| 抽獎人數 | 實現 | 可以自定中獎人數，當符合條件的用戶少於中獎人數時能返回正確結果 |
| 獎品列表 | 部分實現 | 可以在結果展示頁面展示獎品列表 |
| 獲獎名單 | 實現 | 可以根據後端的中獎名單將獲獎名單展示出來 |
鑒於時間所限，在17號晚上11點之前未能完成附加功能的設計。（QQ聊天記錄爬取、分析、生成圖片等）
抽獎算法設計思路
github代碼上傳記錄
github倉庫地址：https://github.com/BenjaminAlvis/live-project
共三十多次commit
貢獻度評定
| 姓名 | 貢獻度 |
|---|---|
| 王彬 | 9% |
| 趙暢 | 26% |
| 李恒達 | 5% |
| 胡展瑞 | 5% |
| 王源 | 20% |
| 佘嶽昕 | 5% |
| 陳誌煒 | 20% |
| 陳文垚 | 5% |
| 林煌偉 | 5% |
PSP
| PSP2.1 | ???Personal Software Process Stages | ??預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | ?計劃 | 5 | 5 |
| · Estimate | ???· 估計這個任務需要多少時間 | ||
| Development | 開發 | 310 | 330 |
| · Analysis | ???· 需求分析 (包括學習新技術) | 130 | 150 |
| · Design Spec | ????· 生成設計文檔 | 0 | 0 |
| · Design Review | ??· 設計復審 | 0 | 0 |
| · Coding Standard | ????· 代碼規範 (為目前的開發制定合適的規範) | 0 | 0 |
| · Design | ????· 具體設計 | 0 | 0 |
| · Coding | ??· 具體編碼 | 260 | 275 |
| · Code Review | ????· 代碼復審 | 0 | 0 |
| · Test | ???· 測試（自我測試，修改代碼，提交修改） | 0 | 0 |
| Reporting | ?報告 | 15 | 20 |
| · Test Repor | ?· 測試報告 | 0 | 0 |
| · Size Measurement | ???· 計算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | ??· 事後總結, 並提出過程改進計劃 | 5 | 10 |
| ????合計 | 430 | 455 |
# GIT團隊實戰博客