神話の男の月、開発者1日あたり10行-大規模プロジェクトではどれくらい近いですか？[閉まっている]

「神話の男月間」から「1日あたり開発者1人あたり10行」に勝てると誰もがいつも言っており、プロジェクトを開始すると、通常1日に数百行を取得できます。

しかし、私の以前の雇用主では、すべての開発者は非常に鋭敏でしたが、それは非常に面倒な認証要件を持ち、他の数百万行のプロジェクトとのインターフェースを備えた、100万行を超えるコードの大規模プロジェクトでした。ある時点で、好奇心を働かせるために、グループの出荷製品にコード行をプロットしました（開発したツールはカウントしていません）。確かに、徐々に、開発者1人あたり1日あたり約12行が追加されました。変更、テストコード、または開発者が毎日実際のプロジェクトコードに取り組んでいないという事実を数えません。

他の人はどうですか？そして、あなたはどのような要件に直面していますか（私はそれが要因だと思います）？

追加される行数はプロジェクトの状態に大きく依存すると思います。新しいプロジェクトに追加する率は、開始プロジェクトの率よりもはるかに高くなります。

作業は2つで異なります。大規模なプロジェクトでは、通常、ほとんどの時間を部品間の関係の把握に費やし、実際に変更/追加するのはほんのわずかです。一方、新しいプロジェクトでは、十分に大きくなり、速度が低下するまで、ほとんどの場合、書き込みを行います。

現在のプロジェクトの1つで、いくつかのモジュールで、コードベースにマイナスの行数を提供したことを誇りに思います。コードのどの領域が不必要に複雑になり、より明確で明確な設計で簡略化できるかを特定することは、有用なスキルです。

もちろん、一部の問題は本質的に複雑であり、複雑なソリューションが必要ですが、要件が十分に定義されていないか変化しているほとんどの大規模なプロジェクト領域では、1行あたりの問題の数が多い過度に複雑なソリューションになる傾向があります。

解決すべき問題を考えると、私は行数を減らすソリューションを大いに好みます。もちろん、小規模なプロジェクトの開始時には、1日に10行を超えるコードを生成できますが、自分が書いたコードの量については考えない傾向があります。私は確かに1日あたり10ラインを打つことを目指したり、それを達成することを達成とは考えません。

私はこの引用が好きです：

コードの行を数える場合、それらを「生成された行」ではなく、「費やされた行」と見なす必要があります。-Edsger Dijkstra

追加するよりもコードを削除する方が貢献することがある

このメトリックの使用は中止してください。ほとんどの場合、意味がありません。凝集度、結合度、複雑度は、コード行よりも重要な指標です。

他の人はどうですか？

私は当社で唯一のフルタイムの開発者であり、過去7年間で500,000行のOCamlおよびF＃コードを書きました。これは、1日あたり約200行のコードに相当します。ただし、そのコードの大部分は、それぞれ数百行の長さの数百の個別のプロジェクトで構成されるチュートリアルの例です。また、OCamlとF＃の間には多くの重複があります。50kLOCを超える社内コードベースは維持していません。

独自のソフトウェアの開発と保守に加えて、過去7年間、業界の多くのクライアントのコンサルティングも行ってきました。以下のために最初のクライアント、私は一日あたりのコードの20行である3ヶ月でのOCamlの2000行を書きました。以下のために、次のクライアント、私たちの4人は、開発者ごとに一日あたりのコードの2000行である6ヶ月でのC / C ++ / Pythonの/ Javaの/ OCamlのコードだけでなく、文書のラインの生成、何百万というコンパイラを書きました。別のクライアントでは、6か月で50kLOCのC ++を6kLOCのF＃に置き換えました。これは1日あたり-352行のコードです。以下のためにさらに別のクライアント、私は一日あたりのコードの0行ので、同じサイズになりますF＃でのOCamlの15kLOCを書き換えています。

以下のために私たちの現在のクライアント、私は一日あたりのコード-6000行される（特注コンパイラを書くことで）1年にF＃の〜160kLOCとC ++とMathematicaコードの160万行を置き換えます。これは、これまでで最も成功したプロジェクトであり、継続的なコストでクライアントの年間数百万ドルを節約します。誰もが1日あたり-6,000行のコードを書くことを目指すべきだと思います。

「The Mythical Man-Month」の私のコピーを実際にチェックすることなく（これを読んでいる人は誰でも実際にすぐに入手できるはずです）、ブルックスが書かれた行ごとに生産性を調べる章がありました。彼にとって興味深い点は、1日あたりに書かれた実際の行数ではなく、アセンブラーとPL / Iでほぼ同じように見えたという事実でした（使用されていた高級言語だったと思います）。

ブルックスは生産性のある種の恣意的な数字を捨てようとしていませんでしたが、彼は実際のプロジェクトのデータから作業しており、私はすべて平均して12ライン/日だったと覚えています。

