『リーダブルコード − 忘れてもいいコードを書こう。』に参加してきた #devlove

• 7月6日 リーダブルコード − 忘れてもいいコードを書こう。(東京都)
• 書籍『リーダブルコード』発売後の反響つぶやきまとめ - Togetter
• 2012/07/06 リーダブルコード − 忘れてもいいコードを書こう。#devlove - Togetter

(写真：会場入り口の立て看板。)

今回のDevLOVEのテーマは、リーダブルコード です。 
「リーダブルコード」がより多くの人が普通に使う言葉となるよう 
Oreillyのリーダブルコードの発刊にあわせて、企画しました。 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

こちらは原著。

The Art of Readable Code: Simple and Practical Techniques for Writing Better Code

最初に、翻訳者の角征典さんより「私と良いコード」というテーマで 
発表を頂きます。その後、サンプルコードをもとに参加者同士で 
これはリーダブルコードなのかどうか、どうすればリーダブルコード 
となるかをディスカッションする時間を設けました。 
皆さんが検討した後に、コードを添削解説するのはもちろん、 
須藤功平さんです。 
この企画を通し、リーダブルコードが現場に生まれ、多くの人々に 
読み継がれることを、願う。 

先月の発売後、かなりの勢いで増刷を重ね、書店で手に入れるのも現状かなり大変な状況となっている書籍『リーダブルコード』。

• 書籍『リーダブルコード』発売後の反響つぶやきまとめ - Togetter

この日企画: Oreilly & DevLOVE 共同企画という形で書籍販売記念イベントが開催されていたので、事前に書籍を購入→目を通し、参加してきました！
(※ちなみに参加定員50名は速攻で埋まってしまっていました。ここにも書籍の人気の高さが伺えますね。

開催会場は株式会社インターネットイニシアティブ＠神保町。個人的には、社会人以降、家のネット回線プロバイダとして現在まで長〜く利用させて頂いております。(*^_^*) ありがとうございます、IIJ！

(※関係無いが、行きの最寄り駅(神保町)で目にした『もやしもん』の広告。)

また、会場内には書籍『リーダブルコード』を含めた関連書籍の販売所も設けられておりました。

講演：「私と良いコード」改め『リーダブル リーダブルコード』

• 角 征典氏 角征典 KADO Masanori(TwitterID:@kdmsnr)

• 20120706-readablecode
  • View more presentations from Masanori Kado

• 『お足元の悪い中、お越し頂きありがとうございます。』
• 早速第4刷決定！

• eBook版に関しては秋頃の発売を予定。
• お詫び：現在第1刷、第2刷分については情報あり。詳細は以下の情報を御参照下さい。
  • O'Reilly Japan - リーダブルコード 第1刷、第2刷正誤表

• 自己紹介
  • 『リーダブルじゃないTwitterIDです』
  • 本業はプログラマ。
  • 訳書多数。

Clean Coder プロフェッショナルプログラマへの道

メタプログラミングRuby

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)

その他年内発売予定の訳書も数冊待ち構えているらしいです。以下は原著。併せてもう1冊、翻訳を進めている書籍があるとの事ですがこちらについては書籍名等は秘密のまま。進行中の書籍共々発売が楽しみですね。

Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services (Addison-Wesley Signature Series (Fowler))

Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement

Running Lean: Iterate from Plan A to a Plan That Works (Lean Series)

• 原著タイトル：『The Art of Readable Code』から翻訳版タイトル：『リーダブルコード』へ

しかしこれには理由が。以下の須藤さんの記事を参照。

• リーダブルコードの解説 - ククログ(2012-06-11)

• 名前重要

• じゃあ、どんなコード？
  • リーダブルコードの基本定理

コードは他の人が最短時間で理解できるように書かなければいけない。(書籍P.3)

• ハァ？なんで？
  • コードの良さは重要だ…は危うい前提

... 読むに耐えないコードが大金を稼いでいる場面を散々目にしてきたので...

実装パターン

• でも、やるんだよ！
  • 良いコードを書くこと自体が喜び。
  • 色々言っても結局徒労に終わる部分も。結局自分でやるしかない。

実装パターン

• 2章：名前に情報を埋め込む
  • 名前をつけるのは難しい。子供の名前をつける時くらいに真剣に。
  • 最も基本的なこと
    • 式は自分で音読するつもりで書こう。

プログラミング作法

