2012年12月15日16日の2日間にわたりDevLOVE 2012が開催されました。

DevLOVE 2012はDevLOVEの100回目の開催だそうです。すごいですね。継続していることもすごいですが、掲げているテーマも「世界を変えるのは他の誰かではない、世界を変えるのは自分自身だ。」と、挑戦的ですごいですね。

さて、そんなDevLOVE 2012で「リーダブルコードを読んだ後」というタイトルのセッションをしてきました¹。今年の7月に「リーダブルコード − 忘れてもいいコードを書こう。」というDevLOVEのイベントに講師として参加したのですが、その縁で声をかけてもらいました。

7月にやったイベントは「リーダブルコードというのはどういうものか考えてみよう」という内容だったので、今回は「リーダブルコードがよいか悪いかを考える時期はもう終わった。リーダブルコードはよいものだとわかった。では、実際にリーダブルコードを書くことが当たり前な文化にしていこうじゃないか。」という内容にすることになりました。具体的にはリーダブルコードが当たり前な文化となっているクリアコードの開発方法を体験するというワークショップ形式のセッションになりました。当日使った資料はRabbit SlideShow²にあります³。

概要

クリアコードの開発方法はリーダブルコードの解説に書いてあるような開発方法です。みんながみんなのコミットを読み、気になったコミットがあったらコメントしたり直接修正したりするという開発方法です。これは、フリーソフトウェアの開発では昔から実践されている方法です⁴。後述するように、他の人のコミットを読むことが当たり前な開発方法はメリットが大きいと思っているのですが、フリーソフトウェアの開発に縁のない職場での開発では使われていないようです。そのため、みんながみんなのコミットを読むという開発方法を実際に体験してみましょう、というのがこのセッションの内容です。

このセッションのおかげで、クリアコードの開発方法では以下の2つのことを大事にしていることに気づきました。

1. 読む人になる

2. 悪いところよりよいところをみつける

それぞれについて説明します。

読む人になる

リーダブルコードの解説を書いたときから、「リーダブルコードが当たり前の開発チームはどうやって作るのだろうか」ということを考えるようになり、解説を書いた後も考えていました。札幌Ruby会議2012の「クリアなコードの作り方」というセッションで話した内容はリーダブルコードの解説の内容からさらに考えを進めたものでした。解説の内容よりもさらに次のことまで踏み込んではいましたが、終わってみたら、話した本人にはモヤっとしたものが残っていました。そして、今回のセッションの準備のために考えたり、セッションで参加者と話したりすることで、より考えが進みました。私にとっては、とても実のあるセッションになった⁵のでとても感謝しています。

今回のイベントで気づいたことは「はじめにすることは読む人になること」ということです。

リーダブルコードの「1.5 でもやるんだよ」にはこう書いてあります。

想像上の誰かが自分のコードを理解しやすいかなんて考えるのは大変なことだ。

他の「よいコードを書くための本」でも同じようなことが書いてあります。一年後の自分のことを想像して書きなさい、とかそういうやつです。

その考え方が違うんだなぁと気づきました。想像するのではなくて思い出す方がよいと気づきました。読む人のことを「想像しながら」書くのではなく、「思い出しながら」書きます。それがクリアコードでやっている開発方法ですし、フリーソフトウェアの開発でもやっている方法です。フリーソフトウェアの開発に関わってきた人なら、「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」というのはよくある話です。これは、自分が読みやすかったコードを「思い出して」よいコードを書いています。

リーダブルコードの解説は、自分がリーダブルなコードを書けるようになったら他の人のコードにも適用範囲を広げていこうという話の流れになっているのですが、これは間違いでした。まず、他の人のコードを読むことを当たり前にしてから、リーダブルなコードを書くことを考える方が正しいと今は思っています。「読む人」を実際にやっていれば、読む人のことを「想像」しないで、「思い出しながら」リーダブルなコードを書くことができます。

ということで、「まず読む人になる」というのがクリアコードの開発方法で大事にしていることだと気づきました。それに気づけて、私はとてもよかったです。

