リーダブルコードをn読んだ後¶ ↑
: author
須藤功平
: institution
株式会社クリアコード
: content-source
DevLOVE 2012
: date
2012/12/16
: allotted-time
10m
: theme
.
やること¶ ↑
クリアコードの開発方法を体験
目標¶ ↑
((‘tag:center’))((‘tag:large’))リーダブルコードを
((‘tag:center’))((‘tag:x-large’))当たり前にする
イベントのテーマ¶ ↑
# image # src = http://devlove2012.devlove.org/theme/jobs/images/copy.png # relative_width = 100
スライドプロパティ¶ ↑
: enable-title-on-image
false
目標¶ ↑
((‘tag:center’))((‘tag:x-large’))あなたが
((‘tag:center’))((‘tag:large’))リーダブルコードを
((‘tag:center’))((‘tag:x-large’))当たり前にする
やること¶ ↑
* クリアコードの開発方法を体験 * 対象: 野生のフリーソフトウェア * 読む人を「想像」しない * 読む人を「思い出す」
想像上の誰か¶ ↑
# blockquote # title = リーダブルコード 1.5 でもやるんだよ 想像上の誰かが自分のコードを理解しやすいかなんて考えるのは大変なことだ。
想像しない¶ ↑
* 読む人を「想像」しない * 読む人を「思い出す」
思い出すには?¶ ↑
読む人になる
クリアコードの開発方法¶ ↑
* コミットメールが全員に届く\n (('note:(diff入り)')) * 全員が読む * 気になったらコメント\n (('note:(プロジェクト外の人でも)')) * 「昨日印象に残ったコミット」を朝会で報告
ポイント¶ ↑
* 全員が書く人で読む人 * 書く時: * 読む時の事を思いながら\n (('note:(こう書くと読みやすいんだよな。)')) * 読む時: * 書く時の事を思いながら\n (('note:(これ読みやすいから今度同じように書こう。)'))
当日は省略¶ ↑
なぜリーダブルコード?¶ ↑
開発をn続けるため
メリット¶ ↑
* メンテナンスコストを低く保つ\n (('note:(開発を続けるわりにあわなくなってしまう)')) * 機能追加・変更をしやすくする\n (('note:(使われないものになって開発する必要がなくなる)')) * プログラマーの意欲を保つ\n (('note:(プログラマーも人です)'))
注意¶ ↑
* すべてを解決するわけではない * よりよくする重要な方法の1つ * トレードオフ
メンテナンスコスト¶ ↑
# blockquote メンテナンスコストを低く保つためにずっとリファクタリングをし続ける と…高いメンテナンスコスト
素早い変更¶ ↑
# blockquote 素早く機能追加・変更できるよう、リーダブルコードにするために必要な時 間を確保して開発しているのに、機能を追加したいというと必ず1週間以上は 必要だと言われる…素早くない変更
ゴール¶ ↑
* 本末転倒にならないように! * リーダブルコードを書くことは\n ゴールじゃない * 効率よく目的を実現するのがゴール\n (('note:(今だけ効率がよければよいのではない。念のため。)')) * 手早くリーダブルコードを\n 書けるようになろう!
なぜコミットメール?¶ ↑
ペアプロよりn スケールする
ペアプロ¶ ↑
* 常にコードレビュー * 2人だけ * 時間をあわせる * 距離をあわせる * プロジェクトをあわせる
コミットメール¶ ↑
* 常にコードレビュー * 2人以上も読める * 時間がずれてもよい * 距離がずれてもよい * プロジェクトがずれてもよい
コミット¶ ↑
((‘tag:center’))((‘tag:large’))((‘tag:margin-bottom’)) ペアプロしているように!
* 小さくコミット * 意図が伝わるコミット
ペアプロの方がよいこと¶ ↑
((‘tag:center’))((‘tag:large’))((‘tag:margin-bottom’)) 全体の設計とかもみれる
* コミットメールだけだとムリ * pull requestだけでもムリ * 一緒に書いていないとムリ\n (('note:(同じプロジェクトだといけそう)'))
ここまで飛ばす¶ ↑
確認¶ ↑
事前課題
事前課題¶ ↑
(1) リーダブルコードを読む (2) Rubyコードの感想戦を読む (3) github://clear-code/git-utilsをfork (4) commit-email.rbを読む * Rubyコードの感想戦のように読む
事前課題確認1¶ ↑
(1) ((*リーダブルコードを読む*)) (2) Rubyコードの感想戦を読む (3) github://clear-code/git-utilsをfork (4) commit-email.rbを読む * Rubyコードの感想戦のように読む
事前課題確認2¶ ↑
(1) リーダブルコードを読む (2) ((*Rubyコードの感想戦を読む*)) (3) github://clear-code/git-utilsをfork (4) commit-email.rbを読む * Rubyコードの感想戦のように読む
事前課題確認3¶ ↑
(1) リーダブルコードを読む (2) Rubyコードの感想戦を読む (3) ((*github://clear-code/git-utilsをfork*)) (4) commit-email.rbを読む * Rubyコードの感想戦のように読む
事前課題確認4¶ ↑
(1) リーダブルコードを読む (2) Rubyコードの感想戦を読む (3) github://clear-code/git-utilsをfork (4) ((*commit-email.rbを読む*)) * Rubyコードの感想戦のように読む
むずかしい?¶ ↑
* 「うまくできない」は今のうち * 聞けば答えます
進め方¶ ↑
* 読み手になる: 15分 * (('note:事前課題をやっていない人: Rubyコードの感想戦を読む')) * 読み手目線で書く: 15分 * (('note:事前課題をやっていない人: 読み手になる')) * 質疑応答: 10分
読み手になる: 15分¶ ↑
(1) 数人のグループを作る (2) グループ用のgit-utilsをclone (3) 読んでcommit & push * リーダブルなら((*理由*))をコメントとして書く * リーダブルじゃないなら直してコミットメッセージで((*理由*))を説明
読み手目線で書く: 15分¶ ↑
(1) 他のグループのリポジトリのコミットを確認\n (('note:コミットメールが届いているはず')) * 自分達にピンとこないものを選ぶ * 直してメッセージで((*理由*))を説明 * コードで伝える (2) 自分たちのリポジトリを確認 (3) 繰り返す
質疑応答: 10分¶ ↑
* 気になったコミットは? * やってみて困ったことは? * 実践すると困りそうなことは?
宣伝¶ ↑
((‘tag:center’))コミットへのコメントサービスn ((‘note:www.clear-code.com/services/#commit-comment’))
# blockquote お客様の開発プロジェクトのコミットを読んでコメントすることにより、お 客様の開発チームが「当たり前のようにクリアなコードを書く文化」を育む ことを支援します。