はじめに
この記事は実務で経験した技術をメモ書きしたものとなります。
不定期更新する予定です。
情報の誤り・不足等はコメント欄にてご指摘頂けますと幸いです。
<内部設計(プログラム設計書)>
①共通処理、個別処理の区分け
内部設計を描く際、「共通処理」、「個別処理」に分ける場合、「共通処理」が個別処理を実装するごとに実施されないよう書き方に注意すること。
【例えば】
初期処理でデータ登録先となるテーブルの前データを削除し、データ取得先の各テーブルを呼び出して登録する場合
➡ データを登録後、またテーブル削除を実行する設計にしてしまう可能性がある(そうなると、登録されたデータは最後に取り出したテーブルのデータのみとなり、他はデータ削除されることになる)。
➡ 内部設計者と実装者の間で認識齟齬が発生する可能性がある。
【対策】
・<初期処理>、<本処理>、<後処理>と明示的に分類し、テーブルデータ登録の繰り返し作業は本処理に記述するようにする。
【その他注意事項】
・「共通処理」、「個別処理」と分類する場合、それは設計上見やすいようにしただけなのか、それとも共通クラスから各個別処理が書かれたクラスをインスタンス化し、呼び出すよう促しているのか、といった考慮の上、設計書を書く必要がある。
②暦日と業務日付
クエリやSQL作成の際、Where句に日付指定をする場合がある。
その際に必ず項目定義を確認し、暦日か業務日付かによって空のデータを選択する場合があるのか等、意図しない結果にならないかどうかあらかじめ考慮しておく必要がある。
【対策】
・テーブル項目の定義は必ず確認すること。
・テスト環境などで実際に夜間バッチを回し、どの日付が入るのかを調査してみる。
③共通処理、定数クラス
内部設計に入る前に、必ず共通処理に関する資料、およびソースコードは見ておく。
定数宣言クラスが存在する場合、必要となる定数はそのクラスから引用すること。
④Excel設計書(読み取り推奨)
Excelで設計書を書いている場合、必ず「読み取り推奨」にすべきか確認を取ること。
【読み取り推奨にする方法】
⑤ 数字について
必ず数字について以下のような考慮を行う事。
- 小数点について切り捨て、切り上げ、四捨五入なのか。
- 整数管理の場合も、小数点切り捨て、切り上げ、四捨五入なのか必ず確認すること。
- 0割りについても考慮すること。
- 除算などのルールがあれば、それも確認すること。
※ここをしっかりと考慮しないと、少数第一位がないなど、狂った計算結果になる可能性が出てくる。
※整数にしても合わないなど、そういった事象が発生する可能性あり。 - 余りが出たらどうするか(按分にするのか、など)。
⑥ 共通クラスに関する詳細設計書
内部設計を始める前に、必ずアプリケーション共通定義、もしくは共通クラス一覧などの詳細設計書があるかどうか確認し、あれば関連する共通処理の詳細設計、ソースコードを必ず確認すること。
※ソースコードは大抵、1万行以上ある可能性もあるため必要最小限の確認にとどめること。
➆ メモリ領域設定
メモリ不足エラーが発生した場合、それぞれのローカル環境の空きメモリ次第で微調整する必要がある。
具体的には、「eclipse.ini」を修正する。
【参考サイト】
※今回のメモリ領域設定と関連はないが、『GC』知識を深める資料があったため載せておく(後ほど、別項目に補足資料として移動する予定)
⑧ サーバ公開
一度サーバ公開に失敗した場合、サーバの設定を削除してもう一度サーバを作り直す方が良い可能性もある。
⑨ マジックナンバー
【クエリの場合】
JPQLでクエリを作成する際、Where句などで値を指定するパターンが頻繁に出てくる。
/** あくまで一例(@NamedQueryや@NamedNativeQueryなどに記述) */
@NamedQuery(name="name", query="select e from テーブル名 where e.sample="0"")
こういった場合、クエリに直接値を指定するのは良くない(マジックナンバーとして扱われる)。
必ずクエリパラメータとして設定し、呼び出し側に内部定数として定義し、パラメータセット時に使用した方が良い。
/** Entityクラス側 */
@NamedQuery(name="sample", query="select e from テーブル名 where e.項目名=:sample")
/** 呼び出し側クラス */
private static final String SampleCode = "0";
@persistenceContext
EntityManager em;
public List<Entity> getBysample() {
return em.CreateNamedQuery(sample, Entity.class)
.setParameter("sample", SampleCode)
.getResultList();
}
※クエリパラメータは配列でも指定できる。
クエリ側でIN句を使用して複数の値を条件値とすることが可能。
【補足資料】
⑩ 頻出する複数値の条件
・頻出する複数値については、必ずList型変数に格納すること。
例えばデータ件数取得時にwhere句に複数の条件値を設定する場合、条件値として事前に変数に格納し、引数に配置すること。
<製造>
①SVNのコミットについて
コミットタイミングとしては、朝一番が望ましい場合もある。
始業時に自分の編集したソースファイルをリモートリポジトリにコミットし、その後、開発チームの誰かにリポジトリをチェックアウトしてもらい、エラーが吐かれていないか確認する。
【もしエラーが検出された場合】
他開発メンバーがコミット前の情報をコミットし、エラーが吐かれていない状態へとロールバックさせる必要がある。
【自身が原因でエラーを出さない方法】
ソースコード編集後、Eclipseのビルドによりコンパイルエラー等が出力されていないか必ず確認すること。エラーが出ている場合はコミット前にエラーを除去し、その後にコミットを行うこと。
②SVNプロジェクトチェックアウト後の必須対応について
チェックアウト後、必ず以下の作業を実施すること。
- 対象プロジェクトに対してF5キーで簡易クリーンを行う。
- 簡易クリーン実施後、プロジェクトタブからクリーンを実行し、対象プロジェクトのクリーンを実施すること。
※クリーン作業を行うことにより、処理速度の向上、およびエラーの再確認を行うことが出来る。
③階層不整合のエラーが表示された場合
SVNプロジェクトをインポートした際、不適切なパス指定を行っていた可能性が高い。
その場合は対象プロジェクトを右クリックし、削除を行うこと(ディスクから削除するか、といったチェックボックスには必ずチェックを入れること)。
そして再度対象プロジェクトをインポートするが、そのさいに適切なパス指定を行っているかどうかをリーダーもしくは他エンジニアに確認をとり、そのパス指定でインポートを行うこと。
④共通定数クラス
プロジェクトによっては共通定数一覧を凝縮させたクラスが存在しており、共通定数を使用する場合はそのクラスをインポートし、定数使用時には『共通定数クラス.定数名』で共通化していく。
これにより、各クラスごとに同じ定義の定数にも関わらず、独自の内部定数を作成するという問題は解消される。
⑤バージョン管理「Tortoise SVN」での管理について
- SVNの更新はEclipse画面から実施。
・プロジェクトを右クリック➡チーム➡リポジトリ―と同期化➡同期化される
・青印のソースファイルを右クリックし、更新を押下して更新する。
※自分の更新したソースファイルは灰色印となっている(コミット対象) - SVNの更新は朝一番に実施(ソース修正の競合を防ぐため)
- コミットについては当日中に完了させ、当日内にチェックアウトによるコミット漏れ確認依頼をする。
- コミットコメントについては、プロジェクトごとの書式に従うこと。
- Eclipseから青印ファイルのSVN更新を実行したとき、ファイルがロックされている、更新できないなどの問題が発生する可能性がある。その場合は、ファイルシステムからクリーンアップをすれば解消される可能性あり。
- 対象プロジェクトをエクスプローラーから右クリック
・TortoiseSVN➡クリーンアップを押下
・以下の項目にチェックを入れ、OKを押下
◆作業コピーの状態をクリーンアップ
◆ロックを強制解除する
◆シェルのオーバーレイを更新
◆外部参照を含める - 無事SVN更新されることを確認する。
⑥工数管理について
- 製造については、以下の工程で進めていくことになる。
内部設計書をもとに機能を実装(一部機能実装後にレビューを推奨)
※レビュー中にUTテストに向けて以下を実施。
①テストケース作成
- 分岐網羅(カバレッジ100%を網羅すること、データパターンを網羅)。
- メソッドごとにケースを作成する
②テストデータ作成
- データについてはデータ型に基づき、隙間なく埋めること(出力時にぬけがないか確認するため)。
- 条件値通りにデータ値を入力すること。
- バッチ実行後、出力されるデータは必ず複数存在する想定。
複数パターンのデータを一つの入力とし、一度の出力時に複数パターンの確認する。
③テストコード実装
- 未実装のクラスを使用する必要がある場合、モックを作成する。
④テスト環境構築
- JUnit起動確認
- カバレッジレポート生成確認
- 実装コード、テストコード作成完了、UT(カバレッジ100%網羅)、レビュー通過で完了。
➆UTに影響すること
コンパイルエラーの状態でSVNコミットを実施しないこと。
もしコミットした場合、他開発担当者のUTテストなどに影響する。
この場合は、コンパイルエラーの原因となっているソースコードをリビジョン番号から履歴で確認し、その対象となるソースファイルをローカル環境から削除することを推奨。
⑧Eclipseでよく使うショートカット
【参考サイト】
※リソース検索、行番号指定はよく使う。
以上となりますが、今後もナレッジが溜まり次第、更新する予定です。