レビュー内容
出社して業務をしていると、他人のレビュー指摘が聞こえてくるときがあります。
よく聞こえてくるのは下記の通り。
- 分岐処理が漏れてる
- この変数はどこで定義しているのか
- 前回指摘した箇所が直ってない
私がレビューするときも、上記はよくありました。
「1」はロジックが複雑だと発生してしまうので割愛しますが、
「2」以降は私が気を付けていることを記載していきます。
気を付けていること
この変数はどこで定義しているのか
これは設計書のレビューで発生します。
他人の設計書を見たことがあるなら「xxxフラグが0なら...」というような記述を何度も見たことがあるのではないでしょうか。
読み手からしたら下記疑問が生じます。
- xxxフラグというのがいきなりでてきたんだけど、どこで設定したの？
- 0以外にどの値を持つの？
xxxフラグというのがいきなりでてきたんだけど、どこで設定したの？
いろんな種類の設計書を見てきましたが、1処理につき1つの項番が割り振られていました。
同じタイプの設計書であれば「1-1(項番)で設定したxxxフラグが...」というように記述すれば設定箇所が伝わると思います。
下記のような記述でも伝わると思います。
- 変数を用意する必要がある箇所は目印をつける
- Excelの設計書であれば、特定の列に変数の設定をした旨を記述しておく
0以外にどの値を持つの？
xxxフラグというのがテーブルから取得した項目であれば、DB関連の設計書を見ればどの値を持つか確認することができると思います。
ですが、処理を分岐させるために独自のフラグを用意したのであれば、そのフラグが持つ値と値が持つ役割について他者は理解できないです。
独自のフラグに対して初期値設定の記述している箇所に、保有する値の種類と役割について記載します。
テーブルAとBを参照して、登録されているかで処理を分岐するフラグのようなものを使う場合、下記のような宣言を記述します。
- 0:テーブルA,Bどちらにも登録されていない
- 1:テーブルAのみ登録されている
- 2:テーブルBのみ登録されている
- 3:テーブルA,Bどちらにも登録されている
前回指摘した箇所が直ってない
忘れてただけなら仕方ないです。次から気をつけましょう。
ただ、多くの人が忘れていたのではなく、指摘内容を理解できていない気がします。
これは指摘内容を理解できるまで質問したり、指摘内容を整理後に認識があっているか確認をしましょう。
指摘内容を理解できてない状態で自分でもよくわからない修正をすると、次回レビュー時にその記述を指摘されることになります。これを繰り返すとレビューの指摘対応が終わらないという状態になります。
指摘内容を整理して現状の認識と合わせることで、指摘内容が明確になったり、逆に矛盾の発生に気づけたりするので、指摘内容は一度整理したほうがいいです。
他者への配慮
設計・実装担当者自身が理解できないものは、数か月後の自分や引継ぎ先担当者が見ても理解できないので、未来で設計書やコードを見る人に向けて記述をするようにしましょう。