コードの複雑さを評価する: サイクロマティック vs. コグニティブ

コードを理解するのはソフトウェア開発者にとって大事だよね。開発者がコードを修正したり直したりするとき、しっかり理解しておく必要があるんだ。もしコードが読みづらいと、ミスが増えたり、書いたりメンテナンスしたりするのに余計な手間がかかっちゃう。理想的には、開発者はあまり手間をかけずに理解しやすいクリアなコードを書いた方がいいよ。

#目的

この文では、McCabeサイクロマティック複雑性と認知的複雑性の2つの複雑性指標が、開発者がコードをどれだけ理解できるかを予測するのに役立つかどうかを調べているよ。どちらがコードのクリアさを評価するのにより良いかを見極めるのが目標だね。

#方法

そのために216人のジュニア開発者を対象にした研究を行ったんだ。彼らは1年から4年のコーディング経験があった。複雑性が異なる12のJavaクラスを見て、サイクロマティックと認知的複雑性の両方の指標を使用したよ。

#結果

認知的複雑性の方が、開発者がコードをどれだけ理解できるかを予測するのにサイクロマティック複雑性よりもわずかに優れていることがわかったんだ。

#結論

この調査から、コードの複雑性をしっかり測る指標を見つけるのはまだ難しいってことがわかったよ。伝統的なサイクロマティック複雑性も新しい認知的複雑性も、少なくともジュニア開発者にとってはコードの理解度を信頼できる形で予測するものではなかった。

#コードの理解しやすさ

コードの理解しやすさってのは、開発者がコードをどれだけ読みやすくて扱いやすいかってことを指すんだ。これには自分が書いたコードや他の人が書いたコードも含まれるよ。コードが読みやすいほど、問題を見つけたり修正したり、変更したり新機能を追加するのが簡単になる。その逆に、読みづらいコードは混乱を招いたり、エラーを引き起こしたり、長いトラブルシューティングに繋がるんだ。

コードの読みやすさにはいくつかの要因が関係してるよ。例えば：

• 明確でシンプルな構文
• 一貫したフォーマット
• 名前付けのルール
• 整理されたコード構造
• 良いドキュメンテーションとコメント

理解しにくいコードは、作業に必要な手間を50％以上増やすことがある。そのため、開発者はわかりやすいコードを書くことを目指すべきなんだ。

コードの複雑性を評価するために様々な指標が提案されていて、サイクロマティックや認知的複雑性もその中に含まれる。今では多くのツールがあって、開発者がリアルタイムでこれらの指標をモニターできるようになってるよ。

認知的複雑性はSonarQubeによって追加されて、コードの読みやすさをよりよく理解するためのものなんだ。以前の研究では、認知的複雑性が理解度を示すことがあるってことがわかったけど、高い値は理解しにくいことを示唆してる。だけど、開発者がその複雑さをどう捉えるかについては考慮されてなかったと思うんだ。

以前の研究でも、複雑さと理解度の指標はあまりよく研究されていないし、検証もされていないって指摘されてる。コードの理解度を予測する正確な指標はまだ不明なんだ。

#複雑性の指標

このセクションでは、私たちが調べた2つの複雑性の指標をざっくり説明するよ。

#サイクロマティック複雑性

サイクロマティック複雑性は1976年に作られた指標で、プログラムのコードに存在する独立した経路の数を測るんだ。独立した経路が多いほど複雑さが増すって考え方だよ。この指標は、コード内の実行経路を表す制御フローグラフに基づいてる。各経路は複雑さを加えると考えられているよ。

広く使われてるけど、サイクロマティック複雑性はすべてのコードの問題に対応できるわけじゃないんだ。特に複雑なシナリオでは、ネストされた条件やループに苦しむことがあるんだ。エラーが出やすいコードの評価には一般的な指標だけど、コードのクリアさを理解するにはあまり役立たないんだ。

SonarQubeのようなツールでは、コード内の意思決定ポイントが増えるとサイクロマティック複雑性も増加するけど、計算方法はプログラミング言語によって少し異なることがあるよ。

#認知的複雑性

認知的複雑性は、コードを理解する人間的な側面を見ているんだ。プログラムのすべての意思決定ポイントが同じってわけじゃなくて、中には理解しやすいものもあれば、そうじゃないものもある。だから、この指標は意思決定ポイントに難易度に基づいて重みをつけるんだ。もっと複雑な決定は高い重みがつくんだ。

認知的複雑性はサイクロマティック複雑性の問題に対処するために作られたんだ。どれだけの精神的労力が必要かを考慮して、あるコードの複雑さをよりよく理解することを目指しているよ。

