C＃開発者は1か月あたり何行のコードを生成できますか？
私の職場の幹部が私と私の開発者グループに質問しました。
C＃開発者は1か月あたり何行のコードを生成できますか？
古いシステムはC＃に移植される予定でしたが、彼はこの計画をプロジェクト計画の一部として希望しています。
一部の（明らかに信用できる）情報源から、彼は "10 SLOC/month"の回答を得ましたが、彼はそれに満足していませんでした。
状況の長いリストに依存するため、これを指定することはほぼ不可能であることにグループは同意しました。しかし、私たちは彼にもっと合った答えを考え出さなければ、その男性が去らない（または私たちに非常に失望する）とは言えません。そのため、彼は "10 SLOC/day"の何倍も良い答えを残しました。
この質問に答えることはできますか？（素直に、または分析によって）
上司に、弁護士が1か月に何ページの契約を書くことができるか尋ねます。その後、（うまくいけば）1ページのコントラクトを書くことと、抜け穴や矛盾のない300ページのコントラクトを書くことには大きな違いがあることに気付くでしょう。または、新しい契約の作成と既存の契約の変更の間。または、新しい契約を作成してからそれを別の言語に翻訳するまでの間。または別の法制度に。 「単位時間あたりの契約ページ数」は弁護士の生産性にとってあまり良い指標ではないことにも同意するかもしれません。
しかし、あなたに本当の質問への回答someを提供します。私の経験では、新しいプロジェクトの場合、1日あたり数百のSLOCと開発者は珍しくありません。しかし、最初のバグが現れるとすぐに、この数は急激に減少します。
C＃開発者は1か月あたり何行のコードを生成できますか？
良い場合は、ゼロ未満です。
別の方法で実行してください...今すぐ。
LoCは、使用できる最悪のメトリックの1つです
悪い開発者は、良い開発者よりも多くのLoCを1日に書き込める可能性がありますが、ごみコードを大量に排出します。
コードの複雑さに応じて、移植は自動化プロセスによって実行でき、1日あたり数千以上のLoC変更が発生しますが、言語構成が大きく異なるコードであるより困難なセクションは、1日100LoCで移植されます。
[〜＃〜] sloc [〜＃〜]のWikipediaページを読むように彼に送信します。もしそれがなぜそんなに悪いメトリックであるのかについてのいくつかのニースで単純な例を与えるなら。
正解：いいえ...
SLOCは分析の進捗状況を示す有効な指標ではないことを、この幹部に伝える必要があります。
ずさんな答え：あなたが作ることができるどんな数でも。
彼にいくつかの番号を与えるだけで、あなたとあなたのチームはとにかくその番号を簡単に増やすことができます。 （ただし、行、空行、コメントなどを付けない限り、この男がファンタジーの世界に住み続け、さらに別のチームに付きまとわれ、thedailywtfにストーリーをもたらす悲惨な強化サイクルを続けることができます。
ニースではありませんが、実行可能です。
一見すると、この質問はまったく愚かであり、ここの誰もが愚かなC＃LoCの部分だけに答えました。しかし、重要なニュアンスが1つあります。それはportingパフォーマンスに関する質問です。この質問をする正しい方法は、開発者が特定の時間内に処理できるソースプロジェクト（移植されるコード）のコードの行数を尋ねることです。コードの総行数がわかっているため、これは完全に正当化された問題であり、実行する作業の量です。そして、この疑問に答える正しい方法は、少しの履歴データを収集することです。たとえば、1週間作業し、各開発者のパフォーマンスを測定します。
私が言えることは1つだけです。
「コードの行ごとにプログラミングの進行状況を測定することは、航空機の建造の進行状況を重量で測定することに似ています。」
- ビルゲイツ
その後、あなたはビル・ゲイツがソフトウェアを成功させる方法を知らなかったと主張するかもしれません;）
注：SLOCはコードベースの複雑さの非常に優れた尺度です！
I
can
write
large
numbers
of
lines
of
code
per
month.
実際、単語数に比例します。
あなたは私のポイントを参照してください？
上司をバカと呼ぶのは一般に悪い考えなので、私の提案は、メトリックを拒否するのではなく、理解して議論することから始まります。
実際に馬鹿者とは見なされていない一部の人々は、コード行に基づいたメトリックを使用しています。フレッド・ブルックス、バリー・ベーム、ケイパーズ・ジョーンズ、ワッツ・ハンフリーズ、マイケル・フェイガン、スティーブ・マコーネルのすべてがそれらを使用しました。同僚に言うだけでも、おそらくこれらを使用しました。このGodモジュールは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
プログラマ時間あたりのコード行の最適な使用法は、プロジェクトの存続期間を通じて、この値がかなり高くなることを示すことだと思いますが、欠陥が見つかり修正されると、新しいコード行が追加されて問題を解決しますは当初の見積もりの一部ではなく、重複を排除して効率を向上させるために削除されたコード行は、LOC/hrが生産性以外のものを示していることを示しています。
- コードが高速で、ずさんで、肥大化しており、リファクタリングを試みない場合、見かけ上の効率は最高になります。ここでの道徳は、あなたがあなたが測定するものに注意しなければならないということでしょう。
- 特定の開発者にとって、今週大量のコードを追加または変更する場合、来週、コードのレビュー、テスト、デバッグ、およびやり直しに関して技術的な負債が発生する可能性があります。
- 一部の開発者は、他の開発者よりも一貫した出力速度で作業します。彼らは、優れたユーザーストーリーを得るのに最も時間を費やし、非常に迅速に向きを変え、対応する単体テストを作成し、次に好転して、ユーザーストーリーのみに焦点を当てたコードをすばやく作成していることがわかります。ここで重要なのは、整然とした開発者はおそらくすぐに好転し、コンパクトなコードを記述し、コーディングを始める前に問題と解決策をよく理解しているため、手直しが少ないということです。コーディングの前後ではなく、考え抜かれた後にのみコーディングするので、コーディングが少なくなるのは合理的です。
- コードの欠陥密度を評価すると、均一ではないことがわかります。一部のコードは、トラブルと欠陥のほとんどを説明します。書き換えの候補になります。その場合、高度な手直しのため、最も高価なコードになります。コードカウントの総行数が最も多く（追加、削除、変更、CVSやSVNなどのツールから報告される可能性がある）、1時間あたりのコードの正味行数が最も少なくなります。これは、最も複雑な問題または最も複雑なソリューションを実装するコードの組み合わせになる可能性があります。
コード行でのプログラマーの生産性に関する議論がどのように行われるかに関係なく、あなたは余裕のあるよりも多くの人材を必要とし、システムが時間内に完成することは決してないでしょう。実際のツールは指標ではありません。これらは、優れた方法論、採用またはトレーニングできる最高の開発者、および範囲とリスクの制御（おそらくアジャイル手法を使用）の使用です。
私はこれについて少し異なるスタンスを持っているかもしれませんが、彼らが現在プロジェクト計画を行っているなら、幹部がなぜこの情報を探していたのか理解できると思います。プロジェクトにかかる時間を見積もるのは難しいため、使用される方法の1つ（参照： Software Estimation：Demystifying the Black Art ）は、プロジェクトにかかる時間を見積もることです。同様のプロジェクトのSLOCの数に基づいて、現在は開発者が平均して生成する可能性があります。実際には、これは、同じまたは類似の開発者がいる類似のプロジェクトについて、グループが手元にある履歴レコードを使用して行われることを意図しています。
ただし、これらの見積もりは基本的なプロジェクト計画のみを目的としており、状況は日々変化するため、実際にはプロジェクトの開発者のペースを設定することを意図していないことには意味がありません。したがって、SLOCを概算ツールとして使用して読んだほとんどのことは、SLOCがすでに十分な知識を持っている場合は長期的には優れているが、日常の使用には粗末であるということです。
大規模なプロジェクトの多くの請負業者が、1年間に15,000 LOC（それぞれ）を書き込んだことを私は言うことができます。これは信じられないほどおおざっぱな答えですが、40万の既存のC++ LoCがあり、それをすべてC＃に変換すると完了するまでに約26人年かかることがわかりました。ギブオアテイク。
これで、大まかな順序がわかったので、より良い計画を立てることができます。20人の開発者を獲得し、それらすべての1年の作業を見積もることはほぼ適切です。数える前に、移行にかかる時間はわかりませんでした。
したがって、あなたへの私のアドバイスは、あなたが書いたすべてのコードを特定の時間内にチェックアウトし（私は新しいプロジェクトで作業することができて幸運でした）、その上で多くのコードメトリックツールの1つを実行することです。時間で数値を割ると、彼に正確な答えを与えることができます-LOC 実際に書く 1日あたりの量。私たちにとっては、1日あたり90 LOCでした！そのプロジェクトについてはたくさんのミーティングとドキュメントがあったと思いますが、次のプロジェクトについてもたくさんのミーティングとドキュメントがあると思います:)
操作するためのより良いメトリックを彼に与える
[〜＃〜] loc [〜＃〜]の代わりに、これがthe使用する最悪のメトリックであることを説明します。次に、彼に代替を与えます：
機能/機能の数Per機能/機能リクエスト-> NOFF/RFF
1週間あたりのリクエスト数に対応するために、NOFF/RFFに加重/正規化を追加する必要がある場合があります。
:)上記は明らかに構成されていますが、SLOCよりも優れています...
正しいように聞こえます。
デバッグ、ドキュメント、計画などを考慮すると、平均して1日あたり約10行のコードになります。実際、私はハイサイドで1日10行を評価します（つまり、非常に生産的な開発者）。
1日で数百行を解約できます（これは持続可能ではありません）。すべてのユニットテストのドキュメントを追加し、ユニットテストでエラーが表示された後にコードをデバッグするまで、高品質のコードにはなりません。すべてが完了した後、10に戻ります。
他の答えは正しいです、それは馬鹿げた質問であり、答えはいまいましいことを意味しません。それはすべて本当ですが、たまたま、約1か月で何行のコードを生成したか知っています。
XML-docなしの約3000行のC＃コードです。私は新しい機能を実装していましたが、1か月または1か月と1週間でこの量になりました。すべてがソース管理になり、多くのコードが作成され、リファクタリングまたは削除されました。
私はC＃開発者であり、それをうまくできるように努力していますが、私がどれほど客観的に優れているかはわかりません。私は良いコードを書こうとし、それを維持しやすくするために多くの努力をしました。私はこのコードにコメントを1回か2回入れるだけです。
コードが多すぎたり少なすぎたりするかどうかはわかりませんが、本当に気にしないと言わざるを得ません。これは意味のないデータであり、外挿に安全に使用することはできません。しかし、私はたまたまこのデータを知っていたので、共有することにしました。
上司に任せるか、就職活動を始めましょう。
真剣に考えれば、プロジェクトの進捗状況を測定するための適切な方法と不適切な方法をエグゼクティブに説明する絶望的な努力となる可能性があることに気を配ることができます。ただし、現実には、エンジニアリングおよびプロジェクトマネージャーの目的は何ですか。
一方、問題のある幹部[〜＃〜] is [〜＃〜]があなたのエンジニアリングおよび/またはプロジェクトマネージャーであるような状況です。まだ明らかにしていない場合でも、対処する必要があるより大きくてより基本的な問題があります。この場合、このような問題は、発生するより大きな問題の「警告」として機能する可能性があります。
私の推測では、C＃のような言語を使用する開発者は、1日あたり約10KのLoCを記述/生成できるはずです。私はそれができると思います。私は決してそうしません。
あなたが開発者に望んでいるのは、彼の仕事を1日10 LoCで完了することです。コードが少ないほど、常に優れています。多くの場合、大量のコードの生成を開始し、単純化の限界に達するまで切り捨てます。そのため、実際にはLoCがマイナスになる日があります。
ある意味で、コーディングは詩のようなものです。問題は、詩人がいくつの行を書くことができるかではなく、ソネットの14行で彼がどれだけ伝えることができるかです。
ええと、私はいつものようにこのパーティーに少し遅れますが、これは実際には興味深いものです。私は当初、幹部の質問は大げさであるとほとんど同じ考えを持っていました。しかし、私はSK-logicの回答を読んで、それが無意味な方法で尋ねられる賢明な質問であることを理解しました。または、別の言い方をすると、質問の背後に有効な問題があります。
多くの場合、マネージャーはプロジェクトの実現可能性、資金調達、人員配置などを決定する必要があります。これは賢明な問題です。ストレートフォードポートの場合、ポートのコード行を1日あたりの開発者ごとの推定平均コード行数で割った値に基づいた見積もりは簡単に魅力的ですが、このページに記載されているすべての理由で失敗する運命にあります。
より賢明なアプローチは次のようになります：-
- 現場での見積もりについては、コードの経験が最も豊富な開発者に、所要時間の概算を尋ねてください。これについては、ここでは触れない多くの理由で正しくありませんが、最初からできることが最善です。少なくとも彼らは、追加のリソースがあっても、それが1週間または数年後に簡単にできるかどうかについての考えを持っている必要があります。同様のサイズのポートまたは作業の一部が行われた場合、これをガイドとして使用できます。
- コンポーネントごとにポートを見積もり、合計サイズを取得します。インフラストラクチャ（マシン、ビルドシステムなど）のセットアップ、ソフトウェアの調査と購入など、移植に直接関係のないタスクを含める必要があります。
- ポートの最もリスクの高いコンポーネントを特定し、それらから始めます。これらは見積もりを最も吹き飛ばす可能性が高いので、可能であれば事前に実行して、港湾での予期せぬ事態が発生しないようにします。
- ポートの予想される継続時間を継続的に計算するために、ステップ2で行われたサイジングに対する進捗状況を追跡します。プロジェクトが進むにつれて、これはより正確になるはずです。もちろん、移植されたコードの行数（移植されたコードに含まれている元のコードベースの機能）もメトリックとして使用でき、実際に移植されるのではなく、元の製品が移植されていることを確認するのに役立ちます。実際のポートに取り組むことなく、追加されているクールな新機能の束。
これらは必要最小限の手順です。もちろん、移植ツールとプラグイン可能なフレームワークの調査、プロトタイプの作成、移植する必要のあるものの決定、テストツールとインフラストラクチャの再利用など、役立つ他の多くのアクティビティがあります。