C＃開発者は1か月に何行のコードを生成できますか？[閉まっている]

私の職場の幹部が私と私の開発者グループに質問をしました。

C＃開発者は1か月に何行のコードを生成できますか？

古いシステムをC＃に移植する予定でしたが、プロジェクトの計画の一環としてこの方法を望んでいます。

ある（明らかに信用できる）情報源から、彼は「10 SLOC / 月」と答えましたが、彼はそれに満足していませんでした。

グループは、状況の長いリストに依存するため、これを指定することはほとんど不可能であることに同意しました。しかし、私たちは彼にもっと合った答えを考え出さなければ、その男性は去らない（または私たちに非常に失望しない）と言うことができました。そこで彼は「10 SLOC / 日」という何倍も良い答えを残しました

この質問に答えられますか？（オフハンドまたは何らかの分析を含む）

弁護士に1か月あたり何ページの契約書を書くことができるかを上司に尋ねてください。それから（願わくば）彼は、単一ページのコントラクトを書くことと抜け穴や矛盾のない300ページのコントラクトを書くことの間に大きな違いがあることに気付くでしょう。または、新しい契約を作成してから既存の契約を変更するまで。または、新しい契約を書いてから別の言語に翻訳するまで。または別の法律制度に。「単位時間あたりの契約のページ数」は弁護士の生産性にとってあまり良い尺度ではないことにも同意するでしょう。

しかし、あなたに与えるためにいくつかのあなたの本当の質問への答えを：私の経験では、昼と開発者あたり数百のSLOCは珍しくありません新しいプロジェクトのために。しかし、最初のバグが現れるとすぐに、この数は急激に減少します。

C＃開発者は1か月に何行のコードを生成できますか？

良ければ、ゼロ未満です。

別の方法で実行...今。

LoCは、使用できる最悪のメトリックの1つです。

悪い開発者は、良い開発者よりも1日に多くのLoCを書く可能性がありますが、ゴミのコードを大量に排出します。

コードの複雑さにもよりますが、移植は自動化プロセスによって行われ、1日に数千件以上のLoCの変更が​​発生しますが、言語構成が大きく異なるコードであるより難しいセクションは1日100LoCに移植されます。

SLOCのWikipediaページを読むために彼を送ってください。なぜそれがそのような貧弱なメトリックであるかのいくつかの素晴らしい簡単な例を与えます。

正解：いいえ...

この幹部は、SLOCが分析の進捗状況の有効な指標ではないことを教育する必要があります

ずさんな答え：あなたが作ることができる任意の番号。

彼にいくつかの番号を与えるだけで、あなたとあなたのチームは簡単にその番号を作ることができます。（ライン、空のライン、コメントなどを除いて、この男が彼のファンタジーの世界に生き続け、さらに別のチームに出没し、thedailywtfに物語を作る悲惨な強化されたサイクルを続けることを許可することによって。

良くないが、できる。

一見したところ、この質問は絶対に馬鹿げているように見え、ここの全員が馬鹿げたC＃LoCの部分だけに答えました。ただし、重要なニュアンスが1つあります。これは、移植のパフォーマンスに関する問題です。この質問をする正しい方法は、特定の時間単位内で開発者が処理できるソースプロジェクト（移植されるコード）のコードの行数を尋ねることです。これは完全に正当化された質問です。コードの行数の合計がわかっているため、実行する作業量そのものです。そして、この質問に答える正しい方法は、少しの履歴データを収集することです。たとえば、1週間働き、各開発者のパフォーマンスを測定します。

言いたいことが一つだけあります。

「コードの行でプログラミングの進行状況を測定することは、航空機の建物の進行状況を重量で測定するようなものです。」

- ビルゲイツ

その後、あなたはビル・ゲイツが成功したソフトウェアを作る方法を知らなかったと主張するかもしれません;）

注：ただし、SLOCはコードベースの複雑さの非常に良い尺度です！

I 
can
write
large
numbers
of
lines
of
code
per
month.

実際、単語の数に比例します。

私のポイントがわかりますか？

私はこれについて少し異なるスタンスを持っているかもしれませんが、プロジェクトの計画を現在行っている場合、エグゼクティブがこの情報を探していた理由を理解できると思います。プロジェクトの所要時間を見積もることは困難であるため、使用される方法の1つ（「ソフトウェアの推定：ブラックアートの謎解き」を参照）は、プロジェクトの所要時間に基づいてプロジェクトの所要時間を見積もることです。同様のプロジェクトのSLOCは、現在、開発者が平均して作成する可能性があります。実際には、これは、同じまたは類似の開発者との類似プロジェクトのためにグループが手元に持っている履歴レコードを使用して行われることを意図しています。

ただし、これらの見積もりはプロジェクトの基本的な計画のためだけのものであり、プロジェクトの開発者のペースを実際に設定することを意図したものではありません。したがって、SLOCを推定ツールとして使用して読んだことのほとんどは、すでに十分な知識を持っている場合は長期的には良好ですが、日常的に使用するにはお粗末なことです。

