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 en ja ja ja ja pl 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
るびま0040号の「Rubyコードの感想戦」とDevLOVE Conference 2012の「リーダブルコードを読んだ後」のお知らせ - 2012-11-26 - ククログ
昨日(2012-11-25)、るびま0040号がリリースされました。今回、久しぶりに記事を寄稿しました1。Ruby コードの感想戦 【第 1 回】 WikiRというタイトルの記事です。あの咳さんのコードにコメントをして、気に入らないところがあったら理由をつけながら直していく(自分好みに変えていく)という内容です。記事中で作ったコードや実際のコミット、記事の原稿などはすべてGitHubにあるので、コードをコピー&ペーストしたりせずに動かしてみたいという人はGitHubにあるリポジトリを見てみるとよいでしょう2。
るびまには「よい 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に参加しない人でも、リーダブルなコードに興味のある人はやってみてください。もう少し具体的な手順は以下の通りです。
リーダブルコードを読む。
「Ruby コードの感想戦 【第 1 回】 WikiR」を読む。
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でのセッション「リーダブルコードを読んだ後」を紹介しました。興味が湧いた人はまずはるびまの記事を読んでみてください。
おまけ(るびまの記事の感想):
wikir review's review — Gist
0031号のるりまサーチの作り方 - Ruby 1.9 で groonga 使って全文検索以来なので約2年ぶり。 ↩
この原稿用のリポジトリがGitHubにあることは記事中では触れていない。 ↩
イベントページによると、すでに満席ですが増席を検討しているとのこと。 ↩
現在クリアコードではソフトウェア開発者を募集しています! フリーソフトウェア開発での開発の仕方をベースに、成果や知識を公開し共有しながら業務に携われます。
CentOS 5でCentOS 6用のzshのSRPMをビルドする方法
いいアドバイスをもらうための相談の仕方
Apache Arrow
milter manager
ククログの記事はCC BY-SA 4.0とGFDLのデュアルライセンスで自由に利用できます。
クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。
クリアコードは「クリアコードをいい感じにする人」を1名募集しています。
クリアコードはフリーソフトウェア開発で培った技術力を提供しています。特にMozilla製品(Mozilla FirefoxとMozilla Thunderbird)とRubyとGroonga(全文検索)に関連した開発を得意としています。