寒假第二次作业-疫情统计

寒假第二次作业-疫情统计

最近新型冠状病毒疫情严重,全国人民都感到担忧,迫切希望能够及时了解到病毒最新的情况,作为IT学子,大家请你帮忙开发一个疫情统计程序。

一、前置要求

1、github初使用

为了保证你的代码能够帮助更多的人,并且能得到有效的管理和开源共享,请先学习github使用:

  1. 注册github账号,在博客中提供github链接
  2. 下载Git和Github Desktop
  3. 学习基础Git命令、Github Desktop使用,参考附录教程
  4. 本次作业采用github,fork项目示例结构到自己的仓库,完成基本需求,并至少进行10次以上的commit修改,并将最终程序以pr的方式提交到主仓库
  5. 对于非仓库要求的代码,如编译器生成的项目文件、输出文件、class、jar包、exe等,应该使用.gitignore进行忽略,并确保不会提交到github上

2、代码规范制定

为了其他同仁可以轻松的阅读你的代码,请制定属于你的代码规范,要求不能偏离主流代码规范:

请参照《码出高效_阿里巴巴Java开发手册》/《腾讯c++代码规范》/《Python PEP8》,从以下几个角度制定你的编程规范,并撰写成markdown文件,请牢记你制定的编码规范,并在此次作业中严格执行

  • 缩进
  • 变量命名
  • 每行最多字符数
  • 函数最大行数
  • 函数、类命名
  • 常量
  • 空行规则
  • 注释规则
  • 操作符前后空格
  • 其他规则

二、疫情统计程序的需求文档

1、日志文本

假设有一家统计网站每天都会提供一个对应的日志文本,记录国内各省前一天的感染情况,如它2020-01-23发布的日志文本可能长这样:

福建 新增 感染患者 23人
福建 新增 疑似患者 2人
浙江 感染患者 流入 福建 12人
湖北 疑似患者 流入 福建 2人
安徽 死亡 2人
新疆 治愈 3人
福建 疑似患者 确诊感染 2人
新疆 排除 疑似患者 5人
// 该文档并非真实数据,仅供测试使用

该日志中出现以下几种情况:
1、 <省> 新增 感染患者 n人
2、 <省> 新增 疑似患者 n人
3、 <省1> 感染患者 流入 <省2> n人
4、 <省1> 疑似患者 流入 <省2> n人
5、 <省> 死亡 n人
6、 <省> 治愈 n人
7、 <省> 疑似患者 确诊感染 n人
8、 <省> 排除 疑似患者 n人
PS:

  • 日志中各种情况的出现顺序不定,省出现的顺序不定,出现哪些省不定,省出现几次不定。
  • 该日志文件的命名遵守对应的规范: 年-月-日.log.txt ,如2020-01-22.log.txt
  • 文件日期并不一定连续,若某天的日志缺失,默认为该天的情况没有变化。认为日志提供的最早一天的前一天不存在任何感染情况。如只提供2020-01-23,2020-01-25则可认为2020-01-24增长变化都为0。-date不会提供在日志最晚一天后的日期,若提供应给与日期超出范围错误提示。

现在请你撰写程序,读取传入的log目录下的所有日志,来实现需求

  ...\
      \--log
        \--2020-01-22.log.txt
        \--2020-01-23.log.txt

2、需求

需要你的程序能够列出全国和各省在某日的感染情况

命令行(win+r cmd)cd到项目src下,之后输入命令:

$ java InfectStatistic list -date 2020-01-22 -log D:/log/ -out D:/output.txt

会读取D:/log/下的所有日志,然后处理日志和命令,在D盘下生成ouput.txt文件列出2020-01-22全国和所有省的情况(全国总是排第一个,别的省按拼音先后排序)

全国 感染患者22人 疑似患者25人 治愈10人 死亡2人
福建 感染患者2人 疑似患者5人 治愈0人 死亡0人
浙江 感染患者3人 疑似患者5人 治愈2人 死亡1人
// 该文档并非真实数据,仅供测试使用

list命令 支持以下命令行参数:

  • -log 指定日志目录的位置,该项必会附带,请直接使用传入的路径,而不是自己设置路径
  • -out 指定输出文件路径和文件名,该项必会附带,请直接使用传入的路径,而不是自己设置路径
  • -date 指定日期,不设置则默认为所提供日志最新的一天。你需要确保你处理了指定日期之前的所有log文件
  • -type 可选择[ip: infection patients 感染患者,sp: suspected patients 疑似患者,cure:治愈 ,dead:死亡患者],使用缩写选择,如 -type ip 表示只列出感染患者的情况,-type sp cure则会按顺序【sp, cure】列出疑似患者和治愈患者的情况,不指定该项默认会列出所有情况。
  • -province 指定列出的省,如-province 福建,则只列出福建,-province 全国 浙江则只会列出全国、浙江

注:java InfectStatistic表示执行主类InfectStatistic,list为命令,-date代表该命令附带的参数,-date后边跟着具体的参数值,如2020-01-22。-type 的多个参数值会用空格分离,每个命令参数都在上方给出了描述,每个命令都会携带一到多个命令参数

