chunky bacon“...so create”

ペアリング対コードレビュー: 開発者文化の比較

08 Dec 2013

前職現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。

(ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。

用語の定義

まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。

ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わっている。日々のプログラミングというのは、朝から晩までペアと会話することを意味する。ペアがコードをコミットしたら、それ以上のレビューはなしにマスターにマージされる。

コードレビュー文化 といったとき、会議室にこもってプロジェクターでコードを映しているチームを想像する人も多いんじゃないかな。自分も最初はそうだった。ありがたいことに、ここで議論するのはそんなチームのことではない。ここで議論するのは、ツールを駆使して高度に自動化されたピアコードレビュープロセスのことだ。GerritのパッチセットやGitHubのプルリクエストなどの仕組みを使えば、個人がコードを書いて、最低でもチームの他の一人に差分をレビューしてもらうことができる。ソースコード一行毎のコメントを使って、質問したり、コードのスタイル、機能についてコメントできる。差分が承認されたら、コードがマスターにマージされる。

成功への前提条件

どちらのパラダイムを使うにせよ、以下が必須であることは議論の余地はない。

自分の経験では、どんなプロセスを選択しようと、これらは絶対に必要だ。

ペア作業の楽しさ

じゃあペアプログラミングの話をしよう。ペアプログラミングはすごい経験だ。誰でも何回かはやってみるべきだ。ペアプログラミングの利点について書いているドキュメントはいろいろあるけれど、ここでちょっとまとめてみよう。

広帯域のコミュニケーションチャネル がペアの間に生成され、あらゆるメリットのために活用される。熟練者とペアにすることで、 若い開発者を鍛える のは簡単だ。コア開発者は、すばやく ベストプラクティスを伝え、チームの知識サイロを越える ことができる。新しいツールや技法は自然にチーム内に広まる。 みんな一緒にうまくなっていく

二人でペアになると、 自然と二人のリズムのバランスをとれる ようになる。お互いのリズムが補完的になる場合、片方がいまいち乗れないときも、もう片方が開発をドライブする。二人ともが集中力を失わないのを助ける。お互いのリズムが合ったときは、ものすごい生産性を発揮する期間があって、それが過ぎたら、二人ともいっしょにちょっとのんびりする。

誰かとつねに一緒にやっていると 改善のモチベーションを生まれる 。尊敬する誰かが見ているときは、誰しもうまくやってやろうと思うものだ。 __戦術的な決定も容易になる__し、結果が改善することも多い。二人でやっていると手抜きをすることはすくなくなるし、トレードオフがあるときは自然に会話が生まれる。

コードの共同所有 というコンセプトの実現は簡単になる。どのコードも一人で書いたものではなくなるからだ。失敗をチームのものとし、個人のものとしない、という健全な見方が実現できる。

ペア作業はチームのバランスに影響を受けやすい

うまくいったペア作業はすばらしい。でも、飼い慣らすのが難しい猛獣にもなる。ペアプログラミングの生産性は、いろいろな軸の チームのバランスの影響を受けやすい 。ものすごく敏感だ。若い人の教育方法としてペアプログラミングはすばらしい。でもペア開発で、 コア開発者を薄めすぎる と、生産性と士気は簡単に失われる。チームに経験の足りない人をいっぺんに加えたら、すぐにこうなる。できる人のペアを考えるのは、テトリスになってしまう。

知識サイロ でも同じような問題が起こりえる。これもとてもよく似たパターンだ。ペア作業は知識サイロを壊すのに有効な方法だが、有用なノウハウを含む知識サイロが一旦できあがってしまうと、ペアの選択や交代は困難になってしまう。

チームは、このような問題が起こらないよう絶えず気を配り、早いうちに対処する必要がある。知識や能力のバランスが崩れると、いろいろなことが見えなくなり、ペアの組み替えを困難にし、さらにいろいろな問題を悪化させる。

ペアリング文化は、多様な文化を許さないことがある

ペアプログラミングは、わりとしんどいプラクティスに入る。誰しもが好むわけではない。このプラクティスを採用することによって、 雇える人材 の幅を狭めてしまうことになる。四六時中いっしょに作業したい人しか雇えないのだ。ペア作業によるメリットに対して、これは大きなトレードオフになる。

ペアプログラミングを採用するチームの場合、新規メンバーの雇用の際の採用規準も異なってくる。開発者は全員、「この人のとなりに一日中座って一緒にコードを書けるか?」と自問するようになる。この質問は健康なチームを維持するには必要だが、「文化が合わない」という言い訳で、チームとは大きく違うパーソナリティや経験を持つ人を除外するようになる危険もある。

ペアリングをすると戦術を選ぶ点(ツール、プラクティス、技術)においては、チームのメリットを考えて統一が進みやすくなる。ただ同時に、他の可能性を検討せずに除外するような単一文化にも陥りやすくなる。テクノロジー産業におけるチームの多様性をめざす戦いは激しさをましているが、ペアプログラミング文化を採用すると、ふとチームを見回すとチェック柄のシャツを着たひょろっとした白人のにいちゃんばっかりになってたりする。

ペア作業自体は、ハンモック問題の解決にはならない

ペア作業は、知識を共有しながら着実に作業をすすめるすばらしい方法だ。ただし、より深い知識や創造性が必要な判断には害になることもありえる。システム設計やアーキテクチャなど大きな問題にとりくんでいるときに、そのような判断が必要となる。

経験の少ない開発者とペアを組んでいるとき、コード設計における熟練開発者の判断は __自然とやっつけてしまうこと__に傾く。ペアの作業の “時間の無駄” を避けようとしてしまう。ペアを待たせるプレッシャーのない場合と比べると、結果として劣った設計になることもある。

いずれにせよコードレビューが必要になることもある

これまでに書いたような問題にチームが直面するようになると、すべてのペアのコードが完全に信頼できるわけではないとコア開発者が考えるようになることは多い。経験の足りない開発者が、未経験者とペアになることもあるだろう。デフォルトでは信頼するというパラダイムは、ここで崩れ去る。本番環境へリリースするまえにはレビューが必要だなと、コア開発者は結局考えるようになるということだ。 こうなるとペアによって得られる共同所有や信頼のメリットは、いくぶんか失われてしまう。

コードレビューの楽しみ

コードレビュー文化に移動が決まったとき、とてもがっかりするだろうと最初は考えていた。ペア作業のすばらしい経験があったからだ。でも、コードレビュー文化に来て最初に経験したのは、言いようのない開放感だった。

コードレビューのある環境では、 準備のできてないコードが他人に見られることはない。 それでもコードが必ず他人の目に触れることは、開発者全員が知っているので、いい意味で、 いいコードを書く動機付け プレッシャーは、コードレビューにも存在する。

ペアの場合と違い、 深い問題 に取り組む障害はない。ホワイトボードとともに1時間部屋にこもったり、散歩に行ったり、情報をググったり、学術論文を印刷してから読んだりなど、ペアでは難しいことも、何だってやってよい。 問題解決技法のツールボックスが拡大 するようなものだ。コード構築のプロセス全体に利益がある。

コードレビューを行っているチームでは、 あなたはコードで判断される。 同僚とプロとしてコンタクトするのは、まず第一にコードを介してとなるからだ。このことは、このような環境で働きやすい 多様な人材タイプ を雇えることを意味する。いっしょに遊びに行ったりはしたくないが、すばらしく堅牢なコードを書く人を、喜んでチームに迎え入れることができる。

コードレビューは非同期である。 これが多くの利益をもたらす。まず、チームは、メンバーが 柔軟なスケジュール で働くことを許容しやすくなる。ある人は午前5時から正午までが集中できる時間帯という人がいても、まったく問題ない。夕方からナイトスクールに通って、その後に働きたい人がいても大丈夫だ。また、戦略的に コードレビューを分散 できる。経験のある開発者が、ある種類のコードを必ずレビューするようにすることで、品質をさらに制御し、バグが本番環境で見つかるのを防ぐことができる。

自分が気がついたのは、ペア環境と比べて、コードレビューをやると 自分の価値をより意識する ということだ。ペア環境では、自分の好み、「ここはこうじゃないと許さねぇ」ですんだことが、コードレビューでは変更を提案するかどうかを判断するのに、十分な理由を説明できるかを考えるようになる。このことで、、自分の考えを確認すること(と考えを改めること)を、なんとかやることができた。これについては、また書こうと思う。

コードレビューでは仲良くなったりしない

ペア文化とコードレビュー文化で一番顕著な違いは、コードレビュー文化のもとでは、日々の コードを書く作業の間、あなたは ひとりぼっち ということだ。それをメリットと考える性格の人もいるだろうが、自分にとっては障害になり得る変化だった。

もちろん、軽減する方法はいくらでもある。他の役割の同僚と一緒に出かけたりね。社会的なつながり方が大きく異なる二つの文化を経験したことで、37signals のリモート勤務の議論を読んでみよう気になった。ここに反応を書くかもしれない。

プライバシー対自律

同僚からの、いいコードを書く動機づけがあるとはいえ、毎時間毎時間を見てみれば、 自分が何をやっているかを知っているのは自分だけだ。 今取り組んでいる問題への完璧な解決策を見つけるために散歩に出かけてもよい。でも、だらけるのも簡単すぎる んだ。ウィンドウを行ったり来たりしつつ、メールを見て、チャットルームを覗いて。進捗に関係しないことをだらだらと。

ペア文化の進捗しなきゃいけないというバイアスとほぼ正反対だ。ひとりでの開発は、ある日、ある時間、ある瞬間に 進捗しなきゃいけないという絶対的な要件は ない。 すべて自分次第ということ。 とても恐ろしくもある。

コードレビューは行き詰まることがある

コードレビューが非同期にできるので、スケジュールには柔軟にできる。とはいっても、 ボトルネック がなくなるわけではない。コードレビューが完了がしないので、仕事が終わらなかったり。コードレビュー待ちが山ほどあるせいで、コア開発者がコードを一行も書けなかったり。

コードレビューでは、コミュニケーションの帯域幅が狭い のも事実だ。コードを書いているそばからコメントするのと、レビュー用にプッシュされたコードに何が間違っているかをコメントするのでは、スピードの桁が違う。レビュー用に“作業中”コミットすることで、ちょっとスピードを上げることはできる。ただコードレビューしか方向修正の機会がないと、経験の足りない開発者は間違った方向にずっと行ってしまうのは避けられない。

“え, 問題ないよ”

ペア作業ではつくっている時点での会話を促すのに対して、コードレビューは、 何かができあがってから 行われ、品質に関係なく マージしてしまえという勢い を自然に持つようになる。リビジョンが上がったときにコメントして、再pushして、再レビューするには、結構なエネルギーが必要だ。結果として、レビューアーはコード品質の問題に対して、だんだん甘くなっていってしまう。

で、誰の勝ち?

さて、コード品質のためのプラクティスとしてのペアプログラミングとコードレビューのいけてるところ、とあんまりいけてないところを十分に示せただろうか。究極のところ、一番重要なのはチームがプラクティスの選択に実践的になることだ。なにがうまくいかないかに正直になれるように。自分のアプローチの弱点がわかったら、改善のアクションを始められる。

まだチームを見つけられていないなら、 コードとプロセスに気を使うチームを見つけよう。 そうすれば、一緒にこれらの問題に組めるようになる。 (ここであげた問題について低減するための戦略について、将来のポストで書くつもりだ)