0.レビューについて書いてみたい

お疲れ様です。
現在の現場で他の方が開発されたものの
レビューを担当させていただいているへっぽこエンジニアです。
なお、まだまだ経験の浅い初心者なのですが、
自身の今後のためや、他にレビューを担当される方、
今後レビューを受けることが増えるかた、
エンジニアになったばかりの方向けに伝えたいと思い記述してます。

「レビューを担当してる」って話をすると
「そもそもレビューってどうやってるの？」
「複数人のチームでやってるんだよね？どうやるの」
といった「レビューの観点」や「レビューの方法」に
関する議論をしていたので、ちらっと書いてみたいと思います。

1.そもそもレビューって何なんだ？

１再調査。再検討。
２批評記事。文芸・芸能などに関する評論。論評。また、評論雑誌。
システム開発において、工程ごとに成果物の品質を検証する会議。レビューの方法には、開発に携わった者を集めて検証を行うウォークスルー、責任のある第三者が検証を行うインスペクションなどがある。
引用：http://ikikatadatabase.com/archives/5409

ざっと要約すると

　作ったものの検証・評価

というのが妥当な線でしょうか。
経験のない方にはイメージがつきにくいと思いますが、
設計書・ソースコード・テスト仕様書・テストコードそれぞれ作成後に
上位のレイヤーの方にそれぞれの成果物を見せる場合があります。
そのことを

レビューを受ける

といいます

2.なんでレビューって必要なの？

「正直このソースコード見せるの恥ずかしい…」
「間違ってたらどうしよう…」
すごく共感できます。むしろ胸とか耳が痛い。

でも、一度でもレビューを受けたことがある方はご存知かと思いますが
「意外と考慮が漏れてしまってるな」って思ったこと、ないでしょうか。
（ないという方は本当に考慮が上手なのだと思います。
　考慮の方法を教えてください。お願いします）

ソースコードを書いてるとソースを作ること、
ロジックを作ることに夢中になって例外の考慮やNULLチェック等
基本的なところの考慮が漏れる場合が往々にしてあります。
第三者の目線から見ることでそういった

・考慮漏れ

・ロジックの簡略化、軽量化（無駄なソースを削る）

・根本的にバグを減らす

上記のようなことを行い品質を上げること。
そのことがレビューの大きな意義と考えています。
（これで全部とは言いません。まだまだあると思います）

3.レビューのしんどさ

シンプルに物量が多いと

きつい

10000ステップ近いコードになるとむちゃくちゃ時間かかります。
普通に作業していて他の人のソースコードを読むときもあると思いますが、
レビューとなると細かなところまでチェックしなくてはならないので
読んでる最中に「あれ？この処理なんだっけ」とか発生します。

複雑ではないコードでも簡易なコードでもどちらでも発生します。
後は、同じ処理が続くとミスに気づきにくいです。
（変数名違うのを使用するはずが、見逃す、等）

なので、途中でブレークポイントやマーカーを使いながらうまく
どこまで読んだか把握したり、処理の分岐を意識して理解・レビューするようにしてます。

・指摘の仕方が悩ましい
指摘する際も一方的に「こうして」「こういうふうにして」というのは
非常にレビューイ（レビューを受ける人）からあまり良い印象を受けないと思います。
なので、「こういう風にしたら○○になると思うけど、これじゃだめ？」とか
「こういうロジックの理由は？」というふうに伺うようにしてます。

私がそうだったのですがレビューを受ける側からすると
お叱りを受けているような気分になりやすい。
ので、「会話」・対話として行えるように留意してます。
ただ…ここはレビューイ、レビューアとの信頼関係にもよると思いますので
万人受けするとは全く思いません。レビューに正解はないとも思っているので
あくまでこういうふうなやり方もあるよ。と一つの参考にしていただければと思います。

4.各フェーズでのレビューの注意していること

・内部設計書・実装はとにかく気を使おう
　正直なところ気をつけていることはキリがないのですが、
　内部設計書・実装での変数・メソッド名・定数名がよく気をつけていることです。

　うっかり変数に間違いがあってそのままテスト仕様書に行ってしまったらもう埒が明かないです。
　実装でも同様に、本来使うべき定数や変数とは違う定数を使っている
　似てるけど間違ったメソッドを使った・違う値を取りに行っているが
　エラーを吐かずに気づかずにテストまで行ってしまったらもう大変です。
とにかく内部設計書・実装での変数・メソッド名・定数名には気を使います。

・テスト仕様書・テストコードはなんとかなる
逆に上記の2つさえ概ね間違えなければ「手戻り」が少ないためカバーできると思います。
テストフェーズでのレビューの注意点はそのうち細かく分けてかければと思いますのでこの場ではこのあたりで。

5.組織的なレビューの弊害

もうすでに若干文章が長くなってきたので締めに入ります。
チームでレビューをする際は下記についてよく議論・検討されていると
チームメンバーはやりやすいと思います。

・ルールはきっちり固めよう
（コメントの前後1行は必ず開ける。IF文だろうとFOR文だろうと関係なく、など）

・認識はそれぞれで差異がないようにわ　か　り　や　す　くルールを書こう。
（上記の例で言えば「コメントの前後1行は必ず開ける。」だけで終えないこと。必ず「IF文の場合はこう、For分の場合はこう」といったルールがあるだけで精神的な負荷は違います。）
（特に日本語はいくつもの解釈が生じる可能性があるから気をつけよう）

・わからなかったらちゃんと聞こう。
　→聞く人・ルールをまとめる人もできるかぎり少数が良いと見てます。
　そして、その少数がきちんとメンバーに共有・展開・最適化できる環境があると無駄がなく、情報の伝達のラグを減らして幸せなレビューライフが送れると思います。

初の投稿で、少々おざなりな部分があったかと思いますが
参考になる箇所があれば幸いです。