Deprecated: preg_replace(): Passing null to parameter #2 ($replacement) of type array|string is deprecated in /home/stsoft/zero-plus-one.jp/public_html/wp-content/plugins/pz-linkcard/pz-linkcard.php on line 898
Deprecated: preg_replace(): Passing null to parameter #2 ($replacement) of type array|string is deprecated in /home/stsoft/zero-plus-one.jp/public_html/wp-content/plugins/pz-linkcard/pz-linkcard.php on line 870
Deprecated: preg_replace(): Passing null to parameter #2 ($replacement) of type array|string is deprecated in /home/stsoft/zero-plus-one.jp/public_html/wp-content/plugins/pz-linkcard/pz-linkcard.php on line 898
今回はWeb系プログラマの仕事とは切っても来れない関係にあるコードレビューについて書きます。
まずコードレビューとは何か。
プログラマとしてはプログラムコードをどんどん生み出すような仕事をしています。そこでプログラミングそのものと同様に重要になるのはソースコードのバージョン管理です。
バージョン管理はツールを使って実現します。以前は CVS や SubVersion(SVNと略される) が流行っていたり、Microsoft系のツールだと Visual SourceSafe(VSS) や TeamSource というものがありましたが、今のWeb開発業界では、はやりの Git を使った仕事ばかりです。
Git を使っていると、ある人が変更した差分をメインのバージョンに取り込む時にプルリクエストというページを作成します。プルリクエストはコードの取り込みを要求するという意味です。
プルリクエストページでは変更された部分のソースコードをみてレビューする側の人が「ここのコードはこう直したほうがいい」「ここのコードのこの書き方はなぜこうなっているのですか？直してください」といったコメントを書いてレビューされる相手に返事とコード修正をうながすことができます。
それが「コードレビュー」というものになります。
Gitが使われる以前のコードレビューもありましたが、Webページ上で行う仕組みではなく数人同時にプロジェクターでソースコードをみて口頭でコードを評価するという仕事も行われていました。これはレビューする人とレビューされる人の二人の場合でも部屋をとったりプロジェクターを用意する必要があったり、また、多人数の場合はみんなの時間が奪われるために、非効率なのが誰の目にもあきらかなのであまり流行りましませんでした。
今はGitというツールが流行っていることによって「レビュー」がWebページ上で簡単に行えるようになってきたので安易に使われるようになってしまいました。レビューする人とレビューされる人が同時に時間をあける必要もないからです。
これがちょっとした罠ですね。
リモートワーク時代でも会話しながらペアプログラミングができる時代なので遠隔地にいても口頭で話すことができるのに、テキストベースのコミュニケーションを使うという無愛想で批判的なことで容易に傷つけることができるということが起きますし、また、口頭なら極めて短時間で意思疎通ができるのにあいまいなテキストを書いて、そのあいまいなテキストを呼んで、修正ポイントが実際にわからないという無駄な作業とかそういうのです。
念の為いっておきますがメッセージツールは有用ですよ。コードレビューのようなものにテキストベースのコミュニケーションを使う事が非効率だということです。
各サイトで話題になった内容
QuoraというQ&Aサイトではこのような記事がありました。
プログラムを飯のタネにされている方に質問です。コードレビューの長所と短所を教えていただけますか？ - Quora
また、コードレビューについてはこういうところで議論になっていることも目にします
新人プログラマをレビューで殺さない方法 - Qiita
コードレビューを受けるのがつらくなったときは - めるノート
そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
無理をしないコードレビュー - クックパッド開発者ブログ
コードレビューのレビューはマネージャーの仕事 | POSTD
コードレビューを怖がっていた新卒エンジニアが始めた対策 | GMOアドパートナーズグループ TECH BLOG byGMO
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
コードレビューの際に気をつけること - Qiita
それぞれのところでコードレビューは「恐怖」ということと関連して語られています。
あるいは恐怖を感じないにせよ「恐怖」を感じないためにどうすればいいのかを考えた上での守るべき厳格なルールをレビューされる側がすごく気にしている気がします。
学校の部活とかで指導教官に痛めつけられないためにはどのようにルールを守ってしっかりやっておこうか。というガチガチに固まったつらい仕事の様子でしょう。
もっと楽しく仕事できないものでしょうか。まあそれは出来ないですよね。理由は記事の続きを読んでいただけるとわかると思います。
結論
もったいぶらずにさっさと結論を出してしまいます。(エンジニアだからね。結論を先に書くの大事だもんね)
こういう記事が他のエンジニアによって書かれている状況、そして自分の見てきた環境とを踏まえて長年の経験から判断します。
結論からいうと「コードレビュー」という開発手法にはデメリットを超えるだけのメリットはないです。
こちらのリンク先では自分は次のように書いています。
コードレビューは否定の文化だから、よほどじゃなければ、自分が直して手本みせて終わります。
出来のよろしくない人を否定して書かせても非効率だし。出来の良い人の重箱のすみつついてもくだらないし、
また、出来の悪い人からレビューされて筋違いの修正を強要されたら不愉快極まりないし、出来のよい人から否定されても恨みを抱くだけだし。
100害あって一利なしの開発手法だと思います。
開発手法として素晴らしいと論じられた事もないのに、適当に差分ツールにそういう機能をくっつけたら、みんなが適当に使って、なんか悪い方に流されている、っていう一例な気がします。
実際、出来の悪い人から変なレビュー受けて、余計な仕事ばかりさせられて仕事を失ったりしました。レビューする側がレビュー相手より技術レベルが低い、しかし、レビュアーは技術レベルが低いがゆえに自分を技術レベルが高いと勘違いする、という場面はたくさんあり、コードレビューの開発手法はその点を考慮されていないので、害しかないです。
なぜそういう結論を出しているかということを細かく書きます。
コードレビューのメリット
「コードレビュー」の大きなそしてほぼ唯一の長所は「見逃していた不具合をみつけてもらえる」というものです。
しかし、これはコードを「レビュー」をされなくても見て勝手に直しておいてくれたらそれで完結するのでコードレビューだけの長所とはいえません。
つまり、コードの相互チェックというメインバージョンに取り込む前に開発者だけではなく他の人の目によって確認してもらう開発手法は長所があります。コードレビューの中にはコードの相互チェックが含まれます。
多くの人はコード相互チェックのメリットをレビューのメリットだと勘違いしていて「コードレビューは有効な開発手法だ」と思い込んでいたりします。分けて考えておいたほうがより賢く物事を分析できます。
コードの相互チェックはメリットのみしかないので、これは単に実行した方がよいでしょう。
コードレビューによって他の人の目に触れることでコード品質を高める意識が生まれやすいというメリットがある、という意見もみかけました。
ですが、レビュー文化などがない時から幾人かの優れたエンジニアと一緒に仕事したときもありましたがコード品質を高める意識はありました。
コード品質を高める高めないというのはプログラマとしての優劣なので「レビュー」によって強化されるメリットには思えません。
コードレビューのメリットを大きくうわまわるデメリット
コードレビューにはデメリットを超えるだけのメリットはないです。
コードレビューはチームの生産性を少しずつ下げて、結果、チームの生産性低下が著しくなるために競争力を失う負け組みになるので私としては参加するメリットもないので「コードレビュー重視チーム」には参加したいとも思いません。
さて、そのより細かい内容を続きで書いていきます。
