生産性を測定するためのSLOCの有効な既知の用途はありますか？
非常に上級の建築家と、動的言語と静的言語について珍しい短い会話をしました。同社のデータによると、静的言語を使用すると生産性が向上するという証拠があるという。注意してください、それは長い歴史を持つ大企業です。私（および他の人）が驚いたことに、彼が使用した測定基準は、追加されたコード行でした。
彼は、メトリックに関する異論をすぐに却下しました。同じ会社内で、同じような文化、基幹業務、十分なデータがあれば、（固有の状況や個人の能力に関する）違いが十分に混じり合うため、SLOCメトリックは、ツールと言語。
この主張が厳密な統計分析に裏付けられているとは思いませんが、この考え方を支持するであろういくつかの証拠が業界にありますか？
上級建築家の議論は二つのことを意味するかもしれません。
これは、会社の平均的な開発者が、動的言語を使用する場合よりも静的言語を使用する場合により多くのコード行を生成することを意味する場合があります。たとえば、15人の開発者がJavaで6か月作業する場合、100 KLOCを書き込み、同じ15人の開発者がPythonで6か月作業する場合、50 KLOCのみを書き込みます。 。
ここでは、LOCと生産性の間に相関関係はありません。 Javaのコードの行数が、Pythonの場合よりも4倍多いとしたらどうでしょうか。これが当てはまる場合、Pythonを使用すると、上記のKLOCメトリックに基づいて2倍の生産性が得られます。
彼はまた、会社の平均的な開発者が生成するコード行数が少ない動的言語を使用する場合よりも静的言語を使用する場合：15人の開発者が6か月でJavaで100 KLOC、またはPythonで200 KLOCを書き込む。
通常はコードの行数が少ないほど（書き込み、読み取り、維持するコードが少ないほど）優れていますが、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で同じ生産性が得られます。 /月、チームが最初にコードを作成するのは、たとえば、頻繁なフィードバックを通じて誤解を減らすアジャイルプロセスを使用したためです。この見かけ上の同等の生産性は、大きな問題を隠しています。
したがって、ソフトウェア開発の生産性を測定するには、要件の分析、コーディングするものの設計、コーディング、テスト、デバッグ、ユーザーの期待に沿うことの確認など、プロセス全体を考慮する必要があります。これらのアクティビティはすべて非常に異なるため、重要なことは、稼働中のソフトウェア、つまり、ソフトウェアがユーザーに与える意味のみを測定することです。 。
ソフトウェア成果物を測定する方法は？
いくつかのアプローチがあります：
- 古典的なソフトウェア工学における典型的なアプローチは Function Points （FP）です。関数ポイントが測定されます 要件に基づいて 満たす（たとえば、フォームの数、各フォームのフィールドの数など...）次に、生産性はFP時間単位および1人あたり）で測定されます。一部の企業では、特定のドメインの特定の言語で、開発者が単位時間あたりに生成できる関数ポイントの数を示すデータさえあります。FPの問題は、非常に詳細な要件を事前に必要とし、時間がかかることです。
- より現代的で実用的なアプローチは ストーリーポイント （SP）です。これらは、生成されるコードの複雑さを評価するために使用され、開発チームの速度を評価するために日常的に使用されます。ただし、SPは、すべての詳細が判明する前に実行された作業の推定尺度です。これは、実際に起こったことの最終的な尺度ではありません。それ 推定プロセスで裏目に出る可能性があります 。
静的型と動的型の生産性について
私は個人的には静的型付け言語のファンであることを告白しなければなりません。なぜなら、私の内面では、それがより信頼できることを知っているからです（長年のコーディングでそれが証明されました）。
つまり、静的型付け言語は、静的型付けされていない言語よりも、コンパイル時のエラー/バグ（タイプミス、予期される型の不一致など）を防ぐことができるということです。しかし、すべての客観性において、私はこれをより高い生産性として乱用して一般化しようとはしません。
あなたの建築家は正しいですか？
多分そうでないかもしれません。
しかし、彼の主張は有効ではないようです。静的に型付けされた言語の生産性の向上は、コンパイラーによって事前に捕捉された多数のエラーから生じています。
したがって、動的に型付けされた言語に必要なやり直しを確認せずにSLOCだけを確認しても、この「より高い」生産性の向上を見つけることはできません。だから彼の比較は公平ではありえない。
比較可能な状況の議論も成り立たない。一部の動的型付け言語では、従来の静的型付け言語の1つで同じことを行うよりも少ないコードで、いくつかの高レベルの構成が可能です。したがって、必要な時間とコードを少なくして、同じ分析、テスト、および検証のオーバーヘッドを追加できます。したがって、SLOCで生産性を測定すると、潜在的な生産性の向上が薄れ、動的に型付けされた言語に対するバイアスが生じます。
その主張を裏付ける研究はありますか？
このトピックに関するいくつかの最近の学術研究が存在します。それらのいくつかは静的型付けの利点を理解していますが、それは一般に特定の目的（文書化、不十分に文書化されたコードまたはAPIの再利用など）に制限されています。現代のIDEにより、動的型付けに関連するリスクが大幅に減少したため、慎重な表現も使用されています。
これは、上級アーキテクトの反例です。3つのクラスの階層を記述したいとします。そのうちの2つは3番目から派生し、基本クラスが定義するいくつかの仮想関数を実装します。
これら3つのクラスをC++で書くと、かなり簡単です。クラスを宣言し、正しい場所でvirtualを使用して、完了します。
これら3つのクラスをCで作成する場合は、かなりのコードを追加する必要があります。vテーブルにstructsを定義する必要があります。基本クラスにvテーブルポインターを追加する必要があります、実際にvテーブルポインターを設定するためにコンストラクターにコードを追加する必要があります。基本クラスコンストラクターを実際に呼び出すためにコンストラクターにコードを追加する必要があります。コンストラクターを呼び出す前に明示的にメモリ割り当てを実行するためのコードを追加する必要があります（C++ newは単一のステップで実行されます）同様に、破壊を後続のfree()呼び出しなどから分離する必要があります。
重要なのは、これらすべての追加事項はまったく気にしないということです。私はそれらを非常に迅速に行うことができます。そのため、Cバージョンの作成に必要な時間よりも、Cバージョンの作成にはそれほど時間はかかりません。それにもかかわらず、C++コードよりも多くのCコード行を生成しています。 SLOCに関しては、Cの方が生産性が高いようです。
一定量のボイラープレートコードを必要とする言語は、同じ量のボイラープレートコードを必要としない言語よりも、SLOCの点で生産性が高くなります。
SLOCの引数には根本的な欠陥があるので、実際には逆に見ます。「プログラマーは静的言語でより多くのSLOCを生成する傾向がある」という言葉を使用します。ボイラープレートコード、したがって生産性を低下させます。」.
私は反対者になります。
私たちは仕事でSLoCを追跡し（人員配置の決定に直接使用することはありません）、ほとんどの人が答えで何を言っているのかを議論する人がいました。事実、「Xテクノロジーにより少ないコードでより多くのことを実行できるため、LoCは重要ではありません」または「より優れた開発者はより優れた短いコードを記述し、他の誰よりも多くのコードを記述しません」。私の経験では（これらを裏付けるための明確な数字はありませんが）、これらの異論は単に正しくありません。私自身の時代には、開発者のコード生成の速度と品質の両方に、エンジニアとしての全体的な「能力」に関する他のすべての意味のある測定値と比較して、明確な相関関係がありました。上記で作成した種類の引数にいくつかの反例を与えるには：
- はい、一部の言語では少ないコードでより多くのことができます。実際、特定のビジネス問題（バックエンドのみ）の開発の大部分を「自動化」するために構築したフレームワーク全体を手に入れました。これらすべての結果は、人々がより少ないコードを書くということではなく、単にコードを書く時間があるということです。その結果、私たちの会社では、コード作成の全体的な速度はテクノロジー全体でかなり一定であり、主にエンジニアの能力レベルに依存しています。
- 彼らが賢く書いているので、より良い開発者がより少ないコードを生成するという考えは間違いなく真実ではありません。はい、より適切に設計されたプログラムでは、必要なコード行が少なくて済みます。しかし、私は個人的に、より効率的なコードを書く「より良い」開発者は、より若い開発者が長い時間をかけて書くよりも、それを計画するのにもはや時間がかからないことを発見しました。その結果、より上級の開発者はコーディングタスクをより迅速に完了し、同じ高率で別のコードを作成することになります。
ところで、最後の部分は私の全体的な要約です。私が見つけたのは、技術スタックやプロジェクトの種類に関係なく、ほとんどの開発者には独自のペース、つまり彼らが活動しているペースがあるということです。言語に、開発者のコードをより効果的にする多くの機能がある場合、それはビジネスにとって大きな恩恵ですが、それは彼らが結果としてより少ないコードを書くという意味ではありません。代わりに、機能をより迅速に実行し、新しいコードにすばやく移行します。繰り返しますが、最終的な結果として、コーディングのレートは主にスキルに依存し、技術スタックには依存しません。実際、これが原因で、私は一般に、技術スタックが、人々がコード化する速度よりも、チケットと機能が開発される速度に大きな違いをもたらすことを期待します。だから、おそらくここにある他の答えよりも、上級建築家の側に寄り添うことになるでしょう。
とはいえ、コード書き込み率もチケットのクローズ率も生産性の完璧な尺度ではないため、SLoCに基づいて人員配置を直接決定することはありません。代わりに、これはプロセスの一部であり、従業員の評価はできるだけ多くのデータポイントを使用して行われます。とはいえ、あなたのアーキテクトは確かに頭がおかしいわけではありません。
1つの例外
私が同意する1つの例外は、定型コードの可能性です。あるクラス（または何でも）から別のクラスにコピーアンドペーストを実行して実行する場合、それは明らかにメトリックを歪めます。これは、大量のコードを自動生成できるツールがある場合にも当てはまります。ただし、これらは通常のルールではなく例外であることが多いと思います。開発者がボイラープレートコードのコピーを開始するために時間を費やしている場合、間違った技術セットを使用しています。彼らが実際にコードを書いている場合、たとえそれがかなり反復的であっても、私はこれが測定値をほんの少しだけ歪めることを期待します：コードを書いているとき、ほとんどの場合、問題を考えることができる速さによって制限されます入力できる速さよりも。比較的反復的なコードを書くときでも、あなたはまだあなたの脳に従事していて、プロセスを通して考えています。
明らかに、上記のすべては私自身の個人的な経験に基づいています。あなたの走行距離は異なる場合があり、明らかに私は少数派です。どうぞご遠慮なく。要約すると：
コーディングレートは、問題をどの程度の速さで考えることができるかによって異なります。その結果、コーディングレートは、テクノロジーセット全体でさえ、生産性の適切な尺度であり、いくつかの可能な例外。
バンドワゴンに飛び乗っていますが。プログラマーの行動への影響を強調する必要があると思います。
生産性の尺度としてSLOCを使用すると、プログラマーの士気に有害な影響があります。チーム/会社のエンジニアがSLOCで測定されていることに気付いた瞬間、いくつかのことが起こります。
- 彼らは同じ機能を実行するためにはるかに長いコードを書き始めます
- 彼らは自分のコードの品質を気にしないでしょう
- 彼らはあなたのチームを助ける他のこと（採用、デバッグ、後輩の援助）をやめるでしょう
- 彼らは仕事を嫌い、おそらく去ります
2つの異なる会社で2回モラルが発生するのを見たことがあるので、士気を高めることがどれほど腐食性であるかを強調することはできません。どのように見える有効なユースケースであっても、その使用が見つかる可能性はわずかであっても、チームや会社に影響を与える価値はないでしょう。場合によっては、書き込まれる行数と有用な機能の量の間に相関関係がある場合でも、プログラマーのすべての誤った動作を促し、品質は重要ではないというメッセージを送信します。
一般に、生産性を測定する有効な方法とは見なされていません。通常、小さいコードは大きいコードよりも優れているため、より生産的な開発者は通常、生成するコードが少なくなります。生産性はデバッグで最大の打撃を受けます。効率的な開発者はデバッグにほとんど時間をかけません。
静的に型付けされた言語は、（言語間の他のすべての違いを制御する場合）より生産的です。賢明に使用すると、デバッグ時間が短縮され、コンパイルフェーズでエラーをキャッチし、修正が速くなるためです。
言語間の開発者の生産性を比較するために使用できる唯一のメトリックは、言語間のコードを比較しないメトリックです。一部の言語は悪名高い（レガシーWinのCOBOL）ものもあれば、1行のコードで実行できることを実行するためにいくつかの手順が必要なものもあります（アセンブリと他のすべてについて）。コードのアクティブな行のみを比較する場合（つまり、宣言をカウントせず、何らかのアクションが関与するコードのみをカウントする場合）でも、結果を歪める可能性があります。
変化率について議論することができるかもしれません。つまり同じ期間の生産性の勾配を比較するコード行が追加されました。ただし、コード行のマイナスの変更は考慮されていません。たとえば、コードをどこにでもコピーアンドペーストできるプロジェクトを継承したとします。いくつかの迅速かつ簡単なリファクタリングを実行して、繰り返されるコードブロックの数を減らします-定義により、負の勾配があります。
真剣に考えると、チーム/言語の生産性を比較することには意味がありません。チームの生産性に影響を与える多くの要因があり、チームから意味のある結論を導き出すことができないためです。
私は、インフラストラクチャが非常に壊れやすく、ツールが古くなっているプロジェクトに取り組みました。プロジェクトはJavaに基づいて構築されましたが、シングルページアプリケーションがそれに組み込まれていますが、明らかな利点がないためにポートレットコンテナでホストされています。単純な変更を行うのにかかる時間は途方もなく長いです。その特定のプロジェクトに基づいてすべての結論を下すと、Javaが悪かった、またはシングルページアプリが悪かった。どちらも当てはまらない。醜いプロジェクトが置き換えることになっていたシステムは、 C＃とWebFormsに基づいて構築されました。既存のアプリケーションを拡張して顧客のニーズに対応するビジネスケースを作成したとき、生産性が急上昇しました。つまり、密結合WebFormsアプリが優れているということですか？この特定のケースであり、世界全体に拡張されるわけではありません。拡張するのに十分な成熟度を持つ既存のアプリケーションがあったため、それはonlyに意味があります。
課題追跡システムでアイテムを解決する率を比較することでさえ、完全なプロジェクトインフラストラクチャを相互に比較しているという意味で欠陥があります。使用されるライブラリとフレームワークは、進行を加速または減速できます。あなたは、克服する慣性がほとんどない起動フェーズにある可能性があります。この場合、「より優れている」プロジェクトは、新しいチケットの数が比較的少ない保守フェーズにあります。同じようなものを比較することは決してありません。