18th
前回の続き。
前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。
で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えておくことができる。そのようにすると、blameっぽいけど地層の底の方を見通すことができるコマンドというものが作成できる。
たとえばこういう出力が得られます:
いかにも更新頻度の高そうな行がどのへんかがちゃんと可視化されているのが分かりますね。
で、これだけでも結構興味深くて、たとえばeval.cで結局どこが一番ホットな箇所だったかといえばすばりここということがわかって、これはとても納得感が高い。つまり、作ってる我々からしてみても「ここは大変だった」と思える箇所なわけで、けっこうな妥当性があるんじゃないかと思いますね。なのでこれはこれで便利に使えるツールに仕上がるのではないかという気がする。
ただまあ、やっぱ図にしてみたいですよね。前回同様に。で、やってみるとこうなる。明るいほど高頻度の編集です
これ、ぱっと見で画像が暗いと感じると思うのですが、ヒストグラムがひじょうに興味深くて、全体の50パーセンタイルが一回しか更新されてないのですよ。二回以下だと76パーセンタイル。まあこれだけで絵づらは決まったようなもんです。
なので実はrubyの実装においては実は、だいたい半分はいっぱつ書きで動いてるといえる。もちろん、コメントとかも含んでるから、実際はもう少し精査しないといけないだろうけれど、それでもかなり予想より多いですね。びっくりです。
逆に言うと、八回以上も編集してる箇所が1パーセンタイル弱くらいあるわけですけども、これはあやしいー。明らかに他と傾向が違うので、こういった部分では何かまずいことが起きていたのではないか? ということが推察されるわけです。たとえば上でも例にあげたeval.cの一番熱かった部分などは、これは二転三転した部分でとても困難だった。他にもそういう所があったのではないか? と思われるわけです。これを利用することで、更新頻度からのバグ探しといったことも可能ではないかと思わせますね。