少しずれますが、世間では「レビューした方がいいとは思っているけど、忙しくて誰も自分のコードをレビューしてくれないんだよね」ということがあるそうです⁶。そういうときは、まず、自分が他の人のコードを読むとよいのではないでしょうか。レビューにどのくらい時間が必要かもわかりますし、あなたがレビューした人が、今度は逆にあなたのコードをレビューしてくれるかもしれません。レビュー時間が思ったより短いものだとわかったら無理せずにレビューの時間を作れるかもしれません。あなたが、「まず読む人になる」のはどうでしょうか⁷。

さらにずれますが、DevLOVE 2012の懇親会⁸でオライリー・ジャパンさん提供のリーダブルコード⁹をプレゼントしたときの話を少しします。事前に、リーダブルコードをプレゼントする人をどうやって決めましょうかと相談されたので、欲しい人に「どうして自分がリーダブルコードを欲しいか」を言ってもらって、私がそれっぽいと思ったらプレゼントすることにしました。その中で、「先輩の○○さんがよいコードを書くので、自分も同じようによいコードを書けるようになりたいから」と言ってくれた人がいました。私は「○○先輩のコードを読むといいんじゃないですかねぇ。」などとプレゼントしなかったのですが、もっとちゃんとプレゼントしない理由を説明するべきでした。リーダブルコードを読む時間を先輩のコードを読む時間に使ったほうがよいです。それは実際に自分たちが開発しているコードなので、サンプルコードで説明しているリーダブルコードよりずっと実践的です。さらに、もし、コードで気になることがあったら直接先輩に聞けます。本の場合はなかなか著者に気になったところを聞くことはできません。よいコードを書く先輩がいるのなら、本を読むよりも先輩のコードを読む時間に使って欲しかったのです。なので、プレゼントしませんでした¹⁰。もしあなたに後輩がいるのなら、リーダブルコードを後輩に渡して「これ読んで、よいコードを書けよ」ではなく、自分のコードで後輩によいコードを教えるのもよいかもしれませんね¹¹。

悪いところよりよいところをみつける

さて、話を元に戻して、2つめの大事な気づきです。

「まず読む人になる」というのも大きな気づきでしたが、もうひとつ大きな気づきがありました。それが、「悪いところよりよいところを見つける」ということです。7月のリーダブルコードのイベントのときも札幌Ruby会議2012のときも触れていたことですが、こんなに大事なことだとは気づいていませんでした。

ランチの時間などにみんなで集まったり、pull requestなどを使ったりして、レビューをしているという話を聞いたことがあります。レビューでは、変なコードが入らないようにしてコードの質を上げるということをやっているようです¹²。これは、フリーソフトウェアの開発でも行われています¹³。つまり、「悪いコードがないか？」視点でコードを読むのがレビューでのコードの読み方のようです。

ところで、「悪いコードがないか？」視点ではなく、「よいコードではないか？」視点でコードを読んでみたことはありますか？

もし、「よいコードではないか？」視点で読んでみたことがないなら読んでみることをオススメします。これは、フリーソフトウェアの開発では実際に行われている読み方です。少し前に「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」という話を紹介しましたが、それができるのは「よいコードではないか？」視点で読んだからです。「悪いコードがないか？」視点だと、悪いコードばかりに目がいって、よいコードは見向きもされません。そうすると、せっかくメンバーがよいコードを書いていても、それが共有されません。自分たちが書いたコード内で「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」ができたらステキじゃないですか。

ただし、よいコードは悪いコードよりもみつけることが難しいです。悪いコードはいびつで目につきやすい¹⁴ですが、よいコードはまわりに自然になじんでいてスムーズに読めてしまうからです。これに気づけたのは、今回のセッションの事前課題のコミットを読んだからでした。事前課題では、リーダブルなコードとリーダブルじゃないコードをみつけてください、としていたのですが、全員リーダブルじゃないところばかりをみつけていました。これが、悪いコードの方がみつけやすいのはどうしてだろう、どうしてよいコードはみつけられないのだろうと考えるきっかけになりました。

