コードレビューを受けたことがないまま年数が経つと、何が起きるか
レビューのない職場は珍しくありませんが、困るのは間違いが残ることではなく、自分のコードを判定する基準が作られないことです。レビューで実際に見られている5つの層と、レビューがない環境で基準を作る方法を整理しました。
目次
実務でコードを書いているのに、レビューを受けた記憶がほとんどない。プルリクエストは出すけれど、中身を見られずに承認が付く。あるいは、そもそもプルリクエストを使っていない。
これは珍しいことではありません。少人数の会社、一人で担当している案件、常駐先で持ち場が分かれている現場では、わりとよく起きます。
困るのは、間違ったコードが本番に残ることではありません。本当に効いてくるのは、自分のコードを判定する基準が、何年経っても作られないことです。
レビューが埋めているのは、正しさではなく基準
レビューを「間違いを見つける作業」だと捉えると、自分でテストを書けば代わりになりそうに見えます。実際には別のものを埋めています。
自分の判断に外の値が返ってくる
- 他人が読めるかどうかが分かる
- 自分の書き方の癖に気づく
- 選ばなかった案を指摘される
- 社内の標準が共有される
動いたかどうかしか分からない
- 読みやすさの判定ができない
- 最初に覚えた書き方が固定される
- 他の案を検討しなくなる
- 「自分のやり方」が標準になる
右側の状態でも、仕事は回ります。むしろ短期的には速いです。問題は、年数が経っても判断の質が上がらないことと、それに自分では気づけないことです。気づくのはたいてい転職の選考か、他社のコードを読んだときです。
「動いている」は、基準として弱すぎる
レビューがない環境で唯一残る判定基準が「動いているかどうか」です。ところがこれは、実務で必要な判定のうち一番外側しか見ていません。
| 層 | 見るもの | 自分で判定できるか |
|---|---|---|
| 1. 動くか | 仕様通りに動作するか | できる |
| 2. 異常系 | 失敗・0件・権限なしの扱い | だいたいできる |
| 3. 読めるか | 他人が追えるか、名前が妥当か | できない |
| 4. 変更に耐えるか | 要件が増えたとき壊れないか | 経験がないとできない |
| 5. 設計として妥当か | その層に置くのが適切か | 比べる相手が必要 |
1と2は自分で閉じられます。3から下は、他人が読むか、将来の自分が読むかしないと判定できません。レビューがない環境で抜けるのはここです。
4と5が抜けたまま年数が増えると、実装はできるのに設計ができない状態になります。実装力の問題ではなく、判定の経験が足りていないだけです。
選考で、レビュー経験の有無はわりと見える
面接で「レビュー経験はありますか」と直接聞かれることは少ないですが、答え方に出ます。
- 「なぜその書き方にしたか」に対して、「そう書くものだと思っていた」になる
- 他の案を聞かれたときに、検討していないので答えがない
- 自分のコードの弱点を聞かれて、思い当たらない
- 指摘を受けて直した経験の話が出てこない
4つ目は特に分かりやすいです。経験者であれば、レビューで指摘されて考えが変わった話が1つ2つあるのが普通なので、それが出てこないと「一人で完結してきた人」として読まれます。評価が下がるというより、判断の質を確認する材料がなくなります。
この構造は、常駐や受託で持ち場が分かれている場合にも同じ形で出ます。SESから自社開発に転職できない本当の理由に、判断の記録が残らない環境の話として書きました。
レビューがない環境で基準を作る方法
環境を変えられないあいだにできることがあります。効き方の強い順です。
プルリクエストの説明を、読む人がいる前提で書く
承認が自動で付く環境でも、説明だけは書きます。「何をしたか」ではなく「なぜこの形にしたか、他にどの案があったか」を3行書く。読む人がいなくても、書こうとすると検討していないことに気づきます。これがいちばん安く始められます。
2週間後の自分にレビューさせる
書いた直後は判定できません。2週間おいてから読むと、他人のコードに近い距離で読めます。読めなかった箇所が、他人も読めない箇所です。
OSSのプルリクエストのレビューを読む
自分のコードではなく、他人のやり取りを読みます。使っているライブラリのリポジトリで、マージされたプルリクエストのレビューコメントを10本読むと、どの層を見ているのかが分かります。4と5の層に触れるには、これがいちばん手軽です。
外の人に1回見てもらう
いちばん効きますが、相手を探すのが難しい項目です。社外のエンジニア、勉強会、有料のレビューサービスなど、手段は何でも構いません。1回でも「自分では気づかない指摘」を受けると、以降の自己レビューの見る場所が変わります。
レビューする側に回ると、もう一段進む
もしチームに後から人が入ったら、レビューする側をやるほうが伸びます。他人のコードに対して「なぜこれが気になるのか」を言葉にしないといけないので、自分の基準が明文化されます。
転職の選考でも、レビューした経験は範囲の広さとして読まれます。30代以降は特にここを見られます。年齢と任される範囲の関係は「30代でプログラミングスクール」は未経験と経験者で答えが正反対になるに書きました。
正直なところ：レビューの質は人による
レビューがあればいいという話でもありません。実際には次のようなレビューも多いです。
- 変数名とインデントの指摘だけで、設計には触れない
- 承認が目的になっていて、読まれずに通る
- 指摘が好みの押し付けで、理由が説明されない
これらは3から5の層を埋めません。「レビューがある職場」を転職の条件にするなら、あるかどうかではなくどの層まで見ているかを聞いたほうが確実です。選考で逆質問するなら、「直近のレビューで設計の指摘が入った例はありますか」が効きます。
まとめ
| よくある理解 | 実際 |
|---|---|
| レビューは間違いを見つける作業 | 判定の基準を作る作業 |
| テストを書けば代わりになる | 読みやすさと設計は判定できない |
| レビューがなくても年数で伸びる | 判定が返らないと基準は作られない |
| レビューがあるかどうかで選ぶ | どの層まで見ているかで選ぶ |
レビューを受けたことがないまま年数が経っても、実装は速くなります。増えないのは自分のコードを外の基準で判定する力です。環境を変えられないなら、説明を書く・時間を置いて読む・他人のやり取りを読む。この3つは今日から始められます。
JISOUは実務経験者向けのオンラインスクールで、受講生は自分のアイデアでサービスを作り、提出したコードに現役エンジニアのレビューが入ります。設計の単位で指摘が返るので、いちばん抜けやすい4と5の層が埋まります。レビューを受ける機会がない環境が続いているなら、一度外の目を通してみてください。