LOC /日の比率が高すぎる場合、私は気にする必要がありますか？[閉まっている]

私は現在インディープロジェクトに取り組んでいるので、人間によるテストや外部コードのレビュー全体を行う余裕はありません。しかし、現在のコードに難しいバグはありません（私が見ているように修正しています） 、そしてほとんどの場合、フィールド名などが間違っているため、1〜2分で修正することができます）。機能を実装した後、プッシュする前にテストします。最近、私のLOC番号は1日あたり約400でした（実際には、C＃です）。新しいシステムを実装するだけでなく、既に記述した内容を書き換えて、いくつかのバグを修正しています。

気にする必要がありますか？これまでに作成したすべてのコードを停止して確認し、リファクタリングする必要があるという兆候ですか？

LOCはおそらく最も悪用されるメトリックの1つであり、その結果、おそらくコードの品質のより無意味な測定の1つであり、プログラミングの労力のさらに無用の測定です。

はい、それは私がする大胆な声明です、そしていいえ、私はあなたに私の主張を証明する研究をあなたに指摘することはできません。しかし、私が苦労して得た経験から、あなたが書いたコードの量について心配し始めると、おそらく間違った問題について心配していると述べることができます。

最初に、何を測定または証明しようとしているのか、この証明が単に関心の対象ではないのか、または幅広い品質向上をサポートするのか、そしてチームから賛同を得るためにこの情報を使用する必要があるのか​​を自問する必要があります。 /それについて何かをするための管理。

LOCを使用する傾向があるものの1つは、少しの妥当性チェックです。大量のコードを記述していることに気付いた場合は、全体のLOCではなく、メソッドごとのLOC、またはクラスごとのLOCに興味を持ちます。これらの測定値は、コードがどの程度適切に因数分解されているかについて少しOCDを感じている場合に、さらにリファクタリングする必要があることを示す指標になる場合があります。非常に大きなクラスは、いくつかの小さなクラスにリファクタリングする必要がある場合があり、長い複数行のメソッドは、いくつかのメソッドや他のクラスに分割する必要がある場合や、削除できる可能性がある繰り返しを示す場合もあります。「マイト」という言葉を数回使用したことに注意してください。

実際には、LOCは可能な指標のみを提供し、コードの変更が必要になる可能性があるという実際の保証はありません。実際に尋ねる質問は、コードが必要に応じて期待どおりに動作するかどうかです。もしそうなら、次の質問は、コードを簡単に保守できるかどうか、そして現在または将来、作業コードに変更を加えて将来の保守のオーバーヘッドを減らす時間があるかどうかです。

多くの場合、多くのコードは後でメンテナンスする必要があることを意味しますが、適切に因数分解されたコードでさえも数百行のコードにまで及ぶ可能性があり、はい、1日で数百行のコードを記述していることがあります。しかし、経験から、毎日数百行の新しいコードの出力を維持している場合、多くのコードが他の場所から不適切にカットアンドペーストされているというリスクがあり、それ自体が複製とメンテナンスですが、これも保証ではありません。そのため、私は自分の経験と直感が、手元のタスクがどのように完了したかに基づいて教えてくれることに依存する傾向があります。

私の質問で提示されたジレンマを回避する最善の方法は、LOCを忘れて、常にリファクタリングすることです。最初にコードテストを記述し、実装して失敗し、リファクタリングして合格し、次にそこにリファクタリングできるものを確認してから、コードを改善します。あなたはすでにあなたの仕事を再確認したことを知っていて、将来自分自身の二次推測についてそれほど心配することはないということを知っているタスクを去ります。現実的に言えば、私が説明したようにテストファーストのアプローチを使用する場合、完成したコードのLOC /日測定は、実際に測定量の3〜5倍を書き込んだことを意味し、その努力は継続的なリファクタリングによって正常に隠されます尽力。

まったくそうではありません。ある日、見つけにくいバグを修正して、1行だけ変更します。他の日は、新しいコードを追加して数千行を書き込みます。

毎日のLOCは、その日のタスクが400行のコードで実行できることを除いて何も通知しません。

これらの回答のいくつかは要点を欠いています。生産性の尺度としてLOCを使用していません（生産性が高すぎることを心配していなかった場合）、実際に行っているのはコードの品質を心配しているためです。コードは敵です。これは心配するのに良いことです。

残念ながら、コードの品質を知る唯一の方法はコードレビューです。あなたが1人のチームなので、コードのレビューを中止したとしても（そして、本当に中止したくないのですか？）自分のコードでは、ピアがあなたのコードをレビューするほどには明らかになりません。誰かがあなたのコードの少なくとも一部をレビューして、1日あたり400 LOCが意味不明なものになっていないかどうかを確認できるようにすることをお勧めします。1日のコードの独立したレビューでさえ、ここで役立ちます

1日に作成するLOCの数に煩わされるべきではありません。

しかし、あなたは気になるはずです：

• コードがテストされていない場合（たとえば、単体テストがない場合）
• 新しい機能の追加または実装された機能の変更で問題が発生した場合（つまり、リファクタリングが適切でなかった場合）
• 経験が大きくなく、コードがレビューされていない場合（余分な目で問題が発見される可能性があります）

LOCは生産性の「公式」測定ですが、その値に対する議論は長くなる可能性があります（ただし、ORMは3分で50,000行のコードを生成する可能性があります。

％完了タスクvs時間vs完了予定タスク％を追跡することで、進捗状況を測定することをお勧めします。これが重要です。顧客は、LOCにではなくビジネス価値を提供する実用的なコードに対して支払います。

LOCに関する参考資料

• に対して：LOC-最も意味のない測定

• ある程度中立：Wiki-LOC

• プロ（私はそれのほとんどに同意しませんが、あなたは見ることができます）：スケールとコード行の不経済

コード重複の数も測定していますか？

高出力がコードに多くのコピーと貼り付けがあるためである場合、心配する必要があります。

理由：copy＆paste-sourceにエラーがあった場合、copy＆pasteのすべての使用法を修正するのは難しく、エラーが発生しやすくなります。

あなたが美しい関数型コードを信じているなら、それがあなたの唯一の手段であるべきです

「流れますか？きれいに見えますか？」