Github実践入門 ─ Pull Request による開発の変革 #githubkaigi

PHP Perl Ruby Chef Puppet Agile

今mixi

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

新品価格
￥2,786から
(2014/6/1 14:11時点)

今日のメッセージ

Githubを利用した開発の世界を知る
Githubを(活用)する違いを知る
Github実践入門はガイドブック

使っているだけのか、十分に使いきっているのかの違いを考える

Githubを利用した開発の世界を知る

世界(所謂ワールドの話はせず、業務、仕事でGithubがある状態とない状態)

Githubについて

pull request ぷるりぷるりく全部一緒

Pull Requestを利用した開発

対話
フィードバック
コードレビュー
テスト(必要性に迫られる)
マージ(mergeできるようにするためにはどうするか)

よくある世界

なんとなく変数名をつける(いまいちしっくり来ないけどとりあえず名前をつける)
この変数名適切じゃない気がする
いくつか候補を出す
機能を完成させるため、そのままにする
あとで適切な名前を思いついたら変更する
「あとで」変数名を変える→一生こない
他の人の眼にも触れずに本番環境で稼働する

Githubのある世界

なんとなく変数名をつける
この変数名適切じゃない気がする
いくつか候補を出す
機能を完成させる
このことをGithubに書く
他の開発者がレビュー
良い変数名 + アルファをフィードバック
コードに反映

6-7が下手をすると数分でかえってくる

2つの世界の差

Githubの開発でやっていると、すごく重要。

習慣(PRを出すとぷるりを見ざるを得ない、読まざるを得ない)
機会(修正拡張学習)
品質（2eyes < over 4 eyes）
心理(不安、安心、自身)

鉞を飛ばされる不安を払拭するために、よりよいコードを書く

変な上司に「頑張ってるなあ」って言われるよりも鉞を飛ばす人に「良いコード書いてるね」って言われる方が嬉しい

機会はすごく重要。機会があるから学習したり改善したり出来る。 GitHubを活用すればそういう機会が増えていく。

人の目が増えれば品質が上がるかどうかは分からんが。

世界の中にも差

使っているだけの人と、十分に活用している人コードを管理 vs コードの価値を高める差分を入れてもらう vs 対話設計改善

(mergeお願いします) (言われたら直すかな) vs (こういうふうに設計したいんだけどどう思う？) (これしっくり来ないんだけどどう思う？) (PRをレビューしてくれ)

↑のほうはコードレビューの習慣が生まれない ↓のほうはコードレビューをするしてもらう

活用している人になる

使っているだけのPR

「このメソッド名は抽象的すぎませんか？」
このようなコメントだけ
他の開発者がコードを見てるだけ、だけど何もしてない世界よりは良い世界

活用しているPR

このメソッド名は抽象的すぎじゃない？「xxxyyyyzzz」のおうが具体的でよいと思いませんか？
そうですね、ですがxxxはクラス名に含まれていますし、yyyzzzのほうが意味も簡素でよいと思う
そうねえ
LGFM
conversationを活用して！！！

指摘=簡単、提案=難しい

「なんだよこのコード」というのはコードを理解していなくてもかけなくてもいえる
コードをよりよくするために行動

GitHubを導入すると

コードをレビューすると、
行動を起こすきっかけ
良い所悪いところが見える→現実
悪いところを回避、解決するノウハウも