プログラマの生産性の公式 - 超ウィザード級ハッカーのたのしみ

n行の動くコードをコーディングするのにかかる時間をTとすると、Tはざっくり以下のようになるだろう。

T = n*(tc + tw) + n*b^2*(tc + tw + tb) + n*b^3*(tc + tw + tb) + ...
  = n*(tc + tw + tb) / (1 - b) - n * tb

ここにtｃはバグの有無を問わず１行のコードを書く時間であり、twはドキュメンテーションといったコーディング以外の作業にかかる時間であり、tbはバグを見つけるのに要する時間である；bは１行のコードを書いたときにバグを含む割合である。このとき、単位時間あたりの動くコードの生産量は、

n / T = (1 - b) / (tc + tw + b * tb)

となる。

さて、プログラマの生産性n / Tを高めるにはどうすればよいだろうか。

twを減らす
tbを減らす
bを減らす

といったことをすればよい。

tcは人による差は無視できる。タイピングの早い遅いも、生産性の絶望的な差ほどは変わらない。他の項の影響の方が大きい。統合開発環境を使う人がいたり、エディタを使う人がいるが、それで生産性に有意な差は生まれない。だからどちらかが駆逐されたりすることはなく、好みの問題になっている。エディタで差が生まれるならエディタ戦争なんて起こらない。したがって、tcはボトルネックではなく、これを減らすことは生産性にあまり寄与しないだろう。

twはドキュメンテーションといったコーディング以外の作業にかかる時間だが、ドキュメンテーションだけでなく調整といった何も生み出さない時間も含んでいる。まずは、何も生み出さない時間を減らすことが生産性の向上への道だ。「７つのムダ」をなくせとか昔は嫌いだったが、ムダをムダと分かってやるというのは精神的にきついと気づいた。

tbを減らすためには読めるコードを書くことが有効だ。ドキュメントを書く時間twを減らしてでも、tcに時間を費やして読めるコードを書いた方がいいと思っているということを

読まないドキュメントより読めるコード - 超ウィザード級ハッカーのたのしみ

で書いた。これはtbを減らすためでもある。バグってることが分かったとして、その原因を見つける作業――デバッグにはデバッガを使うとかやり方はいろいろあるが、結局は地道にやるしかない。コードが綺麗なら動きを追いかけるのが楽だから、デバッグが楽になる。だが、コードが綺麗であっても効率化には限度がある。

したがって、バグの混入の可能性bを減らすのが最も効果的だ。これが最も個人差が出ると思っている。プログラマの生産性が人によって10000倍以上とか対数スケールで変わるのは、すごい人はバグのないコードが書けるからだ。優秀な人は「動くように書いてるのだから動くに決まってる」と言ってのける。

凡人たる我々がバグのないコードを書くためには、先人が考えてきた開発手法や設計手法が有効だ。オブジェクト指向プログラミングだとかテストファーストだとかである。オブジェクト指向はプログラムを部品化して、下手に壊さないようにする手法だ。ユニットテストを書くことは、プログラムを壊すことを直接的に防ぐことができる。ドキュメンテーションは最低限にしろと言っているが、設計が要らないとは思っていない。結果としてバグの入り込にくい設計になることに寄与しないドキュメンテーションが無駄だと言っているだけだ。

読めるコードを書くことも、バグを減らす効果がある。レビューが簡単になる。また、綺麗なコードは他の人が書き換えた時に壊しにくい。何よりも書いた人の頭がクリアでないと読みやすいコードにならない。汚く正しいコードを書ける人はいない。生産性の高い人はコードもきれいだ。