はじめに
こんにちは、エンジニア4年目の嶋田です。
この記事を開いていただき、ありがとうございます！
エンジニアになって最初の頃、コードレビューが正直よく分かりませんでした。
指摘される。直す。また指摘される。直す。
その繰り返しでした。
でも当時の私には、なぜその書き方がダメなのかが分かっていなかったのです。
この記事は、レビューの指摘を「とりあえず直す作業」にしていた私が、少しずつ変わっていった話です。
ぜひ最後までお付き合いください。
目次
当時の自分の状態
レビューでコメントがつきます。
「この書き方はやめてください」
「ここはこう直してください」
言われた通りに直します。承認されます。マージされます。
でも、心の中ではずっとこう思っていました。
「なんで？」
なぜその書き方じゃダメなのか。なぜこっちの書き方の方がいいのか。
理由が分からないまま、ただコードを書き換えていました。
そして翌週、また似たような指摘を受けます。
「あれ、これ前も言われたような…」
理解していないから、同じミスを繰り返してしまうのです。
変わったきっかけ①「なぜですか？」と聞くようにした
あるとき、思い切ってレビュアーの上司に聞いてみました。
「この書き方がダメな理由を教えてもらえますか？」
正直、最初は聞くのが怖かったです。
「そんなことも分からないのか」と思われそうで。
でも、聞いてみたら普通に教えてもらえました。
聞いていい。むしろ聞くべきでした。
理由が分かると、指摘の意味が全然変わります。
「直す」から「理解する」に変わる瞬間でした。
変わったきっかけ②指摘を起点に自分で調べるようにした
聞くと教えてもらえます。でも、毎回聞くのも気が引けます。
そこで、指摘されたらまず自分で調べるようにしました。
「なぜこの書き方が推奨されているのか」
「この設計パターンにはどんな意図があるのか」
調べると、点と点がつながってくる感覚があります。
レビューの指摘が、知識を深めるきっかけに変わりました。
変わったきっかけ③結局、経験が一番大きかった
正直に言うと、この3つの中で一番大きかったのは経験を積んだことです。
同じようなコードを何度も書いて、何度も指摘されて、少しずつ「あ、こういうことか」と分かってきます。
頭で理解するより先に、手が覚えてくる感覚です。
聞いても調べても最初はピンとこなかったことが、半年後に突然腑に落ちる。そういうことが何度もありました。
急がなくていいです。続けることが一番大事でした。
まとめ
コードレビューを「直す作業」にしていた頃の私に伝えるとしたら、この3つです。
- 理由が分からなければ、聞いていい
- 指摘を起点に、自分で調べる習慣をつける
- すぐに分からなくても、続けていれば分かってくる
レビューは怖い時間ではありませんでした。
自分の知識のなさを教えてもらえる、貴重な時間でした。
4年目になった今でも、まだ全部が分かるわけではありません。
でも「なぜ？」と考える習慣がついたことで、確実に成長できている実感があります。
同じように「指摘の意味が分からない」と感じている方の参考になれば嬉しいです。