それでは、よいコードをみつけることができるようになるためにはどうしたらよいでしょうか。最初はうまくいかないでしょうが、まずは「よいコードではないか？」視点で読むことを始めてみてください。ずっとコードを読んでいるとたまーによいコードがみつかるはずです¹⁵。

よいコードをみつけたら、それをマネしたよいコードをコミットしていきましょう。よいコミットに対して「いいね！今度自分もやるよ！」と言うよりも、「実際にやる」ということです。そっちの方が本物です。コミットはみんなが読んでいるので、コミットした人は自分のよいと思ってやっているコミットが他の人に取り入れられていることがわかります。2人が同じようにコミットしていることは他のメンバーにも届いています。もしかしたら、他のメンバーもマネしてくれるかもしれません。もしかしたら、もっとよい書き方でコミットするかもしれません。実際にコードを書くことでよいコードが広まっていくってステキだと思いませんか？

よいコードが当たり前の文化を作ることを支援したい

みんなが読む人になり、悪いところよりよいところをみつける視点で、みんなのコミットを読む。それがクリアコードの開発方法です。これが当たり前の文化になると、新しいメンバーが入ってきても、よいコードでよいコードがどういうものかを伝えることができるチームになるでしょう。

社内で実践したり、フリーソフトウェアの開発に参加したりしているため、クリアコードにはこのよう開発方法を実践するノウハウがあります。そこで、この開発方法を実践し、文化として根付かせたいという開発チームを支援するサービスを提供することにしました¹⁶。支援した結果として、よいコードが当たり前というプログラマーが増えるといいなぁと思っています。

ただし、このサービスは、クリアコードがずっと支援するサービスではなく、サービスを卒業して自分たちだけで新しい人も受け入れられる文化をもった開発チームを作るためのサービスです。もちろん、会社的にはずっと契約が続いた方が安定した収入になるのですが、それではよいコードが当たり前のプログラマーが増える助けにはならないので、卒業して欲しいと思っています。卒業を前提とすると、サービスを提供する方も、提供される方も、「よいコードが当たり前の文化を作る」という同じゴールになるため、より早く卒業できるように協力しあって進められるのではないかと期待しています。

コミットへのコメントサービス

このサービスの名前は「コミットへのコメントサービス」です¹⁷。今のところ、以下のように進めるのがよいのではないかと考えています¹⁸。

1. 導入研修

2. コミットメールを読んでコメントする

3. データを分析する

以下、「開発チーム」とはこのサービスを導入した開発チームのことを指します。

導入研修

まず、DevLOVE 2012でやったようなセッションを導入研修として実施します。導入研修では、どのようにコードを読むのか、どういう文化にしようとしているのかを説明・質疑応答し、「よいコードが当たり前の文化を作る」ということについての理解を深めます。また、実際にコードを読むということを体験します。最初に導入研修をやることにより、自分たちがどのくらいできるのか、今は何ができないのかが把握できることを期待しています¹⁹。

コミットメールを読んでコメントする

「よいコードが当たり前の文化を作る」ことへの理解が深まったら、実際に「みんながみんなのコードを読む」環境を作ります。具体的にはクリアコードの担当者と開発チーム全員にコミットメールが届くようにします。開発チームは通常通り開発をしますが、全員がコミットメールを読みます。全部読めなくても構いません。おそらく、最初は全部読めないでしょう。というのも、「読む人」の経験があまりない人は読みやすいコミットをうまく作れないからです。クリアコードの担当者はコミットメールを読んでどうすればより読みやすいコミットになるかをコメントします。開発チームからの質問にも回答します。開発チーム内でも、どうすればより読みやすいコミットになるかを積極的に試行錯誤することを期待しています。

クリアコードの担当者と開発チームはどのくらいのコミットを読んだかとその日印象に残ったコミットを毎日記録してコミットします²⁰。どのくらいのコミットを読んだかは「3割」とか「8割」とか直感的なもので構いません。最初は読める割合が少ないでしょうが、「読む人」の経験が増えるに従い、読みやすいコミットが増えてくるはずです。そうすると、コミットを読める割合も増えてきます。

