ヒントみたいなもの 循環的複雑度

会社で、品質教育を受けた中で、面白い内容があったので、ちょっと紹介します。

 

「循環的複雑度（Cyclomatic Complexity）」こんな言葉、聞いたことがありますか？

私は知りませんでした。

この説明で一番分かりやすいのがここだと思います。

https://jp.mathworks.com/discovery/cyclomatic-complexity.html

 

内容については、記事を読んで欲しいのですが・・・

簡単に言うと、プログラムの開発で・・・プログラムの複雑度を客観的に評価できる手法があり、その複雑度を低くしましょう。（要は、なるべく単純なプログラムにしましょう、ってこと）　複雑度を低くすることで、プログラムの可読性、保守性、移植性が高まります。

ということです。

ロボカップジュニアのロボットのプログラミングもそうですが・・・品質をあげること（≒バグをなくすこと）が必要ですよね。

その時に、この循環的複雑度が高いと、バグが混入しやすい・・・まあ当たり前の話です。

ただ、今回、「なるほど！」と思ったのは、その複雑さを評価（数値化）する方法や、複雑さとバグの混入率が示されていたことです。

それによると・・・循環的複雑度が10以下だと、バグ混入率が25%なのに・・・循環的複雑度が50以上だと、テスト不可能だし、75以上だと「いかなる変更も誤修正を生む」と壊滅的な評価です。

ロボカップジュニアの競技会で・・・家や学校で、完ぺきにプログラミングをしてきたとしても、やっぱり競技会場で何らかの修正をする必要が出てくると思います。まず、現地での修正箇所をいかに減らすか（現地で修正しなくても良い様なつくり）を考えることと、その修正でバグが混入しないように、元々のプログラムの複雑度を低く抑えて置く・・・が良いようです。

 

と言っても、「言うは易く行うは難し」で・・・いろいろな想定を考えると、どんどん条件分けが増えて・・・プログラムもどんどん複雑化してしまうと思います。

だから、複雑度と可読性、保守性などのバランスなのだと思います。

 

ちなみに、プログラムを読ませて、この循環的複雑度を評価してくれるツールもあるそうです。（私は試してませんが・・・）

 

一連のノード大会を見て・・・

大会当日のパドックの中で、一生懸命にロボットの組み立てやプログラミング（プログラムの修正でなく、構築）をしているようでは、もうその時点で失敗でしょう。現地では、ちょっとプログラムを修正するくらいの完成度のロボットを持ってきて欲しいです。

 

（賛否はあるでしょうけど・・・）競技会当日は、もうやることが無くて、ブラブラして遊んでいられるくらい余裕があると良いと思います。（笑）