コード品質をテーマとした一連の記事で、品質、特にコード品質は、様々な角度から攻撃できる（そしておそらく攻撃すべき）広範なトピックであることを示してきた。シリーズの最終回となる今回は、最も重要なトピックのいくつかを要約し、強調することにしよう。
コード品質とは何か？
ロバート・M・ピルジグの「Zen and the Art of Motorcycle Maintenance（禅とモーターサイクル・メンテナンスの技法）」を読んだことがある人なら、品質を定義するために多くの労力を費やすと、人生にかなり劇的な影響を及ぼす可能性があることを知っているだろう。だから、ここからは慎重に話を進めよう。
すべての状況に適用できるコード品質の単一の定義があるわけではなく、何が良いコード品質を構成するかについて、さまざまな測定基準や提案のスペクトルがある。そのいくつかを紹介しよう：
- 欠陥の数が少ないこと。これは表面的には明らかなことだが、実際には何を意味し、どのように測定するのだろうか？もちろん、発見された不具合を時系列で数えるなどして統計的に測定する方法はあるが、不具合が発生する状況や文脈について何も語らないという点で、かなり主観的な測定方法である。
- コードが保守可能であること、これは読みやすく、合理的な努力で理解できることを意味する。これも非常に主観的な問題で、2人以上のソフトウェア開発者が同じ定義を持つ可能性はゼロに近い。
- コードの全体または一部が、他のソフトウェアプロジェクトで再利用可能である。再利用しやすいかどうかを測る客観的な方法はないからだ。
- コードが安全でセキュアである。ご想像の通り、かなり難しい概念だ。私たちは、平均故障間隔や、時間の経過とともに発見されたセキュリティ欠陥の数など、さまざまな統計的尺度を使うことができる。しかし、それは、時間が経つにつれて良くなるか悪くなるかを教えてくれるだけであり、現在の状況を大まかに教えてくれるだけだ。
- コードの複雑さ - コードベースの複雑さを測定するさまざまな方法があり、複雑さはおそらく他のすべての尺度に影響を与えるので、コードの複雑さはできるだけ低く保つことが重要であると主張することができる。しかし、複雑さの指標として使われるものの中には、指標を下げるかもしれないが、同時に可読性や保守性も下げるような方法でコードを書き換えることを推奨するものもあり、それはおそらく私たちが意図したものではないだろう。
上記の例に共通するテーマのひとつは、これらの品質は事後的にしか測定できないということだ。このような測定は、進捗を測定するためには重要かもしれないが、実際にどのようにこれらのスコアを進歩させるかについては、あまり役に立たない。もうひとつの教訓は、良い品質を定義するのは難しいかもしれないが、そうでない品質に触れたときにそれを認識するのは極めて簡単であることが多いということだ。
繰り返されるテーマ
組込み機器向けのソフトウェア開発には、他のソフトウェア開発と同じ課題が多くあります。しかしその上、私たちはしばしば、ミッションクリティカルな機能を実行するデバイス、敵対的な環境や非常に離れた場所に配備されるデバイス、コイン電池で永遠に動作することが想定されるデバイスなど、デスクトップやサーバーのソフトウェア市場ではめったに起こらないような、困難な配備シナリオを扱っている。
このシリーズを通して、私たちが常に立ち戻っていることが1つある。それは、前もって準備することで、コードの品質、安全性、セキュリティ（これらの用語をどのように定義するかは別として）を向上させ、眠れない夜を減らすことができるということだ。
セキュリティから始めよう
今日、まったく新しい製品のアイデアを念頭に置いてスタートする場合、あるいはすでにある設計の上に段階的に構築する場合、デバイスに何らかの接続性を追加する可能性が非常に高い。それがWiFiであろうと、Bluetoothであろうと、ZigBeeであろうと、あるいは有線接続であろうと構わない。ここ数年の自動車におけるCANバス・ハックの多様性を考えてみてほしい。その決断をした時点で、あなたは将来、ハッキングやクラック、デバイスの完全性の危険にさらされる可能性があるのだ。その上、接続されたIoTデバイスに関して世界中で施行されつつある地域法にもさらされている。このような法規制の焦点は、現在、機密性の高い個人データなどの保護と完全性に置かれているが、ソフトウェアの完全性を確保することで、脆弱なデバイスから別のデバイスへと飛び火するカスケード攻撃を阻止することにも向けられている。
プロジェクトの初期に行うセキュリティ関連の決定は、生産と配備、そして製品のライフサイクル全体を通じて影響を与えることになる。さらに、プロジェクトの後半になってセキュリティ関連の決定を変更することは、非常に高くつくか、不可能に近いかもしれない。したがって、たとえ、今のところセキュリティを無視するという意識的な決断をしたとしても、後日、その決断を再検討しなければならなくなったときのために、自分自身を窮地に追い込まないようにしなければならない。Clive Wattsは、彼の記事How to cover the best security practices by designで、考慮すべきことを徹底的に説明している。
分析する
このシリーズでは、さまざまな文脈における静的解析と実行時解析について、広く話してきた。組込みの世界では、私たちは主にCとC++でソフトウェアを書いているが、これらの言語はそのままでは信頼性の高いシステムを書くのにあまり適していないと言うことができる。これらの言語には、未定義の動作や実装で定義された動作が大量にあり、ある任意のツールやハードウェアの組み合わせでは動作するコードが、別の組み合わせでは失敗する可能性があるということだ。言語にはこのような不明瞭なコーナーが大量にあるため、ベテランのプログラマーでさえ覚えるのはほとんど不可能だ。さらに、単純なタイプミスによって、コンパイルはできても、意図とはまったく異なる動作をするコードに変わってしまうこともある。
機能安全要求事項を扱うのであれば、MISRAのような専用のコーディング標準に従うことで、問題のある言語構造を排除することが強く推奨されることはすでにご存じでしょう。しかし、私たちは、組込みシステム向けのソフトウェア開発では、奇妙で難解な言語ルールの結果である不具合を取り除くために、明確に定義された言語のサブセットを使用することが有益であると主張したいと思う。MISRAの一連のガイドラインは優れた出発点だが、接続されたシステムについては、CERTCも考慮すべきだ。組込み関連の CWE のかなりの部分は MISRA や CERTのルールでカバーされていますが、CWE の取り組み全般について読んでおいても損はないだろう。
そして、この文章でコード品質について、かなりとらえどころのないものであると話してきたことを考えると、自動化されたコード解析は、厄介なコード構造をすぐに強調表示することによって、コード品質を向上させるために、初日から役立つ。解析結果に基づいて行動することで、将来問題に見舞われるのではなく、今問題を取り除くという非常に具体的な方法で品質を向上させることができる。
MISRAのような言語サブセット標準と、言語サブセットでカバーされていないものに対する独自のコーディング標準を組み合わせて適用することも、一貫性を保つのに役立つ。これには、命名規則、モジュールへの機能のまとめ方、グローバルにアクセス可能な変数やデータ構造の使用ルール、volatileキーワードの使用方法とタイミングなどが含まれる。明確なルールのセットと、できればそのルールを守るためのツールのサポートがあれば、コード品質の向上に大いに役立つだろう。
使うか、失うか
コード品質を向上させ、同時に全体的な生産性を向上させようと考えているのであれば、適切なツールを使うことが鍵となる。欠点は、いくつかの機能やプロセス改善のために新しいツールが必要になることだが、利点は、すでに利用可能なツールを持っている可能性があることだ。先見の明のあるマネジャーが、すでに分析ツールなどをあなたの組織に提供しているかもしれない。
自分の開発環境で利用可能なツールについて調べることは、以前は気づかなかった特徴や機能を見つけることができれば、非常に良い投資となるかもしれない。ユーザーからのフィードバックから判断すると、かなり高い確率で、デバッガーにあなたが気づいていなかった機能が見つかるだろう。失敗したらマニュアルを読め」ということわざがあるが、これはかなり正しい。ほとんどの場合、自分が知っていてよく使うツールの機能や機能の中で快適に過ごすことができる。しかし、とげとげしい問題に見舞われたとき、事前にマニュアルを読んでおくと得をする。
未解決の問題を解決する
この連載の過去の記事を読んでいただいた方は、コード・クオリティを攻略する上で何か新しい発見があったのではないだろうか。私たちが発見したように、コード品質を構成するものを明確に定義することは非常に難しい。しかしその一方で、質の悪いコードを書くのを最小限に抑える方法について、多くのツールやアイデアを紹介した。
もうひとつの重要なポイントは、コード品質に集中することで、多かれ少なかれ自動的に、より安全で、よりセキュアで、より信頼性が高く、より保守しやすいコードになるということだ。私に言わせれば、これは本当に素晴らしい副次的効果だ！ だから、コード品質から始めることは、コード品質で終わることでもあるのだ。
