團隊做業第六次—團隊Github實戰訓練

做業描述

課程	軟件工程1916|W(福州大學)
團隊名稱	修！咻咻！
做業要求	團隊做業第六次—團隊Github實戰訓練
團隊目標	搭建一個相對公平公正的抽獎系統，根據QQ聊天記錄，完成從統計參與抽獎人員頒佈抽獎結果的基本流程。
git項目	https://github.com/huangquanhuan/live-project
開發工具	Vistual Studio

團隊信息

隊員學號	隊員姓名	我的博客地址	git地址
221600126	劉忠燏	http://www.cnblogs.com/Downstream-1998/	https://github.com/Downstream1998
221600207	黃權煥	https://www.cnblogs.com/hyry/	https://github.com/huangquanhuan
221600328	蘇明輝	https://www.cnblogs.com/ahuigg/	https://github.com/398315418
221600330	吳可強	https://www.cnblogs.com/masgak/	https://github.com/masgak
221600331	向鵬	https://www.cnblogs.com/xiang-peng/	https://github.com/Snug-XP

做業正文

（一）組員分工和工做量比例

隊員學號	隊員姓名	分工	貢獻度
221600126	劉忠燏	對數據的結構化處理，編寫活動類和活動管理類	20
221600207	黃權煥	圖形界面編輯，獎勵類的編寫，全部類與頁面的交互和最終成品的調試改bug	22
221600328	蘇明輝	編寫博客，抽獎類的編寫	18
221600330	吳可強	附加做業的編寫,博客編寫	19
221600331	向鵬	人員類、管理人員類的編寫，抽獎類的修正，最終成品的調試改bug	21

（二）github 的提交日誌截圖

（三）程序運行截圖

• 一、設置活動管理
  

• 二、導入聊天記錄
  

• 三、運行結果
  

（四）GUI界面

• 一、進入抽獎界面，並導入聊天文件路徑
  
• 二、開始抽獎活動，管理員須要設置抽獎關鍵詞、開始結束時間、文案、獎品相應信息、添加黑名單人員（惡意刷屏或機器號會自動進入）、選擇過濾機制（不過濾、普經過濾、深度過濾），最後按下提交鍵開始抽獎
  
• 三、生成抽獎結果，界面顯示抽獎關鍵詞以及開始結束時間，管理員選擇生成後列表上出現本次抽獎的關鍵詞、中獎id與暱稱，獎勵名稱與獎品信息
  

（五）基礎功能實現

• 不過濾模式：剔除機器，全部參與抽獎的人，都歸入開獎範圍。
• 普通模式：篩除只參與抽獎而無發表任何原創言論的用戶（抽獎機器人），鼓勵你們積極參與有意義的發言。
• 深度模式：爲了使發言更有意義，減小灌水，對如下用戶的中獎機率進行降權處理，只參與抽獎而無發表任何原創言論（抽獎機器人），只參與抽獎且只發送表情（水軍）

核心算法介紹：

• 一、活躍度計算。抽獎發言+1，平時發言+2，刷屏發言（重複發一句話次數）>20時-50（修改身份=預警者），隨後每重複一次-3，>100時-1008611（修改身份=危險者）。學生初始活躍=0；助教老師初始活躍-1008611；活躍度<1500000後再也不減小（防止溢出）
• 二、抽獎機制：活動參與人員名單下 全部活躍度>0的人員進行排序。按2：3：5的比例分紅三個層次：A B C。每一次決定抽獎人員時，按照5：3：2的機率決定實在A B C三個層中哪一個層進行抽取，決定抽取層次後按隨機數mod 層人數決定抽獎者下標。抽獎方式有如下好處：
  (一)：50%的中獎用戶爲高活躍人士。
  (二)各層中獎機率爲：
  A 0.20.5 = 0.1
  B 0.30.3 = 0.09
  C 0.5*0.2 = 0.1
• 三、抽獎算法參考了這篇博客提到的Alias Method，將全部事件拼湊成爲一個方形，從方形圖片中能夠獲得兩個數組：
  
  Prob: [3/4, 1/4, 1/2, 1/4, 1]
  Alias: [4, 4, 0, 1, null] (記錄非原色的下標)
  以後就根據Prob和Alias獲取其中一個物品
  隨機產生一列C，再隨機產生一個數R，經過與Prob[C]比較，R較大則返回C，反之返回Alias[C]。

