= 概要 : author 須藤功平 : institution 株式会社クリアコード : content-source 実践リーダブルコード : date 2015-03-06 : allotted-time 30m : theme clear-code = 今日の流れ - 午前 * 10:00- アイスブレーク * 10:15- 概要と進め方の説明 * 10:45- 実装 * 12:15- ランチ = 今日の流れ - 昼下がり * 13:15- 読み方のデモ * 13:30- チェンジして実装 * 15:00- グループふりかえり * 15:30- グループ発表 = 今日の流れ - 夕方 * 16:00- まとめ * 次のステップを説明 * 16:30- 質疑応答 * 17:30- コードの感想戦 * 時間があれば * 18:00- （有志で懇親会？） = チューター紹介 * 参加者のサポート係 * 現役エンジニア * 参加者がわからない * →聞くと助けてくれる * →モジモジしてると声をかけてくる = チューター紹介 * 結城洋志（ゆうき ひろし） * 得意言語: JavaScript * 沖元謙治（おきもと けんじ） * 得意言語: Ruby * 横山昌史（よこやま まさふみ） * 得意言語: Ruby = 講師紹介 (('tag:center'))(('tag:margin-bottom * 2')) 須藤功平（すとう こうへい） * クリアコード代表取締役 * リーダブルコード（本）の\n 「解説」の著者 * 進行と全体を気にかける係 = 講座の目的 * 自分の開発チームに * ((*リーダブルなコードが\n 当たり前な文化の作り方*))を * 持ち帰る (('tag:center')) (('note:→ 「解説」に書いていることの実践方法を学ぶ')) = サポート * 今日の資料はすべて再利用可能 * チーム内で同じ講座を再現できる * 無料のフォローアップ面談 * チームで実践→悩み\n ↑の相談に乗る * 受講後3ヶ月以内に1回 = そもそもの話 * リーダブルコードはなぜ必要か (('tag:center')) ↓を目指すために\n チームでの共有は必須\n \n リーダブルなコードが\n 当たり前な文化 = リーダブルコードの必要性（1） 作って終わり\n じゃないから = ソフトウェアの生涯 * 昔 * 作って終わり * 作ったらできるだけ触らない * 今 * 機能は少なくてもまず動くものを * 動いてからも継続的に改良・修正 = ソフトウェアの生涯 # image # src = images/software-life-cycle.svg # relative_width = 90 == プロパティー : enable-title-on-image false = 継続的に改良・修正 * 既存の機能の改良 (1) 既存機能の理解→ (2) 改良 * 既存の機能の修正 (1) 既存機能の理解→ (2) 修正 = 既存機能の理解のため リーダブル\n コード = 時間が経つほど効果がでる # image # src = images/readable-code-reasonability.svg # relative_width = 90 == プロパティー : enable-title-on-image false = リーダブルコードの必要性（2） 1人だけの開発\n じゃないから = チームでの開発 * 昔 * 1つのモジュールに1人の担当者 * →1人しか触れないモジュール * →チームとして改良・修正できない * 今 * 1つのモジュールに複数担当者 * →複数人が触れるモジュール * →チームとして改良・修正できる = 複数人が触れる 触れる\n ↓\n 既存機能を\n 理解できる = 既存機能の理解のため リーダブル\n コード = リーダブルコードの必要性 * 継続的に改良・修正したい * チームとして改良・修正したい (('tag:center')) ↑をチームで共有することが\n 最初にやること = 必要性を共有した後 コードを読む\n 文化を作る = 読む？書くじゃないの？ * リーダブルコードを書くには\n コードを読まないといけない * なぜ？ * →リーダブルコードは\n チーム毎に違うから = リーダブルコード 「読む人」が\n 読みやすいなら\n リーダブル = 読む人 * 多くの場合、いない * チームのコードを読んでいますか？ * 読む人（チームメンバー）毎に\n リーダブルの基準は違う * 背景が違うので当たり前\n (('note:（背景：使ってきた言語とか）')) = チームでのリーダブル * 1つずつ見つけていくしかない * 各メンバーの読んだ感覚を\n チームで共有 * 既存の基準をベースにするのはアリ\n (('note:（基準：本の内容やコーディングスタイルなど）')) (('tag:center')) チームでのリーダブルコードは\n 育てていくもの = リーダブルの基準の育て方 * コードを読む文化を作る\n (('note:（最初の難関）')) * チームのコードの中から\n リーダブルなコードを見つける * リーダブルなコードを\n チームで共有 * ↑の繰り返しで基準を増やす = コードを読む文化を作る * まず自分が読み始める * 仲間がいると心強い * リーダブルなコードを探す * 読みにくいコードは今は置いておく\n (('note:（チームにコードを読む文化ができてから！）')) * 見つけたリーダブルなコードは… = リーダブルなコードは… * 他のメンバーに教える\n (('note:（例：話しかける。チャットに書く。Wikiにまとめる。）')) * 「○○さんの△△という書き方、\n リーダブルでしたよー」 (('tag:center')) ↓\n 読みやすさの基準を共有\n コードが読まれているという自覚 = 読むことを「当たり前」に * 「あいつはコードを読むやつ」\n という認識を広める * 自分だけからチームへ (('tag:center')) …続きはセミナーの最後に = ワークショップ内容 (('tag:center')) 改良するために\n 他の人のコードを読む * 「まず自分が読み始める」 * 「リーダブルコードを探す」\n (('note:（読みにくいコードは今は置いておく）')) * 「リーダブルの基準を共有」 = 注意：やらないこと (('tag:center')) リーダブルコードを書くための\n テクニックをたくさん伝授 ((' ')) = テクニック伝授は範囲外 * 順番が違う * まず読む文化を作ること * 今日は↑がメイン * テクニックはその後 * (('note:時間があれば「コードの感想戦」でフォロー')) = やること 読む文化作りの\n 体験 = 読む文化作り * まず自分が読み始める * リーダブルコードを探す * 他のメンバーに教える = 読む文化作りの体験 * 10:45- 課題を実装 * リーダブルコードを書く * 13:30- 実装チェンジ→開発継続 * 「まず自分が読み始める」 * 「リーダブルコードを探す」 * 15:30- グループ発表 * 「他のメンバーに教える」 = おさらい * 講座の目的 * リーダブルコードの必要性 * 講座でやること = 講座の目的 * 自分の開発チームに * ((*リーダブルなコードが\n 当たり前な文化の作り方*))を * 持ち帰る = 文化作りの前 * リーダブルコードの必要性を\n チームで共有 * 必須 * これを飛ばすと頓挫する = リーダブルコードの必要性 * 継続的に改良・修正したい * チームとして改良・修正したい (('tag:center')) ↑\n 既存機能の理解が重要なら必要 = 講座でやること * コードを読む文化作りの体験 * まず自分が読み始める * リーダブルコードを探す * 他のメンバーに教える