Git guilt に表れる責任とコードレビューの重要性

Tim Petterson
Tim Petterson
リストに戻る

私は最近 Git を正しく理解するツアーの第 2 レグの旅に少し出かけていました。このツアーは世界中から大勢の開発者が集まる、とても楽しい集会でした。ツアーの第 1 レグを行ってからの数か月の間に、Git が参加者の間でどれほど多く採用されたかを知って、実に信じられない思いでした。7 月に出席したときに、「Git を使っている人」と尋ねると、参加者のほとんど全員が手を挙げました。

しかし、毎晩がっかりする瞬間があります。それは、「職場でコード レビューをしている人」と尋ねた後です。

たいていの場合、手を挙げるのは聴衆の半分以下です。

コード レビューは私のキャリアの中で非常に有益だったので、これを聞くと悲しくなります。事実、コード レビューは、あらゆるコードベースの品質を段階的に向上させる唯一の最も効果的な方法として、他のどのプラクティスやテクノロジーよりもお勧めです。そして、DVCS に導入されたコード レビュー (プル リクエスト) は、特にすばらしいツールです。

次にあげるのは、私がそう考える理由のトップ 3 です。

より品質の高いコード

1 つ目の理由は非常に明白です。さまざまな経験レベル、さまざまな技術的専門分野、およびさまざまな視点を持つ開発者がコードについて語り合うということは、コードが顧客に届く前に、バグを発見して技術的負債を食い止められる可能性がはるかに高くなるということです。プル リクエストを使用すると、コードをメイン ブランチにマージする前にこれらの問題が発見されるため、レビュー中に発見された問題は誰にも影響を与えません。これは、コードベースと出荷する製品の品質が大きく向上することを意味します。

知識の共有

2 つ目の理由は、そこまで明確ではありません。コードをレビューする開発者は、自分たちに利益をもたらさないサービスを無料で提供しているだけではありません。彼ら自身も学習しているのです。私はジュニア開発者としてコード レビューに参加することで、ソフトウェア パターンやライブラリについて、これまで読んだどの本や出席したどのプレゼンテーションよりも多くのことを学びました。シニア開発者としては、コード レビューによって、特定のソフトウェア プロジェクトやチームに固有の知識を多く得ました。各アプリケーションには、バグのパッチ適用や機能の実装に最適な方法を形作る独自のスタック、パターン、特異性があります。コード レビューは、この情報をチーム全体に広めるのに非常に効果的です。

共同所有権

3 つ目の理由は、最も見落とされがちですが、製品の長期的な健全性にとって最も重要なものの 1 つです。あなたが開発者であれば、おそらくバグを顧客に出荷したことがあるでしょう。それは悲惨な気持ちです。トリアージ セッション中に Jira にバグ レポートがポップアップ表示され、妙に馴染みのある説明を読んで気持ちが沈み、自分が作成して出荷したコードが、顧客 (おそらく多数の顧客) に大変な問題を引き起こしていることに気付くのです。

しかし、これはあまり知られたくない秘密なのですが、開発プロセスの一環としてコード レビューを行っているのであれば、そのバグはあなたのせいではありません。少なくとも、あなただけのせいではありません。開発者の罪悪感は、次のような公式で表せます。

g (罪悪感) = 1 / n + 1

n 人の開発者がレビューを承認した場合、バグを出荷した時、あなたが感じるべき罪悪感は 1/n+1 だけです。

これはちょっとしたジョークです。しかし、より現実的に言えば、n 人の開発者がレビューを承認し、その後に元の作者が会社を辞めた場合や別のタイムゾーンで就寝中の場合などには、起きている顧客が電話や問題トラッカーで悲鳴を上げているときにかけつけてバグを修正できる開発者が n 人いることになります。

このような 3 つの主な理由から、複数のメンバーから成るあらゆる規模のチームにとってコード レビューが良い習慣であると私は考えています。これで、私がこのブログ投稿を書く主な理由にうまくつながります。私は最近、(git を使用した) コード レビューをより簡単なプロセスにするためのちょっとしたツールをリリースしました。

