Web界隈からすると今さらに見えるかもしれない。
職場で PullRequest 駆動開発に近い状況を作れないだろうか、と一部のプロジェクトで検証したり、広めたりしている。
まず言えるのはこれで効率が何倍にも高まるわけではないということ。
細切れの時間でもパフォーマンスが下がりづらくなるというのが効果だと思う。
いくつかのシステムを横断的に見る役割を担っているが、1日の中でシステムを行ったり来たりするとしんどい。
この、いわゆるコンテキストスイッチが緩和される。
リモートワークでもこれは顕著。たまの出張でもあまり差が出ない。
ここに挙げたメリットは、今の自分ならそれなりに感じられる。
しかし初心者にとっては正直効率がよくない。
それは PullRequest を送るまでの流れにある。
おおまかに分解すると以下のとおり。
- 期待結果を検討する
- テストを書く
- 実装する
そこそこの開発者であれば、これらの作業中に誰かに相談することは1回くらいで済むだろう。（もちろん規模にもよる）
これが初心者の場合は5, 6回と何度も手戻ることがありえる。
PullRequest を上げるころには、周囲の開発者がレビューを見なくとも内容をすべて理解しているということもざらだ。
初心者が多いチームでは手間を増やしてしまうだけに過ぎない。
ペアプロなどもっと密に作業して、早く「そこそこの開発者」になってもらうことを目指したほうがお互いのためだ。
まとめよう。
どのような状況であれば PullRequest 駆動開発が効果を発揮するか。
チーム内にそこそこの開発者が揃っていること。
細切れの時間が発生しやすい開発者が多いこと。
もちろん作業がワークフロー化されて理解しやすい、CI との相性がいい、といった効果もある。
しかし技術面に注目しすぎで、上にあげたような人の側面を忘れてはならないと思った。
GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)
- 作者: 大塚弘記
- 出版社/メーカー: 技術評論社
- 発売日: 2014/03/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (22件) を見る
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2013/12/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (7件) を見る