彼は生産性が変化することが期待される可能性があることを指摘しました。彼は、コンパイラはアプリケーションプログラムの3倍のハードであり、オペレーティングシステムはコンパイラの3倍のハードであると述べました。（カテゴリーを分けるために3の乗数を使用するのが好きだったようです。）

プログラマの生産性間の個人的な違いを認めたかどうかはわかりませんが（桁違いの議論では、彼は7倍の差を仮定しました）、私たちが知っているように、優れた生産性は単にもっと書くだけの問題ではありませんコードだけでなく、仕事を行うための適切なコードも作成します。

環境の問題もあります。Brooks氏は、開発者をより速くしたり遅くしたりするものについて少し推測しました。多くの人のように、現在の流行（タイムシェアリングシステムを使用したインタラクティブなデバッグ）が古い方法（マシン全体を使用した2時間のショットの慎重な事前計画）に比べて優れているかどうかを尋ねました。

それを考えると、彼が思いついた実際の生産性の数値は役に立たないものとして無視します。本の継続的な価値は、人々が学ばないことに固執する原則とより一般的な教訓にあります。（ねえ、もしみんながそれらを学んだなら、この本は、潜在意識のようなものがあるというフロイトのすべての主張のように、歴史的にのみ興味があるでしょう。）

1日に数百行のコードを取得するのは簡単です。しかし、1日に数百行のコードを取得しようとすると、それほど簡単ではありません。その上、1日あたりの新しい行がほとんどまたはまったくない状態でデバッグと日々の処理を行うと、平均はかなり速く低下します。難しい問題のデバッグに何週間も費やしてきましたが、答えは1行か2行のコードです。

コードの物理的な行の話はかなり無意味であることを理解する方がはるかに良いでしょう。物理的なコード行数（LoC）はコーディングスタイルに非常に依存しているため、開発者によって桁違いに変化する可能性があります。

.NETの世界では、LoCをカウントする便利な方法があります。シーケンスポイント。シーケンスポイントはデバッグの単位であり、ブレークポイントを配置するときに暗赤色で強調表示されるコード部分です。シーケンスポイントを使用すると、論理的なLoCについて話すことができ、このメトリックはさまざまな.NET言語間で比較できます。論理LoCコードメトリックは、VisualStudioコードメトリック、NDepend、NCoverなどのほとんどの.NETツールでサポートされています。

たとえば、次は8 LoCメソッドです（括弧の最初と最後のシーケンスポイントは考慮されません）。

LoCの生産は長期的に数える必要があります。LoCが200を超える日もあれば、LoCを1つも追加しないで8時間かけてバグを修正する日もあります。死んだコードを削除してLoCを削除する日もあれば、既存のコードをリファクタリングして、合計に新しいLoCを追加しない時間を費やす日もあります。

個人的に、私は自分の生産性スコアで単一のLoCをカウントします。

1. ユニットテストでカバーされています
2. ある種のコードコントラクトに関連付けられています（可能な場合は、すべての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）で興味深い統計を提供しています。彼は、プロジェクトタイプ（Avionic、Business、Telcoなど）とプロジェクトサイズ10 kLOC、100 kLOC、250 kLOCを区別しています。番号は、LOC / StaffMonthの各組み合わせに対して与えられます。EG Avionic：200、50、40イントラネットシステム（内部）：4000、800、600組み込みシステム：300、70、60

つまり：Avionic 250-kLOCプロジェクトの場合、40（LOC /月）/ 22（日/月）== <2LOC /日です！

これは、プロジェクトの実際の開発フェーズがプロジェクト全体の時間のわずか20〜30％になる可能性があるウォーターフォールの開発日から来ていると思います。コードの総行数を取り、プロジェクト全体の時間で除算すると、1日あたり約10行になります。コーディング期間のみで除算すると、人々が引用しているものに近づきます。

私たちのコードベースは約150人年の労力で約2.2MLoCです。これにより、プロジェクトの全期間を通じて、1日あたり開発者あたり約75行のc ++またはc＃になります。

プロジェクトの規模と関係する開発者の数がこれの大きな要因だと思います。私のキャリアはこれをはるかに上回っていますが、私はずっと一人で働いてきたので、他のプログラマーと一緒に仕事をしても何の損失もありません。

優れた計画、優れたデザイン、優れたプログラマー。あなたはそれらすべてを手に入れ、1行を書くのに30分を費やすことはありません。はい、すべてのプロジェクトで停止して計画し、熟考し、議論し、テストし、デバッグする必要がありますが、テトリスを機能させるためには1日2行ですべての会社に軍隊が必要です...

結論として、もしあなたが私のために1時間あたり2行で作業しているなら、あなたは私にたくさんのコーヒーを手に入れ、私の足をマッサージして、解雇されないようにした方がいいでしょう。

すべてがCで記述されたsysアプリであるときに、この永遠に続くmanager-candyのビットが作り出されたのではないかと疑われています。そして、コメントや属性を割り引く必要があります。そして、最終的に誰が書かれたコードの行数を気にしますか？10K行に達したときに終了するはずですか？10万？とても恣意的。

無駄だ。