日常6+1—团队Github实战训练

团队作业第二次—团队Github实战训练

第一部分

组员职责分工

前端：

• 221701104(潘晨宇):负责前端编写，页面跳转，前后端接口与界面对接。
• 221701132(0):负责前端页面的编写跳转，博客撰写
• 111700516(linyyyyyyy):负责前端页面的编写跳转，博客撰写

后端：

• 221701141(马科学):后端代码,判断前三次是否有成功预约以及编写测试数据和数据库
• 091700403(DorisDream):负责中签处理类，数据库sql编写
• 221701116(暮笑):负责后端函数编写，前后端页面对接。
• 221701105(邵研):后端

github 的提交日志截图&统计各组员的commit次数

• 221701141(马科学):4次
  

• 091700403(DorisDream):6次
  

• 221701116(暮笑):11次
  

• 221701105(邵研):5次
  

• 221701104(潘晨宇):5次
  

• 221701132(0):4次
  

• 111700516(linyyyyyyy):4次
  

• master
  
  

程序运行截图 运行环境和GUI截图

使用说明

（realease1.0.0的版本由于后期导入包的时候分成了两个包而未互相导入而无法正常使用，1.0.5版本重新整理了包的顺序）

java程序

编译器：eclipse

JDK：1.8.0_201

mySQL版本：8.0

引用jar包：mysql-connector-java-8.0.16.jar

数据库名：mask，用户名：root，密码：cy990814（信息可在DBUtil中修改）

在eclipse中打开解压后的文件中，找到src/front/mainWindow.java文件，运行即可

1、运行mainWindow.java，出现界面如下图

2、输入设置口罩总量，后按回车键

3、点击开始预约

4、点击口罩预约

5、输入正确信息后提交

6、结束预约

7、查询中签

