CodeIQベストコード発表会
最もエレガントにカラオケマシン問題を解いたのは誰だ?
株式会社ソニックガーデン
伊藤 淳一
SonicGarden Study #10
好評発売中!
倉貫義人著「納品」をなくせばうまくいく
自己紹介
About me
伊藤 淳一
Twitter: @jnchito
Blog: give IT a try
Lives in 西脇市
西脇市???
僕は今ココにいます。
神戸の北西約50km
Wikipedia
リモートで働いてます
窓の外はこんな感じ
翻訳しました!
みなさんは今どこで
観ていますか?
#sg_study を付けてツイート!
SonicGarden Study?
• SonicGardenが主催するIT勉強会
• USTで役立つ技術情報をライブ配信
• 世界中どこからでも参加可能!
• 質問はTwitterから => #sg_study
本日のMenu
本日のMenu
• カラオケマシン問題 優秀賞の発表
• 模範解答の発表
• カラオケマシン問題の総評
• 良いコードとコードレビューの関係
• プレゼント本当選者発表
• Q&A
カラオケマシン問題
優秀賞の発表
そのまえに・・・
カラオケマシン問題?
https://flic.kr/p/6x9dpV
問題の説明
• メロディ(文字列)のキーを変える問題
• ドレミ を +2 すると レミファ#
• 音階はアルファベットで表現
ドレミファソラシド = CDEFGABC
ミ + 2 =ファ# ??
お題: かえるのうた
“C D E F |E D C |E F G A |…”
↓ +2
“D E F# G |F# E D |F# G A B |…”
• 空白 = 休符
• 縦棒(|) = 小節の区切り
要求仕様あれこれ
• キーを上げたり
• キーを下げたり
• オクターブ(12音)を超えたり
• 元のメロディがC以外の音で始まったり
“F# G# A# B |A# G# F# …”
予めRSpec書きました
解答提出の条件
• 解答テンプレートを使って提出
• クラス名やメソッド名を統一
• 全17パターンのテストをパスさせる
• 解答テンプレートはこちら
https://gist.github.com/JunichiIto/c548e39fed6...
優秀賞について
• 挑戦者は全部で50名
• その中から優秀なコードを3本選出
• 3本の中で順位や優劣は付けない
• 自分で解いてから見るのがオススメ
というわけで
優秀賞の発表です!
優秀賞・その1
Muさん
About Muさん
• Ruby歴 1年
• フリープログラマ
• 持ち帰り案件&スカウト募集中!
• こだわった点: 短く簡潔に
• 簡潔さ重視でハッシュの採用は見送り
優秀賞・その2
ttakuru88さん
About ttakuru88さん
• Ruby歴 4年
• kray.jpのRailsプログラマ
• 吹奏楽を7年やっていた
• 音楽系プログラムに馴染みがあった
優秀賞・その3
hitokunさん
About hitokunさん
• Ruby歴 なし
• web&アプリのバックエンド開発メイン
• 変換テーブルを作って処理を効率化
• gsubで置換する方が速い(はず)
• ググりながら1時間ぐらいで解答
優秀賞のみなさん
おめでとうございます!
つづいて
(最強の?)模範解答
出題者が解くと
こうなります。
じゃじゃん!
模範解答のポイント
• 定数的な値は定数として定義する
• 標準APIを活用し変換用ハッシュを作成
• 標準API = rotate, transpose, to_h
• 正規表現を使って音符のみを抽出
• gsubにハッシュを渡してコード量削減
もう一度おさらい
解答の総評
総評・はじめに
• 予想以上の反響で2回増枠!
• さらに50人全員がテストを全パス!
• 挑戦者のみなさん、ありがとう!!
簡単なメトリクス
コード行数の分布
空白行、コメント行、

