结对编程

时间 2019-11-10

标签编程繁體版

原文原文链接

1.编码要求

（1）Fork github 项目https://github.com/Cherish599/WordCount到本身的仓库，在Github仓库中新建一个以一位同窗的学号为名的文件夹，用于创建C#的项目和第二次做业相似。（结对的两人中任意一人的学号均可以）。html

（2）在开始实现程序以前，在PSP表格[附录1]记录下你估计在程序开发各个步骤上耗费的时间，在你实现程序以后，在PSP表格记录下你在程序的各个模块上实际花费的时间。git

（3）使用C#语言实现，C#请使用Visual Studio Community 2017进行开发。github

a) 制定编码规范，能够参考C#语言的规范：简版，讨论版。（邹欣老师在讲义“现代软件工程讲义 3 代码规范与代码复审”中所讨论的有关代码规范与代码复审的内容。内容短小精炼，适合快速入门。）算法

b) 代码自审并修正，每一个人都独立完成了本身的功能任务，对照编码规范，审查修改本身的程序代码并使其符合规范要求。编程

c) 代码互审，按照共同制定的编码规范，审查合做伙伴的代码并记录发现的问题。windows

d) 合并代码，两人协商，将两部分代码合并，造成初始版本。注意应设计合理的软件结构及模块划分。架构

e) 提交的代码要求通过Code Quality Analysis工具的分析并消除全部的警告。框架

f) 完成项目的首个版本以后，请使用性能分析工具Studio Profiling Tools来找出代码中的性能瓶颈并进行改进。ide

g) 使用Github[附录2]来管理源代码和测试用例，代码有进展即签入Github（至少三次）。签入记录不合理的项目会被助教抽查询问项目细节。函数

h) 使用单元测试[附录3]对项目进行测试，并使用插件查看测试分支覆盖率等指标；并写出至少10个测试用例确保你的程序可以正确处理各类状况。

i) 在完成结对项目后，请按照预第二次做业的方式正确地发起一个Pull Request，并设置标题为本次统一使用的学号。

2.博客撰写要求

（1）在文章开头给出结对使用的Github项目地址和结对伙伴的做业地址。（两我的使用同一个）注意：GitHub的地址必须是用于clone的地址即以下图片中的地方获取。（若是不是这个地址，助教就没法批量编译运行大家的程序，出现问题的都会被助教抽中询问详情）

（2）描述结对的过程，提供非摆拍的两人在讨论的结对照片（一块儿工做编码时的照片）。

（3）给出结对的PSP表格。

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

b) 设计实现过程。设计包括代码如何组织，好比会有几个类，几个函数，他们之间关系如何，关键函数是否须要画出流程图？单元测试是怎么设计的？

c) 给出大家制定的代码规范或连接，记录大家代码互审的状况，审查的模块名、发现的问题等。

d) 记录在改进程序性能上所花费的时间，描述你改进的思路，并展现一张性能分析图（由VS 2017的性能分析工具自动生成），并展现你程序中消耗最大的函数。

e) 代码说明。展现出项目关键代码，并解释思路与注释说明。

f) 结合在构建之法中学习到的相关内容与结对项目的实践经历，撰写解决项目的心路历程与收获，以及结对感觉，是否1+1>2。

注：两人都要提交博客，结对共同部分，可在其中一我的的博客给出（另外一我的给出连接），不一样部分分别写在本身的博客中。

3.项目需求说明

实现一个命令行程序，不妨称之为wordCount。

第一步、实现基本功能

输入文件名以命令行参数传入。例如咱们在命令行窗口(cmd)中输入：

wordCount.exe input.txt

则会统计input.txt中的如下几个指标

统计文件的字符数：

只须要统计Ascii码，汉字不需考虑
空格，水平制表符，换行符，均算字符
英文字母：A-Z，a-z
字母数字符号：A-Z，a-z，0-9
分割符：空格，非字母数字符号
例：file123是一个单词，123file不是一个单词。file，File和FILE是同一个单词
输出的单词统一为小写格式

统计文件的单词总数，单词：至少以4个英文字母开头，跟上字母数字符号，单词以分隔符分割，不区分大小写。

统计文件的有效行数：任何包含非空白字符的行，都须要统计。
统计文件中各单词的出现次数，最终只输出频率最高的10个。频率相同的单词，优先输出字典序靠前的单词。
按照字典序输出到文件txt：例如，windows95，windows98和windows2000同时出现时，则先输出windows2000

输出的格式为

·       characters: number

·       words: number

·       lines: number

·       <word1>: number

·       <word2>: number

·       ...

第二步、接口封装

在写了一些代码开胃以后，你们都完成了一份知足基本功能的代码。
你们的代码都各有特点，若是如今咱们要把这个功能放到不一样的环境中去（例如，命令行，Windows图形界面程序，网页程序，手机App），就会碰到困难：代码散落在各个函数中，很难剥离出来做为一个独立的模块运行以知足不一样的需求。
同时咱们也看到，不一样的代码解决不一样层面的问题：

a) 有些是计算数据的（例如统计单词）