三、编码说明

作业的主仓库https://github.com/numb-men/InfectStatistic-main
主仓库内含示例项目结构

1、编码要求

  1. 这次作业重点考察需求的分析
    • 请在正式编写程序之前先理清需求文档
    • 请在理清需求文档后先设计好程序模块、类图、数据结构、算法流程等部分
    • 如果你对需求有不明白的地方可以在作业底部评论提问
  2. 代码的风格要符合你制定的代码规范
  3. 学习单元测试的基础理论和相应技术,并在此次作业中使用,至少测试10个测试用例,在博客中截图描述
  4. 对你的程序进行测试的覆盖率分析和性能分析,并尝试进行优化,在博客中截图描述你的优化过程
  5. 项目结构要求符合以下结构
221700xxx(目录名为学号)
  \--src
    \--InfectStatistic.java
    \--Lib.java
    src下源代码【仅】允许包括这两个文件,Lib可以为空但必须存在,【其他语言可以修改后缀】,但确保文件名一致、区分大小写
  \--README.md
    描述你的项目,包括如何运行、功能简介、作业链接、博客链接等
  \--codestyle.md
    描述你之前定的代码风格

2、程序提交流程

  1. star主仓库,这样你能在你的star列表找到该仓库,fork主仓库到你的仓库,在根目录新建目录,目录名为你的学号

  2. 复制example下的目录结构到你新建的目录下:
    • 如果你使用c/c++或python,修改src下的文件后缀和文件内容对应到你使用的语言
    • src下源代码【仅】允许包括这InfectStatistic、Lib两个文件,Lib可以为空但必须存在,【c/c++或python可以修改后缀】,但确保文件名一致、区分大小写
  3. 语言支持:
    • Java:Java8,推荐使用Java开发
    • c/c++:gcc/g++ 6.3,将java InfectStatistic替换为InfectStatistic.exe
    • python:3.7,将java InfectStatistic替换为python InfectStatistic.py
    • 换行使用'\n',编码统一使用UTF-8
    • 仅允许使用语言自带的库,不允许使用第三方库
  4. 请勿修改example下的文件

  5. example/result下提供了三个测试用例的标准输出,对应的命令在文件尾部提供了,即对example/log下的日志,输入对应的命令应该会是相应的输出。

  6. 为了使测试文件和输出文件不产生诱导性,要在日志文件/输出文件末尾加上// 该文档并非真实数据,仅供测试使用,建议读取日志时直接忽略以//开始的行

  7. 除了示例仓库的给出的文件,其它自己产生的文件都应该在.gitignore忽略,如编译器生成的项目文件、输出文件、class、jar包、exe等

  8. 代码每有更新就可以进行commit签入、push到github,至少进行10次以上的commit签入,并将最终程序以pr的方式提交到主仓库

3、抄袭检查

此次作业会助教会检查commit签入记录是否合理、并进行代码查重,如发现两份代码相似度过高,则后一个在仓库提交的作业此次作业强制负分!并在微信群点名!

四、博客撰写要求

  1. 在文章开头给出Github仓库地址

  2. 阅读《构建之法》第一章至第三章的内容,并在下方作业里体现出阅读后的成果。特别是第2章中的效能分析及个人软件开发流程(PSP)。之后给出此次作业的PSP表格

  3. 解题思路描述。即刚开始拿到题目后,如何思考,如何找资料的过程。

  4. 设计实现过程。设计包括代码如何组织,关键函数的流程图。

  5. 代码说明。展示出项目关键代码,并解释思路

  6. 单元测试截图和描述。

  7. 单元测试覆盖率优化和性能测试,性能优化截图和描述。

  8. 给出你的代码规范的链接,即你的仓库中的codestyle.md

  9. 结合在构建之法中学习到的相关内容,撰写解决项目的心路历程与收获

  10. 在github上寻找你在第一次作业中技术路线图相关的5个仓库,star并fork,在博客中提供名称、链接、简介(简介30字左右)

五、作业评分项和评分规则

本次作业总分100分

  • 博客 30分
    1. 博客排版【10%】:是否采用markdown排版,排版是否整齐,博客是否美观大方
    2. PSP表格【10%】:要求符合真实情况,夸张虚构不合理会得0分
    3. 解题思路描述【10%】:不笼统,图文兼备
    4. 设计实现过程【10%】:设计合理,易扩展,有容错性;提供模块结构图、流程图;
    5. 代码说明【10%】:展示出项目关键代码,并解释思路。
    6. 单元测试截图和描述【10%】:截图单元测试代码,和运行结果。体现测试用例多于10个。
    7. 单元测试覆盖率优化和性能测试,性能优化截图和描述【10%】:体现优化过程,性能测试过程。
    8. git仓库链接、代码规范链接【10%】
    9. 心路历程和收获【10%】:不笼统,有意义,图文兼备
    10. 技术路线图相关的5个仓库【10%】:提供五个仓库的名称、链接、简介(简介30字左右)
  • 代码规范 20分
    1. 囊括要求部分【30%】
    2. 符合主流,制定合理,详细【20%】
    3. 项目代码符合代码规范【50%】
  • github使用 10分
    1. commit 多于10次,并且签入时间合理【60%】
    2. 使用release、issues、pr等其它功能【40%】
  • 程序评测 40分
    1. 基础list命令【30%】:仅仅携带-log、-out参数
    2. 结合命令参数的其余10个测试用例【70%】:-date、-province、-type三个参数组合

