るびま0040号の記事とDevLOVE Conference 2012でのセッションの紹介です。
るびまの記事「Rubyコードの感想戦」の紹介
昨日（2012-11-25）、るびま0040号がリリースされました。今回、久しぶりに記事を寄稿しました1。Ruby コードの感想戦 【第 1 回】 WikiRというタイトルの記事です。あの咳さんのコードにコメントをして、気に入らないところがあったら理由をつけながら直していく（自分好みに変えていく）という内容です。記事中で作ったコードや実際のコミット、記事の原稿などはすべてGitHubにあるので、コードをコピー&ペーストしたりせずに動かしてみたいという人はGitHubにあるリポジトリを見てみるとよいでしょう2。
この記事は「Ruby コードの感想戦」という連載の最初の記事です。この連載の趣旨が記事の最初に書かれているので引用します。
るびまには「よい Ruby コードのお手本を示す」というスタイルの青木峰郎さんの「あなたの Ruby コードを添削します」という名連載がありました。
新しく始まるこの連載もコード添削をテーマにした連載です。青木さんの連載との違いは、「よい Ruby コードのお手本を示す」、「Ruby で書くよいコードのベストプラクティスを提供する」というのではなく、「よいコードにも視点の違いによって多様性があり、それぞれの視点を読んだうえで記事を読む人に自分はどう考えるかを考えてもらう」というスタイルをとる点です。結果として、読んだ人が自分のコードを書くときに、視点がひとつ、ふたつ増えているということを期待しています。
この連載では、「ある人がコードにコメントし、そのコメントに対してまた別の人がコメントする」という記事がセットで進んでいきます。コメントする人は特定の誰かではなく、毎回変わっていきます。先生と生徒の関係ではなく、コメントする人、される人、どちらもコードに一家言持ったプログラマです。きっと、いろいろな視点を見つけられるはずです。
「ベストプラクティスを提供するというのではない」というのがいいですね。「この通りやれば大丈夫だ！」というのをなぞってやっていくことが楽なことはわかりますが、それだけで進んでいくと「ベストプラクティス」から少し外れたことに出会うとうまくいかないという危険があることを忘れてはいけません。「ベストプラクティス」を知識として持っているだけではなく、どうしてこれが「ベストプラクティス」とされているのかという理由まで理解して使えれば、少し外れたことでも「ベストプラクティス」を応用して使いこなせるでしょう。
連載の今後の記事ではどんなスタイルになるかわかりませんが、この記事では「どうして私はそう考えたか」、「咳さんはどのように考えてこのコードを書いただろうか」ということを省略せずにしっかり書いています。テクニックよりも、プログラマーがどうしてそのテクニックを使うのかという理由の方を大事にしているということです。信頼できるコードを書くプログラマーなら、どうしてこういうコードにするかということを考えてコードを書いているものです。この記事を読んだプログラマーが信頼できるコードを書くプログラマーになってくれるといいなぁという期待を込めています。
この記事はコードへコメントする記事なので、コードへたくさんコメントしています。最近では、コードへコメントするというと、GitHub上でpull requestしてコメント欄や行コメントでやりとりするというのが「ベストプラクティス」だというのをちらほらと見かけます。しかし、この記事では違う方法を使っています。それは日本語のコメントではなく直接コミットしてコードで伝える方法です。どうしてこの方法を使っているかという理由を引用します。
直接コミットすると、そのコミットには以下の情報が含まれます。
- どう直したかのサマリー（Use Monitor instead of MonitorMixin）
- どうしてこう直したかという理由（Monitor is readable rather than MonitorMixin.）
- どう直したか（変更点そのもの。diff）
私は、こっちのコードの方がいいんじゃないかということを伝える時には「どうしてそう思うか」という理由も伝えたいなぁと思っています。理由も伝えれば同じパターンの別のケースの時にも使える知識になってくれるのではないかと期待しているからです。そして、上述のようにコミットすることにより私が伝えたい内容を全部含んだ状態で伝えられるのではないかと思っています。ただ、これが本当に効果がある方法なのかどうかはまだわかっていません。
まだ、試行錯誤しているやり方ですが、コードに日本語や英語でコメントするよりも、コードでコメントするやり方をオススメしたいです。コードでコメントするということは、コメントをもらう側がわかりやすいコードでコメントしなければいけません。読む人のことをたくさん考えたコードを書く必要があります。コードでコメントをすることで、読む人のことを考えたコードを書くことがより当たり前のことになり、コメントのためのコードだけではなく、ふだん書くコードも読む人のことを考えたコードになったら、きっと信頼できるコードができるでしょう。
記事中でコードでコメントするやり方をしているのは、そんなことを期待しているからです。
DevLOVE Conference 2012のセッション「リーダブルコードを読んだ後」の紹介
るびまの記事ともつながるのでDevLOVE Conference 2012でのセッションも紹介します。
2012-12-16（日）にDevLOVE Conference 2012でリーダブルコードを読んだ後というセッションをします。このセッションは、今年の夏にやったリーダブルコードの企画のうち「リーダブルコードとはどのようなコードかを実際のコードを題材に考える」というワークショップ部分をもう一度やるセッションです3。セッション概要を引用します。
リーダブルコードという読みやすいコード（リーダブルなコード）の書き方をわかりやすく説明した本があります。リーダブルコードに書かれているテクニックを使えばリーダブルな理解しやすいコードを書けるようになります。
しかし、リーダブルコードを読んだ人すべてがリーダブルなコードを書けるようになれるわけではありません。リーダブルコードに書かれていることを知識として持っているだけではリーダブルなコードは書けません。実際にその知識を使ってコードを書かなければリーダブルコードを読む前と同じようなコードばかり書くことになります。
このセッションはリーダブルコードに書かれていることを実際に使うためにはどうすればよいかということについてのセッションです。前半は講演者がどうすればよいかという話をします。後半は講演者と参加者で実際のコードを題材にリーダブルコードとはどういうコードなのかをディスカッションします。
るびまの記事の紹介のところでも「ベストプラクティスを知識として持っているだけではだめだ」ということを書いていましたが、このセッションでも「リーダブルコードに書かれていることを知識として持っているだけではリーダブルなコードは書けません」という点を問題としています。DevLOVE 2012のページに大きく「世界を変えるのは他の誰かではない、世界を変えるのは、自分自身だ。」とある通り、このセッションに参加したら「自分自身がリーダブルなコードを書いて世界を変えていく」ようになるようにセッションの準備を進めています。
ただ、実際にコードを読み書きしながらリーダブルなコードについて考えるのには50分の枠では時間が足りません。そのため、参加者には事前に以下のことをお願いする予定です。
- リーダブルコードを読んでおくこと。 （リーダブルなコードについての基本的な知識を把握するため）
- この記事で紹介している、るびまの記事「Ruby コードの感想戦 【第 1 回】 WikiR」を読んでおくこと。 （コードでコードにコメントをするやり方を把握するため）
- git-utils/commit-email.rbを読んで、どこがリーダブルでどこがリーダブルではないかをるびまの記事にあるやり方で検討しておくこと。 （リハーサル。セッション内で初見でやるとリーダブルなコードについて考える時間がなくなるため。）
DevLOVE Conference 2012に参加しない人でも、リーダブルなコードに興味のある人はやってみてください。もう少し具体的な手順は以下の通りです。
-
リーダブルコードを読む。
-
GitHubでclear-code/git-utilsをforkする。
-
commit-email.rbを読んでリーダブルなところとリーダブルではないところを考える。
- リーダブルなところがあったらコードのコメントに理由を書いてcommitする。
- リーダブルではないところがあったら、るびまの記事でやっているように、よくなるように変更して、どうしてそれがよいかという理由をコミットメッセージに書いてcommitする。
- ↑は1箇所につき1つのcommitにする。
- 随時pushして誰でも見られるようにする。
- まわりの人に↑のcommitについて意見を求めてみる。同意するとか自分はそうは思わないとかを聞いてみる。「まわりの人」は職場の人でもインターネット上で付き合いのある人でもどちらでもかまわない。
セッションが終わったら以下のようになることを期待しています。
-
commit-email.rbだけではなく、自分がいま関わっているコードでもやる。
-
普段からリーダブルなコードを書く。
-
どうしたらもっとリーダブルなコードになるかを考えながらコードを書く。
まとめ
るびま0040号の記事「Ruby コードの感想戦 【第 1 回】 WikiR」とDevLOVE Conference 2012でのセッション「リーダブルコードを読んだ後」を紹介しました。興味が湧いた人はまずはるびまの記事を読んでみてください。
おまけ（るびまの記事の感想）:
