、GitHubのプロジェクト住所:https://github.com/blanche789/wordCount/tree/master/src/main/java/com/blanche
二、PSP用フォーム
PSP2.1 |
概要 |
所要時間(分)を完了することを計画 |
完了するために必要な実際の時間(分) |
プランニング |
計画 |
45 |
40 |
推計 |
これは、タスクは、一般的手順を作業に多くの時間と計画が必要と推定しました |
45 |
40 |
開発 |
開発 |
880 |
940 |
分析 |
(新しい技術を学ぶ含む)ニーズ分析 |
60 |
90 |
デザインスペック |
設計ドキュメントの生成 |
30 |
- |
デザインレビュー |
デザインレビュー(と同僚が設計文書を見直し) |
10 |
- |
標準コーディング |
コードの仕様(現在の開発のための適切な規範の開発) |
40 |
40 |
設計 |
具体的な設計 |
60 |
80 |
コーディング |
具体的なコーディング |
400 |
500 |
コードレビュー |
コードレビュー |
30 |
30 |
あります |
検査(セルフテスト、コードを変更し、変更を提出) |
250 |
200 |
報告 |
レポート |
450 |
450 |
試験報告書 |
テストレポート |
360 |
370 |
サイズ測定 |
コンピューティングのワークロード |
30 |
- |
死後&プロセス 改善計画 |
その後まとめ、およびプロセス改善計画 |
60 |
80 |
概要 |
トータル |
1375 |
1430 |
第三に、問題解決のアイデアの説明
1、奇妙な開発が必要である:ちょうどこのトピックを取得するときに、一般的に、より抽象的であり、過去の開発では、相互作用の主要なモードとして、グラフィカルなインターフェイスに基づいていますが、これはコマンドラインになることですされているので、開発プロセス全体のアーキテクチャを変更する必要があるように制御し、対話するためのコマンド。過去には、最初は、グラフィカルインタフェースを記述し、適切な対応するインタラクティブインタフェースを作ることであり、開発の顔を指令、それが入ってくるコマンドは、対応する論理演算を呼び出したとき中心として主要な機能である必要があります
2、アーキテクチャ設計:私はまだ開発する伝統的なMVC開発モデルを使用していたプロジェクトが、主な機能指向の補足の図である。約3分間このプロジェクトでは、層のための主な機能(エントリーコード)、層(-Sミートデマンド)などの様々なニーズを処理する一方(論理)にサービスを表示します。前記メイン処理ロジックにサービス層
図3は、インターフェイスを提供し:この6つの(6つの命令)を必要とするので、統計結果の出力は、4つの要件があるに関係します。だから、私は主に4つの命令のニーズに対応するため、サービス層の4つのサービス実装クラス(実装)を設計しました。4つのクラスを達成するための方法は同じですので、私はインターフェイスを設計しました。冗長コードを避けるために、4つのコール・インタフェースの実装クラスを介してメソッドを呼び出すための便利なJavaの多型の思考を使用して
図4は、正規表現の復習は:私は、需要はコード、コメント行、空白行の行を持って見ると、正規表現がマッチするために、私は確かに必要性を理解し、対応することが必要であるので、文字列を判断するために読んで正規表現の知識を学びます。第二に、文字列は、文字列のJava APIのメソッドは、正規表現について持っているかを決定する必要性を一致させます
図5は、列挙:複数の命令ので、命令がエンティティ・クラスが、時間の複雑さを増すだろうというコールを判断する必要がある場合。だから私は、ロジックを扱うには、地図を通じて対応するサービスをバインドするために、次にストア8つの指示、命令を列挙しますが、減らすために、キーと値の方法を通じて対応する命令を通じて対応するサービスエンティティクラスを得ることが可能ですトラバーサル
6、それはファイルがあります:ユーザーの入力ファイルは、ので、この判断を行うことは、より複雑であるとき、それはディレクトリを提出することも可能であるため、入力に応じて、異なる方法で処理する必要があり、加えて、我々は、追加の必要性を考慮する必要がありますファイルの名前を入力するようにユーザの必要性は、ファイルを操作するために解析される論理的な難しさのいくつかの層にまで追加が増加し、再帰的、
第四に、設計と実装プロセス
1のフローチャート。
2、流程图解析:当运行程序时,用户输入相应的指令(例:-c [fileName]),从而调用main函数,main首先会判断是否需要调用图形界面和是否需要进行递归,方便后续进行不同的操作。然后会根据文件名判断当前文件是否可读;若可读,则调用read函数,传递文件和指令进入这个函数,然后根据指令调用相对于的service对文件进行读操作,从而来对其进行相应的WordCount;若不可读,则会通过正则表达式判断文件名是否含有通配符,若符合条件,则获取其所在的目录,若可递归,则进行递归操作,若不可递归,则对该目录下的所有文件进行WordCount;
3、类的目录结构
4、测试
4.1测试文件
4.2测试结果
4.3代码覆盖率
4.4代码覆盖率细节
5、图形界面
四、总结
本次的个人项目虽然是一个小型的练手项目,但是于我而言,它不仅仅是一个从0到1的过程
在0到1的这个过程中,我融入了软件工程的思想,严格按照PSP表来对整个项目进行规划、架构,于我而言,这个过程是有些繁琐与陌生的,与以往一拿到需求就开发的过程是截然不同的,在这个过程中,我更加明白了前期进行规划的重要性,规划看似在浪费时间,但其实好的规划会让我们的开发达到事半功倍的结果
除此之外,我在此次开发中,多次运用到测试代码,这减少了我在开发过程中处理异常的时间;每当我书写好一个函数或者遇到瓶颈的时候,我就会通过测试代码,来进行测试,从而解决自己的问题,我认为培养在开发中注重测试实例的能力是非常有效的
其次是代码覆盖率,本次的代码覆盖率在类和方法上覆盖率基本达到了要求。但是在代码line的覆盖率上还是比较小,基于原因,还是因为加入了太多的判断条件,导致在测试的时候,不符合条件的代码未被调用,这也提示我在今后的开发过程中,尽量减少条件的判断来实现自己的需求,提高代码的覆盖率。