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