参考
- PMワークベンチ
- プロジェクト開発時の品質管理や進捗管理
http://www.nttdata.com/jp/ja/insights/strength/quality.html
用語
- DOA
- データ中心アプローチ。Data Oriented Approach。
業務で扱うデータの構造や流れに着目し、システム設計を行う手法。
- RAD
- Rapid Application Development。
プロトタイピングなどの手法を用いて，ウォータフォール型に比べて短時間でシステムを完成させること。
論理展開のチェック
- 根拠の情報は正しいか？恣意的に都合のいい情報だけ選んでいないか？
- 結論を一部しか説明できない理由で論理展開していないか？
- 「AだからB,よってC」 のBを抜かしていないか。聞く人みんなBを知っているか？
- 事実に対して適用できない論理を使っていないか？
例：一般論：サーバの処理能力とアプリケーションの処理能力は比例する。
事実：とあるとても遅いアプリケーションがあり、ユーザから改善を要望されている。
結論：サーバ能力を増強する。) - 根拠の情報は十分な数を揃えているか？一部だけをみて帰納展開していないか。
- 結論が、論理展開に出てきた以外の事象へ与える影響を考慮しているか？
例：一般論：３６協定により９０時間を越える残業をしてはならない。
事実：A君が９０時間を越える残業を５ヶ月続けている。
結論：直ちにA君に強制的に休暇を取らせる。
発生した悪影響：A君以外の担当者が９０時間以上の残業を行った) - 1.～6.全てを厳密に記述しすぎて、論旨が不明確になっていないか。
規約
用語集
用語集は必ず作成する。
この用語集は誰でも常に閲覧するような場所・資料とし、
いつでも編集されるようにする。
これで随時共有される。
コーディング規約
- 実装する際の単語
- フルスペル、英訳。これも用語集で統一を取る。
- インスタンス変数
- アンダースコアで開始。
- クラス変数
- _classで開始。（または__で開始？）
- コメント
- //のみ。/** */、/* */は禁止。（クラス、メソッド、変数前のJavadoc除く）
- Checkstyle, Findbugs
- 他にはこれらツールを導入することで他のスタイル違反は禁止する。
(if文の連続、１メソッド行数等)
なお、事前にルール決めと、そのルールにした理由・改善方法を資料化する。
また、Dailyによる自動チェック、工程ごとの再チェックを行うことで違反漏れの放置をなくす。
- コードフォーマッター、コードテンプレート
- 事前にEclipse設定を定義し、エクスポート・インポートで共通化する。新規ファイルテンプレートなど。
- Javadoc
- 基本的にはすべて<pre>タグにしてしまい、記述を楽にする。
Javadocはhtml化して閲覧するためではなく、ソースを見た人のために、クラス概要把握、ロジックを追えるようにするために用意する。このためhtml化は特に不要。htmlのための記述はしなくて良い。ロジックを追うための記述レベルでOK。
例えば@return、@exceptionは必ずしも必須ではない。フラグ値等でわかりにくい場合のみ記述で構わない。
Checkstyleルールにこれらの警告を出さないという基準としても良い。
@date、@version、@authorは不要。(Eclipseのヒストリーで確認可能)
- 修正コメント
- 修正開始・終了などの修正履歴がわかるコメントは不要。これらはヒストリーで確認。
ただし理由があって以下の動作をしているなど、説明すべきものはコメントに記載する。
- 参照範囲
- 変数の参照範囲を最小限にする。例えば変数宣言は必要になった時に行う。最小のブロック内に宣言するなど。
- 修飾子
- メソッドはprotected、インスタンス変数、クラス変数はprivateをデフォルトとする。
- 文字列の連結
- ループ内で処理されないようなものは + でOK。(コンパイル時に自動的にStringBuilderにしてくれる)
ループ内で処理されるようなものはStringBuilderを利用。StringBufferはsynchronizedされるので使わない。
- 文字列操作
- 基本はcommons-langのメソッドを利用する。
業務共通的に利用するような関数はあらかじめ共通クラスを作成し定義する。
特にString.replaceAll()は使わない。これは正規表現を使うため大量呼出されると性能影響が出る。
単純な置換であればString.replace()でよい。(これでも複数置換される)
- プリミティブと文字列の変換
- new Integer("String")の禁止。Integer.parseInt("String")を使う。
String.valueOf(int)を使う。
doubleの場合、2.13E10などの表記になってしまうので、小数桁に注意しフォーマッタを使うこと。
- doubleの桁落ち
- double、floatは桁落ちしてしまうため使用しない。
BigDecimal等を使う。
- ロック
- オブジェクトロック（synchronized）、DBロック（SELECT FOR UPDATE）する場合は必ずロック一覧の設計書を作成すること。
使用場所、ロック対象、開始タイミング、解放タイミングなど
- 非推奨APIのチェック
- Checkstyleルールでチェックする。
String.replaceAll()、StringBuilderなど。
- 他者が30秒で理解できるメソッド
- メソッドは他者が30秒で理解できる程度が望ましい。
なお、50行以上のメソッドはまず30秒で理解できない。