第二の冬の操作ガイドとヒント
より多くの仕事が関与して第二の面、自己の予備知識が開始できないと感じていないことがある場合は、以下のギブます。この作品の分析
ジョブを完了するためにどのような順番で1本、どこフォーカス
主にGitの、GitHubの使用コード仕様意識、（コマンドラインに基づいて）特定のプログラミング機能、PSP、ならびにパフォーマンス分析と改善単体テストの作業。
私たちは、最初にあなたがPSPに書かれたときに形成することが容易で、自分で時間のかかるの空白のドキュメント統計を過ごした様々なパーツをビルドすることをお勧めします（テーブルの上にPSP、参照作業付録）。
最初の基礎の後に使用することを学ぶ、プログラムを書くためのGit、GitHubのチュートリアルの数を見て急いではありませんした後、運用要件に合わせて独自のディレクトリの例ディレクトリ構造に従って構築された、主な倉庫をフォーク。
ディレクトリの後に建てられた、彼らはcodestyle.mdで書かれたマークダウンフォーマットに従ってコード仕様、コード規格を策定、業務要件に応じて、独自の言語を使用することができます。
そして、あなたは、要件、設計モジュールの分析を開始することができます。需要分析は明らかにそれが可能なプログラムを書くために開始します。
あなたは出力を持っているとき、それはコミットし、githubのにプッシュすることができます。運用要件は、10回のコミットだけでみんなの習慣を聞かせて、あまりないです。
あなたは関数、クラス、タイムリーに行うことにするユニットテストを書かれているために、ジョブは10のテストケースの最小値が必要です。
"公正"の原則を満足、すなわち、FAST（速い）、自動（自動）は、単離された（単離）、反復（リピート）をテストユニットを覚え。どのような具体的なフレームワークと無制限に使用。
ユニットテストは、プログラム開発として、徐々に行われるべきです。あなたの後の変更は、ユニットテストの失敗につながることはありませんことを確認してください。一方、エラー条件と境界条件は、テストに与えられるべきです。
自動テストの動作は、そう入力および出力ファイルは、絶対パスを経由して渡されます。自動テストプログラムでは、あなたのプログラムは、新しいプロセスを開始するとして扱われます。
テストコマンドと、特定のトピックの間に大きな違いはありませんでした。ログは、より複雑なログに置き換えられますときだけでした。
プログラム全体が終了した後、テストの全てが完了しています。いくつかの細胞は、テストカバレッジ分析、パフォーマンス分析かもしれません。
このすべては、PR（プルリクエスト）githubの中のメイン倉庫に倉庫後に完了することができます。
この作業の目的は、将来的には、「双晶」、「チーム」のプログラムの背面にあります。すべてこの技術は、全ライフサイクルを通じてソフトウェア工学に関連しています。
お時間に余裕がない場合は基盤が弱い、あなたがgithubの、コードの仕様、PSP、ユニットテスト、テスト手順の良いフォーカスを持っており、基本的なを通じて努力することをお勧めします（基本listコマンド[30％]：のみ運ぶ-log、-outパラメータ）。
あなたはまだ学ぶための予備の容量を持っている場合、あなたは（あなたが運用要件に沿った倉庫を提出したが作る）などのmaven、Gradleのように、プロジェクトをビルドするビルドツールを使用する方法を学ぶことができます。
2、需要の簡単な分析
主に、入力と出力、テキスト処理上のプログラム。
テキスト処理モードは、正規表現をお勧めします。以下のような~/(\S+) 新增 感染患者 (\d+)人/マッチング福建 新增 感染患者 2人。
モジュラー設計のために、注意する必要があります。
このジョブは、唯一のコマンドリストを完了する必要がありますが、エンジニアリングの観点から考えられていますが、あなたのアプリケーションを拡張することができるようにする必要があります。
あなたは使用することがありますif ("list".equals(cmd)){}正しい方法かどうかを判断するには、このコマンドを、それは単純ではなく、拡大を助長ではありません。
でデザインパターンを使用してみてくださいコマンドモード。
あなたがログに定期的に使用している場合に加えて、あなたは正規表現、それに合わせてログを決定するための方法の種類によってですか？
スイッチモードを使用しないように良い方法。
、状態モード、Chain of Responsibilityパターンでデザインパターンを使用してみてくださいに別のログと異なる操作に対応したLogLineメディアとそれらを一緒にリンクします。
以下のヒントは次のようになります。
/**
* 不同类型日志行
*/
class LogLine {
private Pattern reg;
private LogHandle handle;
// ...
}ジョブのテストユニットは、いくつかのスキルを必要とし、あなたは、あなたのテストリスト機能としての機能試験、の手になりますpublic void list(String logPath, Sting outPath, Date date, List<String> province, List<ArgType> type)
ユニットテストのための便利な一方で、あなたが、それ解体パーサを命じることができるこの方法。（もちろん、これは、良いデザインではないログがリストに読まれるべきではないので、パラメータの検証がある）
が、ユニットテストが容易になります。assertEquals(list(...), new File(...).text)
どのようにあなたはそれがより直感的にデザインするのですか？
あなたのコマンドの構文解析の独立したが、それは（あなたも、実行するファイルからコマンドを読み取ることができる）使用文字列コンフィギュレーションコマンドへの道を提供しています。
/**
* 解析命令行参数
*/
class CmdArgs {
String[] args
/**
* 传入命令行参数数组构造
* @param args
*/
CmdArgs(String[] args) {
//...
}
/**
* 传入命令构造，可以设置无用的前缀，如`groovy Lib`
* @param argsStr
* @param noUseInStart
*/
CmdArgs(String argsStr, String noUseInStart = '') {
//...
}
/**
* 遍历文件的命令，调用闭包
* @param fileName
* @param noUseInStart
* @param closure{ String line -> }
*/
static void eachLine(String fileName, String noUseInStart = '', Closure closure) {
//...
}
/**
* 获取命令
* @return
*/
String getCmd() {
//...
}
/**
* 获取某个命令行参数的值，多个值只会返回第一个
* @param key
* @return
*/
String argVal(String key) {
//...
}
/**
* 获取某个命令行参数的值，返回列表
* @param key
* @return
*/
def argVals(String key) {
//...
}
/**
* 判断该命令是否有对应的参数
* @param key
* @return
*/
boolean has(String key) {
//...
}
}：これは、可能な流れである
> cmdarg（引数） - - > CmdArgCheck - > Log Parserツール- >のDoCmdの- > dolist - > FILEOUT systemin
SystemInがあまりにも多くの変更を加えることなく、TESTINまたはGUIで置き換えたときにも動作することができます。
3、IDEAの簡単なチュートリアル
インポートgithubのプロジェクト：
コミット
githubのプッシュ
インポートは、JUnitの
セットJUnitのパッケージには、あなたの後にダウンロードすることができます。使用して、ユニットテストJUnitの
TestCaseの継承をすることができます。1、2公共ボイド3の戻り値は、メソッド名がtestで始まる：メソッド名は満足する必要がありますコードカバレッジ解析
JProfilerをパフォーマンス分析
私の技術交流グループへようこそ：