![查询中签](

8、输入正确信息后，点击确认查询

基础功能实现

• 口罩预约定时开放
• 开放预约后，市民可以进行登记；登记内容包括①真实姓名；②身份证号；③手机号；④预约口罩数量（如果中签，想要买几个口罩）
• 如果手机号或者身份证号在此前三次预约中成功中签，预约失败
• 否则预约成功，给出不重复的预约编号
• 预约定时关闭
• 预约页面提供两个按钮，作用分别是开始预约和结束预约；
• 为方便测试，请在预约页面提供设置口罩总量的方法
• 登记时单个用户最高可预约口罩数量，默认为3个

附加功能实现

无

有想法且有用的功能

无

用户体验，操作的方便、快捷性

通过按钮点击直接显示

遇到的困难及解决方法

221701104(潘晨宇):

• 遇到的困难：不同的前端开发IDE开发出来的程序可能会出现不兼容的状态，导致相互的文件内容无法相互融合。
• 解决的办法：在编码之前先统一开发环境，然后再进行开发。

221701132(0):

• 遇到的困难：学习如何利用java可视化编程以及遇到的一些界面设计问题
• 解决的方法：网上查询资料和教程以及和同组成员沟通确定

111700516(linyyyyyyy):

• 你遇到的困难：学习如何利用java可视化编程以及完善代码（页面跳转和事件监听器设计）
• 解决的方法：网上查询资料和教程以及和同组成员沟通确定

221701141(马科学):

• 遇到的困难:在设计数据库的表和类图，其他还有测试数据的生成及判断前三次预约是否有成功记录的部分。在设计数据库表格的过程中，我错误理解了需求，认为前三次预约指的是用户本人预约记录的前三次，事实是发放的前三次。这样自己设计的表格就不适用了。
• 解决的办法:后来小组讨论决定用中签表和预约表实现这个项目，让我不解的是每次预约都要新建这两种表格，我总是想着两个表格记录所有信息，emmm。判断前三次是否有成功预约的记录，实际上只需要查看最近的三个中签表是否有用户的记录就可以了。但由于对界面和链接不太熟悉，仅做出了判断的代码。测试数据用到了身份证号生成器，最终确定十组测试数据，基本满足需要。

091700403(DorisDream)

• 遇到的困难：中签处理的过程中，在处理抽签函数随机抽取那一块，用random函数不可避免会出现重复抽取，于是就想每次都要去判断前面几次有没有抽过这个id，这样处理起来会不会很麻烦。
• 解决的办法：后来想到了利用HashSet集合中元素不可重复的原则，用HashSet去存取，极大地简化了代码的制作流程

221701116(暮笑)

• 遇到的困难：测试处理的时候前后端对接会出现很多的问题，比如回调不正确，入参不正确。
• 解决的办法：积极与小组成员进行沟通。
  221701105(邵研)
• 遇到的困难：ide与GitHub desktop结合的不熟练，切换分支时清空了本地代码
• 解决的方法: Github的学习有待加强x

评估每位组员的贡献比例，总分100

学号	贡献度
221701104	14
221701141	12
221701132	12
111700516	13
091700403	18
221701116	18
221701105	13

PSP表格

221701132(0)

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	10	15
Estimate	估计这个任务需要多少时间	8	15
Development	开发	240	220
Analysis	需求分析 (包括学习新技术)	20	40
Design Spec	生成设计文档	30	30
Design Review	设计复审	10	10
Coding Standard	代码规范 (为目前的开发制定合适的规范)	10	8
Design	具体设计	60	120
Coding	具体编码	300	240
Code Review	代码复审	60	90
Test	测试（自我测试，修改代码，提交修改）	30	30
Reporting	报告	60	45
Test Repor	测试报告	30	30
Size Measurement	计算工作量	20	10
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	30	50
合计	707	633

111700516(linyyyyyyy)

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	5	10
Estimate	估计这个任务需要多少时间	2	3
Development	开发	240	220
Analysis	需求分析 (包括学习新技术)	20	40
Design Spec	生成设计文档	30	30
Design Review	设计复审	10	10
Coding Standard	代码规范 (为目前的开发制定合适的规范)	10	8
Design	具体设计	60	120
Coding	具体编码	300	240
Code Review	代码复审	60	90
Test	测试（自我测试，修改代码，提交修改）	30	30
Reporting	报告	60	45
Test Repor	测试报告	30	30
Size Measurement	计算工作量	20	10
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	30	50
合计	680	700

221701141(马科学)

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	10	8
Estimate	估计这个任务需要多少时间	10	8
Development	开发	295	270
Analysis	需求分析 (包括学习新技术)	30	25
Design Spec	生成设计文档	20	10
Design Review	设计复审	15	25
Design	具体设计	60	100
Coding	具体编码	120	70
Code Review	代码复审	20	15
Test	测试（自我测试，修改原型，优化）	30	25
Reporting	报告	60	46
Test Report	测试报告	20	15
Size Measurement	计算工作量	10	6
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	30	25
	合计	365	324

091700403(DorisDream)

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	35
Estimate	估计这个任务需要多少时间	30	20
Development	开发	180	210
Analysis	需求分析 (包括学习新技术)	30	40
Design Spec	生成设计文档	20	10
Design Review	设计复审	20	10
Coding Standard	代码规范 (为目前的开发制定合适的规范)	30	20
Design	具体设计	20	10
Coding	具体编码	120	150
Code Review	代码复审	30	20
Test	测试（自我测试，修改代码，提交修改）	30	40
Reporting	报告	30	20
Test Repor	测试报告	30	20
Size Measurement	计算工作量	0	0
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	20	10
	合计		590

221701116(暮笑)

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	30
Estimate	估计这个任务需要多少时间	30	20
Development	开发	180	210
Analysis	需求分析 (包括学习新技术)	30	40
Design Spec	生成设计文档	30	10
Design Review	设计复审	40	10
Coding Standard	代码规范 (为目前的开发制定合适的规范)	30	20
Design	具体设计	20	30
Coding	具体编码	120	155
Code Review	代码复审	25	45
Test	测试（自我测试，修改代码，提交修改）	30	50
Reporting	报告	30	20
Test Repor	测试报告	30	20
Size Measurement	计算工作量	0	0
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	20	10
	合计		685
221701105(邵研)

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	2	1
Estimate	估计这个任务需要多少时间	2	1
Development	开发	510	602
Analysis	需求分析 (包括学习新技术)	20	60
Design Spec	生成设计文档	30	30
Design Review	设计复审	10	10
Coding Standard	代码规范 (为目前的开发制定合适的规范)	10	2
Design	具体设计	50	120
Coding	具体编码	300	250
Code Review	代码复审	60	100
Test	测试（自我测试，修改代码，提交修改）	30	30
Reporting	报告	60	45
Test Repor	测试报告	30	30
Size Measurement	计算工作量	20	10
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	10	5
合计	542	633

221701104(潘晨宇)

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	20	10
Estimate	估计这个任务需要多少时间	12	30
Development	开发	240	220
Analysis	需求分析 (包括学习新技术)	20	40
Design Spec	生成设计文档	15	30
Design Review	设计复审	10	10
Coding Standard	代码规范 (为目前的开发制定合适的规范)	10	8
Design	具体设计	60	120
Coding	具体编码	300	240
Code Review	代码复审	60	90
Test	测试（自我测试，修改代码，提交修改）	30	30
Reporting	报告	60	45
Test Repor	测试报告	30	30
Size Measurement	计算工作量	20	10
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	30	60
合计	700	730

第二部分

团队选题展示过程中，老师和同学提出了一些问题。以下问题我们想现在予以解答

• 怎样防止数据库攻击？

  就目前而言，我们了解到的数据库攻击有三个：口令破解、针对数据库漏洞以及SQL注入攻击。

  • 针对口令破解。是指数据库用户的用户名和和口令被黑客破解。一般的默认口令容易被破解，比如用户名“root"或者Scott的默认口令为tiger。但是除此以外对数据库的破解即使不在默认情况下依然容易，现在网上就存在许多破解的软件。为了应对这一问题，就要避免使用默认口令，建立强健的口令管理程序并对口令经常改变。

  • 针对数据库漏洞攻击，数据库厂商总是小心翼翼地避免披露其补丁程序所修正的漏洞细节，但单位仍以极大的人力和时间来苦苦挣扎，它会花费人力物力来测试和应用一个数据库补丁。例如，给程序打补丁要求对受补丁影响的所有应用程序都进行测试，这是项艰巨的任务。 而且一些黑客站点将一些已知的数据库漏洞的利用脚本发布了出来。为了应对这一问题，就要及时更新数据库，更新补丁，补上漏洞。

  • 针对SQL注入攻击：

    在字段可用于用户输入，通过SQL语句可以实现数据库的直接查询时，就会发生SQL攻击。黑客通过对SQL语句中某些未进行规范化检查的语句进行攻击，SQL注入攻击被俗称为黑客的填空游戏。所以在写SQL语句的时候要注意规范化检查，在写web程序的时候也要对数据进行规范检查，防止被钻漏洞。

• 时间轴打算怎么处理？

  还是按照最初的设想，可以新建成若干的时间轴，其中的时间长短可以由用户进行选择，比如一天或者一周或者一个月、一年，在新建完时间轴后，允许使用略缩图使得尽可能多的部分展现在屏幕上（不会影响观感），允许用户进行拖动和添加。

在上次团队选题之后，你们组有什么新的思考和想法？

1. 在社交平台的开发上，我们的大平台是选择类似微博的形式，这也意味着平台的大开发也许并不需要我们自己进行，而可以利用现有的开发信息，可以在github上寻找开源的平台开发源码，直接套用即可获得一个现有的信息交流平台。

2. 关于TAG搜索是否需要多元化？

   目标的搜索功能是允许用户进行文字、语音、图片的搜索。我们仔细考虑了以下是否需要如此多的功能，会不会给我们的开发造成困难。我们经过调查发现百度或者google有直接的API接口以获得文字查询或者图片查询的方法，但是我们认为语音查询可能有些过于繁琐，而且我们的开发更偏向webapp，真正愿意使用语音搜索的用户应该不会很多，所以我们放弃了语音搜索功能，保留了文字和图片的搜索。

3. 这次的开发要往移动端开发还是web端开发？

   说实话此类项目确实移动端开发更加吃香。但是我们的组内并没有之前开发过android和iOS的同学，所以我们的如果开发移动端程序面临的阻力是很大的，但是我们可以退而求其次，我们可以开发webapp，虽然使用的热度可能会下降，但是可以兼容PC和移动端，而且根据我们积累的开发经验我们可以更好地进行开发。