バグの巣を見つける

はじめに

バグは同じところからよく発生しやすいとされています。
その原因としては

• 複雑なドメインを扱っている
• 設計に問題がある
• 変更が多い

などが考えられます。

コードベースに対してバグが多く発生している部分を観察することにより、当該箇所へのテストを強化したり、設計を見直すきっかけにすることができるでしょう。

前提

• Gitでバージョン管理をしていること
• バグ修正のコミットにfixというprefixをつけていること

どうするの

以下のコマンドを叩きます。

$ git log --grep="fix" --pretty=format: --name-only | sort | uniq -c | sort -r

実行結果のサンプル

15 src/components/MyComponent.vue
10 src/utils/helper.js
 5 src/index.js

この出力は、src/components/MyComponent.vueというファイルが15回、src/utils/helper.js が10回、src/index.jsが5回、fixという言葉を含むコミットで変更されたことを示しています。

なにをやったの？

このコマンドは、Gitリポジトリでコミットメッセージに "fix" が含まれるコミットに関連するファイルの変更を集計し、それらのファイルがどの程度頻繁に変更されたかを表示しています。

以下にコマンドを分解して説明します。

1. git log: Gitリポジトリのコミット履歴を表示するコマンドです。
2. -grep="fix":コミットメッセージに fixという文字列が含まれるコミットをフィルタリングするためのオプションです。
3. -pretty=format:: コミット情報のフォーマットを指定します。ここでは空のフォーマットを指定しているので、コミットのハッシュや作者などの情報は出力されず、ファイル名のみが出力されます。
4. -name-only: 変更されたファイルの名前のみを出力するためのオプションです。
5. | (パイプ): 一つのコマンドの出力を次のコマンドの入力として渡します。
6. sort: 出力されたファイル名をソートし、uniq コマンドが正しく集計できるようにします。
7. uniq -c: ソートされたリストで連続する重複行（同じファイル名）を集計し、それぞれの行がいくつあったかを表示します。
8. sort -r: 数字を基にして降順にソートします。つまり、最も多く変更されたファイルがリストの最上部に来るようにします。

実行すると、fixという単語を含むコミットメッセージが関連付けられたファイルが、変更された回数に応じて表示されます。

今後やりたいこと

• 結果をtreemapなどグラフ表示にする
• ファイル単位ではなくmodule, functionなどの単位で集計する
• ファイル名変更やリファクタリングを追跡する