この記事は Wondershake Advent Calendar 2016 22日目の記事です
Wondershake では基本的にほぼすべてのアプリでコードレビューが導入されています。(一部ソロ開発のものはレビューがない)
自分は基本的に LOCARI (のサーバーサイド)を開発してるので、それのワークフロー及びコードレビューで自分なりに気をつけていることを書きます
LOCARI のワークフロー
PivotalTracker, Github を使ってます 😄 (その他諸々ツールを使ってますが、基本的に見てるのはこの2つのみです)
- PivotalTracker に issue 起票
- 勝手に issue を取っていったり、アサインされたりする
- issue に紐づく pull request (以下 p-r)を
WIP:
で作成
WIP:
が取れたらレビュー担当によるレビュー
- コードレビューと動作レビューがある
- 機能追加の場合は後者必須
- すべてのレビューが通れば、 p-r 作成者がマージ
PivotalTracker への起票をスキップしていきなり p-r 出すこともあります(主に自分)
地味に [WIP]
ではなく WIP:
としてあるのは嬉しさがあります。タイプ数が1文字分減ります。(どうでもいい)
コードレビューで自分が気をつけていること
ここからは自分語りです。イタい
70 ~ 80 %で approve 出す
物議を醸しそうですが、自分が 100 % だと思うものを求めてしまうと(おそらく)どっちでもいいことが混在したり、レビューで説明しきれない可能性があったりするので...
「本当はこう実装した方が」みたいな時は「自分であとで p-r 出せばいい」と思うので、実際にそうしてます
その機能開発が本当に正しいかどうかはユーザーに触ってもらって初めて評価できると思うので、なるべくリリース優先になるようにしています。
が、本来は100%でいけるに越したことないので難しいなぁと日々感じています 😇💔
WIP 段階でもなるべくチェック
「WIP だから!まだ見んといて!」となる方もいるかもしれませんが、お互いに余計な時間を使うのを避けるために、方向性に疑問を持ったりしたらコメントを残すようにしてます。
Review changes
の Request changes
は使わず、 Comment
/ Approve
を使う
Github 限定の話です
機能としてはとてもいいんですが、思いっきり ❌ って出ちゃうのが心理的にアレで自分は避けてしまいます(すごいどうでもいい)
最近導入された Reviewers 機能 で右上に status が出るので別に Comment でもいいかなという気がしてます
最優先タスクをコードレビューにする
コードレビュー自体の話になってしまいますが、自分が以前働いていたところでそういう風に仕事してる方がいてかなり開発がしやすかったので、それをリスペクトして自分も真似してやってます
自分の開発は基本的に後回しにして、 p-r が作成されたらまず目を通します 😎🔎
他人の作業を止めるのが一番害だと思うし、出来てすぐのコードをチェックしてもらった方がモチベーション的にも良さそうなので。(自分は昨日書いたコードとか覚えてないので余計にきつい)
おわり
当たり前のことばかり書きましたが、以上になります。
明日は Go エンジニアの greg です。趣味でちょこちょこ Go を勉強しているので個人的に楽しみです 😍