一般的に、上司を馬鹿と呼ぶのは悪い考えです。そのため、私の提案は、メトリックを拒否するのではなく、メトリックを理解して議論することから始めます。

実際に馬鹿と見なされていない人の中には、コード行に基づいたメトリックを使用している人もいます。フレッド・ブルックス、バリー・ベーム、ケーパーズ・ジョーンズ、ワッツ・ハンフリーズ、マイケル・フェイガン、スティーブ・マコーネルはすべてそれらを使用しました。おそらく同僚に言っても、この神のモジュールは4000行であり、より小さなクラスに分割する必要がある場合でも、おそらくそれらを使用しているでしょう。

私たちの多くが尊敬する情報源から、この質問に関連する特定のデータがあります。

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

プログラマー1時間あたりのコード行の最適な使用方法は、プロジェクトの存続期間中にこの値がかなり高くなることを示すことだと思いますが、欠陥が見つかって修正されると、問題を解決するために新しいコード行が追加されます元の推定値の一部ではなかったため、重複を排除して効率を向上させるためにコード行を削除すると、LOC / hrが生産性以外のものを示していることがわかります。

• コードが高速で、ずさんで、肥大化しており、リファクタリングを試みない場合、見かけの効率は最高になります。ここでの教訓は、測定するものに注意する必要があるということです。
• 特定の開発者にとって、今週大量のコードを追加または変更する場合、来週、コードのレビュー、テスト、デバッグ、および再作業に関して技術的な負債が発生する可能性があります。
• 一部の開発者は、他の開発者よりも一貫した出力レートで作業します。優れたユーザーストーリーの取得に最も多くの時間を費やし、非常に迅速に対応して単体テストを行い、その後ユーザーストーリーのみに焦点を当てたコードをすばやく対応して作成していることがわかります。ここで重要なことは、コードを開始する前に問題と解決策を十分に理解しているため、整然とした開発者はおそらくすぐに好転し、コンパクトなコードを記述し、手戻りが少ないことです。コーディングの前と後ではなく、考え抜いた後にだけコーディングするので、コーディングを減らすことは理にかなっています。
• コードの欠陥密度を評価すると、コードは均一ではないことがわかります。一部のコードは、ほとんどのトラブルと欠陥を説明します。書き換えの候補になります。それが起こると、それが最も手間のかかるコードになるのは、そのおかげで高度な手直しが必要だからです。CVSやSVNなどのツールから報告される可能性のある、追加、削除、変更されたコードカウントの総グロス行は最も高くなりますが、投資されたコードの1時間あたりのネット行は最も低くなります。これは、最も複雑な問題または最も複雑なソリューションを実装するコードの組み合わせになる可能性があります。

コードの行におけるプログラマの生産性をめぐる議論がどのようになったとしても、余裕がある以上の人的資源が必要であり、システムが間に合わないことは決してありません。実際のツールはメトリックではありません。それらは、優れた方法論、採用またはトレーニングできる最高の開発者の使用、および範囲とリスクの制御（おそらくアジャイルの方法による）です。

彼に働きかけるためのより良い指標を与える

代わりのLOC、これは説明を使用して、最悪のメトリック。次に、彼に代替を与えます。

関数の番号は/機能ごとの特徴/機能要望- > NOFF / RFF

1週間あたりのリクエスト量に対応するために、NOFF / RFFの上に重み付け/正規化を追加する必要がある場合があります。

:)明らかに上記は構成されていますが、何でも、SLOCよりも優れています...

大きなプロジェクトの多くの請負業者が1年に15000 LOC（各）を書いたと言えます。これは非常に大まかな答えですが、既存のC ++ LoCが40万あるため、すべてをC＃に変換すると完了するのに約26人年かかることがわかりました。ギブオアテイク。

大まかな順序がわかったので、より適切に計画を立てることができます。20人の開発者を獲得し、彼らの1年の作業を見積もることはすべて適切です。数える前に、移行にどれくらいの時間がかかるかはわかりませんでした。

だから、あなたへの私のアドバイスは、あなたが書いたすべてのコードを特定の時間内にチェックアウトすることです（私は幸運にも新しいプロジェクトを扱うことができました）、そして多くのコードメトリックツールの1つを実行します。時間で数値を除算すると、彼に正確な答えを与えることができます- あなたが実際に 1日にどれくらいのLOC を書くか。私たちにとって、それは1日あたり90 LOCで発生しました！私たちはそのプロジェクトに関して多くの会議や文書を作成したと思いますが、次の会議でも多くの会議と文書を作成するでしょう:)

ほぼ正しいように聞こえます。

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

デバッグ、ドキュメント、計画などを考慮すると、平均して1日あたり約10行のコードになります。実際、私はハイサイドで1日10行を評価します（つまり、非常に生産的な開発者）。

