团队作业第六次—团队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 的提交日志截图

（三）程序运行截图

• 1、设置活动管理
  

• 2、导入聊天记录
  

• 3、运行结果
  

（四）GUI界面

• 1、进入抽奖界面，并导入聊天文件路径
  
• 2、开始抽奖活动，管理员需要设置抽奖关键词、开始结束时间、文案、奖品相应信息、添加黑名单人员（恶意刷屏或机器号会自动进入）、选择过滤机制（不过滤、普通过滤、深度过滤），最后按下提交键开始抽奖
  
• 3、生成抽奖结果，界面显示抽奖关键词以及开始结束时间，管理员选择生成后列表上出现本次抽奖的关键词、中奖id与昵称，奖励名称与奖品信息
  

（五）基础功能实现

• 不过滤模式：剔除机器，所有参与抽奖的人，都纳入开奖范围。
• 普通模式：筛除只参与抽奖而无发表任何原创言论的用户（抽奖机器人），鼓励大家积极参与有意义的发言。
• 深度模式：为了使发言更有意义，减少灌水，对以下用户的中奖概率进行降权处理，只参与抽奖而无发表任何原创言论（抽奖机器人），只参与抽奖且只发送表情（水军）

核心算法介绍：

• 1、活跃度计算。抽奖发言+1，平时发言+2，刷屏发言（重复发一句话次数）>20时-50（修改身份=预警者），随后每重复一次-3，>100时-1008611（修改身份=危险者）。学生初始活跃=0；助教老师初始活跃-1008611；活跃度<1500000后不再减少（防止溢出）
• 2、抽奖机制：活动参与人员名单下 所有活跃度>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
• 3、抽奖算法参考了这篇博客提到的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

转载于:https://www.cnblogs.com/xxxiu/p/10750118.html