プログラマ全般

コードレビューの長所と短所-その1

更新日:

今回はWeb系プログラマの仕事とは切っても来れない関係にあるコードレビューについて書きます。

まずコードレビューとは何か。

プログラマとしてはプログラムコードをどんどん生み出すような仕事をしています。そこでプログラミングそのものと同様に重要になるのはソースコードのバージョン管理です。

バージョン管理はツールを使って実現します。以前は CVS や SubVersion(SVNと略される) が流行っていたり、Microsoft系のツールだと Visual SourceSafe(VSS) や TeamSource というものがありましたが、今のWeb開発業界では Git が流行しまくっているので Git を使った仕事ばかりです。

Git を使っていると、ある人が変更した差分をメインのバージョンに取り込む時にプルリクエストというページを作成します。プルリクエストはコードの取り込みを要求するという意味です。

プルリクエストページでは変更された部分のソースコードをみてレビューする側の人が「ここのコードはこう直したほうがいい」「ここのコードのこの書き方はなぜこうなっているのですか?直してください」といったコメントを書いてレビューされる相手に返事とコード修正をうながすことができます。

それが「コードレビュー」というものになります。

Gitが使われる以前のコードレビューもありましたが、Webページ上で行う仕組みではなく数人同時にプロジェクターでソースコードをみて口頭でコードを評価するという仕事も行われていました。これはレビューする人とレビューされる人の二人の場合でも部屋をとったりプロジェクターを用意する必要があったり、また、多人数の場合はみんなの時間が奪われるために、非効率なのが誰の目にもあきらかなのであまり流行っていたようには思いません。

今はGitというツールが流行っていることによって「レビュー」がWebページ上で簡単に行えるようになってきたので安易に使われるようになってしまいました。レビューする人とレビューされる人が同時に時間をあける必要もないからです。

まあこれが罠なんですけどね。対面でできる会話をメッセージツールで記入するという無駄な作業とかそういうのです。※念の為いっておきますがメッセージツールは有用ですよ。

各サイトで話題になった内容

QiitaというQ&Aサイトではこのような記事がありました。


プログラムを飯のタネにされている方に質問です。コードレビューの長所と短所を教えていただけますか? - Quora


 

また、コードレビューについてはこういうところで議論になっていることも目にします


新人プログラマをレビューで殺さない方法 - Qiita

コードレビューを受けるのがつらくなったときは - めるノート

そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操

無理をしないコードレビュー - クックパッド開発者ブログ

コードレビューのレビューはマネージャーの仕事 | POSTD

コードレビューを怖がっていた新卒エンジニアが始めた対策 | GMOアドパートナーズグループ TECH BLOG byGMO

入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング

コードレビューの際に気をつけること - Qiita


それぞれのところでコードレビューは「恐怖」ということと関連して語られているように思います。

あるいは恐怖を感じないにせよ「恐怖」を感じないためにどうすればいいのかを考えた上での守るべき厳格なルールをレビューされる側がすごく気にしている気がします。

学校の部活とかで指導教官に痛めつけられないためにはどのようにルールを守ってしっかりやっておこうか。というガチガチに固まったつらい仕事の様子でしょう。

もっと楽しく仕事できないものでしょうか。まあそれは出来ないですよね。理由は記事の続きを読んでいただけるとわかると思います。

結論

もったいぶらずにさっさと結論を出してしまいます。(エンジニアだからね。結論を先に書くの大事だもんね)

こういう記事が他のエンジニアによって書かれている状況、そして自分の見てきた環境とを踏まえて長年の経験から判断します。

結論からいうと「コードレビュー」という開発手法にはデメリットを超えるだけのメリットはないです。

こちらのリンク先では自分は次のように書いています。

コードレビューは否定の文化だから、よほどじゃなければ、自分が直して手本みせて終わります。

出来のよろしくない人を否定して書かせても非効率だし。出来の良い人の重箱のすみつついてもくだらないし、

また、出来の悪い人からレビューされて筋違いの修正を強要されたら不愉快極まりないし、出来のよい人から否定されても恨みを抱くだけだし。

100害あって一利なしの開発手法だと思います。

開発手法として素晴らしいと論じられた事もないのに、適当に差分ツールにそういう機能をくっつけたら、みんなが適当に使って、なんか悪い方に流されている、っていう一例な気がします。

実際、出来の悪い人から変なレビュー受けて、余計な仕事ばかりさせられて仕事を失ったりしました。レビューする側がレビュー相手より技術レベルが低い、しかし、レビュアーは技術レベルが低いがゆえに自分を技術レベルが高いと勘違いする、という場面はたくさんあり、コードレビューの開発手法はその点を考慮されていないので、害しかないです。

なぜそういう結論を出しているかということを細かく書きます。

 

コードレビューのメリット

「コードレビュー」の大きなそしてほぼ唯一の長所は「見逃していた不具合をみつけてもらえる」というものです。

しかし、これはコードを「レビュー」をされなくても見て勝手に直しておいてくれたらそれで完結するのでコードレビューだけの長所とはいえません。

つまり、コードの相互チェックというメインバージョンに取り込む前に開発者だけではなく他の人の目によって確認してもらう開発手法は長所があります。コードレビューの中にはコードの相互チェックが含まれます。

多くの人はコード相互チェックのメリットをレビューのメリットだと勘違いしていて「コードレビューは有効な開発手法だ」と思い込んでいたりします。分けて考えておいたほうがより賢く物事を分析できます。

コードの相互チェックはメリットのみしかないので、これは単に実行した方がよいでしょう。

コードレビューによって他の人の目に触れることでコード品質を高める意識が生まれやすいというメリットがある、という意見もみかけました。

ですが、レビュー文化などがない時から幾人かの優れたエンジニアと一緒に仕事したときもありましたがコード品質を高める意識はありました。

コード品質を高める高めないというのはプログラマとしての優劣なので「レビュー」によって強化されるメリットには思えません。

コードレビューのメリットを大きくうわまわるデメリット

コードレビューにはデメリットを超えるだけのメリットはないです。

コードレビューはチームの生産性を少しずつ下げて、結果、チームの生産性低下が著しくなるために競争力を失う負け組みになるので私としては参加するメリットもないので「コードレビュー重視チーム」には参加したいとも思いません。

さて、そのより細かい内容を続きで書いていきます。

-プログラマ全般

Copyright© プログラミングアカデミー ゼロプラスワン , 2019 All Rights Reserved Powered by STINGER.