2013年10月14日月曜日

Github と Pull Request とコードレビューって当たり前じゃなかったのか...

メモ。
Webサービス開発現場から / 近頃の開発のやり方 ・・・ Github と Pull Request とコードレビュー

てっきり当たり前の開発手法だと思ってた。
この手法を導入するためにやることは2つ。リポジトリ管理をGithubにすることと
Jenkinsを導入し、テスト用サーバーを用意してテストを回し続けるようにすることだけだ。

開発者としてやることは
・開発をする
・テストを書く
・Pull Requestを飛ばして誰かにマージしてもらう
の3つだ。

Jenkins導入とテストを書くことのメリットだが、これをやることで糞コードが減る。
Jenkinsは特定ブランチにコードがコミットされるたびにテストが実行されるので、
テストが通らないおかしなコードがコミットされるとエラーを吐いて知らせてくれる役割をする。
テストを書くことでなぜ糞コードが減るかというと、テストが書きやすいようにコードを
分割するようになるので、メイン関数にすべてのコードをベタ書きするような、
あの誰も触れないコードを書くような事象を構造的に減らせるというわけだ。

重要なのはそこなので、カバレッジは別に100%じゃなくても構わないと思う。
最悪分岐の多い関数だけ書いておいてもいいわけだし。
バッチとかはメインロジックはそこに書かずにそこで呼び出すモジュールの方に
書いておけばテストもしやすい。

Pull Requestを飛ばしてだれかにマージしてもらうのは、コードレビューを構造的に
組み込むという意味で優れていると思う。これは本番用のブランチにマージする際に
自分でマージするのではなく、他の人にマージしてもらうということだ。
ここでレビューが入ることで、明らかにおかしなコードは入りにくくなるわけだ。

ちなみに設計などはwikiにドキュメントを残して開発チームでレビューを行う仕組み。
ここも属人化を避けるために複数人でミーティングを行っている。