コードレビューで本を参照として使う
コードレビューをすると修正の提案をする機会がありますが、その時に本を参照として添えることをしています。ちょっとポエムっぽい記事です。
そして、この記事は meihei GW アドベントカレンダー3日目の記事です。
meihei GW アドベントカレンダーとは？
meihei GW アドベントカレンダーとは、meiheiがゴールデンウィークの5月1日〜5日までの間に毎日記事を投稿する企画です。勝手にやっています。
コードレビューの目的
個人的にコードレビューを行う目的として
- ソフトウェアの品質を担保する（≒そのPull RequestのコードをBetterなものにする）
- コードレビューを通してレビュイーを教育する
現状と課題感
現在、自分にコードレビューを送るPull Requestのレビュイーは中級者がほとんどです。
初心者あるあるな明確に間違ったコードを書いて指摘されることはほとんど無く、今後10年以上動き続けるソフトウェアの一部としてよりBetterなコードを書けないか、という視点からの指摘がほとんどです。
ここで問題なのは、レビュアーである自分は別に上級者ではなく、エンジニア歴5年のペーペーということです。10年先の未来を語るには知識経験が足りていないです。
その上で、今感じている課題は以下の通りでした。
- コードの不吉な匂いを言語化出来ない事がある
- レビュイーがより深く学ぶための道しるべを用意出来ていない
これらの課題を解決することは、レビュイーの成長速度を上げる事ができますし、ひいては組織全体での成長や、ソフトウェアの品質向上に繋がる事が期待できます。
やったこと
最初に結論を書いていましたが、コードレビューで迷ったときはおもむろに本を取り出して読んで、自分の中で理解してからコメントをし、実際に何の本を参照にしたか書くようにしました。
まず本を読む
そもそもですが、参照となる本を知っていないといけません。つまり、コードレビューの依頼が来る前に一度は本を読んでおきます。そして、この問題の解決方法はこの本に書いてある、というあたりをつけられるような状態にします。
コードレビュー時に本を読み返し、参照となる箇所をPickします。
理解・言語化する
本の内容をそのまま引用はせず、一度自分の中に落とし込んでからコメントします。
自分で言語化せず「これ読んで勉強し直してきて」をやるのはアンチパターン[3]で、レビュイーのためにも、チームのためにもなりません。
本を読み返し、コメントをするときには「参考」として読んだ本を置きます。そして、レビュイーに向けてどうしたらこの考えを学べるのかという道しるべを用意します。
実際に自分がレビューコメントをするときはこんな感じです。
ここの数値は何を表しているのか分からないマジックナンバーになっています。定数で定義して、適切な名前をつけましょう。
const GOOGLE_CWV_PERCENTILE = 75;参考: 良いコード／悪いコードで学ぶ設計入門 9章 9.3 マジックナンバー
マジックナンバーを例として上げましたが、このように問題に名前がついている場合、出来るだけその名前を教えることをしています。
感じたメリット・デメリット
実際にやってみて、いくつかメリットを感じました。
- 問題と解決の理解度が上がり、レビューの質が上がる
- 適切に知識とそのソースを教えることで、レビュイーの成長に繋げられる
- 自分が成長する
３つ目の「自分が成長する」はなかなか大きいと感じています。そもそも自分の理解度が足りていないところを補う勉強にもなっているので、一石二鳥ですね。
逆にデメリットというと、本を買うコストです。この辺は会社の福利厚生などで補ってほしいところですね（ちなみに弊社は自由に買えます）。
おわり
本を読んでコードレビューをしているよっていう話しでした。やっている人にとっては当たり前かもしれないですが、ちょっと意識することで、自分・相手・組織の成長に繋がって一石三鳥だなって感じています。
Discussion