web-dev-qa-db-ja.com

プロジェクトのサイズを正規化するためだけにKLOCを使用することはまだ悪いですか？

一部のマネージャーはそれを生産性と関連付けようとしているため、多くの人がKLOCを軽視しています。ただし、同じ言語とコーディング標準、およびLOC計算用の同じツールを使用するプロジェクトのサイズの比較のみを話す場合。ストーリーポイントとは異なり、これは2つのプロジェクトのサイズを比較できるより合理的な方法のようです。

estimationmetricsloc
2
John V

この質問に対する答えは、コーディング標準によって異なります。それらがより厳格であるほど、2人の開発者によって生成されるコードの変動が少なくなるため、異なる人々からの同じソリューションのKLOCカウントが近くなります。

しかし、コードを書くときに細部をすべて強制するのではなく、ある程度の自己表現を可能にする会社で働いているとします。例として、fizzbuzzゲームのC＃でメソッドを記述する次の2つの方法を検討してください。

バージョン1

IList<string> GenerateFizzBuzzList()
{
    var fizzBuzz = new List<string>();
    for (var i = 1; i <= 100; i++)
    {
        var entry = "";
        if (i % 3 == 0)
        {
            entry += "Fizz";
        }
        if (i % 5 == 0)
        {
            entry += "Buzz";
        }
        if (entry == "")
        {
            entry = i.ToString();
        }
        fizzBuzz.Add(entry);
    }
    return fizzBuzz;
}

バージョン2

IList<string> GenerateFizzBuzzList()
{
    var fizzes = Cycle("", "", "Fizz");
    var buzzes = Cycle("", "", "", "", "Buzz");
    var words = fizzes.Zip(buzzes, (f, b) => f + b);
    var numbers = Range(1, 100);
    return numbers.Zip(words, (n, w) => w == "" ? n.ToString() : w).ToList();
}

どちらのソリューションも同じ言語（C＃）で記述されています。どちらのソリューションも、コーディング標準で一般的な命名、ブレースレイアウト、およびその他のさまざまな規則（varを使用するなど）に関する同じルールに従います。しかし、バージョン1はバージョン2のほぼ3倍のサイズです。

これら2つのアプローチを適度に大きなアプリにスケールアップすると、1つのプロジェクトで80,000行、別のプロジェクトで220,000行になる可能性があります。しかし、その140,000行の違いは、一方が他方よりも多くのことを行うからではなく、採用されたアプローチに完全に依存します。 KLOCは、機能の比較サイズを、プロジェクトごとにまったく同じ方法でコードを記述した場合にのみ通知します。実際には、まったく同じアプローチが、新しい技術やコードの表現方法をまったく学んでいない質の悪い開発者によってのみ使用されます。つまり、実際には、KLOCはコードの行数の測定にすぎません。それは他に何も測定しないので、他のものを測定しようとしても役に立たない。

5
David Arno

KLOCがまだ使用されているのはなぜですか？

KLOCは、キロメートルが中立的な距離の測定であるのと同じように、コードのサイズの中立的な測定です。

KLOCと同様に、キロメートルはあまり役に立ちません。キロメートルの数が多くても、旅がより快適で快適であるとか、観光が多いとかは保証されません。キロは悪い予測因子でもあります。ターゲットに到達するのにかかる時間や、必要な燃料の量はわかりません。

しかし、キロメートルは依然として距離の主要な測定単位です。そして確かに同様の理由から、サイズ測定にはKLOCがまだ使用されています。

KLOCで何を測定したいですか？

KLOCは（非常に）生産性の悪い指標です：再利用可能で保守可能なniceクラス/関数を書くと、単純なコピー/貼り付けよりもはるかに小さなコードになる可能性があります/編集し、永遠に自分を繰り返す。ただし、再利用によりコードを少なくする必要があり、すでにテスト済みのテストに依存できるため、テストを少なくする必要があるため、長期的にはかなり逆ですが、同時に短いコードは生産性が低いように見える場合があります。コンポーネント。

ただし、KLOCは有効なサイズの尺度です。すべての測定単位として、いくつかの欠点があります。すべての線が同じ複雑さであるわけではなく、レイアウトとスタイルが数量に影響を与える可能性があります。しかし、大規模なコードベースでは、いくつかの正規化（空の行やコメント行を無視する、またはスタイルの違いを無力化するためにかなりの印刷を適用するなど）を行うと、統計的に意味があります。

サイズは数量のみを測定します。コンパイル時間やレビュー時間に影響を与える可能性があります。 2つの異なるソースコード間の類似度を測定するために、知的財産権の訴訟で使用されます。しかし、それが時間、労力、または複雑さの優れた予測因子であると期待しないでください（10リーエンの再帰的コードは、50行の連続した状態よりもさらに複雑です）。

代替案は何ですか？

ストーリーポイント は、評価を行ったチームの主観的なものです。このメトリックがサイズまたは労力に対応しているかどうかは、はっきりとはわかりません。

より客観性を目指す 関数ポイント もあります。しかし、これらはコードから容易に入手できず、解釈の余地もある高価な分析が必要です（ストーリーポイントの場合よりは少ないですが）。また、OO GUIのある世界でも、それらがまだ関連しているとは思いません。

ストーリーポイントと機能ポイントは、とにかく要件と期待される機能の推定です。これらはコードが記述される前に評価され、一般に、不正確であると思われる場合は更新されません。それらは複雑さのアイデアを与えるかもしれませんが、生成されるコードのサイズのすべてではありません。

2
Christophe

推定のためのLoCの問題は、最終的なコードに含まれる行数が事前にわからないことです。

プロジェクトの複雑さとサイズの事後測定に関しては、他のどの測定よりも優れています。

人々が一般的に固執するコーディングスタイルと一般的に入力する速度があると仮定します。その後、はい、あなたはbackが彼らが書いたコードを見て、最終的なLoCと、平均速度と比較して開発者がそれらを書き込むのにかかった時間によって、どのタスクが簡単でどれが難しいかを確認できます。

これは、将来の作業を見積もるのに実際には役立ちません。

1
Ewan

ここでは完全に異なる2つのことを混乱させています。

機能を気にかけているのは、マーケティングがこれを販売しているからです。彼らはプロジェクトのサイズを気にしませんまったく機能の完全性の指標として以外は。これは非常に非常に弱い指標であり、より良いものがある場合に悪いマネージャーだけがそれに依存しますが、それは起こります。

プログラマはプロジェクトサイズを気にします。これは、コードベースの処理がいかに難しいかを決定するためです。彼らはそれが彼らのチェックを支払うものである限りを除いて、彼らは（主に）機能性を気にしません。マネージャーとは異なり、プログラマwouldはより小さなコードベースを好み、その他は同等です。

これは、2つの状況がまったく比較できないことを意味します。 KLOCは、プロジェクトのサイズを判断するのに役立つ指標であり、完全性または生産性を判断するのに非常に役に立たない指標です。ここで矛盾はありません。

0
Kilian Foth