生産性を測定するためのSLOCの有効な使用方法は知られていますか？

動的言語と静的言語について、非常に上級のアーキテクトと異常な短い会話をしました。彼は、企業データは、静的言語を使用した場合の生産性向上の証拠があることを示していると述べました。注意してください、それは長い歴史を持つ大企業です。驚いたことに、彼が使用した測定基準は追加されたコード行でした。

彼は、SLOCメトリックが生産性を比較するのに役立つように、同じ企業内で、似た文化、業種、十分なデータを持つ違い（個人の固有の状況と能力に関する）が十分に混ざり合っていると言うメトリックに関する異議をすぐに却下しましたツールと言語。

この主張が厳密な統計分析に裏付けられているとは思わないが、この考え方を裏付ける証拠は業界にあるか？

上級アーキテクトの議論は、2つのことを意味します。

1. 会社の平均的な開発者は、動的言語を使用する場合よりも静的言語を使用する場合の方が多くのコード行を生成することを意味する場合があります。たとえば、15人の開発者が6か月間Javaを使用する場合、100 KLOCを作成し、同じ15人の開発者が6か月間Pythonを使用する場合、50 KLOCのみを作成します。

   ここでは、LOCと生産性の間に相関関係はありません。Pythonで同じ機能を生成するためにJavaで4倍のコード行が必要な場合はどうなりますか？その場合、Pythonを使用すると、上記のKLOCメトリックに基づいて生産性が2倍になります。

2. また、会社の平均的な開発者は、動的言語を使用する場合よりも静的言語を使用する場合のコード行数が少ないことを意味する場合があります。

   通常、コードの行数は少ない方が（書き込み、読み取り、保守のコードが少なくなります）、Java開発者がPythonの機能と比較してどの程度の機能を生成したかはまだ不明です。Python開発者に比べて半行のコードを書いただけでなく、機能の数が半分になったのかもしれません。

どちらの場合も、同じ機能が異なる言語の同じコード行数に変換されないため、LOCは価値のある指標ではありません。一部の言語はより冗長になる傾向があります。その他-よりコンパクト。場合によっては、コンパクトさが重要ですが、そのための一般的なルールはありません。極端な例は、非常にコンパクトですが、読みやすさでは一般的ではないBrainfuck言語です。同様の言語を比較するのは難しい場合があります。たとえば、中括弧に関しては、JavaはK＆Rスタイルに従いますが、C＃では、ほとんどの場合、公式スタイルに従う場合、オープニング中括弧は独自の行にあります。 C＃のLOCの増加。そして、手続き型言語とオブジェクト指向言語、または関数型言語を比較するとどうなりますか？

エラーが発生しやすいメトリックを使用する代わりに、上級アーキテクトは、一緒に使用すると生産性を測定するメトリックのグループに依存できます。1か月あたりに開発される機能の数、コードベースに導入されるバグの数、およびそれらのバグの解決に費やす時間、技術的な負債の進化など。新しい言語にチームが不慣れであることを考慮する必要があるため、この比較は最初は難しいかもしれません。チームが十分な知識を身に付けたら、安定した指標に基づいて選択する必要があります。また、ほとんどの場合、チームのメンバー自身の好みに基づいて選択する必要があります。

LOC は、いくつかの狭い状況で値を持ちます。たとえば、プロジェクトのサイズとプロジェクトの一部についてのヒントを提供したり（平均して機能ポイントと相関しますが、測定しやすいことが多い）、さらに注意が必要なメソッドやクラスを示すことができますその大きなサイズの。ただし、LOCは、関係のないものの間の何らかの相関関係を想像する人によって頻繁に誤用されるため、注意して使用する必要があります。過去に最も悲惨なLOCの使用法は、過去に月ごとに書かれたLOCに基づいて個々の開発者の生産性を測定する試みでした。

生産性とSLOCについて

SLOCの問題

SLOCメトリックの問題は、以下を考慮せずに、記述されたコードの量の概算を測定することです。

• コードの品質（つまり、バグのために100 SLOCごとに90 SLOCを追加しなければならないが、コードが配信された時点ではわからない場合）
• コードで達成された目標（つまり、10K SLOCは予想されるすべてのユースケースまたはユーザーストーリーを処理しますか？それともごく小さなサブセットのみを処理しますか？）
• コードの保守性（つまり、予想される進化する要件に合わせてコードを調整するには、1％または50％のコードを追加する必要がありますか？）

別の言い方をすれば、コピーペーストされた部分を多く含む、エラーが発生しやすいメンテナンス不可能なスパゲッティコードの生成は、慎重に設計された再利用可能なコードよりも生産的であると見なされます。

そのため、SLOCは生産性を測定する最良の方法ではありません。