データを分析する

定期的に以下のようなデータを収集して分析し、レポートします。

• 1コミットあたりのサイズ
• 1日のコミット数
• 開発メンバーのどのくらいのコミットを読めたかの割合

大きなコミットは読みにくいので1コミットあたりのサイズは小さくなっていくでしょう。1つのコミットが小さくなったら1日のコミット数は多くなっていくでしょう。それに伴って開発メンバーがより多くコミットを読めるようになっていくでしょう。

印象に残ったコミットが増えていくかもしれません。印象に残ったコミットを確認すると、よいコードの書き方がコードを通じてメンバー間に広まっているのがわかるかもしれません。コミットを読むために使った時間も記録しておくとよいかもしれません。

このようなデータを分析すれば、どのくらい「よいコードが当たり前の文化」が浸透しているかを確認できるようになるのではないかと期待しています。

お問い合わせ方法

まだ、荒削りなアイディアですが、興味がある方はお問い合わせフォームから「お問い合わせ種類」を「コミットへのコメントサービスについて」にしてお問い合わせください。詳細を説明します。

まとめ

DevLOVE 2012に参加して自分の考えがまとまりました。自分にとってとても実のあるセッションでした。感謝しています。参加者にも実のあるセッションであったらいいなぁと思います。

自分の考えがまとまり、コードを「読む人になる」こと、「悪いところよりよいところをみつける」視点でコード読むことの2つが大事だと気づきました。そして、それを支援するサービスを提供することにしました。

余談

ペアプロよりもコミットメールをみんなが読むほうがエクストリームだという持論があるのですが、それについて、いつか伝える機会があればいいなぁと思います²¹。

1. 最初は須藤一人だけでやる予定だったのですが、手に余りそうだったので沖元さんにも手伝ってもらいました。 ↩

2. Rabbitで作ったスライドをWebブラウザーで閲覧できるサイト。 ↩

3. 同じものがSlideShareとSpeaker Deckにもあります。 ↩

4. Rubyもそんな開発方法です。すべてのコミッターが他の人のコミットを読んでいるわけではありませんが、コミットの後に他の人がtypoを直したりしているのでそこそこ読んでいる人はいそうです。 ↩

5. 参加者にとってもそうであれば嬉しいですが。。。 ↩

6. DevLOVE 2012で数人の人から似たような話を聞きました。 ↩

7. 「世界を変えるのは自分自身だ」そうですよ。 ↩

8. 渾身会！ ↩

9. ありがとうございます！ ↩

10. その場でフォローしなくてすみません。。。 ↩

11. 自分も一緒によいコードを学んでいくんだ！という人は後輩と「一緒に」リーダブルコードを読んで「一緒に」リーダブルなコードを書こうとするのがよいと思います。本だけ渡して、「よいコードを書けよ」というのは、少なくとも私はやりたくありません。 ↩

12. 伝聞です。 ↩

13. 実体験です。YARDのmasterにコードが入るためにはレビューが必要です。 ↩

14. 匂いもするそうです。 ↩

15. 他の人がよいコードを書いていない場合はなかなかみつからないかもしれません。そのときは、自分でよいコードを書いて、自分の書いたコードのコミットは一日寝かしてから読んでみてください。そうすれば、他の人のコミットのように自分のコミットを読めるはずです。自分でよいコードをコミットしていたならよいコードがみつかるはずです。 ↩

16. 有料です。 ↩

17. 後で名前を変えるかもしれません。 ↩

18. 「今のところ」です。変更される可能性が十分にあります。 ↩

19. 最初は、「よいコードじゃないか？」視点で読むことはむずかしいことですよ！ ↩

20. コミットするともちろん全員に通知されます。 ↩

21. 概要はスライドに書いていますが、時間の都合で当日はこの話はしませんでした。 ↩