プログラマーは1日に何行コードを書ければいいのか？行数の目安を提案

2018年7月19日に投稿能力開発アフィリエイトリンクを含みます

急いで仕事をこなす人

ステップ数(コードの行数)で生産性を計るっていう方法は、昔はけっこうやられていましたが、最近は否定されています。

同じ行数でもプログラムの難易度によって生産性は異なるからです。

とはいえ目安の一つとしてステップ数を考えてみるのは良いと思うんです。

一番いいのは毎日何行書いたかを計って、今日は仕事がうまくいったなって思う日の行数を目安にすることです。

とはいえ、何行書いたかを測定するのはなかなか難しいです。

全部新規でコードを書くわけじゃないので、単純に計測できません。

なので、感覚的にこれくらいかなという目安を考えるのが現実的です。

そんなわけで、感覚的にこのくらいの行数を書ければ良いんじゃないかという目安を紹介します。

ちゃんと動くコードを一日に2000行書ければ良し

私の場合は、感覚的には一日に2000行ぐらい書いて、単体テストをパスするところまでいけたら、生産性の高い日だったと感じます。

感覚的にと言いましたが、コードの行数って「今日何行ぐらい書いたか？」ってなかなかわからないですよね、感覚的にも。

一つのソースコードにいっぱいコードを書いた時には、

「おっ、2000行も書いたかぁ。」

って感じますけど、一つのソースコードにたくさん書くのって、私の場合、バッチ処理のプログラム(夜間に動く、データ更新するようなもの)です。

WebアプリとかだとMVCで分割されてコンポーネント毎にファイルが分かれるので、一つのソースコードにたくさん書くみたいなことはないんで、行数がイメージしづらかったりします。

なので、記憶をたどるとJavaでバッチを書いた時に2000行くらいがちょうどよかったかなって感覚なんです。

コードを書くだけなら、もっと書こうと思えば書けますが、単体テストをパスする動くコードとなると2000行くらいだと思うんです。

2000行ってそこまできつくない目標なので、そういう意味でもちょうどいいかなと思います。

バグ修正する時って、「こういうバグが起きてます、直してください」と言われて「原因どこかなー」って考えながら、コードをずっと読んでいて、「ここかな、それともこっちかな」と試行錯誤して、「あ、ここだわ！」ってわかって

「3行コードを書き換えて、バグが直る」

みたいなことがあります。

1日の大半、例えば7時間ぐらいずっとコード読んでてコード直した時間はほんの5分、書いた行数3行なので、生産性低いなってことにはなりません。

その3行を書き換えるためにずっとコードを読み続けて分析する膨大な作業が必要だったわけです。

機能追加や仕様変更するときも同じです。

既存のコードを読んで、どこを変更するかを考えるのに7時間かかって、コードを書くのが10分なんてことがざらにあります。

よって、バク修正や機能追加は書いたコードの行数で生産性は計れないということです。

ということで、

のがいいんじゃないかと思います。