20120706-readablecode

リーダブルリーダブルコード 2012年7⽉6⽇⾓征典 kdmsnr@gmail.com 1/58

御礼2012年7⽉5⽇10:47KOUKeiko<keiko@oreilly.co.jp>Wrote: ２週間⾜らずで４刷というのはすごいスピードです。 2/58

Ebook版は秋ごろ予定 3/58

お詫び 4/58

⾃⼰紹介 @kdmsnr 5/58

⾃⼰紹介訳書(1/2)Martin Fowlers Bliki (2003) ↓『アジャイルレトロスペクティブズ』 (2007) ↓スクラムガイド (2010) ↓『メタプログラミングRuby』 (2010) ↓『ウェブオペレーション』 (2011) ↓『Facebookマーケティング』 (2011) ↓ 6/58

⾃⼰紹介訳書(2/2) ↓『Clean Coder』 (2012) ↓『リーダブルコード』 (2012) ←【イマココ】 ↓『Service Design Patterns』 (2012) ↓『Seven Databases in Seven Weeks』 (2012) ↓『Running Lean』 (2012) ↓『...』(2012?) 7/58

TheArtofReadableCode 8/58

『リーダブルコード』これはもう「翻訳放棄」と⾔ってもよいレベルですねぇ。⾮道過ぎます。http://twitter.com/ytaniike/status/211060068035207170 違うよ。全然違うよ。 9/58

リーダブルコードの理由タイトルは、あえて『リーダブルコード』にした。これは「リーダブルコード」という聞きなれない⾔葉にすることで、読んだ⼈に「リーダブルコード」というものについて注意して欲しいからだ。http://www.clear-code.com/blog/2012/6/11.html 10/58

続リーダブルコードの理由「リファクタリング」という⾔葉を使っていて、「コードをよくすること」がより当たり前になっている。それと同じように、読みやすいコードを⾒たら「リーダブルでいいね！」ということが⾃然に⾔われるようになるといい。 http://www.clear-code.com/blog/2012/6/11.html 11/58

名前重要リーダブルコードは本のタイトルで勝ちだよなぁ。（中略）どんなコード⽬指してるかすぐわかるし。http://twitter.com/chiastolite/status/219793852087808003 誰だか知らないけどありがとう！！！！ 12/58

じゃあ、どんなコード？リーダブルコードの基本定理コードは他の⼈が最短時間で理解できるように書かなければいけない。(p.3) 13/58

ハァ？なんで？「コードのよさは重要だ」は危うい前提読むに耐えないコードが⼤⾦を稼いでいる場⾯を散々⽬にしてきたので、商業的に成功したり、広く活⽤されたりするうえで、コードの品質が必要だとも、それさえあれば⼗分だとも思えないからだ。『実装パターン』KentBeck 14/58

でもやるんだよ！ ……誇りの持てない仕事で無駄にする時聞はない。よいコードを書くこと⾃体が喜びであり、そのコードを他の⼈が理解し、評価し、使⽤し、拡張してくれれば、さらに喜びは増す。『実装パターン』KentBeck 15/58

2章名前に情報を詰め込む 16/58

名前をつけるのは難しい簡単に誤解・誤読されちゃう！変数の名前を決定する際には、最初の⼦供の名前を決めるときと同じくらいの配慮が必要なのです（JimCope）『CleanCode』RobertC.Martin 17/58

本章のアドバイス明確で具体的な単語を選ぶ汎⽤的な名前は避ける単位や情報を名前に追加するスコープの⼤きさを考慮するフォーマット規約を使う 18/58

最も基本的なこと式は⾃分で⾳読するつもりで書こう。『プログラミング作法』BrianKernighan,RobPike 発⾳可能な名前を使⽤する。『CleanCode』RobertC.Martin 19/58

retval（何て読むの？）汎⽤的な名前を避ける（p.12）var eulidean_norm = function(v) { var retval = 0.0; for (var i = 0; i < v.length; i += 1) { retval += v[i] * v[i]; } return Math.sqrt(retval);} 20/58

［ネタ］詠太2で⾳読するhttp://www.justsystems.com/jp/products/ichitaro/feature6.html ※Windowsじゃないと動きません。 21/58

読み⼿のことを考える相⼿を意識したときに、よい⽂章が⽣まれるように、よいプログラムも読み⼿を意識したときに⽣まれる。『実装パターン』KentBeck 22/58

とは⾔っても、難しいよ 23/58

5章コメントすべきこと 24/58

必要なことはコードに書く私はだらしのないプログラマなので、⾃分が担当したコードが、どのように書かれていたのかまったく覚えていません。……私は常に、覚えておくべき情報をコード内に書き込んでおくことにしているので、わざわざ覚える必要がないのです。『リファクタリング』MartinFowler 25/58

コードがドキュメントだ ※写真はイメージです。 26/58

でも、ないものは⾒えないコミットする前のコード使わなかった選択肢却下された要望や提案これからやること 27/58

監督コメンタリー p.60映画DVDの特典のように説明・思い・裏話をコメントに書くうまくいかなかったことも書く疑問を先回りして埋めておく 28/58

理由重要⼈に何かを頼み事をするときには理由を添えた⽅が成功しやすくなる『影響⼒の武器[第⼆版]―なぜ、⼈は動かされるのか』 29/58

理由は何でもいいらしい◯すみません……急いでいるので、先にコピーをとらせてくれませんか？×すみません……先にコピーをとらせてくれませんか？『影響⼒の武器[第⼆版]―なぜ、⼈は動かされるのか』 30/58

