彼の第四の仕事

githubのプロジェクトアドレス
協力の学生はアドレスを働きます

パート1. PSPフォーム

PSP2。	パーソナルソフトウェアプロセス段階	推定時間がかかる（分）	実際の時間がかかる（分）
プランニング	計画	60	80
・見積り	•このタスクが必要と推定どのくらいの時間	60	80
開発	開発	700	785
・分析	・分析（新しい技術を学ぶ含む）が必要	60	45
・デザインスペック	設計ドキュメントの生成	30	45
・デザインレビュー	・デザインレビュー（と彼の同僚は、設計文書を見直し）	30	30
・コーディング標準	・コードの仕様（現在の開発のための適切な規範の開発）	30	25
・設計	・具体的な設計	40	40
・コーディング	・具体的なコーディング	300	400
・コードレビュー	・コードレビュー	90	80
・テスト	・テスト（セルフテスト、コードを変更し、変更を提出）	90	120
報告	レポート	90	120
・試験報告書	・テストレポート	30	60
・サイズ測定	・コンピューティングのワークロード	30	40
・死後＆プロセス改善計画	・後知恵、およびプロセス改善計画を提案します	30	20
	トータル	850	985

パート2計算モジュールインタフェースの設計と実装

まず、問題解決のためのアイデア

文字統計：文字が空であるかどうかを判断横断、空の文字は、文字の合計数の統計を蓄積していません
ワードカウント：最初の統一された場合、単語、例えば：ワード、WORD、Wordが同じ単語である、我々は小文字に大文字に変換します。そして、単語統計の単語数は、文字列配列に文書内の文字は、文字列の配列は、異なる数に1を加えた比較図を決定します。
行統計の数：空白行かどうかを判断するためにトラバーサルは、空行の行数は、非空の行の統計情報を蓄積していません。
単語頻度統計：それぞれの単語の数と、<文字列、整数>のセットに単語の頻度、単語と単語の頻度。辞書式ソートは、すべての単語の頻度に行きました。単語の数最終出力周波数と数の一定数。
統計フレーズ長さ：単語および単語頻度統計の長さに応じて、方法は、単語と単語の長さはそれぞれ、セット<文字列、整数>に格納されています。長さは、見つけるこの長さのすべての単語をプリントアウトする単語を取得します。

そのため、設計プロセスでは、我々は、機能を2つのカテゴリに分類され、このプログラムを置きます：

1.基本的な機能。によって：

文字は、ファイルを数えます。
文書の総単語数。
行統計的文書の有効数。
各単語の統計ファイルの発生回数。
辞書式順序でtxtファイルへの出力。

2.新機能。によって：

指定したフォルダのフレーズの長さの単語の出現頻度の統計。
多くの単語とNの量の出力前にユーザによって指定されました：
1. パラメータ設定ファイルには、パスを読み込みます。
2. 設定し、フレーズの長さのパラメータの統計。
3. 出力パラメータは、ワード数を設定します。
4. パスパラメータ設定の保存ファイルを生成します。

第二に、コードの組織

次の表に示すように、本プログラムの実施中、10クラスの機能16を含みます。

クラス名	機能	機能
プログラム	メイン	メイン：ユーザーがコマンドパラメータを処理するかどうかを選択します
select_way	命令nointrctionのthe_error	命令：処理パラメータのために必要な指示であれば。nointrction：処理パラメータのために必要な指示であれば。the_error：異常のための処理
ファイルパス	ノー	文の入力および出力ファイルパス変数
結果	print_char print_word print_lines print_wordsort print_selectedlong	print_char：文字出力の数。print_word：言葉の出力合計数。print_lines：有効ラインの出力数。print_wordsort：出力ワードソート。print_selectedlong：所定の長さの単語を検索します。
asccII_count	ascciicount	ascciicount：文字の数をカウントし
単語数	word_sumのword_frequency	word_sum：高頻度語を印刷します。word_frequency：単語の頻度を印刷
LINE_COUNT	ライン	行の統計ファイルの数：行
ins_process	ins_select ins_right	ins_select：对于用户选择的指令参数进行处理。ins_right：对已选择的指令进行相应的赋值
uniform_character	uncharater	uncharater：统一字符大小写

函数之间的关系可用下图表示：

最后，附上用户交互界面：

Part 3.代码复审

一、代码规范

1.命名约定

对于类名和变量名，我们都采用“aa_bb”的命名方式，其中aa表示变量名，bb表示操作名。

2.注释约定

将注释放在单独的行上，而不是放在代码行的末尾；

3.布局约定

使用默认的代码编辑器设置（智能缩进，四字符缩进，制表符另存为空格）。
每行只写一条语句；
每行只写一条声明；
如果连续行没有自动缩进，请缩进一个指标位（四个空格）。

二、代码互审