テストコードは除く
採点しながら感じた
良いコードの境界線
良いコードの境界線
• 正規表現の活用
• Array, Hash, String等の標準APIの活用
• 定数やインスタンス変数の使い分け
• for/while/break/next等を避ける
• YAGNIなシンプル設計
勉強になりそうな
参考資料
正規表現を学ぶ
• オライリー「詳説 正規表現 第3版」
標準APIを学ぶ
• ruby-doc.orgを繰り返し読む
Rubyらしさを学ぶ
• Qiita: リファクタリングに使えそうな∼
また挑戦してね!
ところで
良いコードって
どんなコード?
ぱっと思いつく
特性を挙げてみる
良いコードは…
• 短くて簡潔
• 重複がない (DRY)
• 壊れにくい
• わかりやすい
• 改修しやすい
• 再利用しやすい
悪いコードは…
• 長くて冗長
• コピペコピペコピペ・・・
• もろくて壊れやすい
• 何をやってるのか全く理解できない
• 改修しにくい
• 再利用できない
良いコードの長所
• 開発効率が上がる
• すぐに作れる、改造できる
• バグも原因がすぐわかる、すぐ直せる
• ストレスがなくなる
• むしろ作っていて気持ちいい
悪いコードの短所
• 開発効率が下がる
• 全然作れない、改造もできない
• バグの原因を特定するだけで骨が折れる
• ストレスが溜まる
• Twitterに愚痴が増える
じゃあどうしたら
良いコードが書ける?
個人として
• いろんな現場を経験する
• コードの良し悪しによる天国と地獄
• 技術書を読んで勉強する
• コードに対する飽くなき向上心を持つ
• リファクタリングの鬼になる
オススメの技術書
チームや組織として
• 日常的にコードレビューをする
• 他人のコードをレビューする
• 自分のコードをレビューしてもらう
• コードレビューはお互い勉強になる
• 「良いコード」の共通認識を持つ
• 「良いコードとは?」を議論する
具体例で見る
コードレビューの効果
とあるRuby初心者さん
のコード
レビュー前
レビュー前(1/6)
レビュー前(2/6)
レビュー前(3/6)
レビュー前(4/6)
レビュー前(5/6)
レビュー前(6/6)
コードレビューした
リファクタリング後
修正内容について
さらにコードレビュー
再リファクタリング
Before / After
レビュー前後の行数
良いコードを書くために
• 自分でコードを書く
• 他の人が書いたコードを読む
• 書いたコードを読んでもらう
• 1人で書いてハイ終わり、じゃダメ!!
だからコードを書こう
コードを読もう
コードを読んでもらおう
たとえば
CodeIQに挑戦!
勉強会に参加!
教育プログラムを履修!
• ソニックガーデンでは企業向け

教育プログラムを準備中です。
• コードレビューできる人材を育成します。
• 詳細についてはお問い合わせください。
本日のまとめ
本日のまとめ
• 同じ問題でも解き方は人によって千差万別
• 良いコードを書くためには
• 個人で勉強する
• チームや組織でコードレビューする
• コードを書く、読む、読んでもらう
• Webサービス、勉強会、教育プログラム
プレゼント本の
当選者発表
サイン入り本を贈呈!
• 挑戦者の中から抽選で3名様に

『「納品」をなくせばうまくいく』を贈呈
• 著者・倉貫義人のサイン入り!
Rubyで抽選しました
当選者一覧
• m_utaさん
• たがみつさん
• みけCATさん
• さらに、優秀賞を獲得した

Muさん、ttakuru88さん、hitokunさん

にもプレゼントいたします!
当選おめでとうございます!
&
挑戦ありがとうございました!
Q&A
#sg_study で受付中!
アンケートから・その1
• 設計/仕様レベルのレビューは難しい
• 些細な点の指摘に終始してしまう
Answer
• 設計レビューはみんなでじっくり
• リリース前は致命的な問題にフォーカス
• 仕様を把握するレビューは主に前者
アンケートから・その2
• レビューするコード量や大きさは?
Answer
• 1stリリース前のレビューはコード全体
• 以後のリリースはpull request単位
アンケートから・その3
• ネガティブにならないように気を遣う
• 顔文字で工夫したりするが、なかなか
Answer
• 良いコードに対する共通認識を確認する
• ネットのコーディング規則を活用する
• 「自分のことは棚に上げる」ルールにする
アンケートから・その4
• 一人開発なのでレビューの機会がない
• 自分のコードに自信が持てない
Answer
• 勉強会に参加する(もしくは開催する)
• 教育プログラムに参加する
• オープンソースプロジェクトに参加する
アンケートから・その5
• 人によって考え方が違う
• 例) Rubyでreturnを書くかどうか、等
Answer
• 良いコードに対する共通認識を確認する
• ネットのコーディング規則を活用する
• とりあえずreturnは書かない方が主流
アンケートから・その6
• コピペや非構造化コードの指摘に困る
• 角を立てずに指摘するには?
Answer
• 良いコードに対する共通認識を確認する
• ネットのコーディング規則を活用する
アンケートから・その7
• コードレビューの文化はどう作るのか?
Answer
• まずpull request方式を導入してみては?
アンケートから・その8
• 好みと指摘の境界線が気になる
• 社内ルール化するのも自由がなくなる
Answer
• 良いコードに対する共通認識を確認する
• ネットのコーディング規則を活用する
• Hound CI等のツールを導入する
Q&A
#sg_study で受付中!
次回予告
8月のSonicGarden
Studyは
いつまでクソコードを
書き続けるの?
デキるプログラマだけが知っている
コードレビュー7つの秘訣
概要
• 優れたプログラマになるための近道

