コードレビュー、受ける方のレビュイも緊張しますが、レビュアも緊張します。
有意義な時間とするために観点というか心構えを考えてみました。
コードレビューとは
コードのレビューをすることをコードレビューと言います。
プロジェクトによっては、「ウォークスルー」「インスペクション」と言ったりします。
「ペアプログラミング」もレビューの一種と考えられますが、今回は省きます。
レビューイとレビューアがいるような感じのレビューで、効率よくレビューを進めるための心構えです。以下のようなことに気を付けています。
- 事前にコードを見ておく
- コーディングルールを守っているか、命名違反は事前に渡す
- エラーをとっているか(try-catch)
- 巨大クラス、長大関数
- 「求めるな、命じよ」
- コードは書いた人のもの。好みの問題のときは引き下がる
事前にコードを見ておく
事前にコードを見ます。
プログラマが何日もかけて作ったものをレビューをする一時間くらいで見るのは、無理があります。
特に技術力があるレビューイに対しては最大限の敬意を払います。
設計書も見返す必要があります。
使われているデザインパターンを復習しておくのも忘れてはいけません。
コーディングルールを守っているか、命名違反は事前に渡す
「ルールがあったら必ず守るのが人だ」という考えは捨てましょう。
一定数はルールさえも見ていません。見ても守ってくれません。
コーディングルールを全く守っていないコードはレビューに値しない（コーディングは終わっていない）と突き返すのもありかもしれません。うっかりで少し間違っているという程度ならいいんですけど。
特に命名規則破りをレビュー時に指摘するのは時間の無駄ですので、事前に渡すのがいいかと思います。
エラーをとっているか(try-catch)
エラーを全く気にしないプログラマは素人ですので、優しく教えてください。
C++やJavaではtry-catchをあちこちに差し込みます。
たまに忘れる箇所があるのでそういう注意はレビューイにとっても有難いです。
巨大クラス、長大関数
「どういう育ち方をしたら2000行にも及ぶ関数を書くんだ！」と叫びたくなるのは分かりますが、やめましょう。
長大な関数は分割するように冷静に諭します。怒ったら負けです。
「求めるな、命じよ」
Cから来たばかりの人やエンジニア成り立ての人は、オブジェクト指向の考えをよく理解できません。
お手本を示して下さい。
以下のような拙記事でもどうぞ。
>>> 【オブジェクト指向の考え方】オブジェクト指向は滅びたのか、定着したのか
コードは書いた人のもの。好みの問題のときは引き下がる
いろいろ指摘してもコードは書いた人のものです。
「そこは違うと思う」とレビューイが言うのであれば引き下がりましょう。
大体においては好みの問題であることが多いです。
まとめ
コードレビューの観点、心得を考えてみました。
>>> 【ITエンジニア】工程ごとの分類
コメント