企画： QUEST（九州組込みソフトウェアコンソーシアム )

2011/9/4　やっぱり今年も暑かった･･･

九州大会特別企画！今年もやったのです！

• 去年からのあらすじ• 今年の着目点• 評価基準• 解析ツールで評価すると・・・• ツール解析結果から見える考察• 網膜から見える背景（解読容易性）• 総合レビュー結果から見えてくること• 評価結果っ！！！

モデル審査

走行タイム

ココ、ないね・・・では、評価しますか。

・・・というところから、　　昨年は“ミンナにやさしいソースコード”　　　　というテーマでレビューをしました。

基本だし。

命かけてるし。

“ ミンナにやさしいソースコード”　と言ったはいいが、何をすると“ミンナにやさしく”なる

のかを　今年は噛み砕いて、テーマにしてみました。

　それが、　　・清く（元々のコンセプト＜モデル＞が反映してい

る）　　・正しく（複雑度を上げず、色々なことを考慮してい

る）　　・美しく（正しいコメント、分かりやすいコメント）　です。

参加いただいたチームの皆さん！　です。今年は、皆さんの“清く・正しく・美しく”を評価させて頂き

ました。

評価した人：　片平性能審査団員、　松下性能審査団員

参加ありがとうございまし

た！ぱちぱちっ！

(*≧∇≦)/

TeamNo. Team Name 言語

133スーパー HTS くん cpp

202流し満貫 cpp

32Ｎｏｂｕ３ＳＷ（Ｒ） c

273Y 研ロボ ひびきの c

176チキン南蛮 c

257コアファイター c

静的解析ツールによる評価

目視（網膜→脳）による評価

★ ｃ言語：

QAC による解析結果の総合品質得点

★c++ 言語：

QAC++ による解析結果の総合品質得点

・構成（機能、戦略、データなどがキチンとまとめられているか？）

・見易さ（解読容易性）・・・コメントの適正さ、ソース構造の分かりやすさ

・戦略的対応（難所攻略・コース戦略）

　　　　　　　　　　　　　　　　　　　　　　　　　　　　使用ツール：評価委員の網膜と脳

使用ツール：

・障害に繋がる指摘数（減点項目）・複雑度（加点項目…複雑度が低いほうが良い）・最大ネスティング数（加点項目・・・数が少ないほうが良い）

　ツールによる評価点＝減点項目＋加点項目

・構成（基本評価項目１〜５）・ソースコメント（基本評価項目１〜５）・戦略的アルゴリズム（基本評価項目１〜５）・難所攻略（加点項目０〜３）

　目視による評価点＝基本評価項目＋加点項目

静的解析ツールによる評価

目視（網膜→脳）による評価

• Ｃの場合（ QAC ）

指数化、発見数などがクラス毎などで数値化されます。

警告の内容を、警告別に html(txt) 表示できます。

• Ｃ＋＋の場合（ QAC++ ）

• 今年は、昨年と違う非常に面白い傾向が見られました。

　　ツールにおいては、“正しく” = 障害指摘数、“美しく” = 複雑さ、煩雑さを主に見ましたが、ソースコードのボリュームと反比例し、記述内容が多いチームほど、“正しく、美しく”記述されているという傾向が見られました。よく考えているチームほどよく整理されている、という本来あるべき姿といえます。

• 今年は、見やすさだけでなく、いかに“考えぬいているか”も評価の対象にしました。

• 難所攻略やコース戦略性などソースコードから読み取れる“思慮”を読み取ることにしました。そうすると非常に面白い結果が出てきました。

• 結果からいうと“清く（思慮深い）” （戦略的・難易度が高い）ソースほど、キチンと整理されている、という傾向が現れています。

• 今年の総合レビューでは、評価する側から見ると、とても嬉しい結果になっています。

　　それは、熟慮を重ね、新しいコト・難しいコトにチャレンジしたチームほど、

　　　　“清く・正しく・美しく”“清く・正しく・美しく”　ソースを書いているという事実です。

※ツール高評価のチームは目視も高評価

では、いよいよ、・金賞（ｃ＋＋言語部門）・金賞（ｃ言語部門）の発表をします！

・金賞（ｃ＋＋言語部門）は、

　“スーパー HTSくん“　さん　　　　　　　　　　　　　　ですっ！

所感：　総合得点４８点　ツール評価・目視評価とも高得点でした。目視で確認した

難易度の高いアルゴリズムも、ツールで確認した複雑度やネスティング回数などで、複雑すぎないようにキチンと整理されていることが伺えます。

・金賞（ｃ言語部門）は、

　“Ｎｏｂｕ３ＳＷ（Ｒ）”さん

　　　　　　　　　　　　　　ですっ！

所感：　総合得点４４点　ツール評価・目視評価とも高得点でした。目視での確認で

は全ての難所に対して攻略が記述され、なおかつ、考えぬいた戦略が伺えました。またファイル・フォルダ構成、ソースコメントなど、分かりやすさを優先していてお手本的なソースコードといえます。

・総評　　今年の評価では、ツール評価と目視評価において、相関関係がみられました。

　　受賞したチームはともに評価が高く、難所攻略やコース戦略を考慮しソースの難易度・複雑度は本来、高くなるはずですが、キチンと整理されていることが分かります。

　　“見られる“ことを意識したのかはわかりませんが、コーディングという技術として考えた場合、難しい事を整理しながら解決していった事が見て取れます。評価の低いチームはにも逆の相関性が見られ、典型的な”書き散らし”が見て取れました。

• 最後に、ちょっと、オマケ・・・　　ーー；

• 今後、 MBD,MDD が定着していくと、ソフトウェア開発体制には、“モデラー、モデル・クリエーター”という階層が出来ていくと思われます。今、我々が SE,PG と呼んでいる職業のちょうど中間なのかもしれません。　 MBD,MDD が普及し浸透していくと、ソースを書く（修正）するという作業は開発作業全体からみれば少なくなっていくでしょう。　このレビュー自体の意味が重要視されなくなり、淘汰されいく未来が我々の望む未来なのかもしれません。　

• UML からカリカリ書いてたなぁ・・・、ソースコード・レビューなんてやってたよねぇ、 ET ロボコンで・・・、なんて時代に早くなるといいと思ってたりしてます。（そうならなきゃ、いけないんだけどさ・・・）