b) 有些是控制输入的（例如ReadLine，图形界面的输入字段）

c) 有些是数据可视化的（例如WriteLine）

d) 有些则更为特殊，是架构相关的（例如main函数，并非全部的程序都须要某个特定格式的main）

这些代码的种类不一样，混杂在一块儿对于后期的维护扩展很不友好，因此它们的组织结构就须要精心的整理和优化。
咱们但愿把基本功能里的：

a) 统计字符数

b) 统计单词数

c) 统计最多的10个单词及其词频

这三个功能独立出来，成为一个独立的模块(class library, DLL, 或其它)，这样的话，命令行和GUI的程序都能使用同一份代码。为了方便起见，咱们称之为计算核心"Core模块"，这个模块至少能够在几个地方使用：

a) 命令行测试程序使用

b) 在单元测试框架下使用

c) 与数据可视化部分结合使用

把计算核心在单元测试框架中作过完备的测试后，咱们就能够在算法层级保证了这个模块的正确性。
但咱们知道软件并不是只有计算核心，实际的软件是交付给最终用户的软件，除了计算核心外，还须要有必定的界面和必要的辅助功能。
这个Core模块和使用它的其余模块之间则要经过必定的API来交流。
API应该怎么设计呢？
为了方便起见，咱们能够从下面的最简单的接口开始（仅举例，你的代码里可能没有这个函数）：

public int countChar(String path)

这个函数表示输入path文件路径字符串，返回这个文件的字符数。
假设咱们的Core里封装了这个接口，那么咱们的测试程序能够是这样：

String path = "input.txt";

int count = 100;

Assert(countChar(in) == count);

固然，这样的测试程序并不充分，但愿你们测试时不要像这样偷懒。

第三步、增长新功能

在第三步中，咱们但愿各位在第一步的基础上，添加一些新的功能：

a) 词组统计：能统计文件夹中指定长度的词组的词频

b) 自定义输出：能输出用户指定的前n多的单词与其数量

（1）.-i 参数设定读入的文件路径

格式以下

wordCount.exe -i [file]

一个例子如：

wordCount.exe -i input.txt

（2）.-m 参数设定统计的词组长度

格式以下

wordCount.exe -m [number]

词组定义：m个由分隔符隔开的单词组成一个词组
-m参数与数字配套使用，用于设置词组长度
命令行中使用-m参数，例：

wordCount.exe -m 3 -i input.txt

/*

*要求程序统计input.txt中长度为3的词组，最终输出

*例：input文件中内容为"Monday Tuesday Wednesday Thursday"

*则输出以下

*/

characters: 33

words: 4

lines: 1

Monday Tuesday Wednesday: 1

Tuesday Wednesday Thursday: 1

（3）-n参数设定输出的单词数量

格式以下

wordCount.exe -n [number]

-n参数与数字搭配使用，用于限制最终输出的单词的个数
表示输出最多的前[number]个单词
命令行中使用-n参数，例：

wordCount.exe -n 1 -i input.txt

/*

*程序会输出文件中出现次数最多的那个单词

*/

（4） -o 参数设定生成文件的存储路径

格式以下

wordCount.exe -o output.txt

则将统计信息输出到文件 output.txt中。

（5）多参数的混合使用

在实际测试时，-i 与 -o 参数必定会出现（但文件路径不必定正确），但-n或-m 参数可能不出现，参数之间的顺序并不固定，一个完整例子以下

wordCount.exe -i input.txt -m 5 -n 3 -o output.txt

第四步、附加功能

附加需求：用户交互界面绘制（10'）

如今已经有了一个词频统计程序的命令行版本，若是想让你们都能实际使用它，还须要一个简单的界面。请为大家的程序作一个GUI界面，并附上一个简单的使用说明。界面需正确实现下述功能，会按点给分：

支持两种导入单词文本的方式：①导入单词文本文件，②直接在界面上输入单词并提交（3'）
提供可供用户交互的按钮和，实现-i -m -n -o 这四个参数的功能，对于异常状况须要给予用户提示（3'）
将结果直接输出到界面上，并提供“导出”按钮，将结果保存到用户指定的位置（3'）

以上功能所有正确完成，能够得到10分满分。

【注意】选择完成本附加题目的同窗，须要将GUI与单词计算模块做为两个工程开发，后者能够做为依赖库为前者提供调用接口，但不能够把两个工程直接混在一块儿。 GUI相关的部分也须要提供新的可执行文件，放在根目录的GUIBIN文件夹下。

第五步、错误处理并设计单元测试

如今咱们封装了接口，并增长了新功能，如今咱们要对咱们的代码进行正确性验证。
另外一方面咱们都知道健壮性对于软件来讲是很是必要的，请各位使用单元测试对项目进行测试，并使用插件查看测试分支覆盖率等指标；另外，请准备至少10个测试用例确保你的程序可以正确处理各类状况，而且不会崩溃。
对待错误的输入，可以尽量精确报错（就像编译器同样）。
你能够有“容错性”的出错设计，但必须输出必要的提示或说明。

第六步、效能分析

