レビューするときに気を付けること
n次レビューか知りませんが
基本的にはミスをレビュワーが止めなければなりません
責任の大きな作業ですね...
レビュー対象を要件資料、見積もり資料、設計書、コード、試験仕様書の4つに分けて
以下に自分なりの観点や心得をまとめました
1.要件
まぁ本当にケースバイケースですので、特殊解を想定していきましょう。
現行システムに、他システムとの連携機能を追加する要件を決めるものとします。
この場合、連携システムが両者とも現行を持っているので、
完全新規のIF追加と比べて、既存を使いまわせるがどうか、を考慮する必要もあります。
また、追加した場合の既存への改修のあたりが最も小さくなる道を選びたいですよね。
システム間連携はつまるところDB同士のCRUDですので
・各々の主キー
・レコードを特定するに足りる一意キー
・連携項目増加に対応させるカラム
・連携履歴を記録するための他シス連携タイムスタンプ(任意)
あたりが重要になるかと思います。
特にキーが不明、などの場合は連携不能ですので、一刻も早く特定するための情報が何かを知る必要があります。
IFやフロー図、項目が決定された場合
・自システムにとって実現可能か
・他システムにとって実現可能か
・既存のシステムが崩れないか
・今後の改修の際に向けた汎用性があるか
・なるべく既存を流用できる仕組みになっているか
・障害発生時に力技でどうにかできる手段を確保できる状況になれるか
を基準に精査していきましょう。
最終的にやりたいことさえできていれば、多少ログや画面が荒れてもセーフになれる力技を、
念のために確保しておきたいですね
2.見積もりレビュー
要件が決まった段階で、恐らくレコードが通る道のパターンが分かると思います
また、フロー図から、実際のコーディングに必要なステップ数、作業量もおおよそ検討が付きますね
ステップ数と工数は直接的な関連を持たないように思いますので
あくまでなんかこう、密度？的なものを含めたコード量で考えます
製造にかかる時間と、テストで全正常系ルートを網羅させ、いかに異常系をこなすか
それらを鑑みたうえで、途中で要件が変わる場合や
どうせ実装中に何か不祥事があって手が止まることがありますので
それらのバッファを鑑みた工数
よりも
ちょっと多めになっているのが理想ですね
かといって多すぎてもいけませんので
経験がものをいう工程であるというのも納得です
パレートの法則的に、時間に余裕があったとて作業効率が上がるわけではないことは確かですが
かといって過密スケジュールすぎて、納期に間に合わないよりはよいです
それに少数の方が統計的に良いみたいな話をどこかの本で読みました、まぁコミュニケーションラインの問題ですね
3.設計レビュー
要件は、何もない荒野に道を切り開くようなものですので、考慮漏れがないように時間をかけますが
設計作業では、要件を網羅しているかどうか、という絶対的なラインがあります
まずは不足がないうえで
要件を満たすための処理群を作成していきます
また、実際のコードがより共通処理を抜き出し、処理性能もよく、改修もしやすくなるように
詳細なフローを設計します
常に正解が要件資料になるので、漏れがないかをしっかり見比べる作業になるでしょう
どんな工程でも同じですが、この段階で不足があると、下流工程全てに影響しますので
必ず機械ができることは機械に任せましょう
参考
4.コードレビュー
コードのレビューについては様々、先人達の虎の巻があるかとは思いますが
設計を満たしていることが何より重要ですよね
個人的には、おおまかに以下が守られていればよいと思います
・みためがきれい
・無理やりつなげすぎてる感がない
・無駄がない
人によって基準が違うあいまいな言葉ですが、これこそが「読みやすさ」の正体です
結局人は見た目なのです
あとは処理の話で
・文法ミスがない
・トランザクションが適切
・ループ内で重い処理をしない
・要約された過不足のないドキュメント、コメント
テーブル項目が欠損していないかなどを確かめる際は
コーディングする人がどういう方法を使っていようと
レビュワーは必ず定義書から機械的に作成したものと比較する必要があります
また、GitやWinmergeでの差分確認、スピード感のあるドキュメント整理が求められます
コミット履歴やブランチの管理など細かい作業も含め、効率が要求されます
参考
項目精査
Git
DDL
テキスト編集
eclipse
Excel
スプレ
サクラ/正規表現
5.試験仕様書レビュー
試験はあらゆるパターンを考慮されていなければなりません
要件資料と設計書から、まずは試験観点が網羅されているかを確認します
正常系は既に作成された要件資料や設計書にさんざん書いてあるので漏らしにくいですが
異常系を想定するためには
・コード依存
・インフラ依存
・運用依存
の潜在エラーをそれぞれ考慮する必要があります
たとえばIFで想定されない値が来た場合、通信網の疎通がなぜか途絶えた場合、運用で想定しないことをされた場合
どうせしない挙動に対してのバリデーションや、起こる確率が極めて低くとも起きても大丈夫な保障がなされているか
を観点としたテストが作成されている必要があります
観点が網羅されていることを確認したのちに
テスト手順、テストデータ、期待値がそれぞれのケースにおいて適切であるか
を、要件資料、設計書、コードを見ながら判定していきます
大切なのは、しっかりと全ての資料との整合性を取ることです
現場猫みたく、どこの工程でヒューマンエラーが発生しているかわかりません
試験は本当に最後の砦ですので、より一層精度の高い、厳しいフィルターを作成する必要があります