快乐就队——团队Github实战训练
| 这个作业属于哪个课程 | 2020春IW班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第二次—团队Github实战训练 |
| 团队名称 | 快乐就队 |
| 这个作业的目标 | 团队合作开发一个口罩预约程序 |
| 作业正文 | 快乐就队——团队Github实战训练 |
| 其他参考文献 | ... |
组员职责分工
| 学号 | 职责分工 |
|---|---|
| 221701223 | 实现一部分DAO类方法，撰写团队博客 |
| 221701339 | 实现后台与GUI的数据交互，参与GUI和数据库设计 |
| 221701220 | 数据库设计，编写DAO接口和pojo类 |
| 221701102 | GUI界面布局设计和编写 |
| 221701233 | 实现一部分DAO类方法，参与运行测试，撰写运行指南 |
| 221701232 | 实现一部分DAO类方法，参与数据库设计 |
| 221701234 | 实现Service类 |
| 221701327 | ... |
GitHub commit
| 学号 | commit次数 |
|---|---|
| 221701339 | 19 |
| 221701233 | 6 |
| 221701223 | 6 |
| 221701102 | 4 |
| 221701234 | 4 |
| 221701220 | 4 |
| 221701232 | 3 |
贡献度表格
| 学号 | 贡献度 |
|---|---|
| 221701339 | 17 |
| 221701220 | 17 |
| 221701102 | 15 |
| 221701233 | 16 |
| 221701232 | 10 |
| 221701234 | 13 |
| 221701223 | 11 |
| 221701327 | 1 |
程序运行截图
程序运行环境
PSP表格
221701223 叶博宁
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 10 |
| Estimate | 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | 165 | 200 |
| Analysis | 需求分析 (包括学习新技术) | 60 | 60 |
| Design Spec | 生成设计文档 | 10 | 10 |
| Design Review | 设计复审 | 10 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 5 | 5 |
| Design | 具体设计 | 20 | 20 |
| Coding | 具体编码 | 30 | 50 |
| Code Review | 代码复审 | 10 | 15 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 30 |
| Reporting | 报告 | 45 | 60 |
| Test Report | 测试报告 | 15 | 15 |
| Size Measurement | 计算工作量 | 10 | 15 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 30 |
| 合计 | 220 | 270 |
221701339 沈志峰
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 10 |
| Estimate | 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | 255 | 305 |
| Analysis | 需求分析 (包括学习新技术) | 60 | 60 |
| Design Spec | 生成设计文档 | 10 | 10 |
| Design Review | 设计复审 | 10 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 5 | 5 |
| Design | 具体设计 | 20 | 30 |
| Coding | 具体编码 | 100 | 120 |
| Code Review | 代码复审 | 30 | 40 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 30 |
| Reporting | 报告 | 40 | 40 |
| Test Report | 测试报告 | 15 | 15 |
| Size Measurement | 计算工作量 | 10 | 15 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 15 | 10 |
| 合计 | 305 | 355 |
221701102 郑澜
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 10 |
| Estimate | 估计这个任务需要多少时间 | 30 | 10 |
| Development | 开发 | 350 | 380 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 30 | 20 |
| Design Review | 设计复审 | 30 | 20 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 60 | 30 |
| Coding | 具体编码 | 180 | 240 |
| Code Review | 代码复审 | 10 | 20 |
| Test | 测试（自我测试，修改代码，提交修改） | 10 | 20 |
| Reporting | 报告 | 80 | 60 |
| Test Repor | 测试报告 | 30 | 20 |
| Size Measurement | 计算工作量 | 20 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 20 |
| 合计 | 460 | 450 |
221701220 赵伟男
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 40 | 60 |
| Estimate | 估计这个任务需要多少时间 | 40 | 60 |
| Development | 开发 | 390 | 388 |
| Analysis | 需求分析 (包括学习新技术) | 10 | 8 |
| Design Spec | 生成设计文档 | 30 | 20 |
| Design Review | 设计复审 | 10 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| Design | 具体设计 | 60 | 65 |
| Coding | 具体编码 | 180 | 180 |
| Code Review | 代码复审 | 10 | 15 |
| Test | 测试（自我测试，修改代码，提交修改） | 90 | 90 |
| Reporting | 报告 | 10 | 15 |
| Test Report | 测试报告 | 0 | 0 |
| Size Measurement | 计算工作量 | 0 | 0 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 10 | 15 |
| 合计 | 440 | 463 |
221701233 张一凡
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 45 |
| Estimate | 估计这个任务需要多少时间 | 20 | 45 |
| Development | 开发 | 390 | 366 |
| Analysis | 需求分析 (包括学习新技术) | 120 | 100 |
| Design Spec | 生成设计文档 | 100 | 30 |
| Design Review | 设计复审 | 60 | 40 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| Design | 具体设计 | 60 | 60 |
| Coding | 具体编码 | 60 | 50 |
| Code Review | 代码复审 | 30 | 26 |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 30 |
| Reporting | 报告 | 60 | 60 |
| Test Report | 测试报告 | 30 | 30 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 470 | 471 |
221701234 张必润
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计这个任务需要多少时间 | 420 | 480 |
| Development | 开发 | 160 | 180 |
| Analysis | 需求分析 (包括学习新技术) | 40 | 50 |
| Design Spec | 生成设计文档 | 30 | 40 |
| Design Review | 设计复审 | 20 | 20 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 5 | 5 |
| Design | 具体设计 | 20 | 30 |
| Coding | 具体编码 | 45 | 50 |
| Code Review | 代码复审 | 15 | 20 |
| Test | 测试（自我测试，修改代码，提交修改） | 10 | 10 |
| Reporting | 报告 | 20 | 20 |
| Test Repor | 测试报告 | 20 | 20 |
| Size Measurement | 计算工作量 | 15 | 15 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 150 | 520 |
221701232 岳逾先
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 60 | 40 |
| Estimate | 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | 330 | 430 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 0 | 0 |
| Design Review | 设计复审 | 30 | 40 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 30 | 40 |
| Coding | 具体编码 | 180 | 220 |
| Code Review | 代码复审 | 30 | 40 |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 60 |
| Reporting | 报告 | 0 | 0 |
| Test Repor | 测试报告 | 30 | 20 |
| Size Measurement | 计算工作量 | 20 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 20 |
| 合计 | 480 | 530 |
221701327 王清斌
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 10 |
| Estimate | 估计这个任务需要多少时间 | 30 | 10 |
| Development | 开发 | 450 | 480 |
| Analysis | 需求分析 (包括学习新技术) | 20 | 20 |
| Design Spec | 生成设计文档 | 30 | 20 |
| Design Review | 设计复审 | 30 | 20 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 60 | 30 |
| Coding | 具体编码 | 180 | 270 |
| Code Review | 代码复审 | 10 | 20 |
| Test | 测试（自我测试，修改代码，提交修改） | 10 | 20 |
| Reporting | 报告 | 80 | 60 |
| Test Repor | 测试报告 | 30 | 20 |
| Size Measurement | 计算工作量 | 20 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 20 |
| 合计 | 560 | 580 |
遇到的困难及解决办法
-
221701102 郑澜：
遇到的困难：Java的GUI全忘光了，界面写的很吃力，耽误了大家的时间。加上之前用的是VS Code处理冲突，这次用的Eclipse写，还是不熟悉Github的相关操作，整个非常难受。
解决方法：硬着头皮写，只怪自己没有打好基础，多亏有队友的帮忙。
-
221701339 沈志峰：
在这实践中出现遇到编写GUI界面的问题，由于学Java GUI已经是一年前的事早已经忘得一干二净了，所以说不得不把以前的PPT翻出来，快速复习，虽然还是有些问题，但最后还是通过百度的方法成功解决界面的bug。虽然这次时间紧凑，不过大家都配合得很好，代码质量把控得很好（代码按预期工作），最后有条不紊地写好项目。
- 221701233 张一凡：
我的主要工作是实现Dao层的部分函数和进行Dao层的测试工作，主要困难还是在测试的时候如何进行充分的情况考虑，以确保负责其他部分的伙伴够放心调用Dao层的接口，尤其是对判断“手机号或者身份证号在此前三次预约中是否成功中签”这一逻辑的测试，需要手动模拟所要求的环境，比较耗时耗力，也需要细心。
- 221701223 叶博宁：
我的主要困难还是工程能力的欠缺。在前期讨论阶段只能听大佬们讲类和数据库的设计思路，好在一个工程分摊到小组每个人头上工作量就没那么大了。既然代码写得少一些，就多帮团队整理材料和写博客，也算是比较充实。
- 221701220 赵伟男：
遇到的问题：DAO实现过程中需要考虑给service的对接，在短时间内要开发出Bug free的DAO实现类是比较困难的。从最初到最终确定进行了许多次数的修改。另外地，从结对到团队，人数增加而由于疫情又不能面对面交流，再加之缺乏团队合作交流的经验，沟通效率不能得到有效保证，在沟通上花的时间比较多。
一些需要重新回答的问题：
1、我们的项目可以获取或者爬取各种平台的QQ/微信/教务处通知？
答：我们在项目中没有提到这些。我们在项目中没有提到这些。我们在项目中没有提到这些。下图给出了我们项目被大家误解的地方。
老师（老师这里作为一个发布者，不不是说只有老师可以发布，只要用户创建了注册点，他就可以发布在通知）的通知和任务在我们的平台发布。这点需要我们的努力。
解答团队演示的问题：
2、如何获取微信、QQ的消息通知的API？
答：参见问题1。
3、为什么这个想法目前市面上没有，获取qq、微信、课程网站等通知，在技术上有什么难度？你们又有什么特长实现这样的技术？
答：目前市面上没有发现有这种想法，当然也欢迎及时纠正。
获取qq、微信、课程网站等通知，在技术上有什么难度？技术难度是否开放相关API，或者网站反爬虫保护等。你们又有什么特长实现这样的技术？
答：我们也在努力寻找我们的特长，当然这个技术我们以后会考虑，以目前的能力水平比较难以实现。
4、同学我听了下你的阐述我对你们这个软件如何运行还是不太明白。是它自己去各个网站爬数据然后自动生成，还是需要用户自己去网站看任务然后自己输入生成，还是把发布任务的人跟拉群一样在群里发布然后生成备忘录。
答：参见问题1。
5、能否从校内其它平台获取通知？
答：参见问题1。
6、账号如何获取？自助注册？
答：如果有余力实现的话，可以绑定手机号码注册，目前暂定邮箱注册。
7、把所有通知聚合到一个平台固然好，不过万一漏掉也是要承担责任的，如何确定达到用户心中的“所有通知”？
答：这个实现需要我们的探索。
8、有的网站对爬虫是由防护的，你们又将如何实现？
答：参见问题1后，这个实现需要我们的探索。
9、那这样的话，老师是不是也要去注册然后发布消息，那这样是不是就与福大教学平台这种网站的消息通知功能类似呢？
答：可以参见问题1，从发布通知上讲是大家都有这个功能的。
10、将订阅，转化未待办事项，这个在你们自己平台中，没有问题，最大的问题还是在于前面，如何获取足够全面的通知和任务？
答：参见问题1，如何获取足够全面的通知和任务，这个实现需要我们的探索。
11、老师在你们平台发布通知后，平台也帮忙发布到qq或微信上吗？
答：参见问题1后，再转发到qq或微信上好像不是我们的目的。
12、是任何人还是，只有老师能发布？
答：参见问题1。
13、对于消息发布者来说，为什么要使用该平台呢，如果消息不是自动获取的，那么直接竞争品就变成了QQ和微信这些即时通讯应用。
答：我们专注于提供通知或任务的发布、订阅，并且增加备忘录这个功能来方便用户来对这些通知或任务进行安排，对于一些无需依靠某些平台来完成的任务，这非常有用，当然大家希望大家喜欢用。我们也没有做即时通讯这个功能。
14、对于获取信息要从非常多的平台来说，如何获信息的难度会不会太大？
答：参见问题1后，被大家这么一说难度确实很大。
15、产品模式有点像消息队列，有相关技术储备吗，实时通知相关技术有了解吗？
答：我觉消息队列用在各个服务级别之间发布订阅，这个说起来好像有点勉强。当然我们中部分人有学过Spring Boot消息队列的内容，但不是很熟悉。实时通知相关技术，目前来讲大家似乎都没有过了解。
16.如何说服校方取代原有的所有通知渠道？
答：当我们产品做得足够好我们会更有底气，现在还是一句话：爸爸们求你们用吧，给您跪下了。
新的思考和想法
通过解答同学和老师们提出的问题，我们也意识到了我们的idea有很多不足之处，但是我们不想放弃这个大方向，决定尽我们所能在实践过程中改进我们的idea！
