下っ端エンジニアにできるコードレビューについてゆるく考えてみた
悩んでます。
私、エンジニア3年目です。
昨年、今の会社に転職して、コードレビューを受けることができる環境に入ることができました。
前の会社は一人開発でレビューすらなかったので、レビュー文化があるだけでありがたいなぁと、思っていたのですが、私自身もレビュアーになる機会があるのですね。。
下っ端エンジニアが、コードレビューすることはその人自身の成長になる、みたいな話はよく聞くので、これもありがたいなぁと思うのですが、下記の点で毎回困っているのです。
・ある箇所が修正された時、どこからどこまでソースを見れば良いのか
・誤字脱字やら書式の間違いばっかり先に目に入ってきて本質的なレビューにならない
・何を持ってLGTMとして良いのか、コードレビューの終点がわからない
先日、面談の際に弊社のCTOに雑談混じりにコードレビューについて相談したところ、
完璧なコードレビューは、ありえないから、いかに効率よく主に塗り潰すべきところを塗りつぶすかを考える、というような旨のことを言われ、なるほどなぁと思いました。
コードレビュー依頼が来た時、自分のレビュー漏れで障害が起こらないようにという緊張感を持つことは大切かと思います。
ですが、働いている以上はある程度の時間の中で、コードレビューを行う必要があります。
どうすれば、限られた時間で、塗り潰すべきところを塗りつぶすコードレビューができるのか。
ここの精度を上げたくて色々本と記事を漁りました。
上記はコードレビューというより、設計書・要件定義書などドキュメントのレビューについての本でした。著者は元ITエンジニアとして従事された経験を持って、今は効果的なレビューについて大学で研究されているようです。
この本はレビューをする時の大まかな手順・心持ちについて記載があります。
一言感想としては、やはりコードレビューもいきなりMRドキュメント/コードを漫然と見るのではなく、準備と観点をまず策定する必要があることを感じました。
上記の本の著者がコードレビューについて書いた記事は下記でしたが、
レビューの目的は何か定めるプロセス・レビューの目的の共有の大切さが
コンパクトにまとまっています。
こちらはもっと具体的な業務を念頭において記載されてます。
ここでもレビュー目的・観点の共有の大切さについて述べられています。
さて、下っ端にもできるコードレビューとはなんでしょうか。
上記を読んだ上での感想としては
・機能の目的を抑える
・主なユースケースを検討する
・それらを元にレビュー目的・観点を固める
・定めたレビュー目的・レビュー観点がズレていないか上司に確認をとる
・目的・観点の中でコードレビューを行う
・本質的でないけど気になる点は`nits`などラベリングを利用する
かなぁと思いました。
ただ全てのレビュー目的・観点を上司にいちいち確認するのも、リリースの多い会社だとそれはそれで工数が取られるので、
これからは、レビューの前にこれこれの観点でレビューしました。と文頭につけようかと思います。
そしてレビュー観点の精度は一重にドメイン・仕様理解/ 設計力の向上にあるなと当然のことなのですが思いました。
意外だったのは、コードレビューという名前からは想像できないくらい、ドメイン理解にコードレビューは重きが置かれるものなのかな、と思ったことです。
こちらもまださらーっとしか読んでませんが
Googleのコードレビュー観点に関する記述も翻訳されていました。
コードは1行1行読んでいくべき。というのは身が引き締まりました。
今年ももう1月が終わります
結局、目標の2記事が書けなかったけど、一気に書くのでなく、少しずつ書いて行かんと無理ですね。
ではっ。
この記事が気に入ったらサポートをしてみませんか？