コードレビューとは、プログラマーが書いたプログラムを、別のプログラマーが見て、
「ちゃんとできてるかなー？」
とみる、検品のようなお仕事です。
もちろん、やった方がいいことになっています。
一人がやるより、複数人の目で見たほうがいいですからね！
しかし、なかなか難しい仕事なんですよ。明らかに仕様と違うとか、動作が違うとかは明らかにNGでいいんですが、それ以外のクオリティということでいうと、できている・できていないの線引きが大変難しいからです。
仕様上の動作はするが、優劣でいうと、劣だな～ というのが、これがなかなか難しい。
プログラムの要素を
①クラス設計の仕方
②データベース設計の仕方
③メソッドの作り方
④名前（変数名、メソッド名など）のつけかた
などとします。
たとえば、クラス設計でいえば、違うクラスのフィールドが紛れ込んでいるとか、余計なループがあるなどは、明らかにダメなので、それはダメでいいんですが、クラス設計がなんか微妙な感じ…な時があります。わかりにくいとかわかりやすい、ですかね。
「俺だったらこうするね」
みたいに感覚に近い判断基準が入ってきちゃいます。
また、プログラマーの力量に、もちろん差があります。
駆け出しのプログラマさんに、うまく作ってもらうのは無理です。(´ω`)
粗削りでもある程度でスタートさせないと、成長しないですよね。まぁ、これは私の考えなんですが。
とはいえ、プロダクトレベルのものにあんまりひどいのが入るのはちょっと…というところもあります。
私の考えとしては60％ぐらいできていればOKにしています。
動作確認は、テスト、ユニットテストで行うのがいいんじゃないでしょうか。
「60％ってなんだ！なんかいい加減じゃない？」
って思うかもしれません。
プログラムって書いたことがない人にはあまりわからないかもしれませんが、ハンドメイドの創作物なんですよｗ
感覚でしか表せないんですよね。
小説を読んでいて、
「うまい小説だな」
というのと
「下手な小説だな」
というのは、感覚でしか説明できないのと一緒です。
不思議なもんで、プログラマー一人一人にすっごく個性があって、あまりコードをうまく書けなくっても、お客さんが使いやすいものを書く人もいます。
私としては、お客様にとって使いやすいものが一番だと思います。