= 優れたプログラマによる指摘!!
• レビューを上手に実践する秘訣を紹介
• 講師: 西見公宏(@mah_lab)
• 放送予定日: 8/11(月)
最後に
みなさんにお願い
アンケートにご協力を
• 放送終了後、簡単なアンケートを

メールでお願いしています。
• 今後のSonic Garden Studyを改善して

いくためにぜひご協力ください。
• よろしくお願いします!!
Thank you.
CodeIQベストコード発表会 #sg_study
CodeIQベストコード発表会 #sg_study
CodeIQベストコード発表会 #sg_study
Upcoming SlideShare
Loading in...5
×

CodeIQベストコード発表会 #sg_study

2,522

Published on

SonicGarden Study #10「CodeIQベストコード発表会 ~最もエレガントにカラオケマシン問題を解いたのは誰だ?~」の発表資料です。

放送内容のまとめ
http://blog.jnito.com/entry/2014/07/10/091216

告知ページ
http://sonicgarden.doorkeeper.jp/events/12901

カラオケマシン問題
http://blog.jnito.com/entry/2014/06/06/104420

解答テンプレート
https://gist.github.com/JunichiIto/c548e39fed60bf4bd36a

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,522
On Slideshare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
6
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

CodeIQベストコード発表会 #sg_study

  1. 1. CodeIQベストコード発表会 最もエレガントにカラオケマシン問題を解いたのは誰だ? 株式会社ソニックガーデン 伊藤 淳一 SonicGarden Study #10
  2. 2. 好評発売中! 倉貫義人著「納品」をなくせばうまくいく
  3. 3. 自己紹介
  4. 4. About me 伊藤 淳一 Twitter: @jnchito Blog: give IT a try Lives in 西脇市
  5. 5. 西脇市???
  6. 6. 僕は今ココにいます。
  7. 7. 神戸の北西約50km Wikipedia
  8. 8. リモートで働いてます
  9. 9. 窓の外はこんな感じ
  10. 10. 翻訳しました!
  11. 11. みなさんは今どこで 観ていますか? #sg_study を付けてツイート!
  12. 12. SonicGarden Study? • SonicGardenが主催するIT勉強会 • USTで役立つ技術情報をライブ配信 • 世界中どこからでも参加可能! • 質問はTwitterから => #sg_study
  13. 13. 本日のMenu
  14. 14. 本日のMenu • カラオケマシン問題 優秀賞の発表 • 模範解答の発表 • カラオケマシン問題の総評 • 良いコードとコードレビューの関係 • プレゼント本当選者発表 • Q&A
  15. 15. カラオケマシン問題 優秀賞の発表
  16. 16. そのまえに・・・
  17. 17. カラオケマシン問題? https://flic.kr/p/6x9dpV
  18. 18. 問題の説明 • メロディ(文字列)のキーを変える問題 • ドレミ を +2 すると レミファ# • 音階はアルファベットで表現 ドレミファソラシド = CDEFGABC
  19. 19. ミ + 2 =ファ# ??
  20. 20. お題: かえるのうた “C D E F |E D C |E F G A |…” ↓ +2 “D E F# G |F# E D |F# G A B |…” • 空白 = 休符 • 縦棒(|) = 小節の区切り
  21. 21. 要求仕様あれこれ • キーを上げたり • キーを下げたり • オクターブ(12音)を超えたり • 元のメロディがC以外の音で始まったり “F# G# A# B |A# G# F# …”
  22. 22. 予めRSpec書きました
  23. 23. 解答提出の条件 • 解答テンプレートを使って提出 • クラス名やメソッド名を統一 • 全17パターンのテストをパスさせる • 解答テンプレートはこちら https://gist.github.com/JunichiIto/c548e39fed60bf4bd36a
  24. 24. 優秀賞について • 挑戦者は全部で50名 • その中から優秀なコードを3本選出 • 3本の中で順位や優劣は付けない • 自分で解いてから見るのがオススメ
  25. 25. というわけで 優秀賞の発表です!
  26. 26. 優秀賞・その1
  27. 27. Muさん
  28. 28. About Muさん • Ruby歴 1年 • フリープログラマ • 持ち帰り案件&スカウト募集中! • こだわった点: 短く簡潔に • 簡潔さ重視でハッシュの採用は見送り
  29. 29. 優秀賞・その2
  30. 30. ttakuru88さん
  31. 31. About ttakuru88さん • Ruby歴 4年 • kray.jpのRailsプログラマ • 吹奏楽を7年やっていた • 音楽系プログラムに馴染みがあった
  32. 32. 優秀賞・その3
  33. 33. hitokunさん
  34. 34. About hitokunさん • Ruby歴 なし • web&アプリのバックエンド開発メイン • 変換テーブルを作って処理を効率化 • gsubで置換する方が速い(はず) • ググりながら1時間ぐらいで解答
  35. 35. 優秀賞のみなさん おめでとうございます!
  36. 36. つづいて (最強の?)模範解答
  37. 37. 出題者が解くと こうなります。
  38. 38. じゃじゃん!
  39. 39. 模範解答のポイント • 定数的な値は定数として定義する • 標準APIを活用し変換用ハッシュを作成 • 標準API = rotate, transpose, to_h • 正規表現を使って音符のみを抽出 • gsubにハッシュを渡してコード量削減
  40. 40. もう一度おさらい
  41. 41. 解答の総評
  42. 42. 総評・はじめに • 予想以上の反響で2回増枠! • さらに50人全員がテストを全パス! • 挑戦者のみなさん、ありがとう!!
  43. 43. 簡単なメトリクス
  44. 44. コード行数の分布 空白行、コメント行、
 テストコードは除く
  45. 45. 採点しながら感じた 良いコードの境界線
  46. 46. 良いコードの境界線 • 正規表現の活用 • Array, Hash, String等の標準APIの活用 • 定数やインスタンス変数の使い分け • for/while/break/next等を避ける • YAGNIなシンプル設計
  47. 47. 勉強になりそうな 参考資料
  48. 48. 正規表現を学ぶ • オライリー「詳説 正規表現 第3版」
  49. 49. 標準APIを学ぶ • ruby-doc.orgを繰り返し読む
  50. 50. Rubyらしさを学ぶ • Qiita: リファクタリングに使えそうな∼
  51. 51. また挑戦してね!
  52. 52. ところで
  53. 53. 良いコードって どんなコード?
  54. 54. ぱっと思いつく 特性を挙げてみる
  55. 55. 良いコードは… • 短くて簡潔 • 重複がない (DRY) • 壊れにくい • わかりやすい • 改修しやすい • 再利用しやすい
  56. 56. 悪いコードは… • 長くて冗長 • コピペコピペコピペ・・・ • もろくて壊れやすい • 何をやってるのか全く理解できない • 改修しにくい • 再利用できない
  57. 57. 良いコードの長所 • 開発効率が上がる • すぐに作れる、改造できる • バグも原因がすぐわかる、すぐ直せる • ストレスがなくなる • むしろ作っていて気持ちいい
  58. 58. 悪いコードの短所 • 開発効率が下がる • 全然作れない、改造もできない • バグの原因を特定するだけで骨が折れる • ストレスが溜まる • Twitterに愚痴が増える
  59. 59. じゃあどうしたら 良いコードが書ける?
  60. 60. 個人として • いろんな現場を経験する • コードの良し悪しによる天国と地獄 • 技術書を読んで勉強する • コードに対する飽くなき向上心を持つ • リファクタリングの鬼になる
  61. 61. オススメの技術書
  62. 62. チームや組織として • 日常的にコードレビューをする • 他人のコードをレビューする • 自分のコードをレビューしてもらう • コードレビューはお互い勉強になる • 「良いコード」の共通認識を持つ • 「良いコードとは?」を議論する
  63. 63. 具体例で見る コードレビューの効果
  64. 64. とあるRuby初心者さん のコード
  65. 65. レビュー前
  66. 66. レビュー前(1/6)
  67. 67. レビュー前(2/6)
  68. 68. レビュー前(3/6)
  69. 69. レビュー前(4/6)
  70. 70. レビュー前(5/6)
  71. 71. レビュー前(6/6)
  72. 72. コードレビューした
  73. 73. リファクタリング後
  74. 74. 修正内容について
  75. 75. さらにコードレビュー
  76. 76. 再リファクタリング
  77. 77. Before / After
  78. 78. レビュー前後の行数
  79. 79. 良いコードを書くために • 自分でコードを書く • 他の人が書いたコードを読む • 書いたコードを読んでもらう • 1人で書いてハイ終わり、じゃダメ!!
  80. 80. だからコードを書こう コードを読もう コードを読んでもらおう
  81. 81. たとえば
  82. 82. CodeIQに挑戦!
  83. 83. 勉強会に参加!
  84. 84. 教育プログラムを履修! • ソニックガーデンでは企業向け
 教育プログラムを準備中です。 • コードレビューできる人材を育成します。 • 詳細についてはお問い合わせください。
  85. 85. 本日のまとめ
  86. 86. 本日のまとめ • 同じ問題でも解き方は人によって千差万別 • 良いコードを書くためには • 個人で勉強する • チームや組織でコードレビューする • コードを書く、読む、読んでもらう • Webサービス、勉強会、教育プログラム
  87. 87. プレゼント本の 当選者発表
  88. 88. サイン入り本を贈呈! • 挑戦者の中から抽選で3名様に
 『「納品」をなくせばうまくいく』を贈呈 • 著者・倉貫義人のサイン入り!
  89. 89. Rubyで抽選しました
  90. 90. 当選者一覧 • m_utaさん • たがみつさん • みけCATさん • さらに、優秀賞を獲得した
 Muさん、ttakuru88さん、hitokunさん
 にもプレゼントいたします!
  91. 91. 当選おめでとうございます! & 挑戦ありがとうございました!
  92. 92. Q&A #sg_study で受付中!
  93. 93. アンケートから・その1 • 設計/仕様レベルのレビューは難しい • 些細な点の指摘に終始してしまう Answer • 設計レビューはみんなでじっくり • リリース前は致命的な問題にフォーカス • 仕様を把握するレビューは主に前者
  94. 94. アンケートから・その2 • レビューするコード量や大きさは? Answer • 1stリリース前のレビューはコード全体 • 以後のリリースはpull request単位
  95. 95. アンケートから・その3 • ネガティブにならないように気を遣う • 顔文字で工夫したりするが、なかなか Answer • 良いコードに対する共通認識を確認する • ネットのコーディング規則を活用する • 「自分のことは棚に上げる」ルールにする
  96. 96. アンケートから・その4 • 一人開発なのでレビューの機会がない • 自分のコードに自信が持てない Answer • 勉強会に参加する(もしくは開催する) • 教育プログラムに参加する • オープンソースプロジェクトに参加する
  97. 97. アンケートから・その5 • 人によって考え方が違う • 例) Rubyでreturnを書くかどうか、等 Answer • 良いコードに対する共通認識を確認する • ネットのコーディング規則を活用する • とりあえずreturnは書かない方が主流
  98. 98. アンケートから・その6 • コピペや非構造化コードの指摘に困る • 角を立てずに指摘するには? Answer • 良いコードに対する共通認識を確認する • ネットのコーディング規則を活用する
  99. 99. アンケートから・その7 • コードレビューの文化はどう作るのか? Answer • まずpull request方式を導入してみては?
  100. 100. アンケートから・その8 • 好みと指摘の境界線が気になる • 社内ルール化するのも自由がなくなる Answer • 良いコードに対する共通認識を確認する • ネットのコーディング規則を活用する • Hound CI等のツールを導入する
  101. 101. Q&A #sg_study で受付中!
  102. 102. 次回予告
  103. 103. 8月のSonicGarden Studyは
  104. 104. いつまでクソコードを 書き続けるの? デキるプログラマだけが知っている コードレビュー7つの秘訣
  105. 105. 概要 • 優れたプログラマになるための近道
 = 優れたプログラマによる指摘!! • レビューを上手に実践する秘訣を紹介 • 講師: 西見公宏(@mah_lab) • 放送予定日: 8/11(月)
  106. 106. 最後に
  107. 107. みなさんにお願い
  108. 108. アンケートにご協力を • 放送終了後、簡単なアンケートを
 メールでお願いしています。 • 今後のSonic Garden Studyを改善して
 いくためにぜひご協力ください。 • よろしくお願いします!!
  109. 109. Thank you.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×