此方法決定了獎項歸屬於那一部分人羣（高活躍度或低活躍度），最後在這我的羣中選擇一位做爲獲獎者。

（六）附加功能實現

• 1.由中獎消息造成祝賀海報
  • 使用python pil庫中的Image等屬性，從獲獎txt文件中分別讀取獲獎人員與獎項，最後打印在海報模板的相應位置
    
• 2.對提供的聊天記錄進行分析

  • 熱度隨月份變化的條形圖，對聊天數據進行正則匹配，將統計完的數據存儲到列表中，使用plt繪畫出相應圖形
    

  • 熱度在一天的時間段內變化圖，分析聊天記錄中有關小時的數據存入excel文件中，再由excel文件使用plt繪畫出相應圖形
    

  • 能夠導入導出熱度隨時間斷變化的excel文件，對excel文件進行分析
    
• 3.生成詞雲
  • 導入python的jieba庫進行中文分析，去除掉符號以及空白等無心義信息後將相應頻率存入列表中，再根據python自帶的wordcloud工具生成相應詞雲，但缺點是詞語過濾的還不明顯，還有圖片以及「一個」這樣無心義的詞存在，後續能夠繼續改進。
    

經過對聊天記錄的分析，能夠看出該羣一天中活躍度比較高的時間段是早晨九點多，晚上十一二點達到活躍度達到最高。從月份活躍度上也能夠看出，在放假期間（二月與七八月）活躍度達到低點，開學後逐漸回升。從詞雲上也能夠看到有四六級，考研，二手，電動車等與大學生密切相關的詞語，由此也能夠明顯感覺到互聯網大數據與咱們我的息息相關。

（七）特點功能

• 使用黑名單機制，活動更加爲所欲爲

• 自定義獎勵數目、名稱、獎品、人數，一切盡在掌握

• 使用活躍度計算抽獎資格。活躍度低於多少就喪失抽獎資格，並對於特殊身份以及惡意刷屏者都作了限制，例若有人之前正常發言，抽獎時惡意刷屏這樣只會下降該活躍度而不是直接拉入黑名單。

• 監測刷屏的淘汰算法。
  保留最近五次不重複發言的hashcode值爲<鍵，值>數組a。初始Map a[5] = {-1,-1};新發言的值進行兩次數組遍歷。第一次遍歷：監測hashcode是否重複，若重複將hashcode對應值+1，若不然進入第二次循環：監測是否有空位置,如有則插入，若無則將遍歷到的最後一個位置(（進入位置-1）mod 5)進行數據替換。使用靜態變量保留每次最新訪問的下標，且逢5歸0。值知足條件時按算法一進行處理。

（八）遇到的困難及解決方法

劉忠燏

• 正則表達式編寫
  我在團隊裏的工做有一個內容就是負責解析聊天記錄，然而就如一個笑話裏說的：「我有一個問題，我決定用正則表達式解決，如今我有兩個問題了」。可是聊天記錄這種信息，是有很明顯的格式的，因而沒轍，只能在 MSDN 上翻 .NET 裏有關正則表達式的文檔，並照着這個示例去學習了大概一兩個小時，勉強寫出了匹配消息頭部分的正則表達式，然而匹配抽獎關鍵詞的正則表達式我仍是沒有頭緒，最後在這篇博客中找到了答案。不過我仍是不能理解爲何這樣能夠匹配，還望有人能解釋一下

Regex KeywordRegex = new Regex(
    @"#(?<code>[^\\#|.]+)#",
    RegexOptions.Compiled,
    TimeSpan.FromMilliseconds(200)
);

• 撰寫註釋
  也不知道是什麼緣由，我在寫註釋的時候發現本身很容易詞窮（我知道我寫的這個方法作了什麼，但我就是沒法表示出來）。多是我平時註釋寫得太少吧，目前只能是硬着頭皮把註釋寫完，同時和交接代碼的同窗交待清楚我所寫的一些功能。（有沒有什麼資料講怎麼寫註釋的😂）

蘇明輝

