コードレビューしてますか？
CyberX エンジニアの塚原です。
チームでアプリの開発・運用をしていると、
機能追加やバグ修正などで他人の書いたソースコードを読む機会が多々ありますよね。
その際に、コーディング規約に沿っていないオレオレなソースコードだったり、
メソッドが長過ぎるコードに出会ってPCを閉じたくなった経験はエンジニアなら誰でもあるはず。
そういったコードは保守性に欠け、バグも生み出してしまいます。
（そんなことは理解していても、開発期間が足りずに泣く泣くそのままリリースすることも）
「// 最低なソースでごめんなさい。。。朝5時なんです。」なんてコメントがあったりw
とはいえ、出来るだけ始めからキレイなコードにしておきたいですよね。
ということで、今回は「コードレビュー」をテーマにしてみました。
今更な感じはありますが、
結局のところコレが皆が幸せになる手っ取り早い方法なのかな、と。
他人のソースコードを読んでいると
ここはこう書くべきでは？
とか思いますよね。
それを早い段階で指摘しておければいいわけです。
じゃあコードレビューをしましょうよ、と。
コードレビューには次のようなメリットがあります。
＊ソースコードが共有できる
書いた本人がいなくなったら誰もわからない。。。
ってことが防げるはず。
ちょっと話がズレますが、
以前の職場で、ある日になるとプログラムが動かなくなる処理が意図的に組み込まれていて困ったことがあります。。。
まぁこんなことはあまりないと思いますが、これもレビューしてれば防げます。
＊勉強になる
レビューする側、される側の双方にとって効果が見込めるはず。
ペアプログラミングと同じような効果があるかと。
他人の書き方で勉強になることは多いです。
新しくjoinした方に規約などを教える機会にもなります。
＊ソースコードの質が向上する
指摘はなるべく受けたくないですよね？
となると必然的にコードの質は上がります。
保守性があがり、バグも減るでしょう。
もうコレだけでやる価値があると思いませんか。
「いやいや、そんなこといっても時間もかかるし、導入は面倒だよ」
という考えもあるでしょう。
その時は時間を要しますが、長い目でみれば少なく済むはずです。
変更しやすく拡張性が高いコードになっているはずですから、
機能追加やバグ修正には少ない時間で対応できます。
「上司や先輩には指摘し辛い」というのもあるでしょう。
これはチームで先にルールを決めておきましょう。
立場に関係なく議論できる環境を用意しておけばきっと良いレビューが増えるでしょう。
コードを書いた人ではなく、コード自体に意見するんだよ、ということ。
レビューの手法として取り入れ易いものをいくつか例を挙げると
＊ペアレビュー
コードを書いた人とレビューする人がペアで進める手法。
2人で進めるため、抜け漏れがあるかも。
＊パスアラウンド
複数人が非同期でレビューする手法。
GitHubやGerritを利用するのが多い。
＊アドホックレビュー
必要になった時にチームメンバーにコードをみてもらう手法。
これが一番ハードルが低いと思います。
あとは、ブランチにコミットする前にレビューするのか、後にレビューするか。
非同期でレビューを行うならば、コミット後の方が都合が良いでしょう。
ただ、手法はいくつもありますが、どれも完璧ではないので、
複数組み合わせたり、ペアプログラミングと組み合わせたり、
より自分たちに合ったやり方を探す必要があります。
（パスアラウンド＋アドホック＋たまにはペアプログラミングがやり易いかな）
＋テスト駆動開発でバグのないキレイなソースコードでハッピーになりましょう！
参考文献：
http://gihyo.jp/magazine/wdpress/archive/2013/vol72
参考URL：
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC
https://speakerdeck.com/fujimura/aiminggithub
チームでアプリの開発・運用をしていると、
機能追加やバグ修正などで他人の書いたソースコードを読む機会が多々ありますよね。
その際に、コーディング規約に沿っていないオレオレなソースコードだったり、
メソッドが長過ぎるコードに出会ってPCを閉じたくなった経験はエンジニアなら誰でもあるはず。
そういったコードは保守性に欠け、バグも生み出してしまいます。
（そんなことは理解していても、開発期間が足りずに泣く泣くそのままリリースすることも）
「// 最低なソースでごめんなさい。。。朝5時なんです。」なんてコメントがあったりw
とはいえ、出来るだけ始めからキレイなコードにしておきたいですよね。
ということで、今回は「コードレビュー」をテーマにしてみました。
今更な感じはありますが、
結局のところコレが皆が幸せになる手っ取り早い方法なのかな、と。
他人のソースコードを読んでいると
ここはこう書くべきでは？
とか思いますよね。
それを早い段階で指摘しておければいいわけです。
じゃあコードレビューをしましょうよ、と。
コードレビューには次のようなメリットがあります。
＊ソースコードが共有できる
書いた本人がいなくなったら誰もわからない。。。
ってことが防げるはず。
ちょっと話がズレますが、
以前の職場で、ある日になるとプログラムが動かなくなる処理が意図的に組み込まれていて困ったことがあります。。。
まぁこんなことはあまりないと思いますが、これもレビューしてれば防げます。
＊勉強になる
レビューする側、される側の双方にとって効果が見込めるはず。
ペアプログラミングと同じような効果があるかと。
他人の書き方で勉強になることは多いです。
新しくjoinした方に規約などを教える機会にもなります。
＊ソースコードの質が向上する
指摘はなるべく受けたくないですよね？
となると必然的にコードの質は上がります。
保守性があがり、バグも減るでしょう。
もうコレだけでやる価値があると思いませんか。
「いやいや、そんなこといっても時間もかかるし、導入は面倒だよ」
という考えもあるでしょう。
その時は時間を要しますが、長い目でみれば少なく済むはずです。
変更しやすく拡張性が高いコードになっているはずですから、
機能追加やバグ修正には少ない時間で対応できます。
「上司や先輩には指摘し辛い」というのもあるでしょう。
これはチームで先にルールを決めておきましょう。
立場に関係なく議論できる環境を用意しておけばきっと良いレビューが増えるでしょう。
コードを書いた人ではなく、コード自体に意見するんだよ、ということ。
レビューの手法として取り入れ易いものをいくつか例を挙げると
＊ペアレビュー
コードを書いた人とレビューする人がペアで進める手法。
2人で進めるため、抜け漏れがあるかも。
＊パスアラウンド
複数人が非同期でレビューする手法。
GitHubやGerritを利用するのが多い。
＊アドホックレビュー
必要になった時にチームメンバーにコードをみてもらう手法。
これが一番ハードルが低いと思います。
あとは、ブランチにコミットする前にレビューするのか、後にレビューするか。
非同期でレビューを行うならば、コミット後の方が都合が良いでしょう。
ただ、手法はいくつもありますが、どれも完璧ではないので、
複数組み合わせたり、ペアプログラミングと組み合わせたり、
より自分たちに合ったやり方を探す必要があります。
（パスアラウンド＋アドホック＋たまにはペアプログラミングがやり易いかな）
＋テスト駆動開発でバグのないキレイなソースコードでハッピーになりましょう！
参考文献：
http://gihyo.jp/magazine/wdpress/archive/2013/vol72
参考URL：
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC
https://speakerdeck.com/fujimura/aiminggithub