寒假第二次作业-疫情统计
最近新型冠状病毒疫情严重，全国人民都感到担忧，迫切希望能够及时了解到病毒最新的情况，作为IT学子，大家请你帮忙开发一个疫情统计程序。
一、前置要求
1、github初使用
为了保证你的代码能够帮助更多的人，并且能得到有效的管理和开源共享，请先学习github使用：
- 注册github账号，在博客中提供github链接
- 下载Git和Github Desktop
- 学习基础Git命令、Github Desktop使用，参考附录教程
- 本次作业采用github，fork项目示例结构到自己的仓库，完成基本需求，并至少进行10次以上的commit修改，并将最终程序以pr的方式提交到主仓库
- 对于非仓库要求的代码，如编译器生成的项目文件、输出文件、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、 感染患者 流入 n人
4、 疑似患者 流入 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.txt2、需求
需要你的程序能够列出全国和各省在某日的感染情况
命令行（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、编码要求
- 这次作业重点考察需求的分析
- 请在正式编写程序之前先理清需求文档
- 请在理清需求文档后先设计好程序模块、类图、数据结构、算法流程等部分
- 如果你对需求有不明白的地方可以在作业底部评论提问
- 代码的风格要符合你制定的代码规范
- 学习单元测试的基础理论和相应技术，并在此次作业中使用，至少测试10个测试用例，在博客中截图描述
- 对你的程序进行测试的覆盖率分析和性能分析，并尝试进行优化，在博客中截图描述你的优化过程
- 项目结构要求符合以下结构
221700xxx（目录名为学号）
\--src
\--InfectStatistic.java
\--Lib.java
src下源代码【仅】允许包括这两个文件，Lib可以为空但必须存在，【其他语言可以修改后缀】，但确保文件名一致、区分大小写
\--README.md
描述你的项目，包括如何运行、功能简介、作业链接、博客链接等
\--codestyle.md
描述你之前定的代码风格2、程序提交流程
star主仓库，这样你能在你的star列表找到该仓库，fork主仓库到你的仓库，在根目录新建目录，目录名为你的学号
- 复制example下的目录结构到你新建的目录下：
- 如果你使用c/c++或python，修改src下的文件后缀和文件内容对应到你使用的语言
- src下源代码【仅】允许包括这
InfectStatistic、Lib两个文件，Lib可以为空但必须存在，【c/c++或python可以修改后缀】，但确保文件名一致、区分大小写
- 语言支持：
- Java：Java8，推荐使用Java开发
- c/c++：gcc/g++ 6.3，将
java InfectStatistic替换为InfectStatistic.exe - python：3.7，将
java InfectStatistic替换为python InfectStatistic.py - 换行使用'\n'，编码统一使用UTF-8
- 仅允许使用语言自带的库，不允许使用第三方库
请勿修改example下的文件
example/result下提供了三个测试用例的标准输出，对应的命令在文件尾部提供了，即对example/log下的日志，输入对应的命令应该会是相应的输出。
为了使测试文件和输出文件不产生诱导性，要在日志文件/输出文件末尾加上
// 该文档并非真实数据，仅供测试使用，建议读取日志时直接忽略以//开始的行除了示例仓库的给出的文件，其它自己产生的文件都应该在
.gitignore忽略，如编译器生成的项目文件、输出文件、class、jar包、exe等代码每有更新就可以进行commit签入、push到github，至少进行10次以上的commit签入，并将最终程序以pr的方式提交到主仓库
3、抄袭检查
此次作业会助教会检查commit签入记录是否合理、并进行代码查重，如发现两份代码相似度过高，则后一个在仓库提交的作业此次作业强制负分！并在微信群点名！
四、博客撰写要求
在文章开头给出Github仓库地址。
阅读《构建之法》第一章至第三章的内容，并在下方作业里体现出阅读后的成果。特别是第2章中的效能分析及个人软件开发流程（PSP）。之后给出此次作业的PSP表格。
解题思路描述。即刚开始拿到题目后，如何思考，如何找资料的过程。
设计实现过程。设计包括代码如何组织，关键函数的流程图。
代码说明。展示出项目关键代码，并解释思路。
单元测试截图和描述。
单元测试覆盖率优化和性能测试，性能优化截图和描述。
给出你的代码规范的链接，即你的仓库中的codestyle.md
结合在构建之法中学习到的相关内容，撰写解决项目的心路历程与收获。
在github上寻找你在第一次作业中技术路线图相关的5个仓库，star并fork，在博客中提供名称、链接、简介（简介30字左右）
五、作业评分项和评分规则
本次作业总分100分
- 博客 30分
- 博客排版【10%】：是否采用markdown排版，排版是否整齐，博客是否美观大方
- PSP表格【10%】：要求符合真实情况，夸张虚构不合理会得0分
- 解题思路描述【10%】：不笼统，图文兼备
- 设计实现过程【10%】：设计合理，易扩展，有容错性；提供模块结构图、流程图；
- 代码说明【10%】：展示出项目关键代码，并解释思路。
- 单元测试截图和描述【10%】：截图单元测试代码，和运行结果。体现测试用例多于10个。
- 单元测试覆盖率优化和性能测试，性能优化截图和描述【10%】：体现优化过程，性能测试过程。
- git仓库链接、代码规范链接【10%】
- 心路历程和收获【10%】：不笼统，有意义，图文兼备
- 技术路线图相关的5个仓库【10%】：提供五个仓库的名称、链接、简介（简介30字左右）
- 代码规范 20分
- 囊括要求部分【30%】
- 符合主流，制定合理，详细【20%】
- 项目代码符合代码规范【50%】
- github使用 10分
- commit 多于10次，并且签入时间合理【60%】
- 使用release、issues、pr等其它功能【40%】
- 程序评测 40分
- 基础list命令【30%】：仅仅携带-log、-out参数
- 结合命令参数的其余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之前三天在班级群提出；
- 若助教对作业要求有修改，会在群内公告，请务必查看并按新的要求完善作业；