作业描述
|||||||||
|:-|:-|
|课程：| 软件工程1916|W（福州大学) ||
|作业要求：|团队作业第六次—团队Github实战训练 ||
|团队名称：|火鸡堂||
|作业目标：|进行github实战训练，锻炼团队合作能力|
团队信息###
队名：火鸡堂####
队员信息：####
|||||||||||
|:-|:-|:-|:-|
|队伍学号|队员姓名|分工|队员贡献度占比|
|221600111|彼术向(组长) |前端、正则匹配|36%|
|221600136|墨染白衣颜|定时发布和写随笔|23%|
|221600137|海怪呦|文件上传和读取|21%|
|221600138|魔垣|随机数生成|20%|
作业正文###
一、开发程序####
0、github地址
https://github.com/Mookiepiece/live-project
1、github的提交日志截图
2、程序运行截图和GUI界面
3、程序运行环境
-WampServe上运行php
-程序尚未按需开发完成
二、基础功能及附加功能实现####
1.基础功能
- 随机数算法：这个部分老师要求是要尽量保证公平，并且不能使用太过简单的随机算法，但是因为组员的相关知识欠缺，无法很好的完善相关算法并且觉得普通的随机数Math.round(Math.random()*k)也是比较的公平，其各种数据产生的概率基本上是均匀的，故我们在这一部分并没有多大改进
- 文件通过php文件上传再回显到浏览器端使用JS处理，我们将文件中的数据先分开并存储在map中，结构是[key(user),value(msg){date,txt}],其中的user用来存储文件中的用户昵称，msg中的date用来存储对应的发言时间，而txt则是存储其发言内容。
- 已实现的过滤功能：过滤老师、过滤助教
2.附加功能
- 增加学生的命名规范判断：整个聊天的群中有很多的学生在老师的要求规范改名的情况下仍是命名不规范或者干脆不改，所以我们添加一个过滤掉命名不规范部分的人的参与抽奖的机会
**3.未实现功能
- 抽奖功能：getRandom中应有随机数算法，但截止时该模块未拼接
- 发布时间倒计时：ReaalseTime.php应接收表单/AJAX的时间参数与结果，实现一个动态页面
- 友好的交互界面
三、遇到的困难及解决方法####
（1）221600111 彼术向(组长）
- 遇到的困难：组员对于web并不熟悉，代码整合困难
- 解决方案：督促小组成员学习相关知识，帮助修改相关任务代码
- 遇到的困难：自己前端的文件上传表单写错了一个子母，这里给编写上传文件的队友带来了许多麻烦
- 解决方案：通过与网上的代码对比并排查错误
（2）221600136 墨染白衣颜 - 遇到的困难：获取表单时，text和按钮传递的属性为空的情况没有认真考虑;打算做时时刷新时，因为运行原因造成了死循环。
- 解决方案：判断所有的获取属性是否为NULL，是的话给一个参数0；取消while（）循环，只做一次Date比较。
（3）221600137 海怪呦
- 遇到的困难：在设计上传文件时考虑到文件的格式和命名问题，对上传文件进行重新命名时，得考虑到文件的重名替换以及文件的删除
- 解决方案：最后用了unlink删除以上传的文件，运用filename固定上传文件为upload.txt
（4）221600138 魔垣
- 遇到的困难：一个队友的代码中涉及了map相关的内容并不懂，js,php相关的知识部分薄弱，在编写时出现错误
- 解决方案：了解相关知识，查找相关资料，队友帮助
四、马后炮####
彼术向的吐槽：如果我的组员能够更给力一点，那么我能飞出银河系
墨染白衣颜的吐槽：
海怪呦的吐槽：
魔垣的吐槽：如果当初我能领略语言的美，那么我会将随机数做的很漂亮
五、PSP表格与效能分析####
1.221600111 彼术向(组长）
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 120 | 80 |
| • Estimate | • 估计这个任务需要多少时间 | 300 | 480 |
| Development | 开发 | 200 | 250 |
| • Analysis | • 需求分析 (包括学习新技术) | 30 | 20 |
| • Design Spec | • 生成设计文档 | ||
| • Design Review | • 设计复审 | ||
| • Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| • Design | • 具体设计 | 120 | 150 |
| • Coding | • 具体编码 | 120 | 150 |
| • Code Review | • 代码复审 | 0 | 0 |
| • Test | • 测试（自我测试，修改代码，提交修改） | 30 | 25 |
| Reporting | 报告 | 0 | 0 |
| • Test Report | • 测试报告 | ||
| • Size Measurement | • 计算工作量 | ||
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | ||
| 合计 | 940 | 1165 |
2.221600136 墨染白衣颜
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 120 | 100 |
| • Estimate | • 估计这个任务需要多少时间 | 300 | 270 |
| Development | 开发 | 200 | 250 |
| • Analysis | • 需求分析 (包括学习新技术) | 60 | 70 |
| • Design Spec | • 生成设计文档 | ||
| • Design Review | • 设计复审 | ||
| • Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| • Design | • 具体设计 | 120 | 150 |
| • Coding | • 具体编码 | 60 | 120 |
| • Code Review | • 代码复审 | 0 | 0 |
| • Test | • 测试（自我测试，修改代码，提交修改） | 60 | 50 |
| Reporting | 报告 | 0 | 0 |
| • Test Report | • 测试报告 | ||
| • Size Measurement | • 计算工作量 | ||
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | ||
| 合计 | 940 | 1020 |
3.221600137 海怪呦
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 90 | 60 |
| • Estimate | • 估计这个任务需要多少时间 | 300 | 450 |
| Development | 开发 | 120 | 150 |
| • Analysis | • 需求分析 (包括学习新技术) | 60 | 90 |
| • Design Spec | • 生成设计文档 | ||
| • Design Review | • 设计复审 | ||
| • Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 35 | 20 |
| • Design | • 具体设计 | 40 | 50 |
| • Coding | • 具体编码 | 100 | 120 |
| • Code Review | • 代码复审 | 20 | 30 |
| • Test | • 测试（自我测试，修改代码，提交修改） | 20 | 60 |
| Reporting | 报告 | 60 | 30 |
| • Test Report | • 测试报告 | ||
| • Size Measurement | • 计算工作量 | ||
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | ||
| 合计 | 845 | 1060 |
4.221600138 魔垣
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 20 |
| • Estimate | • 估计这个任务需要多少时间 | 300 | 270 |
| Development | 开发 | 200 | 250 |
| • Analysis | • 需求分析 (包括学习新技术) | 60 | 70 |
| • Design Spec | • 生成设计文档 | ||
| • Design Review | • 设计复审 | ||
| • Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| • Design | • 具体设计 | 120 | 150 |
| • Coding | • 具体编码 | 120 | 150 |
| • Code Review | • 代码复审 | 0 | 0 |
| • Test | • 测试（自我测试，修改代码，提交修改） | 30 | 25 |
| Reporting | 报告 | 0 | 0 |
| • Test Report | • 测试报告 | ||
| • Size Measurement | • 计算工作量 | ||
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | ||
| 合计 | 880 | 945 |
组长的反思####
一个下午努力过来，我们组的程序只实现了上传文件和提取用户的功能，完成度只有50%，而且功能不算很有特点
实验前一天我们有进行讨论，题目要求随机算法不能简单，但由于缺乏经验我们想不出特别的随机算法，虽然有提议让活跃度高的权重也高，但如何判断是不是灌水刷屏呢
由于我本人对web感兴趣所以提议的使用web程序，可是下午实际编码时，发现队友的相关知识没有掌握好，几乎现学现做的，开发效率极其低下，事实上我自己也没有贡献多少代码，虽然功能都十分简单，整个小组整个下午都在调试修Bug，代码规范都顾不上了
雪上加霜的是一名队友的笔记本还挂了
我还以为有余力还能写写css文件的，但小组能力实在有限，能和各位dalao们在一个班里学习真是莫大的荣幸