1日で数百行を解約できますが（これは持続可能ではありません）。ユニットテストですべてのドキュメントを追加し、もちろんユニットテストでエラーが表示された後にコードをデバッグするまで、品質の高いコードではありません。すべて完了したら、10に戻ります。

私の推測では、C＃のような言語を使用する開発者は、1日あたり約10K LoCを記述/生成できるはずです。できると思う。私は決してしません。

開発者に求めているのは、1日10 LoCで仕事を成し遂げることです。コードは少ないほど良いです。多くの場合、大量のコードの作成を開始してから、シンプルさの極限に達するまで切り捨てます。そのため、実際には負のLoCを使用する日があります。

ある意味では、コーディングは詩のようなものです。問題は、詩人が何行書くことができるかではなく、ソネットの14行でどれだけ伝えることができるかです。

マネージャーに処理させるか、就職活動を始めてください。

真剣に、あなたはそれを費やして、プロジェクトの完了までの進捗を測定する適切で不適切な方法を経営陣に説明する上で絶望的な努力になる可能性があります。しかし、現実には、エンジニアリングマネージャーとプロジェクトマネージャーの目的は何ですか。

一方では、状況はエグゼクティブ・イン・質問がようなものであるISあなたのエンジニアリングおよび/またはプロジェクトマネージャー。まだ明らかになっていない場合でも、対処するべきはるかに大きく基本的な問題があります。この場合、このような問題は、今後発生するより大きな問題の「警告ショット」として機能します。

他の答えは正解です。それは馬鹿げた質問であり、答えはいまいましいことを意味するものではありません。それはすべて真実ですが、約1か月で何行のコードを生成したかを知りました。

XML-docなしの約3000行のC＃コードです。私は新しい機能を実装していて、1か月または1か月と1週間でこの金額になりました。ソース管理に終わったのはそれだけです。多くのコードが作成され、リファクタリングまたは削除されました。

私はC＃開発者であり、それを上手にしようとしていますが、私がどれほど客観的に優れているかを伝えることはできません。良いコードを書き、それを維持しやすくするために多くの努力をしました。このコードには1回か2回だけコメントを入れます。

コードの行数が多すぎるか少なすぎるかはわかりません。本当に気にしないと言わざるを得ません。これは無意味なデータであり、外挿に安全に使用することはできません。しかし、私はたまたまこのデータを知っているので、共有することにしました。

まあ、私はいつものようにこのパーティーに少し遅れていますが、これは実際に興味深いものです。私は当初、経営者の質問は無難であるとほとんど同じ考えを持っていました。しかし、私はSK-logicの答えを読んで、それが無意味な方法で尋ねられた賢明な質問であることに気付いた。または、別の言い方をすれば、質問の背後にある有効な問題があります。

多くの場合、マネージャーはプロジェクトの実現可能性、資金、人員配置などを決定する必要があります。これは賢明な問題です。ストレートフォードポートの場合、ポートのコード行を開発者ごとの1日あたりの推定平均コード行で割った推定値は単純に魅力的ですが、このページに記載されているすべての理由で失敗する運命にあります。

より賢明なアプローチは次のとおりです。-

1. 現場での見積もりについては、コードの経験が最も豊富な開発者に、どのくらいの時間がかかるかを直感的に見積もってください。これは多くの理由で間違っていると思われますが、ここでは説明しませんが、最初からできることが最善です。少なくとも彼らは、追加のリソースがあったとしても、それが1週間で簡単にできるのか、それとも数年後にできるのかを知っている必要があります。似たようなサイズのポートや作業が完了している場合は、これをガイドとして使用できます。
2. コンポーネントごとにポートを見積もって、全体のサイジングを取得します。インフラストラクチャ（マシン、ビルドシステムなど）のセットアップ、ソフトウェアの調査と購入など、ポートに直接関連しないタスクを含める必要があります。
3. ポートの最もリスクの高いコンポーネントを特定し、最初にそれらから始めます。これらは推定値を最も大きく損なう可能性が高いため、可能であれば、ポートの後半で限られたサプライズが発生するように事前に行う必要があります。
4. ポートの予想継続時間を継続的に計算するために、ステップ2で行われたサイジングに対する進捗を追跡します。プロジェクトが進むにつれて、これはより正確になるはずです。もちろん、移植されたコードの行数（現在の移植されたコードにある元のコードベースの機能）もメトリックとして使用でき、実際には、元の製品が移植されるのではなく、実際の移植に取り組むことなく、数多くのクールな新機能が追加されます。

これらは必要最低限​​の手順です。もちろん、移植ツールとプラガブルフレームワークの調査、プロトタイプの作成、移植が本当に必要なものの決定、テストツールとインフラストラクチャの再利用など、役立つこの他の多くのアクティビティがあります。