团队做业第六次—团队Github实战训练

时间  2019-11-09
标签 团队 第六 github 实战 训练 栏目 Git 繁體版
原文   原文链接

做业描述

课程 软件工程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 的提交日志截图

（三）程序运行截图

  • 一、设置活动管理
    html

  • 二、导入聊天记录
    前端

  • 三、运行结果
    python

（四）GUI界面

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

（五）基础功能实现

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

核心算法介绍：git

  • 一、活跃度计算。抽奖发言+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.3    0.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]。

此方法决定了奖项归属于那一部分人群（高活跃度或低活跃度），最后在这我的群中选择一位做为获奖者。github

（六）附加功能实现

  • 1.由中奖消息造成祝贺海报
    • 使用python pil库中的Image等属性，从获奖txt文件中分别读取获奖人员与奖项，最后打印在海报模板的相应位置
  • 2.对提供的聊天记录进行分析

    • 热度随月份变化的条形图，对聊天数据进行正则匹配，将统计完的数据存储到列表中，使用plt绘画出相应图形
      正则表达式

    • 热度在一天的时间段内变化图，分析聊天记录中有关小时的数据存入excel文件中，再由excel文件使用plt绘画出相应图形
      算法

    • 能够导入导出热度随时间断变化的excel文件，对excel文件进行分析
  • 3.生成词云
    • 导入python的jieba库进行中文分析，去除掉符号以及空白等无心义信息后将相应频率存入列表中，再根据python自带的wordcloud工具生成相应词云，但缺点是词语过滤的还不明显，还有图片以及“一个”这样无心义的词存在，后续能够继续改进。

经过对聊天记录的分析，能够看出该群一天中活跃度比较高的时间段是早晨九点多，晚上十一二点达到活跃度达到最高。从月份活跃度上也能够看出，在放假期间（二月与七八月）活跃度达到低点，开学后逐渐回升。从词云上也能够看到有四六级，考研，二手，电动车等与大学生密切相关的词语，由此也能够明显感觉到互联网大数据与咱们我的息息相关。express

（七）特点功能

  • 使用黑名单机制，活动更加为所欲为编程

  • 自定义奖励数目、名称、奖品、人数，一切尽在掌握c#

  • 使用活跃度计算抽奖资格。活跃度低于多少就丧失抽奖资格，并对于特殊身份以及恶意刷屏者都作了限制，例若有人之前正常发言，抽奖时恶意刷屏这样只会下降该活跃度而不是直接拉入黑名单。

  • 监测刷屏的淘汰算法。
    保留最近五次不重复发言的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
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程