ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja zh ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja en ja ja en ja ja vi ja sv eu ja en en hu ja ja en en pl ja ja jbo hbs_lat en ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja ja
DevLOVE 2012: 「リーダブルコードを読んだ後」 #devlove2012 - 2012-12-18 - ククログ
他の「よいコードを書くための本」でも同じようなことが書いてあります。一年後の自分のことを想像して書きなさい、とかそういうやつです。
その考え方が違うんだなぁと気づきました。想像するのではなくて思い出す方がよいと気づきました。読む人のことを「想像しながら」書くのではなく、「思い出しながら」書きます。それがクリアコードでやっている開発方法ですし、フリーソフトウェアの開発でもやっている方法です。フリーソフトウェアの開発に関わってきた人なら、「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」というのはよくある話です。これは、自分が読みやすかったコードを「思い出して」よいコードを書いています。
リーダブルコードの解説は、自分がリーダブルなコードを書けるようになったら他の人のコードにも適用範囲を広げていこうという話の流れになっているのですが、これは間違いでした。まず、他の人のコードを読むことを当たり前にしてから、リーダブルなコードを書くことを考える方が正しいと今は思っています。「読む人」を実際にやっていれば、読む人のことを「想像」しないで、「思い出しながら」リーダブルなコードを書くことができます。
ということで、「まず読む人になる」というのがクリアコードの開発方法で大事にしていることだと気づきました。それに気づけて、私はとてもよかったです。
少しずれますが、世間では「レビューした方がいいとは思っているけど、忙しくて誰も自分のコードをレビューしてくれないんだよね」ということがあるそうです6。そういうときは、まず、自分が他の人のコードを読むとよいのではないでしょうか。レビューにどのくらい時間が必要かもわかりますし、あなたがレビューした人が、今度は逆にあなたのコードをレビューしてくれるかもしれません。レビュー時間が思ったより短いものだとわかったら無理せずにレビューの時間を作れるかもしれません。あなたが、「まず読む人になる」のはどうでしょうか7。
さらにずれますが、DevLOVE 2012の懇親会8でオライリー・ジャパンさん提供のリーダブルコード9をプレゼントしたときの話を少しします。事前に、リーダブルコードをプレゼントする人をどうやって決めましょうかと相談されたので、欲しい人に「どうして自分がリーダブルコードを欲しいか」を言ってもらって、私がそれっぽいと思ったらプレゼントすることにしました。その中で、「先輩の○○さんがよいコードを書くので、自分も同じようによいコードを書けるようになりたいから」と言ってくれた人がいました。私は「○○先輩のコードを読むといいんじゃないですかねぇ。」などとプレゼントしなかったのですが、もっとちゃんとプレゼントしない理由を説明するべきでした。リーダブルコードを読む時間を先輩のコードを読む時間に使ったほうがよいです。それは実際に自分たちが開発しているコードなので、サンプルコードで説明している10。もしあなたに後輩がいるのなら、リーダブルコードを後輩に渡して「これ読んで、よいコードを書けよ」ではなく、自分のコードで後輩によいコードを教えるのもよいかもしれませんね11。
悪いところよりよいところをみつける
さて、話を元に戻して、2つめの大事な気づきです。
「まず読む人になる」というのも大きな気づきでしたが、もうひとつ大きな気づきがありました。それが、「悪いところよりよいところを見つける」ということです。7月のリーダブルコードのイベントのときも札幌Ruby会議2012のときも触れていたことですが、こんなに大事なことだとは気づいていませんでした。
ランチの時間などにみんなで集まったり、pull requestなどを使ったりして、レビューをしているという話を聞いたことがあります。レビューでは、変なコードが入らないようにしてコードの質を上げるということをやっているようです12。これは、フリーソフトウェアの開発でも行われています13。つまり、「悪いコードがないか?」視点でコードを読むのがレビューでのコードの読み方のようです。
ところで、「悪いコードがないか?」視点ではなく、「よいコードではないか?」視点でコードを読んでみたことはありますか?
もし、「よいコードではないか?」視点で読んでみたことがないなら読んでみることをオススメします。これは、フリーソフトウェアの開発では実際に行われている読み方です。少し前に「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」という話を紹介しましたが、それができるのは「よいコードではないか?」視点で読んだからです。「悪いコードがないか?」視点だと、悪いコードばかりに目がいって、よいコードは見向きもされません。そうすると、せっかくメンバーがよいコードを書いていても、それが共有されません。自分たちが書いたコード内で「自分が読んだあのコードがよかったからマネして自分も同じようにコードを書いている」ができたらステキじゃないですか。
ただし、よいコードは悪いコードよりもみつけることが難しいです。悪いコードはいびつで目につきやすい14ですが、よいコードはまわりに自然になじんでいてスムーズに読めてしまうからです。これに気づけたのは、今回のセッションの事前課題のコミットを読んだからでした。事前課題では、リーダブルなコードとリーダブルじゃないコードをみつけてください、としていたのですが、全員リーダブルじゃないところばかりをみつけていました。これが、悪いコードの方がみつけやすいのはどうしてだろう、どうしてよいコードはみつけられないのだろうと考えるきっかけになりました。
それでは、よいコードをみつけることができるようになるためにはどうしたらよいでしょうか。最初はうまくいかないでしょうが、まずは「よいコードではないか?」視点で読むことを始めてみてください。ずっとコードを読んでいるとたまーによいコードがみつかるはずです15。
よいコードをみつけたら、それをマネしたよいコードをコミットしていきましょう。よいコミットに対して「いいね!今度自分もやるよ!」と言うよりも、「実際にやる」ということです。そっちの方が本物です。コミットはみんなが読んでいるので、コミットした人は自分のよいと思ってやっているコミットが他の人に取り入れられていることがわかります。2人が同じようにコミットしていることは他のメンバーにも届いています。もしかしたら、他のメンバーもマネしてくれるかもしれません。もしかしたら、もっとよい書き方でコミットするかもしれません。実際にコードを書くことでよいコードが広まっていくってステキだと思いませんか?
よいコードが当たり前の文化を作ることを支援したい
みんなが読む人になり、悪いところよりよいところをみつける視点で、みんなのコミットを読む。それがクリアコードの開発方法です。これが当たり前の文化になると、新しいメンバーが入ってきても、よいコードでよいコードがどういうものかを伝えることができるチームになるでしょう。
社内で実践したり、フリーソフトウェアの開発に参加したりしているため、クリアコードにはこのよう開発方法を実践するノウハウがあります。そこで、この開発方法を実践し、文化として根付かせたいという開発チームを支援するサービスを提供することにしました16。支援した結果として、よいコードが当たり前というプログラマーが増えるといいなぁと思っています。
ただし、このサービスは、クリアコードがずっと支援するサービスではなく、サービスを卒業して自分たちだけで新しい人も受け入れられる文化をもった開発チームを作るためのサービスです。もちろん、会社的にはずっと契約が続いた方が安定した収入になるのですが、それではよいコードが当たり前のプログラマーが増える助けにはならないので、卒業して欲しいと思っています。卒業を前提とすると、サービスを提供する方も、提供される方も、「よいコードが当たり前の文化を作る」という同じゴールになるため、より早く卒業できるように協力しあって進められるのではないかと期待しています。
コミットへのコメントサービス
このサービスの名前は「コミットへのコメントサービス」です17。今のところ、以下のように進めるのがよいのではないかと考えています18。
コミットメールを読んでコメントする
以下、「開発チーム」とはこのサービスを導入した開発チームのことを指します。
まず、DevLOVE 2012でやったようなセッションを導入研修として実施します。導入研修では、どのようにコードを読むのか、どういう文化にしようとしているのかを説明・質疑応答し、「よいコードが当たり前の文化を作る」ということについての理解を深めます。また、実際にコードを読むということを体験します。最初に導入研修をやることにより、自分たちがどのくらいできるのか、今は何ができないのかが把握できることを期待しています19。
コミットメールを読んでコメントする
「よいコードが当たり前の文化を作る」ことへの理解が深まったら、実際に「みんながみんなのコードを読む」環境を作ります。具体的にはクリアコードの担当者と開発チーム全員にコミットメールが届くようにします。開発チームは通常通り開発をしますが、全員がコミットメールを読みます。全部読めなくても構いません。おそらく、最初は全部読めないでしょう。というのも、「読む人」の経験があまりない人は読みやすいコミットをうまく作れないからです。クリアコードの担当者はコミットメールを読んでどうすればより読みやすいコミットになるかをコメントします。開発チームからの質問にも回答します。開発チーム内でも、どうすればより読みやすいコミットになるかを積極的に試行錯誤することを期待しています。
クリアコードの担当者と開発チームはどのくらいのコミットを読んだかとその日印象に残ったコミットを毎日記録してコミットします20。どのくらいのコミットを読んだかは「3割」とか「8割」とか直感的なもので構いません。最初は読める割合が少ないでしょうが、「読む人」の経験が増えるに従い、読みやすいコミットが増えてくるはずです。そうすると、コミットを読める割合も増えてきます。
定期的に以下のようなデータを収集して分析し、レポートします。
1コミットあたりのサイズ
開発メンバーのどのくらいのコミットを読めたかの割合
大きなコミットは読みにくいので1コミットあたりのサイズは小さくなっていくでしょう。1つのコミットが小さくなったら1日のコミット数は多くなっていくでしょう。それに伴って開発メンバーがより多くコミットを読めるようになっていくでしょう。
印象に残ったコミットが増えていくかもしれません。印象に残ったコミットを確認すると、よいコードの書き方がコードを通じてメンバー間に広まっているのがわかるかもしれません。コミットを読むために使った時間も記録しておくとよいかもしれません。
このようなデータを分析すれば、どのくらい「よいコードが当たり前の文化」が浸透しているかを確認できるようになるのではないかと期待しています。
まだ、荒削りなアイディアですが、興味がある方はお問い合わせフォームから「お問い合わせ種類」を「コミットへのコメントサービスについて」にしてお問い合わせください。詳細を説明します。
DevLOVE 2012に参加して自分の考えがまとまりました。自分にとってとても実のあるセッションでした。感謝しています。参加者にも実のあるセッションであったらいいなぁと思います。
自分の考えがまとまり、コードを「読む人になる」こと、「悪いところよりよいところをみつける」視点でコード読むことの2つが大事だと気づきました。そして、それを支援するサービスを提供することにしました。
ペアプロよりもコミットメールをみんなが読むほうがエクストリームだという持論があるのですが、それについて、いつか伝える機会があればいいなぁと思います21。
最初は須藤一人だけでやる予定だったのですが、手に余りそうだったので沖元さんにも手伝ってもらいました。 ↩
Rabbitで作ったスライドをWebブラウザーで閲覧できるサイト。 ↩
同じものがSlideShareとSpeaker Deckにもあります。 ↩
Rubyもそんな開発方法です。すべてのコミッターが他の人のコミットを読んでいるわけではありませんが、コミットの後に他の人がtypoを直したりしているのでそこそこ読んでいる人はいそうです。 ↩
参加者にとってもそうであれば嬉しいですが。。。 ↩
DevLOVE 2012で数人の人から似たような話を聞きました。 ↩
「世界を変えるのは自分自身だ」そうですよ。 ↩
ありがとうございます! ↩
その場でフォローしなくてすみません。。。 ↩
自分も一緒によいコードを学んでいくんだ!という人は後輩と「一緒に」リーダブルコードを読んで「一緒に」リーダブルなコードを書こうとするのがよいと思います。本だけ渡して、「よいコードを書けよ」というのは、少なくとも私はやりたくありません。 ↩
実体験です。YARDのmasterにコードが入るためにはレビューが必要です。 ↩
匂いもするそうです。 ↩
他の人がよいコードを書いていない場合はなかなかみつからないかもしれません。そのときは、自分でよいコードを書いて、自分の書いたコードのコミットは一日寝かしてから読んでみてください。そうすれば、他の人のコミットのように自分のコミットを読めるはずです。自分でよいコードをコミットしていたならよいコードがみつかるはずです。 ↩
後で名前を変えるかもしれません。 ↩
「今のところ」です。変更される可能性が十分にあります。 ↩
最初は、「よいコードじゃないか?」視点で読むことはむずかしいことですよ! ↩
コミットするともちろん全員に通知されます。 ↩
概要はスライドに書いていますが、時間の都合で当日はこの話はしませんでした。 ↩
現在クリアコードではソフトウェア開発者を募集しています! フリーソフトウェア開発での開発の仕方をベースに、成果や知識を公開し共有しながら業務に携われます。
CutterをWindowsでgrowlnotifyと一緒に使う方法
「コミットへのコメントサービス」の販売を開始
Apache Arrow
milter manager
ククログの記事はCC BY-SA 4.0とGFDLのデュアルライセンスで自由に利用できます。
クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。
クリアコードは「クリアコードをいい感じにする人」を1名募集しています。
クリアコードはフリーソフトウェア開発で培った技術力を提供しています。特にMozilla製品(Mozilla FirefoxとMozilla Thunderbird)とRubyとGroonga(全文検索)に関連した開発を得意としています。