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