どのような生産性を考慮していますか？

プロセスの生産性が測定されます。したがって、SLOCは、コーディングプロセスだけで完全に有効な指標になる可能性があります。

たとえば、貧しい要件を誤解し、ソフトウェアを生産するために5か月を費やし、それをユーザーに見せ、それが明らかに間違っていることを発見し、さらに5か月を費やして最初から完全に書き直す場合、SLOCでも同じ生産性が得られます/ month、たとえば、頻繁にフィードバックすることで誤解を減らすアジャイルプロセスを使用したために、チームがコードを最初に作成すること。この明らかな平等な生産性は、大きな問題を隠しています。

そのため、ソフトウェア開発の生産性の測定では、要件の分析、コーディング対象の設計、コーディング、テスト、デバッグ、ユーザーの期待を満たしていることの検証など、プロセス全体を考慮する必要があります。これらのアクティビティはすべて非常に異なるため、最も重要なことは、問題となる唯一の思考を測定することです。つまり、動作しているソフトウェア、つまり、ソフトウェアが生成したものがユーザーにとって意味するものです。

ソフトウェア成果物の測定方法

いくつかのアプローチがあります。

• 従来のソフトウェアエンジニアリングの典型的なアプローチは、ファンクションポイント（FP）です。機能ポイントは、満たすべき要件に基づいて測定されます（たとえば、フォームの数、各フォームのフィールドの数など）。生産性は、単位時間あたりおよび1人あたりFPで測定されます。一部の企業は、特定のドメインの特定の言語で、開発者が単位時間あたりに生成できる機能ポイントの数を示すデータさえ持っています。FPの問題は、事前に非常に詳細な要件が必要であり、時間がかかることです。
• より現代的で実用的なアプローチは、ストーリーポイント（SP）です。これらは、生成されるコードの複雑さを評価するために使用され、開発チームの速度を評価するために日常的に使用されます。ただし、SPは、すべての詳細が判明する前に実行された作業の推定尺度です。実際に起こったことの最終的な測定値ではありません。そのため、生産性の指標として使用する場合は、推定プロセスで裏目に出る可能性があるため、注意が必要です。

静的タイピングと動的タイピングの生産性について

私は自分が静的に型付けされた言語のファンであることを告白しなければなりません。なぜなら、私の内なる自己のほうがより信頼性が高いことを知っているからです（コーディングの年月がそれを証明してくれました）。

したがって、私が確実にとるべきことは、静的に型付けされた言語は、静的に型付けされていない言語よりもコンパイル時のエラー/バグ（タイプミス、予想される型の不一致など）を防ぐことができるということです。しかし、すべての客観性において、私はこれをより高い生産性として虐待的に一般化することを敢えてしません。

あなたの建築家は正しいですか？

多分そうでないかもしれません。

しかし、彼の議論は有効ではないようです。静的に型付けされた言語の生産性の向上は、コンパイラーによって事前にキャッチされたかなりの数のエラーに由来します。

したがって、動的に型付けされた言語に必要な手直しを見なくても、SLOCだけを見て、この「より高い」生産性の向上を見つけることはできません。したがって、彼の比較は公平ではありません。

同様の状況の議論も当てはまりません。一部の動的型付け言語では、従来の静的型付け言語のいずれかで同じことを行うよりも少ないコードで済む、より高いレベルの構成体を使用できます。したがって、必要な時間は短くなり、コードの記述は少なくなりますが、同じ分析、テスト、検証のオーバーヘッドが追加されます。したがって、SLOCで生産性を測定すると、潜在的な生産性の向上が希薄になり、動的に型付けされた言語に対するバイアスが生じます。

その主張を裏付ける研究はありますか？

このトピックに関するいくつかの最近の学術研究が存在します。それらの一部には静的型付けの利点がありますが、一般的には特定の目的（文書化、不十分に文書化されたコードまたはAPIの再利用など）に限定されます。慎重な表現も使用されます。これは、最新のIDEが動的型付けに関連するリスクを大幅に削減したためです。

• IDEが存在する場合のAPIの使用に関する静的型システムと動的型システムの経験的比較：JavaとGroovy with eclipse、2014
• 明示的な型宣言の生産性への影響を考慮して、2014年、ただし決定的ではありません
• 文書化されていないソフトウェアのユーザビリティに対する静的型システムの影響の経験的研究

上級アーキテクトの反例は次のとおりです。3つのクラスの階層を作成し、そのうち2つは3つ目のクラスから派生し、基本クラスが定義するいくつかの仮想関数を実装するとします。

これら3つのクラスをC ++で記述すれば、それは非常に簡単です。クラスを宣言し、正しい場所で仮想を使用して、完了です。