認知的複雑性を計算するルールには以下が含まれる：

• コードを読みやすくする構造は無視する。
• コードのフローが壊れると複雑さが加わる。
• 制御構造がどれだけ深くネストされているかを考慮する。

#実証研究

私たちの研究は、サイクロマティックと認知的複雑性を比較して、どちらが開発者のJavaコードの複雑さの認識をよりよく反映するかを見ようとしたよ。以下がその手順だね：

#コードの選定

私たちは、理解しやすさに影響を与える様々な問題を含むJavaクラスを選んだんだ。評価者のグループが、全員が同意する問題を抱えたクラスを特定したよ。

#複雑性の測定

そのクラスのサイクロマティックと認知的複雑性をSonarQubeを使って計算したよ。

#開発者の選定

ジュニア開発者を参加者に選んだのは、彼らがしばしば慣れないコードを扱うからなんだ。Javaに親しんでいる216人のジュニア開発者が参加してくれて、全員が少なくとも1年のコーディング経験があったんだ。

#コードの確認

参加者は、クラスを手動で確認してコードの理解しやすさを評価したよ。彼らは4つのセクションに分かれたアンケートに記入したんだ：

• 回答者の背景、経験レベルを含む。
• コードの確認で、理解しやすさを1から5のスケールで評価（1が非常に簡単で、5が非常に難しい）。
• コード内の問題の特定と、それらの深刻度の認識も1から5のスケールで評価。

#データ分析

集めたデータは、開発者がコードの理解しやすさをどう評価したかに基づいて分析されたよ。知覚された理解しやすさと2つの複雑性指標の相関を統計的手法を使って調べたんだ。

#結果

216人の参加者からデータを集めたんだけど、大半の人がほとんどのクラスを理解しやすいとも難しいとも評価しなかったんだ。

認知的複雑性はコードの理解しやすさのより良い指標のように見えた。開発者はサイクロマティック複雑性と比べて、認知的複雑性の有用性には概ね同意していたよ。クラスが複雑でないときは、理解しやすいと見なされることが多くて、複雑さが低いほど読みやすさが向上するという考えを支持していたよ。でも、複雑さが高いと理解しやすさに関する意見が分かれたんだ。

統計分析からは、認知的複雑性が開発者の認識とより良く相関しているって重要な結果が明らかになったよ。

#問題の特定と問題の深刻度

この研究では、開発者がクラス内のコーディングの問題を特定できたかどうかも調べたんだ。ほとんどの参加者が少なくとも1つの問題を正しく特定したことから、開発者はコードを見るとデザインの問題に気づくことがあるってことが示唆されたよ。

特定した問題の深刻度については、開発者は平均して少なくとも中程度の深刻度と評価したんだ。つまり、開発者は見つけた問題を真剣に受け止めていたってわけだ。

#妨げる要因

研究の妨げになるいくつかの要因を考慮したよ：

#構成妥当性

関連タスクを慎重に選定して、分析されたクラスが同じツールからのもので、複雑さの認識に対する誤解を防ぐようにしたんだ。

#内部妥当性

ジュニア開発者を選ぶことで研究の焦点を保とうとしたけど、これがバイアスを引き起こす可能性もあるんだ。彼らのトレーニングレベルにはばらつきがあったかもしれないからね。

#外部妥当性

結果の一般性は懸念材料で、研究で使った特定のクラスセットを考えると、より広い結論を導くためには異なるコーディングの文脈での追加研究が必要かもしれないね。

#結論の妥当性

研究のデザインは、タスクが観察された結果に密接に関連していることを確保することを目指していて、専門家評価を行ってアンケートの妥当性を確認したんだ。

#今後の研究

今後の研究では、より大きな開発者グループを対象にして、問題に対処するためのリファクタリングの提案を求めることができるかもしれないね。また、ジュニアとシニア開発者の間でコードの理解しやすさに対する認識の違いを比較することで、さらなる洞察が得られるかもしれない。他のプログラミング言語も探求して、これらの傾向が異なるコーディング環境でも当てはまるかを見てみるのもいいかも。

#最後の考え

開発者がコードの複雑さをどのように認識しているかを理解することは重要なんだ。サイクロマティック複雑性も認知的複雑性も、コードの理解しやすさを示す完璧な指標を提供するわけじゃなかったけど、認知的複雑性は可能性を示したよ。開発の実践が進化する中で、コードをクリアで扱いやすくするための理解をさらに深めるための研究が続いていくだろうね。