Work In Progressなプルリクエストをチームに適用してみて

チーム開発で起きていた以下の問題に対応する為、WIPなプルリクエストの運用を開始した

• 巨大なプルリクエスト
  1000行超えるPRが結構な頻度で出来てた

• 巨大な変更点に対するコメントのしずらさ
  そもそも論の修正だったりテストのやり直しに繋がりそうだなぁと思いコメントを控えてしまう

• 1コミットがデカい
  デカい1機能1コミットにまとまって微修正のコミットが2,3個みたいな状況

• テストやってるの?問題, どこまでやれば終わりなの?問題
  曖昧な機能要件に対するプルリクエストであるが故、テスト観点など不明瞭な為、テスト仕様書を求められたり、実装者もどこまでやれば良いか認識しきれていなかったり

これらはそもそもGitに扱いなれてないメンバーやチーム開発に慣れてないメンバーが多いや、タスクの切り方がしっかり出来ていないなどの問題の為起きていた。
なのでプルリクエストの在り方以前ではあったが、良い機会なので、課題の切り方やGitの運用方法なども見直した

WIPパターンのプルリクエストとは

WIP ... Work In Progressの略。進行中を表す

主な特徴としては

• 最初のコミットは空コミットで始める

• 実装者はプルリクエストをその時点で作成し、コメント内に実装内容などをチェックボックス形式で記載する(この時、PRのタイトルに**[WIP]**などつけ作業中を明確にし、マージを禁ずる)

• レビュアーは認識の齟齬などないか確認する(実装者とレビュアーの意思疎通ツールとしてのプルリクエスト)

• なるべく小さい粒度でコミットし、レビュアーやチームメンバーは適時コードをレビューしたりできる

• すべての実装が完了したらタイトルの**[WIP]**を外し、最終レビューとマージをする

詳しくはこちら

Work in ProgressパターンによるPull Requestを利用した開発フロー

実際にやってみて

そもそも巨大なプルリクエストにならないようにタスクを切ったり、細かくコミットを心掛けるように喚起してから適用した。

良かった点

• 未完成の段階でレビューや指摘ができる
  データ構造の設計や、アンチパターンを踏みそうなソースに早い段階で指摘できる
  完成してからだと実装者もレビュアーも心的疲労が大きい。それが改善された。
  当たり前だが、これが一番デカい。早い段階でパブリックな場所にソースが置かれるのは良いことしかない。
  特に若手メンバーを育成するのには最良だと思う。

• 勿論コミットは小さくなるし、コンフリクトを未然に防げる
  前述と被るがコンフリクトしそうなソースに気づけ、指摘できる

• 手戻りが減った。あったとしても早い段階で気付ける
  最初にタスクを細かく洗い出すので、レビューする時に「ここの〇〇ってどういう改修？」、「あれやってないけど大丈夫？」みたいなやり取りができる。

悪かった点

• メンバーによってやったりやってなかったり
  コードレビューに重きを置いているメンバーや自分に近いメンバーはしっかりやってくれたが、始めた当初はメンバー間でモチベーション格差があった。
  タスクの洗い出しが雑だったり、コミットの粒度もマチマチだったり。
  コードレビューが怠惰なメンバーには単純に手間が増えたと感じるかもしれない。
  後述する空コミットの運用にも関係してくる

• 空コミットが出来ない問題
  僕が所属してるチームが基本SourceTreeなどのGUIクライアントを使うメンバーが多く、コマンドでGitを操作したことないメンバー多数である。
  空コミットの仕方を教える手間や、空コミットだけターミナルでやる手間などが発生した。

• プルリクエストが勝手にマージされてしまう
  チームで使っているリポジトリ管理がBacklogの為、ブランチを切っただけでプルリクエストが作れるメリットがあるのだが、その際空コミットしていないブランチが親ブランチがマージされるとそのブランチも差分なしと判断され、マージ済みになってしまう。(GithubはコミットないとPR作れないのでこの問題は起きないと思うが)
  これは空コミットの義務化をする以外ない

• レビュータイミングが人によってまちまち
  これはwip適用する前からあった問題ではありますが、しっかりしたスクラムとかを組んでるわけではないので、結局実装完了後にPRを見るなんてこともありました。
  これに関しては週次などでコードレビューの時間を設けたり、レビュアー側のルール整備も必要だなといったところ

空コミットをGUIツール陣にも手軽にしてもらう施策

GUIツールにカスタムコマンドを登録する

Forkを例に挙げるが、SourceTreeにも同等の機能あり

1. 設定からCustom Commandの項でAdd Branch Custom Commandを登録する

1. 空コミットのカスタムコマンドを登録
   この時、$shortname を含めておくと自動でブランチ名がコミットされ課題管理ツールと紐付き便利

1. 対象ブランチから右クリックから簡単に空コミットが出来るように

まとめ

総じてメンバーやリーダー層やレビューする側からの評判が良く、やって良かったと言える。
やっぱりコードレビューはチーム開発においてかなりの比重と重要度を締めると思うので、一番改善しておくべきかつ効果が出るところ。
同じような悩みを抱えてるチームは一度やってみることを勧めます。
ただ、モチベーション格差などを感じた瞬間に、凹んだりしますが、チームビルディングってまぁこんな感じだよなぁと。利点を知って貰えるように自分が働きかける以外に道はないかなと思ってます。

現在、テストがない状態だったソースにテストコードを書くようにする施策などレガシーで非効率な開発スタイルから脱却しようと施策を打って少しでもチームがうまく回るように頑張っております。