これらの3つのクラスをCで記述する場合、かなりのコードを追加する必要がありますstruct。v-tableにs を定義する必要があり、v-tableポインターを基本クラスに追加する必要があるため、追加する必要がありますコンストラクタのコードは実際に私が実際に基底クラスのコンストラクタを呼び出すコードにコンストラクタを追加する必要があり、V-テーブルポインタを設定するために、私は明示的にC ++コンストラクタ（呼び出す前に、メモリ割り当てを実行するためのコードを追加する必要がありnew、単一のステップで行いますが）、同様に、私は破壊を後続のfree()呼び出しから分離する必要があります。

重要なのは、これらの追加事項はすべて非常に無意味だということです。私はそれらを非常に迅速に行うことができます。ですから、C ++バージョンを書くのに必要な時間よりも、Cバージョンを書くのに長い時間はかかりません。それにもかかわらず、私はC ++コードよりも多くのCコード行を生成しました。そのため、SLOCに関してはCの方が生産的だったように見えます。

一定量のボイラープレートコードを必要とする言語は、同量のボイラープレートコードを必要としない言語よりも、SLOCの観点から生産性が高くなります。

ご存知のように、SLOC引数には根本的な欠陥があるため、実際には逆のことを見ることになります。「プログラマーは静的言語でより多くのSLOCを生成する傾向があります」という文を取ります。定型コード、したがって生産性の低下」

私は反逆者になります。

私たちは仕事でSLoCを追跡します（人員配置の決定にSLoCを直接使用しません）が、ほとんどの人が答えで言っていることを人々に議論させました。実際、「Xテクノロジーはより少ないコードでより多くのことを行えるため、LoCは重要ではありません」または「より良い開発者がより良い、より短いコードを書くため、他の誰よりも多く書くことはありません」。私の経験では（これらのことを裏付けるハードナンバーはありませんが）、これらの異議は単に正しくありません。私自身の時間では、エンジニアとしての全体的な「能力」のその他すべての意味のある測定値と比較すると、開発者にとってコード生成の速度と品質の両方に明確な相関関係が見られました。上記の種類の引数にいくつかの反例を与えるには：

1. はい、一部の言語では、より少ないコードでより多くのことができます。実際、特定のビジネス上の問題（バックエンドのみ）の開発の大部分を「自動化」する、構築したフレームワーク全体があります。このすべての結果は、人々が書くコードが少なくなるということではなく、単にコードを書く時間が増えたということです。その結果、当社では、コード記述の全体的な割合はテクノロジー全体でほぼ一定であり、主にエンジニアの能力レベルに依存しています。
2. 優れた開発者がよりスマートに記述しているため、より少ないコードを生成するという考えは間違いなく真実ではありません。はい、より適切に設計されたプログラムは、より少ないコード行を使用する可能性があります。しかし、個人的には、より効率的なコードを作成する「より良い」開発者は、より若い開発者が長い時間をかけて作成するよりも、計画を立てるのに時間がかからないことを発見しました。その結果、上級の開発者はコーディングタスクをより迅速に完了し、同じ高率で異なるコードを記述することに進みます。

その最後の部分は、私の全体的な要約です、ところで。私が見つけたのは、技術スタックやプロジェクトの種類に関係なく、ほとんどの開発者が独自のペースを持っているということです。言語に開発者のコ​​ードをより効果的にする多くの機能がある場合、それはビジネスにとって大きな恩恵ですが、それは結果としてより少ないコードを書くことを意味しません。代わりに、機能をより迅速に実行し、すぐに新しいコードに移行します。繰り返しになりますが、最終的な結果は、コーディングのレートが主にスキルに依存し、技術スタックに依存しないことです。実際、このため、一般的に技術スタックは、人々がコーディングするレートよりも、チケットと機能が開発されるレートに大きな違いをもたらすと期待しています。

そうは言っても、コード書き込み率もチケット終了率も生産性の完全な尺度ではないため、SLoCに基づいてスタッフの決定を直接行わないのはこのためです。代わりに、プロセスの一部であり、従業員の評価はできるだけ多くのデータポイントを使用して行われます。私はあなたのアーキテクトが確かに狂っていないと言うでしょう。

1つの例外

私が同意する1つの例外は、定型コードの可能性です。あるクラス（または他のクラス）から別のクラスへのコピーアンドペーストが多く行われて実行される場合、それは明らかにメトリックをゆがめます。これは、大量のコードを自動生成できるツールがある場合にも当てはまります。しかし、これらは規則ではなく例外であることが多いと思います。開発者が時間をかけてボイラープレートコードをコピーして開始する場合、間違った技術セットを使用しています。彼らが実際にコードを書いている場合、それがかなり反復的であっても、私はこれが測定値を少しだけ歪めると期待しています：コードを書くとき、ほとんどの場合、私たちはむしろ問題を考えることができる速さによって制限されます入力できる速さよりも 比較的反復的なコードを記述する場合でも、