附录

1. PSP表格

PSP是卡耐基梅隆大学(CMU)的专家们针对软件工程师所提出的一套模型:Personal Software Process (PSP, 个人开发流程,或称个体软件过程)。

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

一个功能完备的程序不是一蹴而就的。可将一个大任务划分为可操作的小任务,同时最好按照任务难度或紧急程度指定各个任务的完成次序。因此,在动手开发之前,要先估计将在程序各模块开发所需耗费的时间,以及完成整个项目所需的时间,将这个[估计值]记录下来,写成PSP 的形式。
PSP的目的是:记录工程师如何实现需求的效率,和我们使用项目管理工具(例如微软的Project Professional,或者禅道等)进行项目进度规划类似。
有关PSP的更多内容,请自行阅读邹欣老师的博客:工程师的能力评估和发展

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

2. Github

请阅读邹欣老师的博客:源代码管理,了解源代码管理的10个实践问题。
本次作业要求使用Github进行源代码管理,代码有进展即签入Github。签入记录不合理的项目会被助教抽查询问项目细节。
对代码签入的具体要求如下:根据需求划分功能后,每做完一个功能,编译成功后,应至少commit一次。具体的功能划分,请自行定义,并在撰写博客时体现出来,遵循自己对需求的功能划分来提交代码即可。
对Commit不是很熟悉的话,请阅读阮一峰的博客:Commit message 和 Change log 编写指南,了解更多细节。
杨助教提供的github简单教程:https://www.cnblogs.com/jhy16193335/p/11477334.html
.gitignore配置语法完全版:https://blog.csdn.net/le_17_4_6/article/details/92789993
助教提供的gitDesktop、多人协作教程:https://blog.csdn.net/le_17_4_6/article/details/86560878


3. 单元测试

请根据自己以往积累的测试经验,在编码完成之后,提交产品之前,设计测试用例,并编写单元测试,对自己的项目进行测试。
首先,至少应采用白盒测试用例设计方法来设计测试用例,其他测试方法不限。其次,要设计至少10个测试用例,确保你的程序能够正确处理各种情况。最后,结合测试评估的要求,对自己的测试设计进行评价,这些测试用例能满足该程序测试的要求吗?
另一个重要的措施是要把单元测试自动化,这样每个人都能很容易地运行它,并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的,这样每个单元测试的错误就能及时被发现并得到修改。
推荐阅读邹欣老师的博客:关于单元测试和回归测试

规则&格式

1、为了方便其他学校的老师或者助教了解课程实况,请大家在作业开头添加格式描述:(必做)

这个作业属于哪个课程 <班级的链接>
这个作业要求在哪里 <作业要求的链接>
这个作业的目标 <写上具体方面>
作业正文 ....
其他参考文献 ...

markdown代码

|这个作业属于哪个课程|<班级的链接>|
|-- |-- |
|这个作业要求在哪里|<作业要求的链接>|
|这个作业的目标|<写上具体方面>|
|作业正文|....  |
|其他参考文献|... |

2、提交规则

  • 在deadline前交,得实际得分 * 100%;
  • 补交:在deadline 后两天内提交视为补交,得实际得分 * 50%;
  • 缺交:在deadline 之后两天未补交视为博客缺交,分数为0分;

(忘记提交作业和补交扣分一致)

3、计分规则

每次作业的基准分为100分,根据作业难度会对作业的实际分数进行换算,
比如:

对同一次作业,统计得分时为满分100分,换算权重为25%


小李此次作业得分85分,作业在deadline前提交,那么他的实际得分为85*100%*25% = 21.25


小张此次作业得分85分,并是在deadline后的两天内补交,那么实际得分为85*50%*25% = 10.625


小王在作业deadline两天后还未补交,作业提交已经关闭,此次作业得0分


...

4、其它规则

  • 作业抄袭:当助教发现两篇博客文字/图片/代码相似度超过50%时,判定两篇博客都为抄袭,分数都为-100%;
  • 伪造提交:虽然作业博客没有完成,但是先提交到作业占位置,判定为伪造提交,分数得0分;
  • 微信班级群如果发布相关通知也是作业要求一部分,请及时查看群通知;
  • 若需要在微信群填写相关信息,未能在deadline之前完成填写的,扣实际得分的50%;
  • 如对作业存在疑问,请在deadline之前三天在班级群提出;
  • 若助教对作业要求有修改,会在群内公告,请务必查看并按新的要求完善作业;

猜你喜欢

转载自www.cnblogs.com/hengyumo/p/12276160.html
今日推荐