團隊現場程式設計實戰
阿新 • • 發佈：2018-11-18
一、組員職責分工及貢獻分
| 學號 | 成員 | 分工 | 貢獻分 |
|---|---|---|---|
| 031602428 | 蘇路明 | 整合程式碼，抽獎演算法實現部分 | 12 |
| 031602401 | 陳瀚霖 | 設計演算法、文案 | 8 |
| 031602406 | 程曉巨集 | 提取抽獎名單 | 12 |
| 031602438 | 葉一帆 | 抽獎介面、海報介面 | 15 |
| 031602407 | 何家健 | 設計演算法、文案 | 6 |
| 031602410 | 黃海潮 | 設計演算法、文案 | 8 |
| 031602429 | 王錦揚 | 原型設計 | 8 |
| 031602442 | 鄭孔宇 | 撰寫部落格，思考附加需求(orz 根本沒時間實現) | 8 |
| 031602439 | 俞凱欣 | 原型設計 | 9 |
| 031602421 | 林世傑 | 使用者權重演算法設計、實現 | 14 |
二、github 的提交日誌截圖
三、程式執行截圖
- 先按照格式輸入時間資訊和其他資訊
- 點選抽獎即可生成結果介面
四、程式執行環境
- 程式語言:python
- 程式執行環境:桌面程式（可在pycharm裡直接執行）
五、GUI介面
- 主介面
- 獲獎名單介面
六、基礎功能實現
- 採用的抽獎演算法
1.根據得出的權重 Value 進?行行累加計算得 TotalValue,並根據 key 的個數得出KeyCount.
2.將每個?的 Value 除 TotalValue 得到 T_value(小於 1 的數).
3.將得到的 T_value(0.02KeyCount))得到 P_Value.
4.取?個 0-1 之間的隨機數 Random
5.Math 的值為 Random*(1-P_Value).
注：權重越高的使用者得到的P_Value值越大，Math值由隨機數和P_Value值決定，兩者權重五五開，權重越高的使用者獲獎的機率越高，同時也保證權重相對低的使用者也有獲獎的機會 - 抽獎演算法2
由於時間關係，只實現了由上述演算法的抽獎方式，而沒有采用分等獎品的抽獎方式，在此就不贅述了。 - 使用者權重計算方法
1.系統訊息使用者權重為0，未發言過的使用者權重為0。
2.訊息傳送得越多的使用者權重越高，但是增長也會逐漸降低。
3.採用使用者參與聊天的次數和發言數量結合來產生權重。例如，使用者A與使用者B發言數量相當，但是使用者A只在某一時段參與聊天，而使用者B在多個時段參與聊天，使用者B的權重有可能會比使用者A高。（在本次演算法中，來不及實現） - 提取某項參與抽獎使用者
1.使用者過濾，剔除不在抽獎時段參與抽獎的使用者。
2.使用者去重，使用者多次傳送參與同一抽獎，只佔一份名單。 - 抽獎演算法詳細文件
(https://files.cnblogs.com/files/kkyblog/%E5%9F%BA%E7%A1%80%E5%8A%9F%E8%83%BD%E7%AE%97%E6%B3%95.pdf)**
七、附加功能實現
- 自動爬取聊天記錄功能：無
- 對聊天記錄進行分析與挖掘：無
- 獲獎名單海報生成，但不能自動分享。
- 鼓勵有想法且有用的功能：應該是無吧。
八、遇到的困難及解決方法
蘇路明
- 遇到的困難和問題：沒有極速開發經驗，團隊技能不一，開發技能不足
- 解決方法：瞭解題意，根據隊員技能情況分工，開發硬鋼
- 吐槽：有壓力才有動力，然而這原本一早上的任務也太重了吧，一早上的課就變成一早上一晚上了，要考試了啊... 原本以為只有一早上，所以求穩選擇了python作為團隊開發語言，早知道會推遲，肯定選取其他大家都比較有接觸過的開發語言呀，導致團隊開發力量後期不足。
陳瀚霖
- 遇到的困難和問題：第一次遇到這種實際應用的功能的演算法 有點束手無措。
- 解決方法：和同學合作解決。
- 吐槽：都是全新的挑戰太累了。
程曉紅
- 遇到的困難和問題：與其他部分的引數傳遞
- 解決方法：在演算法設計環節主要的解決方法是查閱了網上的演算法之後，再和隊友一起討論。在演算法設計之初沒有嚴密的定義各部分介面之間傳遞引數的格式，再後面完善的過程中，演算法經歷了重構，比較費時。
- 吐槽：如果對程式設計的愛多一點點，那麼就不會那麼難過。
葉一帆
- 遇到的困難和問題：遇到python tkinter 視覺化介面不提供日期控制元件
- 解決方法：只好妥協，用其他方式代替達到差不多的效果
- 吐槽：如果早知道會推遲時間，就做web服務了
何家健
- 遇到的困難和問題：一開始不知道具體用什麼演算法來解決有點手足無措。
- 解決方法：百度看了別人的演算法，再加上跟同學討論。
- 吐槽：演算法基本都大同小異。
黃海潮
- 遇到的困難和問題：設計抽獎演算法的時，不同人數和分等獎品的設計，演算法沒辦法全部適用。
- 解決方法：關於在qq和微信群的人數得出人數限制，考慮到演算法中重新解決設計。
- 吐槽：實際應用的演算法設計，時間不夠，考慮不夠周全。
王錦揚
- 遇到的困難和問題：海報以及原型的設計會考慮多種格式，在這方面挺糾結的。
- 解決方法：經過詳細討論最後選出確定的方案。
- 吐槽：如果能回到過去，那麼我不會選這課了。
鄭孔宇
- 遇到的困難和問題：如何使用python對資料探勘分析。
- 解決方法：百度一下啥都有。
- 吐槽：wordcloud這個庫有毒，下載後又說其他庫不行，單獨呼叫又可以，而且庫下載速度忒慢了，最後還沒完成附加功能2部分，只能淪落到寫部落格，我崩潰了。
俞凱欣
- 遇到的困難和問題：負責了做獲獎海報和抽獎介面的原型設計，圖片的解析度問題傳給前端不方便寫進GUI介面。
- 解決方法：用PS改了圖片解析度。
- 吐槽：如果時間再長一點，那麼可能做得更好！
林世傑
- 遇到的困難和問題：python不熟悉。
- 解決方法：百度啊。
- 吐槽：這個遊戲太秀了，直接從零開始學習py，語法一堆出錯。
九、個人部分
- 個人PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
| Planning | 計劃 | 40 | 45 |
| · Estimate | · 估計這個任務需要多少時間 | 40 | 45 |
| Development | 開發 | 380 | 450 |
| · Analysis | · 需求分析 (包括學習新技術) | 30 | 40 |
| · Design Spec | · 生成設計文件 | 0 | 0 |
| · Design Review | · 設計複審 (和同事稽核設計文件) | 0 | 0 |
| · Coding Standard | · 程式碼規範 (為目前的開發制定合適的規範) | 0 | 0 |
| · Design | · 具體設計 | 40 | 90 |
| · Coding | · 具體編碼 | 280 | 280 |
| · Code Review | · 程式碼複審 | ||
| · Test | · 測試（自我測試，修改程式碼，提交修改） | 30 | 40 |
| Reporting | 報告 | 40 | 55 |
| · Test Report | · 測試報告 | 20 | 30 |
| · Size Measurement | · 計算工作量 | 10 | 15 |
| · Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 10 | 10 |
| 合計 | 460 |
- 個人學習進度條
| 第N周 | 新增程式碼(行) | 累計程式碼(行) | 本週學習耗時(小時) | 累計學習耗時(小時) | 重要成長 |
| 8 | 300 | 300 | 8 | 8 | 微信小程式前端編寫 學習了map元件的使用 |
| 8 | 100 | 400 | 4 | 12 | 微信小程式前端編寫 瞭解到markers和callout的使用 |
| 8 | 50 | 450 | 3 | 15 | 初識echarts |