26

ソフトウェア開発プロセスを文書化しています。技術者にとって、これは非常に簡単です。内部のマイルストーンは 4 週間ごと、外部のマイルストーンは 3 か月ごとの反復開発です。

ただし、この演習の目的は、プロジェクト管理者が理解できる用語で物事を明らかにすることです。具体的には、これらの非技術系マネージャーは、理解できる指標を必要としています。

私はメトリクスのオプションをよく理解しており、一連のセット全体を提案しています (要件が満たされ、実際のコストと予算コストが私のお気に入りの 2 つです)。ただし、私たちには何人かのベテランが関与しており、彼らは SLOC のようなメトリックに固執する傾向があります。

SLOC の魅力は理解できます。ソフトウェアに詳しくない人でも簡単に理解でき、物理的なものに最も近いアナログのように思えます (昔のパンチ カードを数えるようなものです!)。

ここで質問があります。SLOC の危険性を技術者ではない人にどのように説明すればよいでしょうか?

具体的な動機は次のとおりです。私たちは、何年にもわたる歴史を持つ、かなり成熟したデプロイ済みシステムに取り組んでいます。機能を追加すると、SLOC はほぼ横ばいになるか、減少する傾向があります (リファクタリングにより古いコードやデッド コードが削除され、新しい機能は実際には既存の機能の調整にすぎません)。プログラマー以外のマネージャーにとって、開発プロジェクトで増加しない SLOC は、せいぜい当惑するだけです....

以下の最近の回答に応じて明確にします: プロジェクトの進捗状況を測定する目的では、SLOC は不適切な指標であると主張していることを思い出してください。収集する価値のない数字だと主張しているわけではありません。有用なことを行うには広範なコンテキストが必要ですが、ほとんどのプログラム マネージャーはそのコンテキストを持っていません。

4

13 に答える 13

45

誰かが言った：

「ソフトウェアの進捗状況を測定するために SLOC を使用することは、航空機製造の進捗状況を測定するために kg を使用するようなものです」

次のような悪い慣行を助長するため、まったく不適切です。

  • コピペ症候群

  • 物事を簡単にするためのリファクタリングを思いとどまらせる

  • 無意味なコメント詰め込み

  • ...

唯一の用途は、完全なソース ツリーを印刷するときに、プリンタに入れる紙の量を見積もるのに役立つことです。

于 2010-09-22T13:34:18.313 に答える
24

SLOCの問題は、ゲームをするのが簡単なことです。生産的であることは、より多くのコードを生成することと同じではありません。だから私がスキルドリックが言ったことをむき出しの人々にそれを説明した方法はこれです：

  1. コードの行が多いほど、何かが複雑になります。
  2. 何かが複雑になるほど、それを理解するのは難しくなります。
  3. 新しい機能を追加したり、バグを修正したりする前に、それを理解する必要があります。
  4. 理解には時間がかかります。
  5. 時間はお金がかかります。

より小さなコード->より理解しやすい->より安価に新しい機能を追加する

Beanカウンターはそれを理解できます。

于 2010-09-22T13:38:51.360 に答える
13

次の違いを示します。

for(int i = 0; i < 10; i++) {
    print i;
}

と

print 0;
print 1;
print 2;
...
print 9

そして、10 SLOC と 3 SLOC のどちらが優れているかを尋ねます。

コメントへの応答:

  1. forループがどのように機能するかを説明するのに長くはかかりません。

  2. これを見せたら、「100 までの数字を表示する必要があります。変更方法は次のとおりです」と伝えます。非 DRY コードの変更にかかる時間を示します。

于 2010-09-22T13:34:09.770 に答える
11

于 2010-09-22T13:36:51.407 に答える
5

SLOC は、アプリケーション内のコード行の優れた測定値であることを説明します。

本の行数や映画の長さは、その良さを決定するものではありません。映画を改善して短くすることも、アプリケーションを改善してコード行を減らすこともできます。

于 2010-09-22T16:10:05.587 に答える
5

かなり悪いです （-：

コードではなく、テストケースをカバーする方がはるかに良いアイデアです。

アイデアは次のとおりです。開発者は、失敗したテスト ケースをコミットし、次のビルドで修正をコミットする必要があります。テスト ケースは成功する必要があります。開発者が追加したテスト ケースの数を測定するだけです。

おまけとして、カバレッジの統計を収集します (ここでは、ブランチ カバレッジはライン カバレッジよりも優れています)。

于 2010-09-22T13:33:20.017 に答える
3

SLOC は優れた指標だと思います。システムの規模を示します。これは、複雑さとリソースを判断するのに適しています。また、次の開発者がコードベースで作業するための準備にも役立ちます。