在代码互审过程中，我主要关注的是具体功能是否能够实现、代码是否符合规范、异常处理以及代码的结构。在代码互审的过程中我们遇到的问题以及改进方法如下：

原来版本打开exe文件只能进行无指令操作，经过改进，我们可以进行选择，既能无指令操作又能有指令操作。
原来版本的代码结构的方法比较简单，即就几个大的功能的类，没有细分功能的实现，改进后，我们的代码结构更有逻辑性，能容易理解，方便团队协作。
原来版本的对异常的处理比较少，对于许多错误指令没有考虑，没有提示，改进后，我们会加入错误指令的提示。

Part 4.计算模块接口部分的性能改进

在改进计算模块性能的过程中，我们发现的问题以及改进思路如下：

1.对统一字符的处理，原来需要对一个单词的每一个字符用for循环来依次判断，再对产生的flag进行判断，而这样的对时间和空间的占用率较高，我们将去到for循环，对一个单词统一判断，减少判断次数和循环次数。提高代码的运行速度。
2.对于使用率较高的word_wore和word_len两个参数，原来是放在一个类里面，导致其他地方调用十分复杂，所以我们对两个参数进行封装重构，减少了代码的臃肿。

使用VS的性能探查器得到的效能分析报告如下图：

从上图中我们可以看到，result类中的print_char函数在总CPU耗时中占用了56%左右，由于print_char函数只是由打印语句和调用line_count中的lines函数构成，所以在总CPU耗时最多的函数等价为lines函数。

Part 5.计算模块部分单元测试展示

对word_count类中的word_sum方法进行测试：新建一个字典集合，向集合中添加一个单词，比较添加后的情况。

public void Test_word_sum()
{
//
// TODO: 在此处添加测试逻辑
//
Dictionary<string, int> frequen = new Dictionary<string, int>();
file_path.output_path=@"E:\GITwrod\WordCount\201731062322\WordCount\UnitTest_WordCount\testoutfile.txt";
string a = "word";
frequen.Add(a, 1);
//frequen.Add("word",1);
Assert.AreEqual(1, word_count.word_sum(frequen));
// Assert.Fail();
}

对字符统计的测试：读取文件内容（该文件为空文件），比较文件中的字符数与人工算出的字符数是否相等，相等则测试成功，否则失败。

public void TestMethod1()
{
//
// TODO: 在此处添加测试逻辑
//
file_path.input_path = @"E:\GITwrod\WordCount\201731062322\WordCount\UnitTest_WordCount\testfile.txt";
int num = 0;
Assert.AreEqual(num, asccII_count.ascciicount());
//Assert.Fail();
}

IZGG$XA5V9S1A5JX.png)

3.对行数统计的测试：与测试字符数的方法类似，读取文件内容（该文件为空文件），比较文件中的行数与人工算出的字符数是否相等，相等则测试成功，否则失败。因为本程序是除去了空行的，所以当没有显示的字符（空格不显示）的时候为零行。

public void TestMethod1()
{
file_path.input_path = @"E:\GITwrod\WordCount\201731062322\WordCount\UnitTest_WordCount\testfile.txt";
int x = 0;
Assert.AreEqual(x, line_count.lines());
// Assert.Fail();
}

Part 6.计算模块部分异常处理说明

在本程序中，异常处理主要是针对用户输入的异常处理：

1.在选择是否使用指令参数时的异常处理。如果用户输入了不存在或者错误的选项，则报错：

switch(cmd_num)
            {
                case 1: select_way.instruction();
                    break;
                case 2: select_way.nointrction();
                    break;
                default: select_way.the_error();
                    break;
            }

public static void the_error()
        {
            Console.WriteLine("the error instruction");
            Console.ReadKey();
        }

2.在输入指令参数是的异常处理。如果用户输入了不存在或者错误的参数，则报错：

else
            {
                Console.WriteLine("the wrong instruction");
                Console.ReadKey();
            }

3.在没有输入输入文件路径时的异常处理。如果用户没有输入输入文件路径就要进行下一步，则报错：

if(x%2==0)
                {
                    Console.WriteLine("need a input file");
                    Console.ReadKey();
                }

Part 7.描述结对的过程

Part 8.心得体会

在项目编写中，我主要负责的功能模块是行数统计和字符统计，代码逻辑不是很复杂，采用的暴力搜索求解，但也由于这个原因，导致我写的这两个功能在占用总CPU耗时方面都是最多的，想要改进却也无从下手，下来应该多多学习。

在合作的过程中，由于是分工行动，两个人产生的分歧不多，在互审时通过同伴的提醒能够发现自己的不足，并加以改进，我认为这是一个人做项目很难自己发现的，而且能一定程度的提高代码的质量。这次的结对编程我认为对以后的团队项目打下了合作的基础，让我意识到该如何高效的合作、和平的合作，毕竟团队合作也能转换为多个一对一合作。

所以我认为：1+1>2。