「神話のマン月」の「開発者 1 人あたり 1 日 10 行」を超えることができると誰もがいつも言いますが、プロジェクトを開始すると、通常は 1 日で数百行を取得できます。
しかし、私の前の雇用主では、すべての開発者が非常に頭が良かったのですが、それは大規模なプロジェクトであり、100 万行を超えるコードがあり、非常に厄介な認定要件があり、他の数百万行のプロジェクトと連携していました。ある時点で、好奇心の練習として、私のグループの出荷製品のコード行をプロットしました (私たちが開発したツールは数えません)。変更、テスト コード、または開発者が実際のプロジェクト コードに毎日取り組んでいないという事実はカウントされません。
他の人はどうしてる？そして、あなたはどのような要件に直面していますか（私はそれが要因だと思います）?
現在のプロジェクトの1つで、一部のモジュールでは、コードベースに負の行数を提供できたことを誇りに思います。コードのどの領域が不必要に複雑になり、よりクリーンで明確な設計で単純化できるかを特定することは、有用なスキルです。
もちろん、一部の問題は本質的に複雑で、複雑なソリューションが必要ですが、要件が十分に定義されていない、または変更されているほとんどの大規模なプロジェクト領域では、ラインあたりの問題数が多い過度に複雑なソリューションになる傾向があります。
解決すべき問題を考えると、私は行数を減らす解決策を非常に好みます。もちろん、小さなプロジェクトの開始時には、1日に10行を超えるコードを生成できますが、作成したコードの量は考えず、コードが何を実行し、どれだけうまく機能するかだけを考える傾向があります。私は確かに1日あたり10行を超えることを目指したり、そうすることを達成したとは考えていません。
私はこの引用が好きです：
コードの行数を数えたい場合は、それらを「生成された行」ではなく、「消費された行」と見なすべきです。- エドガー・ダイクストラ
コードを追加するよりも削除することで、より多くの貢献をしたことがあります
追加される行数はプロジェクトの状態に大きく依存すると思います。新しいプロジェクトに追加する割合は、開始するプロジェクトの割合よりもはるかに高くなります。
作業は2つで異なります。大規模なプロジェクトでは、通常、パーツ間の関係を理解するためにほとんどの時間を費やし、実際に変更/追加するのはごくわずかです。一方、新しいプロジェクトでは、ほとんどの場合、それが十分に大きくなり、レートが低下するまで書き込みます。
このメトリックの使用を停止する必要があります。ほとんどの場合、意味がありません。結束、結合、複雑さは、コード行よりも重要な指標です。
他の人はどうしてる？
私は会社で唯一のフルタイムの開発者であり、過去 7 年間で 500,000 行の OCaml および F# コードを作成しました。これは、1 日あたり約 200 行のコードに相当します。ただし、そのコードの大部分は、それぞれ数百行の長さの数百の個別のプロジェクトで構成されるチュートリアルの例です。また、OCaml と F# の間には多くの重複があります。私たちは、50kLOC を超える社内コード ベースを維持していません。
独自のソフトウェアの開発と保守に加えて、過去 7 年間、業界の多くのクライアントのコンサルティングも行ってきました。最初のクライアントの場合、3 か月間で 2,000 行の OCaml を書きました。これは 1 日あたり 20 行のコードです。次のクライアントでは、私たち 4 人が、数百万行の C/C++/Python/Java/OCaml コードとドキュメントを生成するコンパイラを作成しました。別のクライアントの場合、6 か月で C++ の 50kLOC を F# の 6kLOC に置き換えました。これは、1 日あたり -352 行のコードです。さらに別のクライアントのために、F# で OCaml の 15kLOC を書き直しています。これは同じサイズになるため、1 日あたりのコード行数は 0 行になります。
現在のクライアントの場合、1,600,000 行の C++ および Mathematica コードを 1 年で ~160kLOC の F# に置き換えます (特注のコンパイラを作成することにより)。これは、1 日あたり約 6,000 行のコードになります。これは、これまでで最も成功したプロジェクトであり、クライアントは継続的なコストで年間数百万ドルを節約できます. 誰もが 1 日あたり -6,000 行のコードを書くことを目指すべきだと思います。
私の「TheMythicalMan-Month」のコピーを実際にチェックすることなく（これを読んでいる人は誰でもすぐに利用できるはずです）、ブルックスが書かれた行で生産性を調べた章がありました。彼にとって興味深い点は、実際に1日に書き込まれる行数ではなく、アセンブラーとPL / Iでほぼ同じように見えたという事実です（これは、使用されている高級言語だったと思います）。
ブルックスは、ある種の恣意的な生産性の数値を捨てようとしていませんでしたが、彼は実際のプロジェクトのデータから作業していました。
彼は、生産性は変動すると予想される可能性があることを指摘しました。彼は、コンパイラーはアプリケーションプログラムの3倍、オペレーティングシステムはコンパイラーの3倍難しいと述べました。（彼は、カテゴリーを分けるために3つの乗数を使用するのが好きだったようです。）
彼がプログラマーの生産性の個人差を評価したかどうかはわかりませんが（桁違いの議論では、彼は7倍の差を仮定しました）、私たちが知っているように、優れた生産性は単にもっと書くことの問題ではありませんコードだけでなく、仕事をするための正しいコードを書くこともできます。
環境の問題もあります。Brooksは、開発者を速くしたり遅くしたりする理由について少し推測しました。多くの人と同じように、彼は現在の流行（タイムシェアリングシステムを使用したインタラクティブなデバッグ）が古い方法（マシン全体を使用した2時間のショットの慎重な事前計画）よりも優れているかどうかを疑問視しました。
それを考えると、私は彼が思いついた実際の生産性の数値を役に立たないものとして無視します。この本の継続的な価値は、人々が学ばないことに固執する原則とより一般的な教訓にあります。（ねえ、もし誰もがそれらを学んだとしたら、この本は歴史的な興味だけになります。潜在意識のようなものがあるというフロイトのすべての議論のように。）
1 日に数百行のコードを取得するのは簡単です。しかし、1 日に数百行の高品質のコードを取得しようとすると、それほど簡単ではありません。その上、デバッグを行い、1 日あたりの新しい行がほとんどまたはまったくない日を過ごすと、平均はすぐに下がります。困難な問題のデバッグに何週間も費やしましたが、その答えは 1 ～ 2 行のコードでした。
コードの物理的な行について話すことはまったく無意味であることを認識したほうがよいでしょう。コードの物理的な行数 (LoC) はコーディング スタイルに大きく依存するため、開発者によって桁違いに異なる場合があります。
.NET の世界では、LoC をカウントする便利な方法があります。シーケンス ポイント。シーケンスポイントはデバッグの単位で、ブレークポイントを入れる際に濃い赤でハイライトされたコード部分です。シーケンス ポイントを使用すると、論理 LoCについて話すことができ、このメトリックをさまざまな .NET 言語間で比較できます。論理 LoC コード メトリックは、VisualStudio コード メトリック、NDepend または NCover を含むほとんどの .NET ツールでサポートされています。
たとえば、8 LoC メソッドは次のとおりです (開始および終了ブラケット シーケンス ポイントは考慮されません)。
LoC の生産は、長期的にカウントする必要があります。200 以上の LoC を吐き出す日もあれば、LoC を 1 つも追加しないで 8 時間かけてバグを修正する日もあります。デッド コードをクリーンアップして LoC を削除する日もあれば、既存のコードのリファクタリングにすべての時間を費やし、新しい LoC を合計に追加しない日もあります。
個人的には、次の場合にのみ、自分の生産性スコアで 1 つの LoC をカウントします。
この状態で、.NET 開発者向けの NDepend ツールをコーディングした過去 5 年間の私の個人的なスコアは、コードの品質を決して犠牲にすることなく、1 日あたり平均 80 の物理 LoC です。リズムは維持されており、すぐに減少する様子はありません。全体として、NDepend は現在約 115K の物理的 LoC の重みをもつ C# コード ベースです。
LoC をカウントするのが嫌いな人 (ここのコメントでその多くを見ました) のために、いったん適切に調整されれば、LoC をカウントすることは優れた推定ツールであることを証明します。開発の特定のコンテキストで達成された数十の機能をコーディングして測定した後、LoC の TODO 機能のサイズと、それを本番環境に提供するのにかかる時間を正確に見積もることができるようになりました。
銀の弾丸のようなものはありません。
そのような単一のメトリックは、それ自体では役に立ちません。
たとえば、私は自分のクラスライブラリを持っています。現在、次の統計が当てはまります。
合計行数：252.682
コード行数：127.323
コメント：99.538
空行数：25.821
コメントをまったく記述しない、つまり127.323行のコードを記述しないと仮定します。あなたの比率で、そのコードライブラリは私が書くのに約10610日かかるでしょう。それは29年です。
私は確かにそのコードを書くのに29年も費やしませんでした。なぜなら、それはすべてC＃であり、C＃はそれほど長くはないからです。
さて、あなたはコードがそれほど良くないと主張することができます、なぜなら明らかに私はあなたの1日12行を超えたに違いないので、そうです、私はそれに同意します、しかし私がタイムラインを1.0がリリースされたとき（そして2.0がリリースされるまで実際に作成を開始しなかった）、2002-02-13、約2600日、平均は1日あたり48行のコードです。
これらのコード行はすべて適切ですか？嫌です。しかし、1日に12行のコードになりますか？
嫌です。
すべてが異なります。
一流のプログラマーが1日に数千行のオーダーでコードを作成し、中規模のプログラマーが1日に数百行のオーダーでコードを作成することができます。品質は同じです。
そして、はい、バグがあります。
あなたが望む合計はバランスです。変更されたコードの量、検出されたバグの数、コードの複雑さ、それらのバグを修正することの難しさ。
Steve McConnell は、著書「Software Estimation」(p62 表 5.2) で興味深い統計を示しています。彼は、プロジェクトの種類 (アビオニクス、ビジネス、電話会社など) とプロジェクト サイズを 10 kLOC、100 kLOC、250 kLOC と区別しています。番号は、LOC/StaffMonth の組み合わせごとに与えられます。EG アビオニック: 200、50、40 イントラネット システム (内部): 4000、800、600 組み込みシステム: 300、70、60
つまり、たとえば。Avionic 250-kLOC プロジェクトの場合、40 (LOC/月) / 22 (日/月) == <2LOC/日!
これは、プロジェクトの実際の開発フェーズがプロジェクト時間全体の 20 ～ 30% 程度である、ウォーターフォール開発の日々から来ていると思います。コードの合計行数をプロジェクト時間全体で割ると、1 日あたり約 10 行になります。コーディング期間だけで割ると、人々が引用しているものに近づくことができます.
私たちのコードベースは約 2.2MLoC で、約 150 人年を費やしています。つまり、プロジェクトの全期間にわたって、開発者 1 人あたり 1 日あたり約75行の C++ または C# になります。
これには、プロジェクトの規模と関与する開発者の数が大きな要因だと思います。私は自分のキャリアでこれをはるかに上回っていますが、ずっと一人で働いてきたので、他のプログラマーと一緒に仕事をしても損はありません。
優れた計画、優れた設計、優れたプログラマー。これらすべてをまとめれば、1 行を書くのに 30 分も費やすことはありません。はい、すべてのプロジェクトでは、停止して計画し、考え直し、議論し、テストし、デバッグする必要がありますが、1日2行で、すべての企業がテトリスを機能させるために軍隊が必要になります...
要するに、もしあなたが私のために 1 時間に 2 行で働いていたなら、クビにならないように、コーヒーをたくさん飲んで足をマッサージしてもらったほうがいいでしょう。
すべてが C で記述された sys アプリであったときに、この永続的なマネージャー キャンディーが造られたのではないかと疑っています。そして、コメントと属性を割引する必要があります。そして最終的に、書かれたコードの行数を誰が気にしますか? 10,000 行に達したときに終了することになっていますか? 100K? とても恣意的です。
無駄だ。