More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to 20120706-readablecode
Similar to 20120706-readablecode (20)
More from Masanori Kado
More from Masanori Kado (20)
Recently uploaded
Recently uploaded (14)
20120706-readablecode
- 1. リーダブル リーダブルコード 2012年7⽉6⽇ ⾓征典 kdmsnr@gmail.com 1/58
- 2. 御礼 2012年7⽉5⽇10:47KOUKeikokeiko@oreilly.co.jpWrote: ２週間⾜らずで４刷というのはすごい スピードです。 2/58
- 3. Ebook版は秋ごろ予定 3/58
- 4. お詫び 4/58
- 5. ⾃⼰紹介 @kdmsnr 5/58
- 6. ⾃⼰紹介訳書(1/2) Martin Fowler's Bliki (2003) ↓ 『アジャイルレトロスペクティブズ』 (2007) ↓ スクラムガイド (2010) ↓ 『メタプログラミングRuby』 (2010) ↓ 『ウェブオペレーション』 (2011) ↓ 『Facebookマーケティング』 (2011) ↓ 6/58
- 7. ⾃⼰紹介訳書(2/2) ↓ 『Clean Coder』 (2012) ↓ 『リーダブルコード』 (2012) ←【イマココ】 ↓ 『Service Design Patterns』 (2012) ↓ 『Seven Databases in Seven Weeks』 (2012) ↓ 『Running Lean』 (2012) ↓ 『...』(2012?) 7/58
- 8. TheArtof ReadableCode 8/58
- 9. 『リーダブルコード』 これはもう「翻訳放棄」と⾔ってもよ いレベルですねぇ。⾮道過ぎます。 http://twitter.com/ytaniike/status/211060068035207170 違うよ。全然違うよ。 9/58
- 10. リーダブルコードの理由 タイトルは、あえて『 リーダブルコー ド』にした。これは「リーダブルコード 」 という聞きなれない⾔葉にすることで、読 んだ⼈に「リーダブルコード 」というもの について注意して欲しいからだ。 http://www.clear-code.com/blog/2012/6/11.html 10/58
- 11. 続リーダブルコードの理由 「リファクタリング 」という⾔葉を使 っていて、「コードをよくすること」がよ り当たり前になっている。それと同じよ うに、読みやすいコードを⾒たら「リーダ ブルでいいね！」ということが⾃然に⾔わ れるようになるといい。 http://www.clear-code.com/blog/2012/6/11.html 11/58
- 12. 名前重要 リーダブルコードは本のタイトルで勝 ちだよなぁ。（中略）どんなコード⽬指し てるかすぐわかるし。 http://twitter.com/chiastolite/status/219793852087808003 誰だか知らないけどありがとう！！！！ 12/58
- 13. じゃあ、どんなコード？ リーダブルコードの基本定理 コードは他の⼈が最短時間で理解でき るように書かなければいけない。(p.3) 13/58
- 14. ハァ？なんで？ 「コードのよさは重要だ」は危うい前提 読むに耐えないコードが⼤⾦を稼いで いる場⾯を散々⽬にしてきたので、商業的 に成功したり、広く活⽤されたりするう えで、コードの品質が必要だとも、それさ えあれば⼗分だとも思えないからだ。 『実装パターン』KentBeck 14/58
- 15. でもやるんだよ！ ……誇りの持てない仕事で無駄にする 時聞はない。よいコードを書くこと⾃体が 喜びであり、そのコードを他の⼈が理解し 、評価し、使⽤し、拡張してくれれば、さ らに喜びは増す。 『実装パターン』KentBeck 15/58
- 16. 2章名前に情報を詰め込む 16/58
- 17. 名前をつけるのは難しい 簡単に誤解・誤読されちゃう！ 変数の名前を決定する際には、最初の ⼦供の名前を決めるときと同じくらいの配 慮が必要なのです（JimCope） 『CleanCode』RobertC.Martin 17/58
- 19. 最も基本的なこと 式は⾃分で⾳読するつもりで書こう。 『プログラミング作法』BrianKernighan,RobPike 発⾳可能な名前を使⽤する。 『CleanCode』RobertC.Martin 19/58
- 20. 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
- 21. ［ネタ］詠太2で⾳読する http://www.justsystems.com/jp/products/ichitaro/feature6.html ※Windowsじゃないと動きません。 21/58
- 22. 読み⼿のことを考える 相⼿を意識したときに、よい⽂章が⽣ まれるように、よいプログラムも読み⼿を 意識したときに⽣まれる。 『実装パターン』KentBeck 22/58
- 23. とは⾔っても、難しいよ 23/58
- 24. 5章コメントすべきこと 24/58
- 25. 必要なことはコードに書く 私はだらしのないプログラマなので、 ⾃分が担当したコードが、どのように書か れていたのかまったく覚えていません 。… …私は常に、覚えておくべき情報をコード 内に書き込んでおくことにしているので、 わざわざ覚える必要がないのです。 『リファクタリング』MartinFowler 25/58
- 26. コードがドキュメントだ ※写真はイメージです。 26/58
- 28. 監督コメンタリー p.60 映画DVDの特典のように 説明・思い・裏話をコメントに書く うまくいかなかったことも書く 疑問を先回りして埋めておく 28/58
- 32. こじつけでも、つじつまが 合えばそれにこしたことは ない！！ 32/58
- 33. 思考の断⽚を刻む場所 （コードではないかもだけど……） コミットの情報 須藤先⽣の「解説」も参考に チケット駆動開発（Ref,Fix,Close） ドキュメント ReVIEW（ステマ） http://github.com/kmuto/review Sphinx 33/58
- 34. たいせつなTODO.md 多くのデベロッパは、この種の観察作 業のために簡単なtodoリストを作って いる。 『テスト駆動JavaScript』ChristianJohansen 34/58
- 35. TODO.mdの例 # 商品関連 * 在庫のトランザクション。楽観的ロックでいいの？ # 管理画⾯ * Admin::ApplicationControllerにBasic認証 * Twitter Bootstrap使うかもしれない * ■ Deviseのカスタマイズ → できたけど微妙 # 画像リサイズ * ■ RMagicでやる → できた！ 35/58
- 36. ドキュメント読まれないし それでも「ポステルの法則」を参考に 受信するものには寛容に、送信するも のには慎重に http://ja.wikipedia.org/wiki/ジョン・ポステル 36/58
- 37. 12章コードに 思いを込める 37/58
- 38. アインシュタインの⾔葉 p.158 おばあちゃんがわかるように説明でき なければ、本当に理解したとは⾔えない。 38/58
- 39. テディベアやアヒルちゃん に説明してみる（p.165） 『プログラミング作法』や『達⼈プログラマ』にも記述がある 39/58
- 40. 説明内容をコメントに書く （すごく⼿続き的だけど） # originalディレクトリのhtmlファイルから # code.literalの要素を削除する # （ってか、Nokogiriの使い⽅わからねえ） # それから、ファイルをテキスト形式に置き換えて # ワード数を数える 40/58
- 41. その下にコードを書く # 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.size end 41/58
- 42. 整形する 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_count end 42/58
- 43. 説明とコードを可逆に あまり⼤きなリファクタリングはしない 読む側の少し上を⾏くのはよいが、あ まり複雑すぎると、相⼿にされなくなって しまう。 『実装パターン』KentBeck 43/58
- 44. 例：本体のないif⽂ p.159 // 権限があるのは、以下の2つ // 1) 管理者 // 2) ⽂書の所有者（⽂書がある場合） // その他は、権限がない。 44/58
- 45. 例：本体のないif⽂ p.159 // 権限を確認する if (is_admin_request()) { // 1) 管理者は権限あり } else if (...) { // 2) ⽂書の所有者は権限あり（⽂書がある場合） } else { // その他は、権限がない。 return not_authorized(); } 45/58
- 47. 例えば、どういうふうに？ 47/58
- 48. 13章短いコードを書く 48/58
- 49. APIをぜんぶ読む p.172 yugui:Javaを覚えるとき『プログラミ ング⾔語Java』を読んで、それからリファ レンスマニュアルを頭から全部読みまし た。 http://www.atmarkit.co.jp/news/200907/24/ruby2.html 49/58
- 50. 不要な要求を削除する p.168 DOorDONOT.ThereisnoTRY. やるか、やらぬかじゃ。試しなどいらん。 ヨーダの⾔葉（『CleanCoder』RobertC.Martin） 50/58
- 51. ［余談］試しにやってみる 「試しにやってみる」は前向きな感じ がする。でも、それで何か「できた」ので あれば、それまで⼒を温存していたことに なる。 『CleanCoder』RobertC.Martin 51/58
- 52. あれ？ だんだん コードの話から 離れてきた 52/58
- 53. 名著を読もう！ p.218 53/58
- 54. リーダブルコード もよろしくお願いします。 54/58
- 55. ぼくのかんがえた さいきょうの リーダブルコード 55/58
- 56. やり⽅ 1. みんなでコードについて話し合う 2. 須藤先⽣の「ぼくならこう書く」 3. 質疑応答 ※これを３ラウンド繰り返します。 56/58
- 57. お題 0. github.com/dproject21/yaruo_tdd_triangle 1. github.com/mataki/fast_spork_runner 2. github.com/randym/axlsx 3. github.com/todesking/okura ※「0」のお題でやり⽅を説明します。 57/58
- 58. ENJOY!! 58/58