2012が開催されました。2012はDevLOVEの100回目の開催だそうです。継続していることもすごいですが、掲げているテーマも「世界を変えるのは他の誰かではない、世界を変えるのは自分自身だ。」と、挑戦的ですごいですね。2012で「リーダブルコードを読んだ後」というタイトルのセッションをしてきました*1。忘れてもいいコードを書こう。」というDevLOVEのイベントに講師として参加したのですが、その縁で声をかけてもらいました。7月にやったイベントは「リーダブルコードというのはどういうものか考えてみよう」という内容だったので、今回は「リーダブルコードがよいか悪いかを考える時期はもう終わった。リーダブルコードはよいものだとわかった。実際にリーダブルコードを書くことが当たり前な文化にしていこうじゃないか。」という内容にすることになりました。具体的にはリーダブルコードが当たり前な文化となっているクリアコードの開発方法を体験するというワークショップ形式のセッションになりました。SlideShow*2にあります*3。概要クリアコードの開発方法はリーダブルコードの解説に書いてあるような開発方法です。みんながみんなのコミットを読み、気になったコミットがあったらコメントしたり直接修正したりするという開発方法です。これは、フリーソフトウェアの開発では昔から実践されている方法です*4。後述するように、他の人のコミットを読むことが当たり前な開発方法はメリットが大きいと思っているのですが、フリーソフトウェアの開発に縁のない職場での開発では使われていないようです。そのため、みんながみんなのコミットを読むという開発方法を実際に体験してみましょう、というのがこのセッションの内容です。このセッションのおかげで、クリアコードの開発方法では以下の2つのことを大事にしていることに気づきました。読む人になる悪いところよりよいところをみつけるそれぞれについて説明します。読む人になるリーダブルコードの解説を書いたときから、「リーダブルコードが当たり前の開発チームはどうやって作るのだろうか」ということを考えるようになり、解説を書いた後も考えていました。札幌Ruby会議2012の「クリアなコードの作り方」というセッションで話した内容はリーダブルコードの解説の内容からさらに考えを進めたものでした。解説の内容よりもさらに次のことまで踏み込んではいましたが、終わってみたら、話した本人にはモヤっとしたものが残っていました。今回のセッションの準備のために考えたり、セッションで参加者と話したりすることで、より考えが進みました。私にとっては、とても実のあるセッションになった*5のでとても感謝しています。今回のイベントで気づいたことは「はじめにすることは読む人になること」ということです。やるんだよ」にはこう書いてあります。想像上の誰かが自分のコードを理解しやすいかなんて考えるのは大変なことだ。他の「よいコードを書くための本」でも同じようなことが書いてあります。一年後の自分のことを想像して書きなさい、とかそういうやつです。その考え方が違うんだなぁと気づきました。想像するのではなくて思い出す方がよいと気づきました。読む人のことを「想像しながら」書くのではなく、「思い出しながら」書きます。それがクリアコードでやっている開発方法ですし、フリーソフトウェアの開発でもやっている方法です。フリーソフトウェアの開発に関わってきた人なら、「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」というのはよくある話です。これは、自分が読みやすかったコードを「思い出して」よいコードを書いています。リーダブルコードの解説は、自分がリーダブルなコードを書けるようになったら他の人のコードにも適用範囲を広げていこうという話の流れになっているのですが、これは間違いでした。他の人のコードを読むことを当たり前にしてから、リーダブルなコードを書くことを考える方が正しいと今は思っています。「読む人」を実際にやっていれば、読む人のことを「想像」しないで、「思い出しながら」リーダブルなコードを書くことができます。いうことで、「まず読む人になる」というのがクリアコードの開発方法で大事にしていることだと気づきました。それに気づけて、私はとてもよかったです。ずれますが、世間では「レビューした方がいいとは思っているけど、忙しくて誰も自分のコードをレビューしてくれないんだよね」ということがあるそうです*6。いうときは、まず、自分が他の人のコードを読むとよいのではないでしょうか。レビューにどのくらい時間が必要かもわかりますし、あなたがレビューした人が、今度は逆にあなたのコードをレビューしてくれるかもしれません。レビュー時間が思ったより短いものだとわかったら無理せずにレビューの時間を作れるかもしれません。あなたが、「まず読む人になる」のはどうでしょうか*7。2012の懇親会*8でオライリー・ジャパンさん提供のリーダブルコード*9をプレゼントしたときの話を少しします。事前に、リーダブルコードをプレゼントする人をどうやって決めましょうかと相談されたので、欲しい人に「どうして自分がリーダブルコードを欲しいか」を言ってもらって、私がそれっぽいと思ったらプレゼントすることにしました。その中で、「先輩の○○さんがよいコードを書くので、自分も同じようによいコードを書けるようになりたいから」と言ってくれた人がいました。私は「○○先輩のコードを読むといいんじゃないですかねぇ。」などとプレゼントしなかったのですが、もっとちゃんとプレゼントしない理由を説明するべきでした。リーダブルコードを読む時間を先輩のコードを読む時間に使ったほうがよいです。それは実際に自分たちが開発しているコードなので、サンプルコードで説明しているリーダブルコードよりずっと実践的です。コードで気になることがあったら直接先輩に聞けます。本の場合はなかなか著者に気になったところを聞くことはできません。よいコードを書く先輩がいるのなら、本を読むよりも先輩のコードを読む時間に使って欲しかったのです。プレゼントしませんでした*10。あなたに後輩がいるのなら、リーダブルコードを後輩に渡して「これ読んで、よいコードを書けよ」ではなく、自分のコードで後輩によいコードを教えるのもよいかもしれませんね*11。悪いところよりよいところをみつけるさて、話を元に戻して、2つめの大事な気づきです。「まず読む人になる」というのも大きな気づきでしたが、もうひとつ大きな気づきがありました。それが、「悪いところよりよいところを見つける」ということです。7月のリーダブルコードのイベントのときも札幌Ruby会議2012のときも触れていたことですが、こんなに大事なことだとは気づいていませんでした。requestなどを使ったりして、レビューをしているという話を聞いたことがあります。レビューでは、変なコードが入らないようにしてコードの質を上げるということをやっているようです*12。これは、フリーソフトウェアの開発でも行われています*13。「悪いコードがないか?」視点でコードを読むのがレビューでのコードの読み方のようです。ところで、「悪いコードがないか?」視点ではなく、「よいコードではないか?」視点でコードを読んでみたことはありますか?もし、「よいコードではないか?」視点で読んでみたことがないなら読んでみることをオススメします。これは、フリーソフトウェアの開発では実際に行われている読み方です。前に「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」という話を紹介しましたが、それができるのは「よいコードではないか?」視点で読んだからです。「悪いコードがないか?」視点だと、悪いコードばかりに目がいって、よいコードは見向きもされません。すると、せっかくメンバーがよいコードを書いていても、それが共有されません。自分たちが書いたコード内で「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」ができたらステキじゃないですか。よいコードは悪いコードよりもみつけることが難しいです。悪いコードはいびつで目につきやすい*14ですが、よいコードはまわりに自然になじんでいてスムーズに読めてしまうからです。これに気づけたのは、今回のセッションの事前課題のコミットを読んだからでした。事前課題では、リーダブルなコードとリーダブルじゃないコードをみつけてください、としていたのですが、全員リーダブルじゃないところばかりをみつけていました。これが、悪いコードの方がみつけやすいのはどうしてだろう、どうしてよいコードはみつけられないのだろうと考えるきっかけになりました。それでは、よいコードをみつけることができるようになるためにはどうしたらよいでしょうか。最初はうまくいかないでしょうが、まずは「よいコードではないか?」視点で読むことを始めてみてください。コードを読んでいるとたまーによいコードがみつかるはずです*15。よいコードをみつけたら、それをマネしたよいコードをコミットしていきましょう。よいコミットに対して「いいね!今度自分もやるよ!」と言うよりも、「実際にやる」ということです。そっちの方が本物です。コミットはみんなが読んでいるので、コミットした人は自分のよいと思ってやっているコミットが他の人に取り入れられていることがわかります。2人が同じようにコミットしていることは他のメンバーにも届いています。したら、他のメンバーもマネしてくれるかもしれません。したら、もっとよい書き方でコミットするかもしれません。実際にコードを書くことでよいコードが広まっていくってステキだと思いませんか?よいコードが当たり前の文化を作ることを支援したいみんなが読む人になり、悪いところよりよいところをみつける視点で、みんなのコミットを読む。それがクリアコードの開発方法です。これが当たり前の文化になると、新しいメンバーが入ってきても、よいコードでよいコードがどういうものかを伝えることができるチームになるでしょう。社内で実践したり、フリーソフトウェアの開発に参加したりしているため、クリアコードにはこのよう開発方法を実践するノウハウがあります。そこで、この開発方法を実践し、文化として根付かせたいという開発チームを支援するサービスを提供することにしました*16。支援した結果として、よいコードが当たり前というプログラマーが増えるといいなぁと思っています。このサービスは、クリアコードがずっと支援するサービスではなく、サービスを卒業して自分たちだけで新しい人も受け入れられる文化をもった開発チームを作るためのサービスです。会社的にはずっと契約が続いた方が安定した収入になるのですが、それではよいコードが当たり前のプログラマーが増える助けにはならないので、卒業して欲しいと思っています。卒業を前提とすると、サービスを提供する方も、提供される方も、「よいコードが当たり前の文化を作る」という同じゴールになるため、より早く卒業できるように協力しあって進められるのではないかと期待しています。コミットへのコメントサービスこのサービスの名前は「コミットへのコメントサービス」です*17。今のところ、以下のように進めるのがよいのではないかと考えています*18。導入研修コミットメールを読んでコメントするデータを分析する以下、「開発チーム」とはこのサービスを導入した開発チームのことを指します。2012でやったようなセッションを導入研修として実施します。導入研修では、どのようにコードを読むのか、どういう文化にしようとしているのかを説明・質疑応答し、「よいコードが当たり前の文化を作る」ということについての理解を深めます。実際にコードを読むということを体験します。最初に導入研修をやることにより、自分たちがどのくらいできるのか、今は何ができないのかが把握できることを期待しています*19。コミットメールを読んでコメントする「よいコードが当たり前の文化を作る」ことへの理解が深まったら、実際に「みんながみんなのコードを読む」環境を作ります。具体的にはクリアコードの担当者と開発チーム全員にコミットメールが届くようにします。開発チームは通常通り開発をしますが、全員がコミットメールを読みます。全部読めなくても構いません。最初は全部読めないでしょう。いうのも、「読む人」の経験があまりない人は読みやすいコミットをうまく作れないからです。クリアコードの担当者はコミットメールを読んでどうすればより読みやすいコミットになるかをコメントします。開発チームからの質問にも回答します。開発チーム内でも、どうすればより読みやすいコミットになるかを積極的に試行錯誤することを期待しています。クリアコードの担当者と開発チームはどのくらいのコミットを読んだかとその日印象に残ったコミットを毎日記録してコミットします*20。どのくらいのコミットを読んだかは「3割」とか「8割」とか直感的なもので構いません。最初は読める割合が少ないでしょうが、「読む人」の経験が増えるに従い、読みやすいコミットが増えてくるはずです。すると、コミットを読める割合も増えてきます。データを分析する定期的に以下のようなデータを収集して分析し、レポートします。大きなコミットは読みにくいので1コミットあたりのサイズは小さくなっていくでしょう。1つのコミットが小さくなったら1日のコミット数は多くなっていくでしょう。それに伴って開発メンバーがより多くコミットを読めるようになっていくでしょう。印象に残ったコミットが増えていくかもしれません。印象に残ったコミットを確認すると、よいコードの書き方がコードを通じてメンバー間に広まっているのがわかるかもしれません。コミットを読むために使った時間も記録しておくとよいかもしれません。このようなデータを分析すれば、どのくらい「よいコードが当たり前の文化」が浸透しているかを確認できるようになるのではないかと期待しています。お問い合わせ方法まだ、荒削りなアイディアですが、興味がある方はお問い合わせフォームから「お問い合わせ種類」を「コミットへのコメントサービスについて」にしてお問い合わせください。2012に参加して自分の考えがまとまりました。自分にとってとても実のあるセッションでした。参加者にも実のあるセッションであったらいいなぁと思います。自分の考えがまとまり、コードを「読む人になる」こと、「悪いところよりよいところをみつける」視点でコード読むことの2つが大事だと気づきました。それを支援するサービスを提供することにしました。余談ペアプロよりもコミットメールをみんなが読むほうがエクストリームだという持論があるのですが、それについて、いつか伝える機会があればいいなぁと思います*21。最初は須藤一人だけでやる予定だったのですが、手に余りそうだったので沖元さんにも手伝ってもらいました。Rabbitで作ったスライドをWebブラウザーで閲覧できるサイト。Deckにもあります。Rubyもそんな開発方法です。すべてのコミッターが他の人のコミットを読んでいるわけではありませんが、コミットの後に他の人がtypoを直したりしているのでそこそこ読んでいる人はいそうです。参加者にとってもそうであれば嬉しいですが。2012で数人の人から似たような話を聞きました。「世界を変えるのは自分自身だ」そうですよ。その場でフォローしなくてすみません。自分も一緒によいコードを学んでいくんだ!という人は後輩と「一緒に」リーダブルコードを読んで「一緒に」リーダブルなコードを書こうとするのがよいと思います。本だけ渡して、「よいコードを書けよ」というのは、少なくとも私はやりたくありません。