• 時間不足，在算法和測試上可能還存在一些bug
• 對git的不熟練，這個理應在早些階段就熟練掌握，然而我在使用時仍然出了些問題，浪費了時間
• 對C#語言的不熟悉，由於團隊使用的是C#，以前我沒有選修這門課，因此在語言的熟悉上也花了些時間
• 隊員之間代碼的相互銜接，在兩個關聯類之間的方法和變量處銜接沒作好，應該在設計初畫好類圖，討論好每個屬性和方法，真的頗有必要。
• 解決方法
  時間不夠，熬夜來湊，前期商量好一些變量和方法十分重要，對類圖必定不能忽視，以前聽老師說過他們以前作的一個題目，花了大量時間在前期的需求及準備工做上，然而最後作出來的總時間反而比其餘隊要來得短，當時還心存疑惑，如今着實體驗了一下，前期工做不能忽視。

吳可強

• 對vs以及git操做不熟悉
  因爲平時不多使用git與vs編程，在同步與拉取遠程倉庫時常常失敗並且根本不知道問題出在哪裏，再加上沒有學習過c#,對相關操做不熟悉，編寫相應列表與類時，在無限循環的嘗試過程當中浪費了大量時間。

• python中文件格式錯誤
  由於只要掌握了pil的使用，製做相應海報應該是很容易的事情。可是控制檯時不時爆出的 Non-UTF-8 code starting with '\xbd' in file 錯誤確實讓人頭大。畫圖與打印海報也會出現中文亂碼問題，之前不多對文本進行操做因此這種問題仍是第一次碰到，嘗試了開頭加上 # -- coding:utf-8 --與gbk的聲明，以及使用特定的編碼方式打開，但都不行。
  對python不經常使用庫不瞭解，例如jieba、imageio等，只知道中文分隔須要這個東西，但不知道爲何須要，也不知道工做原理是什麼。以致於真正須要使用時無法直接拿來用，而是用了其餘更復雜效率更低的方法。
  - 解決方法
  多找資料和git手冊，熟悉使用vs對git進行操做，並向隊友學習了好幾回。
  最後發現亂碼並非編碼問題，而是因爲使用了外國字體，文字打印上去時字體出錯。更改了文件編碼方式與中文字體才解決問題。
  參考官方源碼以及其餘人的博客介紹，瞭解它包括哪些函數與函數的做用，弄明白了才知道怎麼用

黃權煥

• 需求階段：前期只作了大體類圖，說明了類須要什麼屬性和什麼函數，但沒有對接口和調用採起嚴格約束，致使發現真正編碼時須要GUI去各類調用類的方法，鏈接代碼至關混亂，進過一些簡單重構也難以徹底改善。這種混亂致使的時間延長甚至超過了我我的熬夜作好前端界面和對算法的概括描述。原覺得最難是算法，後來發現基礎編程也有至關多的坑難以免，好比git,實際上咱們一開始甚至浪費了近一個小時在git和開發工具的相關配置上，數據處理也由於基礎類很難到帳而出現漫長拖延。近乎致鬱，下降了調度和把控能力。
• 開發階段：我我的完成了大部分的前端對各類類的連接轉換，但我發現不少代碼由於時間關係提供的接口並不合理，他人代碼冗餘而難懂，但我並不能一一去強行修正。前端控件的配置與操做已不佔用一下午開發時間的狀況下，咱們還算很難完成這個項目。只能說明前期準備依舊不足，太過關注於細節。
• 解決問題：我我的還算以爲要增強前期準備，好比咱們討論得出的三個難點算法，我分別給出了文檔式的解決算法描述，這幫助咱們在編程三個函數感到了十分輕鬆。這讓我想到：若是咱們能以僞代碼的方式去提早進行程序預演，相信能減小不少開發時間。

向鵬

• 雖然前期花了大量時間進行討論設計，可是實現有時仍是和隊友有一些設計想法不同，致使不少地方實現後就對接不上，刪刪改改，還超級浪費時間。解決方法：估計就是要多磨練，慢慢學會在前期討論設計要掌握好方法和粒度。

（九）馬後炮

