WC数えるプログラムの概要

資料の冒頭に記載されたアドレスのGitHubプロジェクト: https://github.com/ppp-203/wc

第二に、問題解決のためのアイデア

次の表のIデザインのアイデア

ブロック

実現

文字の数

印刷可能な文字を探します

語数

Wordの文字認識(2以上)

それともおよびI

行数

 

改行文字認識

インポートファイルの内容(読み取り)

BufferedReaderの実現

治療のディレクトリ適格なファイルの下で

OK再帰条件:現在のファイルがディレクトリであります

空行

これ以上行以上を含む印刷可能な文字は、検索します

コメント行

コメント文識別子ではなく、コードの文を含む行を探します

コードの行

文字を表示することができますつ以上のコードステートメントを含むエントリを探します

メイン(主機能、テストと呼ばれます)

 オブジェクトの作成とテスト

 

第三に、設計と実装プロセス

1、言語の使用:JAVA

2、設計時間の前半:

  私は最終的に、このメソッドをあきらめたので、私は、非常に簡単なミスにあるとごちゃ混ぜのif-else文を使用しようとするが、設計プロセスを発見した、さまざまな状況があれば、他のコードを使用して、そこにあります

3、後半の設計時間:

  正規表現の使用 - 私は方法の別の高い実現可能性を発見し、オンラインの方法を探します。私は、正規表現、およびPatternクラス、Matcherのクラスの使用法について学び、そして最終的に3つのカウント数を達成するために、この知識を使用し、様々な状況を識別します

 

第四に、コード説明

基本的な機能を実現します:

 

 

 

機能実現:

 

 

 

 

補助インタフェース:

 

 テスト:

  

 

第五に、テストの実行

示されるようにテストケース:

 

試験結果は次の通りであった:入力形式wc.exe [parament] [ファイル名]を

 

 

ユニットテストカバレッジ基本機能と拡張機能:

  

 

 

第六に、推定時間と支出の時間

PSP2.1

パーソナルソフトウェアプロセス段階

推定時間がかかる(分)

実際の時間がかかる(分)

プランニング

計画

 

 

・見積り

•このタスクが必要と推定どのくらいの時間

 1230

 1400

開発

開発

 

 

・分析

(新しい技術を学ぶ含む)・ニーズ分析

 120

 分析:40

学習:200

・デザインスペック

設計ドキュメントの生成

 40

 30

・デザインレビュー

・デザインレビュー(と彼の同僚は、設計文書を見直し)

 40

 20

・コーディング標準

・コードの仕様(現在の開発のための適切な規範の開発)

 40

 10

・ 設計

・具体的な設計

 60

 60

・コーディング

・具体的なコーディング

 360

 300 + 240

・コードレビュー

・コードレビュー

 60

 80

・テスト

・テスト(セルフテスト、コードを変更し、変更を提出)

 240

 150 + 120

報告

レポート

 

 

・ 試験報告書

・テストレポート

 180

120

・サイズ測定

・コンピューティングのワークロード

 30

 10

・死後&プロセス改善計画

・後知恵、およびプロセス改善計画を提案します

 30

 20

トータル

 

 1210

 1400

 

VII。まとめ

1、事前のオプションを比較するために、(可能な限り多様など)のプロジェクトを達成するために、関連する方法を理解します。これは、多くの時間を節約し、時間の浪費を避けることができます

2、この個人的なプロジェクトは、私はユニットテスト、回帰テストを行う方法を学びました、バグのためのテストが有用であることが判明しました。

図3は、常に一般的なプログラミングの個人的なプロジェクトをやるべき仕事とは私の経験を与えた非常に異なっています。私は、プラグインを使用することを学ぶのGithubなどの機能を実現するために、テストだけではなく、通常の書き込みコードを実行する必要があります。

4は、私が書いたプログラムのためにも、これらの日変更試運転の後、多くは完璧だったが、いくつかの場所でまだ抜け穴がある、唯一の特殊な状況のテストのためのより一般的なC言語ファイルを満たすことができ、存在がたくさんあります不十分。

おすすめ

転載: www.cnblogs.com/mbya/p/12499583.html