明らかに、上記のすべては私自身の個人的な経験に基づいています。あなたの走行距離は異なる場合があり、明らかに私は少数派です。反対意見をお気軽に。要約すると：

コーディングの速度は、問題をどのくらい早く考えることができるかによって異なります。その結果、わずかな例外を除いて、コーディング率は技術セット全体でさえ生産性の適切な尺度であることがわかりました。

私は時流に乗っていますが。プログラマーの行動への影響を強調する必要があると思います。

生産性の尺度としてSLOCを使用すると、プログラマの士気に有害な影響があります。チーム/会社のエンジニアがSLOCで測定されていることに気付いた瞬間、いくつかのことが起こります。

1. 彼らは同じ機能を実行するためにはるかに長いコードを書き始めます
2. 彼らはコードの品質についてあまり気にしません
3. 彼らはあなたのチームを助ける他のことをやめます（募集、デバッグ、後輩を助ける）
4. 彼らは自分の仕事を嫌い、おそらく去るでしょう

2つの異なる企業で2回発生するのを見て、士気を設計することはどれほど腐食性があるかを十分に強調することはできません。あなたがそれに対して持っている一見有効なユースケースが何であれ、その使用が発見される可能性はほんのわずかであるとしても、それがあなたのチーム/会社に影響を与える価値はありそうにないと主張します。場合によっては、書き込まれた行数と有用な機能の量との間に相関関係がありますが、プログラマーのすべての間違った動作を助長し、品質が重要ではないメッセージを送信します。

一般に、生産性を測定する有効な方法とは見なされません。通常、小さなコードは大きなコードよりも優れているため、生産性の高い開発者は通常、少ないコードを生成します。デバッグでは生産性が最大の打撃を受けます。効率的な開発者はデバッグにほとんど時間をかけません。

静的に型付けされた言語は（言語間の他のすべての違いを制御する場合）より生産的です。賢明に使用すると、デバッグ時間を短縮し、コンパイル段階でエラーをキャッチし、修正が速くなるためです。

言語間で開発者の生産性を比較するために使用できる唯一のメトリックは、言語間でコードを比較しないメトリックです。いくつかの言語は冗長である（悪名高いCOBOL）こともあれば、1行のコードで実行できることを実行するためにいくつかの手順を必要とするものもあります（アセンブリとそれ以外のほぼすべて）。アクティブなコード行のみを比較した場合（つまり、宣言をカウントせず、何らかのアクションが関係するコードのみをカウントした場合）、結果を歪めることができます。

変化率について議論することができるかもしれません。つまり、同じ期間の生産性の傾斜を比較するコード行が追加されました。ただし、コード行のマイナスの変更は考慮されていません。たとえば、どこにでもコードをコピーして貼り付けるプロジェクトを継承します。繰り返しのコードブロックの数を減らすために、いくつかの迅速かつ簡単なリファクタリングを実行します。定義により、負の勾配があります。

すべての深刻さにおいて、チーム/言語の生産性を比較することは無意味です。なぜなら、チームの生産性に影響する多くの追加要因があり、そこから有意義な結論を引き出すことができないからです。

インフラストラクチャが非常に脆弱で、ツールが時代遅れであるプロジェクトに取り組みました。このプロジェクトはJava上に構築され、シングルページアプリがスラップされていますが、明らかな利点がないため、ポートレットコンテナでホストされています。簡単な変更でさえ、とてつもなく長い時間でした。その特定のプロジェクトにすべての結論を下す場合、Javaが悪い、または単一ページアプリが悪いと結論付けるかもしれません。どちらも真実ではありません。いプロジェクトが置き換えることになっているシステムは、C＃とWebFormsで構築されました。顧客のニーズに対応するために既存のアプリケーションを拡張するビジネスケースを作成したとき、生産性が急上昇しました。それは、密結合されたWebFormsアプリの方が優れているということですか？あなたはこの特定のケースについてのみその結論を出すことができますそして、それは世界全体には及ばない。そして、それはだけ延長するのに十分な成熟度を持つ既存のアプリケーションがあったので意味があります。

問題追跡システムで解決するアイテムのレートを比較することでさえ、完全なプロジェクトインフラストラクチャを互いに比較しているという意味で欠陥があります。使用されるライブラリとフレームワークは、進行を加速または減速させることができます。立ち上がる段階で、克服する慣性がほとんどない場合があります。この場合、「より良い」プロジェクトは、新しいチケットの数が比較的少ないメンテナンス段階にあります。似たようなものを比較することは決してありません。