黃權煥：若是時間長一點，那麼我還有不少idea能夠實現呢
劉忠燏：若是咱們在進機房前，把準備工做作得再充分一點，那麼就不會把時間浪費在配置環境上，編寫類的時候也不會出現功能模糊不清的狀況。
蘇明輝：若是時間能再多一點協調溝通，那麼咱們將作得更好。
向鵬：若是能拿到相關教程，學習一段時間，那麼咱們就不會感受很慌張
吳可強：若是我能力強一些，那麼個人團隊就能夠更快更完美的完成這項項目。

（十）PSP表格

1.黃權煥

PSP2.1	Pesonal SoftWare Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	30	40
Estimate	估計這個任務須要多少時間	10	10
Development	開發	60	120
Analysis	需求分析（包括學習新技術）	120	130
Design Spec	生成設計文檔	30	40
Design Review	設計複審	20	30
Coding Standard	代碼規範（爲目前的開發制定合適的規範）	0	0
Design	具體設計	230	300
Coding	具體編碼	450	600
Code Review	代碼複審	0	0
Test	測試（自我測試，修改代碼，提交修改）	60	70
Reporting	報告	100	120
Test Report	測試報告	20	25
Size Measurement	計算工做量	10	10
Postmortem&Process Improvement Plan	過後總結，並提出過程改進計劃	30	30
	合計	1180	1525

2.劉忠燏

PSP2.1	Pesonal SoftWare Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	20	30
Estimate	估計這個任務須要多少時間	20	30
Development	開發	700	760
Analysis	需求分析（包括學習新技術）	40	100
Design Spec	生成設計文檔	20
Design Review	設計複審	20	20
Coding Standard	代碼規範（爲目前的開發制定合適的規範）	10
Design	具體設計	50
Coding	具體編碼	500	555
Code Review	代碼複審	30	15
Test	測試（自我測試，修改代碼，提交修改）	30	70
Reporting	報告	35	45
Test Report	測試報告	10	10
Size Measurement	計算工做量	15	15
Postmortem&Process Improvement Plan	過後總結，並提出過程改進計劃	10	20
	合計	760	810

3.蘇明輝

PSP2.1	Pesonal SoftWare Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	60	100
Estimate	估計這個任務須要多少時間	10	10
Development	開發	200	210
Analysis	需求分析（包括學習新技術）	120	130
Design Spec	生成設計文檔	30	40
Design Review	設計複審	20	30
Coding Standard	代碼規範（爲目前的開發制定合適的規範）	0	0
Design	具體設計	220	360
Coding	具體編碼	200	200
Code Review	代碼複審	0	0
Test	測試（自我測試，修改代碼，提交修改）	60	70
Reporting	報告	100	120
Test Report	測試報告	20	25
Size Measurement	計算工做量	10	10
Postmortem&Process Improvement Plan	過後總結，並提出過程改進計劃	30	30
	合計	1080	1325

4.向鵬

PSP2.1	Pesonal SoftWare Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	120	170
Estimate	估計這個任務須要多少時間	10	10
Development	開發
Analysis	需求分析（包括學習新技術）	120	130
Design Spec	生成設計文檔	30	40
Design Review	設計複審	20	40
Coding Standard	代碼規範（爲目前的開發制定合適的規範）	0	0
Design	具體設計	160	200
Coding	具體編碼	450	550
Code Review	代碼複審	0	0
Test	測試（自我測試，修改代碼，提交修改）	20	30
Reporting	報告	30	40
Test Report	測試報告	20	25
Size Measurement	計算工做量	10	10
Postmortem&Process Improvement Plan	過後總結，並提出過程改進計劃	30	30
	合計	1170	1275

5.吳可強

PSP2.1	Pesonal SoftWare Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	30	40
Estimate	估計這個任務須要多少時間	10	10
Development	開發
Analysis	需求分析（包括學習新技術）	120	130
Design Spec	生成設計文檔	30	40
Design Review	設計複審	20	30
Coding Standard	代碼規範（爲目前的開發制定合適的規範）	0	0
Design	具體設計	420	560
Coding	具體編碼	300	320
Code Review	代碼複審	0	0
Test	測試（自我測試，修改代碼，提交修改）	60	70
Reporting	報告	100	120
Test Report	測試報告	20	25
Size Measurement	計算工做量	10	10
Postmortem&Process Improvement Plan	過後總結，並提出過程改進計劃	30	30
	合計	1150	1385