ただし、SLOC カウントは、他の適切なコード品質メトリックが適用された後にのみ分析する必要があります。そう...

  • 2 行バージョンの方がコードの保守が 2 倍簡単になる場合を除き、1 行で十分な場合に 2 行のコードを記述しないでください。
  • SLOC カウントを無効にするためだけに、不要なコメントでコードを無効にしないでください。
  • SLOC カウントで人に支払いをしないでください。

私は 30 年間ソフトウェア プロジェクトを管理してきました。成熟したシステムを理解するために、私は常に SLOC カウントを使用しています。プロジェクトがバージョン 1.0 リリースに近づくまで、SLOC カウントをちらりと見ることさえ有用だとは思いませんでした。

基本的に開発の過程では、品質、性能、使い勝手、仕様への適合性を気にします。それらを正しく理解すれば、プロジェクトはおそらく成功するでしょう。ほこりが落ち着いたら、SLOC カウントを確認します。5,000 行のコードから非常に多くのことが得られたことに驚くかもしれません。そして、あなたはとても少ないことに驚くかもしれません! (ただし、SLOC カウントは、品質、パフォーマンス、使いやすさ、および仕様への準拠には影響しません。)

そして、次にあなたのコードに取り組む人は、あなたがどこに住んでいるかを知っている暴力的なサイコパスであるように常にコーディングしてください.

乾杯、チップおじさん

于 2016-07-17T08:03:00.763 に答える
3

飛行機がどれだけ優れているか (機能の数、パフォーマンスなど) をその重量 (sloc) に基づいて判断することはありません。

飛行機をより高く、より長く飛ばし、パフォーマンスを向上させたい場合、飛行機に重量を追加する必要はありません。その一部をより軽い/より良い材料に置き換えます。無駄な重量を増やさないように、必要のない部分を取り除きます。

于 2010-09-22T13:37:51.047 に答える
1

最新のコード メトリクス ツールでさえ、SLOC の主張を批判しています。

コード行数 (SLOC / LLOC) のカウントの何が問題になっていますか?

于 2011-11-04T08:22:38.633 に答える
1

個人の生産性指標として SLOC が良くない理由

コードを粘土/石のブロックと考えてください。あなたは彫る必要があります、例えば10個の彫像を。重要なのは彫像の数ではありません。重要なのは、どれだけうまく彫ったかです。同様に、書いた行数ではなく、それらがどれだけうまく機能しているかです。コードの場合、LOC はこのようにメトリックとして逆効果になる可能性があります。

複雑なコードを書くと、生産性も変わります。print ステートメントの作成には 1 秒かかりますが、複雑なロジックの作成には多くの時間がかかります。すべての指が同じというわけではありません。

SLOC をどのように活用できるか

欠陥 % の SLOC は良い指標だと思います。はい、難易度が関係しますが、これはマネージャーがビジネスを行う際に使用できる優れたパラメーターです。彼らの視点からも考えてみてください。彼らはあなたやあなたの仕事を嫌いませんが、あなたが最高であり、そのために具体的なものが必要であることを顧客に伝える必要があります. あなたができることを彼らに与えてください:)

于 2010-09-22T13:37:47.997 に答える
0

SLOC は変わっていないのに、新しい機能を追加したり、バグを修正したりすることで、ソフトウェアが昨日よりも多くのことを実行できることを彼らが理解できないのはなぜですか?

今、彼らにこのように説明してください。コードの行数を比較してコードでどれだけの作業が行われたかを測定することは、サイズで比較して携帯電話に含まれる機能の数を測定することと同じです。携帯電話は、技術の向上と技術のおかげで、より多くの機能を追加しながら、20 年以上にわたってサイズが小さくなっています。優れたコードは、同じロジックをより少ないコード行で表現できるため、これと同じ原則に従います。問題の理解を深め、開発のための新しい手法を導入するにつれて、実行が速くなり、保守が容易になり、理解しやすくなります。

機能の開発、メンテナンス、バグ修正によって得られるビジネス価値に集中してもらいます。ソフトウェアに満足している人が、改善が見られると言うなら、SLOC を心配する必要はありません。

これを読んでください：

https://stackoverflow.com/questions/3800707/what-is-negative-code

于 2010-09-22T15:50:43.300 に答える
0

SLOC は、空行を追加する (「読みやすくするため」) か、コメントを追加または削除することで大幅に変更できます。そのため、SLOC のみに依存すると、混乱が生じる可能性があります。

于 2010-09-22T13:34:47.637 に答える