プル リクエストの作成で注意が必要な点の 1 つが、コードのレビュアーの人選を完璧に行うことです。迷うまでもなくはっきりしている場合もあります。小規模なチームで作業をしている場合や同じチームに長くいる場合は、あなたが行ったコードベースの変更部分に関する領域に精通しているのは誰かがわかっています。しかし、チームに入ったばかりの場合や、大勢で作業している場合、いつもの作業と異なるプロジェクトに貢献している場合は、人選は少し難しくなる可能性があります。

git-guilt の紹介

git-guilt は私が書いたちょっとしたツールで、一連のコミットによってリポジトリ内に生じた責任の移行を表示します。たとえば、前回のコミット時に責任がある作者から別の作者にどのように移ったかを調べるには、次のコマンドを実行します。

git guilt HEAD~1
Terminal — bash — 98×28 2014-07-17 18-17-48 2014-07-17 18-49-07

出力は、私の最後のコミットによって 239 行のコードが追加されたと同時に、以前は Patrick に帰属していた 2 行、Seb の 5 行、Anders の 13 行、JD の行全体が削除されたことを示しています。あなたが競争好きな性格なら、これはちょっと楽しいことですが、より現実的に言えば、出力に表示される開発者は、これらの変更を main ブランチにマージするために私が作成するプル リクエストのレビュアーとして適した候補です。

このとらえ方の裏にある理屈は、今書き直しているコードを作成した開発者はその件で何か言いたいことがあるかもしれないということです。

git-guilt という名前は、コミットとコミットの間でコードベースの責任 (つまり罪悪感) が転嫁されることを示しています。git スイートの他のコマンドと同様に、コミットや ref を引数として取ることができます。たとえば、merge-base コマンドを使ってブランチ ポイントを決定すると、フィーチャー ブランチ全体の責任を次のように表示できます。

 git guilt `git merge-base main my-feature-branch` my-feature-branch
ターミナル

あるいは、一定期間に生じた責任の変遷:

git guilt `git log --until="3 days ago" --format="%H" -n 1
ターミナル

インストール

git-guilt は npm モジュールとしてパッケージ化されているので、試してみたい場合には、簡単にインストールできます。

  • Git、Node.js、および npm がインストールされていることを確認します
  • npm install-g git-guilt を実行します (sudo が必要な場合があります)
  • 任意の git リポジトリで git-guilt HEAD~1 を実行して、最新のコミットの責任デルタを確認します。また post-commit フックとして簡単にインストールすることもできます。すると、ローカルで新しいコミットを作成するときにライブで移行する様子を表示できます。次のコマンドを.git/hooks/post-commit にエコーするだけです。
#!/bin/sh git guilt HEAD~1

そして、ファイルが実行可能かどうか確認してください。

chmod a+x .git/hooks/post-commit

次にコミットした時に、責任がどう移行したかを示す git-guilt の出力が表示されます。

fix it profile

ソースは Bitbucket で公開されているので、自由に閲覧や貢献ができます。

Bitbucket Server のファンですか。

これが便利だと感じ、Git ホスティングに Bitbucket Server を使用している方は、しばらく前に私が ShipIT コンペティション用に構築した無料の Bitbucket Server Reviewer Suggester アドオンも活用できるでしょう。このアドオンは、レビュアーを提案するために同様のアルゴリズムを実装し (いくつかの便利な機能付き)、Bitbucket Server プル リクエスト作成 UI にうまく統合されています。

後記 私は真剣です

もしあなたがコード レビューを実践していない 50% の開発者の 1 人なら、今日から始めましょう。決して後悔しないでしょう。このブログ投稿を読むよりも短い時間で、バグを発見して (多くの顧客に大変な思いをさせずに済むようにして)、さらにコードベースに関するさまざまな新しいことを学ぶことができるでしょう。:)

Git を学習する準備はできていますか?

この対話式チュートリアルを利用しましょう。

今すぐ始める