| GIT地址 | https://github.com/Decadeeeee/WordCount |
| GIT地址 | Decadeeeee |
| 人员 | 彭正杰：201731062125 梁江：201731062126 |
| 博客地址 | https://www.cnblogs.com/pzjdsb/ |
1.结对项目PSP编写
我们的项目于4月1日正式开始，在开始编写代码之前，我们先对我们如何完成项目以及对老师布置的作业等进行再一次的商定和讨论。并结合我们平时上课的时间以及项目外等因素，约定了我们一起进行结对编程的时间和地点。最后一起完成了PSP表格的填写：
|
PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时（分钟） |
|
Planning |
计划 |
30 |
30 |
|
· Estimate |
· 估计这个任务需要多少时间 |
30 |
30 |
|
Development |
开发 |
740 |
1650 |
|
· Analysis |
· 需求分析 (包括学习新技术) |
50 |
30 |
|
· Design Spec |
· 生成设计文档 |
30 |
50 |
|
· Design Review |
· 设计复审 (和同事审核设计文档) |
30 |
50 |
|
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
20 |
5 |
|
· Design |
· 具体设计 |
60 |
100 |
|
· Coding |
· 具体编码 |
500 |
885 |
|
· Code Review |
· 代码复审 |
30 |
50 |
|
· Test |
· 测试（自我测试，修改代码，提交修改） |
20 |
500 |
|
Reporting |
报告 |
90 |
60 |
|
· Test Report |
· 测试报告 |
50 |
30 |
|
· Size Measurement |
· 计算工作量 |
20 |
10 |
|
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
20 |
20 |
|
合计 |
860 |
1740 |
总结分析：这次在项目完成后，发现预估时间和实际耗时相差比较大，其主要表现在开发阶段。由于我们在代码自审和互审阶段，都发现了编码所存在的不规范，所以花了更多的时间去修改代码。还有就是在编码的时候，我们要完成的内容比我们想象得要困难一点，所以在编码的时候花了更多的时间。最后就是测试，这次项目开发采用了TDD，我们要先编写测试代码，再实现接口，这与我们之间采用的方式也不同，所以也花了更多的时间。
2.代码互审
2.1总体情况分析
在审查之后发现，队友的代码已经根据了我们一起编写的小组编程规范进行了修改。修改后的代码风格简洁明了，非常容易理解和阅读。但是仍需注意的地方是，方法里的代码注释要写在对应代码的上面而不是后面，这样会使代码阅读更加清晰。除此之外，在互审之后，发现代码存在一个小bug需要进行改正。
2.2 问题
出现问题的模块在CountUtil类中的returnWords方法。
问题是在测试时发现：当一个文件为空的时候，它会返回单词数为1，而且当有两个文件同时测试时，如果第一个文件的单词数比第二个文件的单词数多的话，只显示第一个的单词数。
2.3 解决方法
在问题提出后，我和队友一起解决了问题，发现问题出在每次统计单词数目所要用的StringBuffer没有进行清空的操作。
3.设计
3.1 结构设计
功能类：主函数类（WordCount类） 接口类（CountUtil类）
WordCount类：
CountUtil类：
3.2 类间关系
3.3 WordCount类的流程图（类的介绍再结对伙伴博客里 https://www.cnblogs.com/decade2019/）
4.我的代码：
主函数里的TFile类
WordGet类：（后面代码互审时发现这里筛选英文的条件不行，后面改正了）
改正后：
总结
在这次结对项目实践完成之后，我发现1+1是大于2的。我们项目完成的效率远比当时我一个人完成的时候要高出很多，而且我们一起编程可以及时解决所遇到的问题和避免一些不必要的问题。避免走了很多的弯路。除此之外，我还学习到了我队员的编程思想和他的学习方式，这些东西都给我带来了很多的启发和新的思路。总得来说，整个项目的完成也比之前的更加顺利和充满动力。提高了我对完成项目的积极性。