@ledsun blog

Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

コミット数はよいKPIか?

自分はコミット数をとあるプロジェクトのKPIとして使っています。 KPIというか「週次で50切るとヤバいな」みたいな感覚で見ています。 なぜコミット数を重要と感じているのか考えてみました。

コードを書くとコーディング能力が上がる

コミット数を増やすにはコードを書かないと始まりません。 どっから手をつけたらよくわからない段階でも、まず手をつけてみることが重要です。 手をつけてみたら意外と簡単なこともあります。

また、コーディング能力はコードを書くことであがります。 読んで上がる人も居るのかもしれないが、自分のはまだ書いた方がコーディング能力が上がる段階のようです。 書く経験が増えると読むのも速くなるのは感じます。

ここでコーディング能力が上がると言っている物が指しているのは、例えば。 新しい機能やライブラリにチャレンジするときに、 小さい単位で試す引き出しが増えます。 試して体験して理解を深めるサイクルが小さく回せるようになります。

プログラマとしてご飯を食べていく上でコーディング能力の向上は欠かせません。

ソースコードになってないアイデアは過大評価される

人間はなぜか形になっていないアイデアを過大評価します。 自分のアイデアでも同じです。 アイデアだけ思いついて実装していないと、自分の中でアイデアの価値が段々大きくなっていきます。 相対的に実装していない自分の価値を低く感じるようになります。 メンタルに良くないです。 雑魚っぽいアイデアをさっと実装して雑魚であると認識するのが良いです。 弊害がなければ、そのまま入れておきますし、害が出てきたらリバートすればいいです。

小さいコミットの方が速く進める

コミット数がKPIだとコミットが小さくなります。 小さくなったらエディタから離れてコミットメッセージを書く頻度が増えるから、ソースコードを書くのが遅くなると予想できます。 実際はそうはなりません。

ひとつには間違える規模が小さくなるので、方向修正が速くできます。 小さいコミットは影響範囲が明確なのでリバートするのも簡単です。 デバッグするときにもバグが生まれたコミットさえ特定すれば、原因特定が早くできます。 コミットは二分探索できるのでlog nで見つかります。 コミット数が増えた方が探索時間が短くなってお得ですね。

また、小さいコミットは「コミットしていいかな?」につかう決断力が小さく出来ます。 決断力は有限のリソースです。 大きい決断は一日に何十回もできません。 小さい決断はたくさん出来ます。 コーディングに集中する時間を長く出来ます。

新しいアイデアがでる

コミットで区切らずにエディタだけ見ている方が集中して物事を進められる人も居るみたいです。 僕はそうではないようです。 適度に区切ったほうが新しいアイデアが出てきます。

あるアイデアAを抱えたまま、別のアイデアBを考えることは難しいです。 ある程度時間かけてアイデアBのことを考えてコンテキストスイッチする必要があります。 10~15分、場合によっては1時間かもしれません。

1時間掛けてアイデアAを実装してしまいます。 アイデアAについて覚えておく必要は無くなるので、アイデアBに集中できます。 コンテキストスイッチの時間を使って実装出来ちゃいました。

とはいってもアイデアAの実装中に別のアイデアCが出てくることがあります。 脳みそはこういう邪心を生み出すのが得意なので、出てきます。 すぐに着手できる物であれば、すぐに実装して忘れます。 作戦を立てる必要がある物はメモを残して忘れます。