「なんとなく」が⼀番困る「どうしてこうなってるんですか？」「なにがですか」「ここのコードが」「ああ、なんとなくですよ」「えっ」「えっ」「……」「……」 31/58

こじつけでも、つじつまが合えばそれにこしたことはない！！ 32/58

思考の断⽚を刻む場所（コードではないかもだけど……）コミットの情報須藤先⽣の「解説」も参考にチケット駆動開発（Ref,Fix,Close）ドキュメント ReVIEW（ステマ） http://github.com/kmuto/review Sphinx 33/58

たいせつなTODO.md 多くのデベロッパは、この種の観察作業のために簡単なtodoリストを作っている。『テスト駆動JavaScript』ChristianJohansen 34/58

TODO.mdの例# 商品関連* 在庫のトランザクション。楽観的ロックでいいの？# 管理画⾯* Admin::ApplicationControllerにBasic認証* Twitter Bootstrap使うかもしれない* ■ Deviseのカスタマイズ → できたけど微妙# 画像リサイズ* ■ RMagicでやる → できた！ 35/58

ドキュメント読まれないしそれでも「ポステルの法則」を参考に受信するものには寛容に、送信するものには慎重に http://ja.wikipedia.org/wiki/ジョン・ポステル 36/58

12章コードに思いを込める 37/58

アインシュタインの⾔葉 p.158 おばあちゃんがわかるように説明できなければ、本当に理解したとは⾔えない。 38/58

テディベアやアヒルちゃんに説明してみる（p.165）『プログラミング作法』や『達⼈プログラマ』にも記述がある 39/58

説明内容をコメントに書く（すごく⼿続き的だけど）# originalディレクトリのhtmlファイルから# code.literalの要素を削除する# （ってか、Nokogiriの使い⽅わからねえ）# それから、ファイルをテキスト形式に置き換えて# ワード数を数える 40/58

その下にコードを書く# originalディレクトリのhtmlファイルからDir.glob("original/*.html").each do |html| doc = Nokogiri.HTML open(html) # code.literalの要素を削除する # （ってか、Nokogiriの使い⽅わからねえ）→できた doc.search("//code[@class=literal]").remove # それから、ファイルをテキスト形式に置き換えて text = doc.css("body").text # ワード数を数える wc = text.split.sizeend 41/58

整形するdef count_word_in_html_files word_count = 0 Dir.glob("original/*.html").each do |html| doc = Nokogiri.HTML open(html) doc.search("//code[@class=literal]").remo text = doc.css("body").text word_count = text.split.size end return word_countend 42/58

説明とコードを可逆にあまり⼤きなリファクタリングはしない読む側の少し上を⾏くのはよいが、あまり複雑すぎると、相⼿にされなくなってしまう。『実装パターン』KentBeck 43/58

例：本体のないif⽂ p.159// 権限があるのは、以下の2つ// 1) 管理者// 2) ⽂書の所有者（⽂書がある場合）// その他は、権限がない。 44/58

例：本体のないif⽂ p.159// 権限を確認するif (is_admin_request()) { // 1) 管理者は権限あり} else if (...) { // 2) ⽂書の所有者は権限あり（⽂書がある場合）} else { // その他は、権限がない。 return not_authorized();} 45/58

⾃分の思いを込める前にその分野ですでにどんなことが解明されているかを調べてみなければならない。さもないと、優れた⼿法がすでに存在するのに、⾃⼰流の下⼿なやり⽅を考案するのに時間を無駄にするはめになるからだ。『プログラミング作法』BrianKernighan,RobPike 46/58

例えば、どういうふうに？ 47/58

13章短いコードを書く 48/58

APIをぜんぶ読む p.172 yugui:Javaを覚えるとき『プログラミング⾔語Java』を読んで、それからリファレンスマニュアルを頭から全部読みました。http://www.atmarkit.co.jp/news/200907/24/ruby2.html 49/58

不要な要求を削除する p.168 DOorDONOT.ThereisnoTRY.やるか、やらぬかじゃ。試しなどいらん。ヨーダの⾔葉（『CleanCoder』RobertC.Martin） 50/58

［余談］試しにやってみる「試しにやってみる」は前向きな感じがする。でも、それで何か「できた」のであれば、それまで⼒を温存していたことになる。『CleanCoder』RobertC.Martin 51/58

あれ？だんだんコードの話から離れてきた 52/58

名著を読もう！ p.218 53/58

リーダブルコードもよろしくお願いします。 54/58

ぼくのかんがえたさいきょうのリーダブルコード 55/58

やり⽅1. みんなでコードについて話し合う2. 須藤先⽣の「ぼくならこう書く」3. 質疑応答 ※これを３ラウンド繰り返します。 56/58

お題0. github.com/dproject21/yaruo_tdd_triangle1. github.com/mataki/fast_spork_runner2. github.com/randym/axlsx3. github.com/todesking/okura ※「0」のお題でやり⽅を説明します。 57/58

ENJOY!! 58/58

http://d.hatena.ne.jp	1536
http://capsctrl.que.jp	532
http://studiosamente.wordpress.com	101
http://br.0r2.info	97
https://si0.twimg.com	19
https://twitter.com	8
https://twimg0-a.akamaihd.net	6
http://www.freerss.net	4
http://webcache.googleusercontent.com	4
http://pinterest.com	1

20120706-readablecode

by Masanori Kado on Jul 06, 2012

Accessibility

Categories

Upload Details

Usage Rights

10 Embeds 2,308

Statistics

20120706-readablecode Presentation Transcript