• • • 発音可能な名前をつける。
  • retval (なんて読むの？）
    • 汎用的な名前をつける (書籍P.12)
    • [ネタ]詠太2で音読する ※Windowsじゃないと動きません
      • 滑らかで自然な音声読み上げ 詠太2｜日本語ワープロソフト 一太郎2012 承

…あれ？これショウ君の声じゃね？w (でもイベント当日はソースコードを女性の声で読み上げておりました。ソフト自体に幾つか音声が入ってるのかな？)

• モヤモヤさまぁ〜ず2：テレビ東京 公式サイト
  • ショウ君コーナー | HOYA音声合成ソフトウェア VoiceText

やべぇ、これ欲しくなってきたかも(笑)

一太郎2012 承 特別優待版

• 読み手の事を考えよう。...とは言っても難しいよ。

• 5章：コメントすべきこと
  • 必要なことはコードに書く
    • 覚えておくべき情報をコード内に書き込んでおく事…
  • コードがドキュメントだ。
  • でも、無いものは見えない
    • コミットする前のコード
    • 使わなかった選択肢
    • 却下された要望や提案

• 監督コメンタリー(書籍 P.60)
  • 映画DVDの特典のように
  • 説明・思い・裏話をコメントに書く
  • うまく行かなかった事も書く
  • 疑問を先回りして埋めておく

• 理由重要
  • 影響力と武器

• 理由は何でもいいらしい
  • [◎]すみません、急いているので、先にコピーを…
  • [×]すみません、先にコピーを取らせてもらえませんか‥？
  • 理由をつけたもん勝ち。【なんとなく】というのが一番困る

• 思考の断片を刻む場所
  • コードではないかもだけど…
    • コミットの情報
    • ドキュメント

• 大切なTODO.md
  • 多くのデベロッパはこの種の観察作業の為に簡単なtodoリストを作っている。

テスト駆動JavaScript

• ドキュメント書いても読まれないし
  • それでも『ポステルの法則』を参考に
  • 受信するものには寛容に、送信するものには慎重に
    • ジョン・ポステル - Wikipedia

• 12章 コードに思いを込める
  • 以下のアインシュタインの言葉

おばあちゃんがわかるように説明できないと、本当に理解したとは言えない。

• • テディベアやアヒルちゃんに説明してみる。(書籍 P.165)
  • まさか？とは思うが、『プログラミング作法』『達人プログラマー』にも書いている。なのでぐぬぬ…となる(※角さん談)

プログラミング作法

達人プログラマー―システム開発の職人から名匠への道

• コードの書き方
• 1.説明内容をコメントに書く
• 2.その下にコードを書く
• 3.整形する

• 説明とコードを可逆に
  • あまり大きなリファクタリングはしない
    • 読む側の少し上をいくのはいいが、あまり複雑すぎると...(実装パターン)
  • 例：本体の無いif文

• 短いコードを書く
  • APIを全部読む。(書籍 P.172)
    • 開発コアメンバが語るRubyの今とこれから（後編） − ＠IT
  • 以下は、Ruby1.9系統リリースマネージャ Rubyコミッタのyuguiさんのコメント。

Javaを覚えるとき「プログラミング言語Java」を読んで、それからリファレンスマニュアルを頭から全部読みました。

• • 不要な要求を削除する(P.168)

Do or DO NOT . There is no TRY
やるかやらぬかじゃ。試しなどいらん。

• 余談：試しにやってみる

『試しにやってみる』は前向きな感じがする。でも、それで何か『できた』のであれば、それまで力を温存していた事になる。

Clean Coder プロフェッショナルプログラマへの道

• あれ？だんだんコードの話から離れてきた
  • 名著を読もう！(P.218 あわせて読みたい)

色々な書籍や格言に言及されており、それだけで聞いててとても楽しくなる講演内容でした。

そしてそのまま、休憩無しでディスカッションのコーナーへ。

ディスカッション：「ぼくのかんがえたさいきょうのリーダブルコード」

• コード解説&質疑応答：須藤 功平氏

1. サンプルコードに対し参加者同士でどうすればリーダブルコードとなるか、ディスカッションを行います。
2. 須藤功平氏によるコード解説&質疑応答
※このラウンドを3回繰り返します

このディスカッションでは、

• 1.みんなでコードについて話し合う
• 2.須藤先生のぼくならこう書く
• 3.質疑応答

というサイクルを計3回実施しました。

コンセプトはこういう感じで。

このディスカッションに先立ち、告知ページ経由で『githubアカウントのソースコードをレビューする際の題材にさせて欲しい』というやり取りが運営側と参加者側であり、結果選ばれたのは以下の4つのアカウント。

• 0.dproject21/yaruo_tdd_triangle
• 1.mataki/fast_spork_runner
• 2.randym/axlsx
• 3.todesking/okura

そして、アカウントを4つ選んだ理由としては以下のような基準だったそうです。

• ここ1ヶ月くらいにコミットがあること。
• イニシャルコミットだけじゃないこと。
• Forkじゃなくて自分のプロジェクトであること。
• リリースされたプロジェクトであること。
• 今回のレビューの観点からWebアプリ系フレームワークとかは外している。(フレームワークのコード内容を見たい訳では無いので)

偶然なのか、選ばれたソースコードは全て『Ruby』。自分も事前にメールで通知された際には『あれ〜？』と不思議に思ったのですが、これについては

との須藤さんからの厳しいお言葉。反省ですね…(U_U;)w

進行については0.の題材で角さん＆須藤さんが『演劇』でやってみせる(そしてそれを生暖かく見守る)→以降1〜3について[参加者同士がディスカッション、質疑応答]×3セットという流れ。以下はその際のメモです。

0.yaruo_tdd_triangle / triangle.rb

• yaruo_tdd_triangle/triangle.rb at master · dproject21/yaruo_tdd_triangle · GitHub

• コードが詰まってますね〜(※メソッド間に空白が無い)。コード間が空いてないと読みにくい。(須藤さん)→スペースを入れた
• ホワイトスペースが空いてないのが気になります。(※同じような表記で == 周りのスペースが空いてるとこと空いてないとこが混在していた)→同じ体裁になるように調整
• rubyだとisとか使いたくないよね〜→置き換える。
• いいところも褒めよう！(須藤さん)
• スペースが入ってないのが気になる。一貫性を求める。
  • 同じような事をする場合は同じように書く。
• 一貫性の観点で見ると
  • 最後だけキャメルケースになってるのが気になる。
  • Returnを1箇所だけ使ってるのが気になる。
  • Unlessを使ってるのは必要の無いコードである
• コードの意味を把握する前に、見た目の整備をしておきたい。

• 読みやすいコード：という観点であれば、フォーマットとかは些細な問題では？(※ここまでの指摘事項に対し)
• 対して須藤さん
  • いや、大事なことですよ！
  • 一見本質じゃない所をちゃんとする→本質に集中する事が出来る、というのが私の考え。
  • でも『コードの意図はどこだろう？』と考えるのも大事です。
• まぁ、(小芝居の流れとして)段階的な部分もあったので.. (角さん)

1.mataki / fast_spork_runner

• fast_spork_runner/bin/spork_runner at master · mataki/fast_spork_runner · GitHub

ここからはチーム(テーブル)間でディスカッション開始。チーム間で出たのはこの辺のポイントでした。指摘と言うよりも『へぇ、Rubyってこう書くんだ〜』というポイントへの言及が多かったような気がします。(4人中3人Java、残る1人がRubyという状況だったので。というか、そのRubyの方がソースコード提供者という偶然(笑)もあり、経緯とかコードのRuby解説的なお話を聞いた感じでした。)

• 空行
• 変数は外出しにすべき(localhost)
• Begin – rescue – endの使い方について
• returnが重なっている箇所
• if else との違い
• コメントあるの？
• <<の使い方

角さん、須藤さんのやり取りはこんな感じでした。

• 全体として一貫性とれているかをみます。
• メソッド間に改行を入れる。
• 『to_argument』：ピンと来ない？
  • line.to_argumentとかに変えれば
  • line/line、同じ意味合い？
    • 何なんですかね〜(しばし黙考の後)私も悩みますよ？(須藤さん)
    • "1行"はrspecでなんて言うんだろう…

• returnの重複箇所、気になる。
  • どっちでもchompを読んでいる。
  • まずchompして、正規表現で判定。
    • XXXしてるんだろうな〜とエスパー力を発揮しないといけない。

• Config << file, STDERR, STROUT
  • この箇所、字面からだと想像がしづらい。

• 『モヤモヤしまくりですよ。』
  • 『都度、メモったりしないんですか？』(角さん)
  • 『メモらないですねぇ〜』(須藤さん)
    • 一旦見て、次見てもやっとしなければ大丈夫
    • あ、でもホントにやばいのはTODOコメントとか書きますよ。

• ソースコード全体を見ればわかるんだけど、一部分だけを見てもわかるように書いてあった方がいい。(須藤さん)
• result って何を意味している？
• configってよりもoptions何じゃないのか？（メソッド名について言及）
• localhostの値は統一？

• 冒頭のコメントは意図があるのか？(角谷さん)
  • 『いいとこに気が付きましたね〜ミムラくん』(須藤さん)
• IRBサーバ起動に関する"気持ちの流れ"が書いてある。全部読んでからでないと把握しづらい？(角谷さん)
  • 『さすがミムラ君』(須藤さん)

(注：このくだり、2回程繰り返されていたようですが、個人的には謎でした。 何が元ネタだったんだろう？w)

• 『角さんがサインしまくりたいそうなので、たまたま書籍を持っている人は是非サインを貰って下さい。』(須藤さん)

と言うわけでこのディスカッション後の休憩時間を利用して、サインを頂いてきました〜♪ありがとうございました！

また、当日イベントにはRails Contributorになった事で一躍脚光を浴びた@suginoyさんも来ておられました。『動画観ました！』とちゃんと伝えましたよ〜。

• @suginoyさんがRails Contributor になるまでのドキュメンタリーが作られる様子のまとめ - Togetter
• The GitHub poweredby Agile渋谷 に参加してきた #Agile渋谷 - Shinya’s Daily Report
• 参加のSOCIAL CODING // Speaker Deck

2.axlsx/lib/axlsx/workbook/worksheet/worksheet.rb

• axlsx/lib/axlsx/workbook/worksheet/worksheet.rb at master · randym/axlsx

※ブログエントリ用にソースコードを拝見してみたところ、既に修正が施されておりました！

• make to_xml_string more #readablecode · b937c69 · randym/axlsx
• make fit_to_page MOAR readable · 8df90fd · randym/axlsx

• 横とか縦に長いと、危険な匂いを感じます。(須藤さん)
  • もっと分割したほうがいいのでは。(縦に長い場合)
  • そこでやらなくてもいい事をしてるのでは。(横に長い場合)

• メソッド分割
  • 一文字変数 o → key, valueにした方が。
  • If文を設けることで理解をしやすくする

• エラーメッセージ
  • これがダメならこっち使いなよ！的なエラーメッセージは良い。
  • とてもいいです。皆さん真似しましょう。

    # Indicates if gridlines should be shown in the sheet.
    # This is true by default.
    # @return [Boolean]
    # @deprecated Use {SheetView#show_grid_lines=} instead.
    def show_gridlines=(v)
      warn('axlsx::DEPRECIATED: Worksheet#show_gridlines= has been depreciated. This value can be set over SheetView#show_grid_lines=.')
      Axlsx::validate_boolean v
      sheet_view.show_grid_lines = v
    end

• クラス、デカいよね。
• コメント多過ぎ？スリムになるかも。
• メソッドワンライナーで書いてるところが多い。Rubyだとこんなもんすかね？

• XML構造体を模したメソッド
  • 長いのは意図的なもの？XML構造を分かり易くするように敢えてそうしている？
    • メソッドは分けつつ、構造がわかるようにしておくかな。(須藤さん
  • "ノコギリ"と文字列処理パフォーマンスに関する言及あり。(※『Rubyでノコギリ』って最初キーワードとしては『何？』と思いましたが、これの事言ってるという認識で合ってますかね？)
    • Nokogiri
  • str ではなく xml とかにする。
  • xml_string ってstringじゃないの？
    • Domかもしれない。

と言うわけで、時間もこの辺りで終了時刻となっていたので、最後は角さん・須藤さん、スタッフの方々のご挨拶などを以てお開きという形に。
(時間の都合もあり、最後の3つめの課題は行いませんでした)

• リーダブルコード、ピンときましたか？
• 気をつけてコード書いていってください。
• コード書く事は楽しい。楽しく書いていた時期が皆さんにもあるはずです。
• そういう時期を得る事に、この本を使いましょう。
• 本は殴るためのものではありません。
• 本買ってください。保存用と読書用と普及用と。

角さん、須藤さん、会場をご提供頂いた株式会社インターネットイニシアティブ様、参加者及びスタッフの皆様、ありがとうございました！

(※これまた関係無いが、帰りの駅(神保町)で目にした映画『ダークナイト ライジング』の広告。)

その他関連：

• イベント前の関連エントリ
  • 「リーダブルコード」が良書すぎて胃が痛い - As a Futurist...
  • 書評: リーダブルコード - 刺身☆ブーメランのブログ / @kyanny's blog
  • 2012年上半期限定 プログラマだったら読んでおきたい書籍11選 | Act as Professional - hiroki.jp by HIROCASTER
  • リーダブルコードに共感出来ない人とは一緒にコーディングしたくない - ぼっち勉強会

• Togetter
  • 2012/07/06 リーダブルコード − 忘れてもいいコードを書こう。#devlove - Togetter