如今咱们已经有了一个基础的词频统计软件，若是它经过了足够多的单元测试，那它可能也已是一个比较完善的词频统计软件了。可是一个软件光正确了还不够，还须要有必定的性能。
那么，如何让软件又快又好地执行呢？那就须要咱们找到执行消耗时间最久的模块，而后不断地优化改进它。那么，如何知道哪些语句是软件的时间瓶颈呢，这就须要用到效能分析。

如下连接中的Part6部分有效能分析的介绍

http://www.javashuo.com/article/p-gozxhvvr-dq.html

4.评分细则

博客评分规则（总分100）

（1）在文章开头给出大家Fork仓库的Github项目地址。（5'）

（2）在开始实现程序以前，在下述PSP表格记录下你估计将在程序的各个模块的开发上耗费的时间。（5'）

（3） 计算模块接口的设计与实现过程。 设计包括代码如何组织，好比会有几个类，几个函数，他们之间关系如何，关键函数是否须要画出流程图？说明你的算法的关键（没必要列出源代码），以及独到之处。并讲讲你的设计是如何体现“Design by Contract”、“Information Hiding”、 “Interface Design”、 “Loose Coupling”等原则的。（25'）

（4） 代码复审过程。代码互审状况、发现的问题等。（10‘）

（5） 计算模块接口部分的性能改进。 记录在改进计算模块性能上所花费的时间，描述你改进的思路，并展现一张性能分析图（由VS 2017/JProfiler的性能分析工具自动生成），并展现你程序中消耗最大的函数。（10'）

（6） 计算模块部分单元测试展现。 展现出项目部分单元测试代码，并说明测试的函数，构造测试数据的思路。并将单元测试获得的测试覆盖率截图，发表在博客中。（15'）

（7） 计算模块部分异常处理说明。 在博客中详细介绍每种异常的设计目标。每种异常都要选择一个单元测试样例发布在博客中，并指明错误对应的场景。（10'）

（8） 描述结对的过程，提供非摆拍的两人在讨论的结对照片。（5'）

（9）在你实现完程序以后，在附录提供的PSP表格记录下你在程序的各个模块上实际花费的时间。（5'）

（10）附加功能（10'）

5.附录

（1）PSP表格

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

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

一个功能完备的程序不是一蹴而就的。经过将词频统计的需求划分为4个部分，可将一个大任务划分为可操做的小任务，同时最好按照任务难度或紧急程度指定各个任务的完成次序。所以，在动手开发以前，要先估计将在程序各模块开发所需耗费的时间，以及完成整个项目所需的时间，将这个[估计值]记录下来，写成PSP 的形式。
PSP的目的是：记录工程师如何实现需求的效率，和咱们使用项目管理工具（例如微软的Project Professional，或者禅道等）进行项目进度规划相似。
有关PSP的更多内容，请自行阅读邹欣老师的博客：
http://www.cnblogs.com/xinz/archive/2011/10/22/2220872.html

（2） Github

请阅读邹欣老师的博客：http://www.javashuo.com/article/p-gjtthikg-km.html 源代码管理，了解源代码管理的10个实践问题。
本次做业要求使用Github进行源代码管理，代码有进展即签入Github。签入记录不合理的项目会被助教抽查询问项目细节。
对代码签入的具体要求以下：根据需求划分功能后，每作完一个功能，编译成功后，应至少commit一次。本例中，至少应区分基本功能和扩展功能，即分别针对基本功能、扩展功能，编译成功后，总共至少应commit两次。具体的功能划分，请自行定义，并在撰写博客时体现出来，遵循本身对需求的功能划分来提交代码便可。
对Commit不是很熟悉的话，请阅读阮一峰的博客：Commit message 和 Change log 编写指南，了解更多细节。

（3）单元测试

请根据本身以往积累的测试经验，在编码完成以后，提交产品以前，设计测试用例，并编写单元测试，对本身的项目进行测试。
首先，至少应采用白盒测试用例设计方法来设计测试用例，其余测试方法不限。其次，要设计至少10个测试用例，确保你的程序可以正确处理各类状况。最后，结合测试评估的要求，对本身的测试设计进行评价，这些测试用例能知足该程序测试的要求吗？
另外一个重要的措施是要把单元测试自动化，这样每一个人都能很容易地运行它，而且可使单元测试天天都运行。每一个人均可以随时在本身的机器上运行。团队通常是在每日构建中运行单元测试的，这样每一个单元测试的错误就能及时被发现并获得修改。
推荐阅读邹欣老师关于单元测试和回归测试的博客：
http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html

6.提醒

（1）代码不要出现抄袭或者直接拷贝的现象，一旦发现做业将没有成绩。

（2）确保代码可以运行经过，代码不能经过，则博客成绩最多给60分。

（3）博客要体现出本身的思想，每一个人遇到的问题和解决方法以及感得到的感觉都应是不同的，博客出现抄袭或者拷贝现象，一旦发现做业将没有成绩。

7.参考

本做业参考北京航空航天大学发布的做业：结对编程 - 词频统计，在此表示感谢！