团队Github实战训练
| 这个作业属于哪个课程 | 点击前往 |
|---|---|
| 这个作业的要求在哪里 | 点击前往 |
| 团队名称 | RATE-MAX |
| 这个作业的目标 | 开发一个向社会限量供应的口罩应用 |
| 作业正文 | .... |
| 其他参考文献 |
第一部分：本次实训
组员职责分工
前端：林海峰、林露、陈如滨
后端：陈炀、黄筱宇、李波、黄毅、洪楷滨
github 的提交日志截图（鼓励小粒度提交），统计各组员的commit次数
由于github在九点项目即将完工之际被我一顿操作导致大量地commit变成一下这样
程序运行截图
程序运行环境（方便助教进行测试。如果是web服务最好了，如果是桌面程序，建议使用GitHub的"Releases"发布程序包，参考这里（https://blog.csdn.net/Eggy2015/article/details/52138751）
GUI界面
基础功能实现
基础设计
基本实现了基础的功能，只是在九点的时候的一次merge pr中出现了情况，导致项目需要重新整合。基本功能实现都好了，但是由于我的错误的github操作，导致项目目前还在整合文件。
附加功能实现
鼓励有想法且有用的功能
我们会尽可能把程序代码重新组装好。
用户体验，操作的方便、快捷性
一般般
具体分工
前端： 林海峰、林露、陈如滨
后端：市民预约部分 陈炀
管理员部分 黄筱宇 黄毅
系统部分 李波 洪楷滨
遇到的困难及解决方法
-
洪楷滨
个人对团队的把控不够，不熟悉团队开发的流程和不能熟练使用github，在九点项目即将完工的情况下，由于我错误地操作，导致merge pr时整体项目缺少了大量的文件夹，感觉内心非常难过，队友努力了一天的成果，就这样被我一个无意的操作所毁掉，还有就是对组员的分工及中间一些流程的协作缺少大量经验，导致团队出现大量的冲突及代码的重复。我认为这次任务的失败我有主要的责任。
解决：就最接近的版本进行push。但是仍有许多冲突，尽可能地还原原本地情况。 -
陈炀
遇到的困难
不得不说人一多遇到的困难旧的多了起来,一个是分析阶段容易出现意见的分歧导致开发进度的减慢,第二个就是每个人的一件无法有效的整合在一起导致设计的冲突
还有就是由于虽然每个人都分了模块但是由于有些模块需要用到别人的模块,导致开发进度的减缓
github是用不熟练导致的版本管理混乱,结对作业的时候由于只有两个人还能通过一些方法解决,但是人一多就很难解决.
不是到是不是因为在家里的原因,github方法实在是有点慢,或者说eclipse的git用不熟练老是出现push rejected的情况
再没有练习过的情况下,团队开发的难度确实很大,这也应该是就是程序员的核心竞争力吧. -
黄毅
人一多遇到的问题格外的多，也格外的复杂，不同的数据库版本，不同的代码编程风格，彼此之间不够熟悉，总有一些无法有效的将大家一起凝聚力量一同编写的方法，时长出现在别人电脑上正常的程序在自己这边抛出异常，内心非常难过。
-
李波
不懂得如何进行组队作业，并且在web开发方面欠缺经验。跟队友不断讨论、不断分析，慢慢地融入了作业环境，在开发过程中边开发，边查资料。
-
林露
遇到的困难以及解决办法
对git的使用不是很熟悉，在队长汇总了dev分支的所以内容后，我clone了不下五次。。前几次打开只有自己写的部分代码（后来发现不小心clone成队长的链接=.=），后面一次就是项目不再是web工程。。我好难，重新clone了一下就可以了。
另外就是对jsp不是很熟悉，靠百度找到了解决办法。 -
陈如滨
在做管理员设置预约时间段时遇到困难，在网上学习了DatePicker的使用，做出了可以选择日期、时间而非手动输入的界面。在jsp中读取数据库时也遇到了困难，后来百度了一下解决了。
-
林海峰
难题：采用的构建方式基本不熟悉
解决：在有限的时间里，去花费宝贵的时间去学习并试错的话风险过大。于是在分工时尽自己所能选择可以完成的任务去，避免影响整体进度。 -
黄筱宇
难题：主要是github的使用的不熟练，碰到了很多问题，包括pull upstream发生错误、push upstream发生冲突等问题。
解决：通过上网搜索相关内容以及和队友的沟通，算是更加熟练掌握了github的团队协作。
评估每位组员的贡献比例，总分100
| 学号 | 贡献度 |
|---|---|
| 221701123 | 5 |
| 221701101 | 13 |
| 221701108 | 13 |
| 221701120 | 13 |
| 221701122 | 14 |
| 221701133 | 13 |
| 221701139 | 15 |
| 221701202 | 13 |
PSP表格（每名组员一个表格，发布在团队博客中）
- 洪楷滨
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 60 | 90 |
| Estimate | 估计这个任务需要多少时间 | 600 | 650 |
| Development | 开发 | 500 | 520 |
| Analysis | 需求分析 (包括学习新技术) | 10 | 0 |
| Design Spec | 生成设计文档 | 30 | 40 |
| Design Review | 设计复审 | 10 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 60 | 60 |
| Coding | 具体编码 | 400 | 420 |
| Code Review | 代码复审 | 10 | 10 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 25 |
| Reporting | 报告 | 20 | 30 |
| Test Report | 测试报告 | 20 | 20 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 580 | 700 |
- 陈炀
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 60 | 90 |
| Estimate | 估计这个任务需要多少时间 | 600 | 650 |
| Development | 开发 | 500 | 550 |
| Analysis | 需求分析 (包括学习新技术) | 10 | 0 |
| Design Spec | 生成设计文档 | 30 | 60 |
| Design Review | 设计复审 | 10 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 60 | 60 |
| Coding | 具体编码 | 400 | 400 |
| Code Review | 代码复审 | 10 | 10 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 30 |
| Reporting | 报告 | 20 | 20 |
| Test Report | 测试报告 | 20 | 20 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 580 | 660 |
- 黄毅
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 60 | 90 |
| Estimate | 估计这个任务需要多少时间 | 600 | 650 |
| Development | 开发 | 500 | 850 |
| Analysis | 需求分析 (包括学习新技术) | 10 | 0 |
| Design Spec | 生成设计文档 | 30 | 60 |
| Design Review | 设计复审 | 10 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 60 | 100 |
| Coding | 具体编码 | 400 | 440 |
| Code Review | 代码复审 | 10 | 220 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 40 |
| Reporting | 报告 | 20 | 20 |
| Test Report | 测试报告 | 20 | 20 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 580 | 660 |
-
李波
> PSP2.1 Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟） Planning 计划 30 37 Estimate 估计这个任务需要多少时间 740 717 Development 开发 250 243 Analysis 需求分析 (包括学习新技术) 30 42 Design Spec 生成设计文档 20 26 Design Review 设计复审 20 17 Coding Standard 代码规范 (为目前的开发制定合适的规范) 20 18 Design 具体设计 30 42 Coding 具体编码 120 119 Code Review 代码复审 40 34 Test 测试（自我测试，修改代码，提交修改） 60 48 Reporting 报告 20 17 Test Repor 测试报告 20 16 Size Measurement 计算工作量 30 24 Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 50 43 合计 1480 1453 -
林露
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 15 | 15 |
| Estimate | 估计这个任务需要多少时间 | 15 | 15 |
| Development | 开发 | 430 | 430 |
| Analysis | 需求分析 (包括学习新技术) | 30 | 50 |
| Design Spec | 生成设计文档 | 60 | 50 |
| Design Review | 设计复审 | 20 | 20 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| Design | 具体设计 | 120 | 100 |
| Coding | 具体编码 | 120 | 135 |
| Code Review | 代码复审 | 30 | 20 |
| Test | 测试（自我测试，修改代码，提交修改） | 60 | 45 |
| Reporting | 报告 | 70 | 60 |
| Test Report | 测试报告 | 30 | 25 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 15 |
| 合计 | 515 | 505 |
- 陈如滨
| PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
|---|---|---|---|
| Planning | 计划 | 20 | 15 |
| -Estimate | 估计这个任务需要多少时间 | 20 | 15 |
| Development | 开发 | 425 | 495 |
| -Analysis | 需求分析 (包括学习新技术) | 20 | 30 |
| -Design Spec | 生成设计文档 | 30 | 25 |
| -Design Review | 设计复审 | 15 | 20 |
| -Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| -Design | 具体设计 | 60 | 70 |
| -Coding | 具体编码 | 180 | 200 |
| -Code Review | 代码复审 | 60 | 80 |
| -Test | 测试（自我测试，修改代码，提交修改） | 60 | 70 |
| Reporting | 报告 | 150 | 125 |
| -Test Report | 测试报告 | 60 | 45 |
| -Size Measurement | 计算工作量 | 30 | 25 |
| -Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 60 | 55 |
| 合计 | 595 | 635 |
- 林海峰
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| Estimate | 估计这个任务需要多少时间 | 10 | 15 |
| Development | 开发 | 360 | 465 |
| Analysis | 需求分析 (包括学习新技术) | 70 | 80 |
| Design Spec | 生成设计文档 | 60 | 90 |
| Design Review | 设计复审 | 40 | 45 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 15 |
| Design | 具体设计 | 60 | 90 |
| Coding | 具体编码 | 120 | 110 |
| Code Review | 代码复审 | 30 | 15 |
| Test | 测试（自我测试，修改代码，提交修改） | 15 | 20 |
| Reporting | 报告 | 40 | 40 |
| Size Measurement | 计算工作量 | 20 | 15 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 25 |
| 合计 | 410 | 520 |
- 黄筱宇
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 30 |
| Estimate | 估计这个任务需要多少时间 | 20 | 30 |
| Development | 开发 | 460 | 470 |
| Analysis | 需求分析 (包括学习新技术) | 60 | 60 |
| Design Spec | 生成设计文档 | 30 | 20 |
| Design Review | 设计复审 | 30 | 25 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 20 |
| Coding | 具体编码 | 240 | 300 |
| Code Review | 代码复审 | 30 | 15 |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 20 |
| Reporting | 报告 | 45 | 40 |
| Test Report | 测试报告 | 20 | 20 |
| Size Measurement | 计算工作量 | 10 | 5 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 15 | 15 |
| 合计 | 525 | 540 |
随笔的第二部分如下
团队选题展示过程中，老师和同学提出了一些问题。有没有哪个问题你们想重新回答？
-
1、敏感信息是否屏蔽？
后端会使用相关的敏感词屏蔽api。对于聊天和名字的命名等各处会有。 -
2、qq邮箱原来有漂流瓶，后面推出市场，有分析过原因吗？
qq漂流瓶退出市场的原因很大程度上是信息的延时性，造成用户的流失，所以我们将漂流瓶的功能作为部分功能。 -
3、如何防止用户发表不法言论？
设有举报机制，用户之间直接相互监督，后台加强管理防止用户发表不法言论。 -
4、如何防止骚扰信息、广告信息？
会对广告信息进行限制，并进行封号。 -
5、同一个人多次发言会变成不同命名吗？
不会，始终统一。但是用户可以自行修改自己的昵称，改变自己的昵称后过往的发言署名不会改变。 -
6、系统如何保证用户隐私的安全？
软件本身实行匿名制度，在创建账号时没有包含太多个人信息（一个手机号即可），每周清空一次的机制从一定程度上也使得不会有用户的太多信息渗透到平台上被人获取。 -
7、是不是可以理解为任何言论可以不负责任？
不是，网络不是法外之地，本产品本身是为了提供一个释放自我以身心放松的场所，并不是倾泻恶意与污秽的地方。 -
8、如何防止恶意举报？阅后即焚？
对于举报信息，在程序的自动审查基础上加上人工审查。 -
9、加强管理？人工还是自动？人工的话一旦用户量增加，可能吗？自动的话，计划考虑自然语言处理吗？
在管理上将会使用自然语言处理工具，然后人工审查辅助甄别。 -
10、后台可以看到所有的信息吗？
可以从数据库中提取出来显示，主要是为了对不良言论进行处理或者是用于警方的侦破使用。 -
11、有考虑不是单纯的清空，而是存储被检举的内容留作证据吗？
服务器方面存储起来，但是用户方面是清空状态（即仅有后台可查阅）。
在上次团队选题之后，你们组有什么新的思考和想法？
-
1.发言的内容格式是应该只有文字？还是可以语音或视频，乃至图片？
按理说，仅仅局限于文字可能会有些枯燥，但是如果有语音或者视频的话又往往会打破匿名带来的神秘感，所以我们考虑进行折中。一方面是保持文字的对话方式，一方面内置表情包供用户使用。 -
2.是否需要在app中内嵌休闲小游戏（如2048、盖楼大作战），以陶冶情操并一定程度上让用户可以更容易放下生活负担？
-
3.虽然用户对我们这类产品的需求总是源源不断的，但是我们又应该怎么去抓住用户的心，让他们始终会记得我们这一款产品并第一时间想到然后使用呢？
参考支付宝的蚂蚁森林，我们将推出定时收取“心声”的功能。 -
4.收益与激发用户依赖性。
听人家吐槽一次，别人觉得你对她确实有帮助点赞的话，可以给予积分或送上鲜花。（积分源于登录获取，鲜花源于充值，收到的鲜花可以拿去按一定比例兑换成现金）