ベストプラクティス #1 – 抽象化レイヤーを使用して依存関係を削除するコードベースをレビューする際によくある問題の一つは、開発者がアプリケーションコードと使用するソフトウェアライブラリを密接に統合していることです。例えば、開発者がFreeRTOSを使用している場合、アプリケーションコードはFreeRTOS固有のAPIを呼び出すため、RTOSを変更すると、それらのRTOS呼び出しをすべて置き換えるために、かなりの量のコードを書き直す必要があります。ライブラリの変更はまれだと思うかもしれませんが、オペレーティングシステム、ライブラリ、またはコンポーネントからパスを開始し、変更が必要になったときにコードを書き直さなければならないことがいかに多いか、驚くことでしょう。 オープンソースや商用コンポーネントを選択する際にチームが最初に行うべきことは、そのコンポーネントと連携するための抽象化レイヤーを作成することです。RTOSを例に挙げると、チームはOS抽象化レイヤー（OSAL）を使用します。これにより、OSに依存しないAPIを使用してアプリケーションコードを記述できます。オペレーティングシステムが変更されても、アプリケーションは抽象化レイヤーにアクセスしているため、変更を気にする必要がありません。また、ソフトウェアの変更は数日ではなく数分で完了する可能性があります。 ベストプラクティス2 – 統合ソフトウェアを可能な限り活用するほとんどのオープンソースソフトウェアは、相互作用する可能性のある他のコンポーネントをあまり考慮せずに、独自のサンドボックス内で開発されています。コンポーネントは、異なるコーディング規約、スタイル、テストレベルで開発されることがよくあります。組み込み開発者が、連携を想定していない複数のオープンソースコンポーネントを組み合わせると、デバッグに長時間を要し、納期に間に合わない可能性があります。可能な限り、既に統合・テスト済みのコンポーネントを選択するのが最善です。 良い例としては、Amazon FreeRTOS を使用して AWS に接続することが挙げられます。FreeRTOS は、クラウド接続に必要な他の接続ライブラリと既に統合およびテストされているため、他のライブラリもテストおよび統合されていない場合は選択しないでください。もう一つの例は、多くのマイクロコントローラーメーカーが提供しているコード生成ツールです。これらのツールは通常、ドライバーソフトウェアコンポーネント、RTOS、ファイルシステム、USB、その他複数のコンポーネントを統合しています。これらは連携して動作することが実証されているため、活用することで時間とコストを節約できます。 ベストプラクティス3 – ソフトウェア監査と品質分析の実施優れたオープンソースソフトウェアプログラムは数多く存在しますが、そうでないプログラムも数多く存在します。開発者がプロジェクトでオープンソースコンポーネントを使用することを決定する前に、ソフトウェアのデューデリジェンスを必ず実施する必要があります。これには、コンポーネントの監査と品質分析に時間を費やすことが含まれますが、品質はしばしば外部の目によって左右されます。 少なくとも、オープンソース コンポーネントの使用を開始する前に、ソース コードを確認する必要があります。
少なくとも、組み込み開発者が何を使用しているか、また潜在的な問題や落とし穴を理解するのに役立ちます。 ベストプラクティス4 – 弁護士にライセンスをレビューしてもらうオープンソースソフトウェアのライセンス管理は、12種類以上のライセンス体系があり、ユーザーに様々な要件を課すため、複雑になりがちです。開発者がオープンソースソフトウェアを適切と判断した方法で使用できるケースもあれば、ソフトウェア自体は使用できるものの、他のソフトウェアもオープンソースであることが必須となるケースもあります。この場合、製品の秘密の製法を公開する必要が生じ、競争上の優位性が損なわれる可能性があります。 近年、これらのライセンスはより分かりやすくなっていますが、製品開発者は事業を営んでいるため、ソフトウェアライセンスの審査を弁護士に依頼し、すべてが適切であることを確認する必要があります。追加費用は発生しますが、事業運営にかかるコストの一部であり、万が一エラーが発生した場合でも、長期的にはコスト削減につながります。 ベストプラクティス #5 – 活発なコミュニティからソフトウェアを選択する問題を解決するソフトウェアコンポーネントを見つけるために、Webを素早く検索したり、GitHubをじっくりと読んだりしたくなるのは当然です。しかし、オープンソースコンポーネントを選択する際には、組み込み開発者にとって、そのコンポーネントに活発なコミュニティがあることを確認することが重要です。 例えば、FreeRTOS を使用している開発者は、フォーラムにアクセスして質問すれば、通常はすぐに回答が得られることを知っています。新しいバージョンは定期的にリリースされ、ソフトウェアは新機能の追加によって常に改善されています。コミュニティが活発でないコンポーネントを選択すると、開発者が孤立し、自ら問題を見つけざるを得なくなったり、最悪の場合、コンポーネントのメンテナンスを強いられる可能性があります。 結論はオープンソースソフトウェアを適切に活用することは、開発チームに大きなメリットをもたらします。しかし、成功するためには、開発者はオープンソースコンポーネントに関して十分な情報に基づいた選択を行う必要があります。これには、アプリケーションの柔軟性と保守性を維持するためにコンポーネントを抽象化することが含まれます。また、Linux以外のオープンソースソフトウェアについては、コンポーネントをコミットする前に、品質と一般的な要件が満たされていることを確認するために、慎重な審査も必要です。 これらのベスト プラクティスに従うことで、組み込み開発チームは、製品の遅延、ソリューションの設計不足、品質の問題、および製品開発中に頻繁に発生するその他の多くの問題につながる泥沼を回避することができます。 |
