概要¶ ↑
: 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 既存機能の理解が重要なら必要
講座でやること¶ ↑
* コードを読む文化作りの体験 * まず自分が読み始める * リーダブルコードを探す * 他のメンバーに教える