序文オープンソースソフトウェアは広く普及しており、企業の開発を加速させ、ソフトウェアの品質を向上させる可能性を秘めています。しかし、慎重に扱わなければ、問題を引き起こす可能性があります。 オープンソース ソフトウェアを効果的に活用するための 5 つのベスト プラクティスを紹介します。 1. 抽象化レイヤーを使用して依存関係を解決します。コードベースをレビューする際によく見かける問題の一つは、開発者がアプリケーションコードと使用するソフトウェアライブラリを密接に結び付けていることです。例えば、開発者がFreeRTOSを使用している場合、アプリケーションコードがFreeRTOS固有のAPIを呼び出す方法を考えると、開発者がRTOSを変更すると、それらのRTOS呼び出しをすべて置き換えるために、かなりの量のコードを書き直す必要があります。 ライブラリを変更することはまれだと思うかもしれませんが、チームがオペレーティング システム、ライブラリ、またはコンポーネントの使用を開始した後で、変更が必要であると判断したときに、コードに戻って書き直さなければならないことがよくあると知ったら、驚かれることでしょう。 チームがオープンソースコンポーネント、あるいは商用コンポーネントを選択した場合、まず最初に行うべきことは、そのコンポーネントと連携するための抽象化レイヤーを作成することです。例えば、RTOSの場合、OS抽象化レイヤー(OSAL)を使用することで、OSに依存しないAPIを用いてアプリケーションコードを記述できます。 オペレーティング システムが変更されても、アプリケーションは抽象化レイヤーにアクセスしているので気にしません。ソフトウェアの変更には数日ではなく数分しかかからない可能性があります。 2. 統合ソフトウェアを可能な限り活用する。ほとんどのオープンソースソフトウェアは、他のコンポーネントとのやり取りを考慮せずに、独自のサンドボックス内で開発されています。コンポーネントは、異なるコーディング標準、スタイル、テストレベルなどを使用して開発されることがよくあります。 連携動作を想定していない複数のオープンソースコンポーネントを組み合わせると、デバッグ作業の長期化、問題の発生、納期の遅延につながる可能性があります。そのため、可能な限り、既に統合・テスト済みのコンポーネントを選択してください。 良い例としては、Amazon FreeRTO を使用して AWS に接続することが挙げられます。FreeRTOS は、クラウド接続に必要な追加の接続ライブラリと既に統合およびテストされているため、他のライブラリもテストおよび統合されていない限り、選択しないでください。別の例としては、多くのマイクロコントローラーメーカーが提供しているコード生成ツールが挙げられます。 これらのツールは通常、ドライバソフトウェアコンポーネント、RTOS、ファイルシステム、USB、その他のコンポーネントを統合します。これらは効果的に連携し、時間とコストを節約できることが実証されています。 3. ソフトウェア監査と品質分析を実行します。優れたオープンソースソフトウェアプログラムは数多く存在しますが、理想的とは言えないプログラムも数多く存在します。開発者がプロジェクトでオープンソースコンポーネントを使用することを決定する前に、ソフトウェアのデューデリジェンスを実施するか、デューデリジェンスを実施する専門家を雇う必要があります。これには、コンポーネントのレビューと品質分析に時間を費やすことが含まれます。 オープンソース コンポーネントの使用を開始するときは、少なくとも、循環的複雑度を使用して測定された複雑度、ビジネスのニーズと目標を機能的に満たしていることの確認、ベスト プラクティスとコーディング標準への準拠 (必要に応じて)、エラー処理機能、およびテスト可能性など、ソース コードの次の側面を確認する必要があります。 これにより、開発者は少なくとも、何を使用しているか、また潜在的な問題や落とし穴を理解するのに役立ちます。 4. 活発なコミュニティからソフトウェアを選択する問題を解決するソフトウェアコンポーネントを、Web検索やGitHubで簡単に見つけたい誘惑に駆られることはよくあります。オープンソースのコンポーネントを選ぶ際には、活発なコミュニティがあることを確認することが重要です。 これには、フォーラムでの質問への迅速な回答、新バージョンの定期的なリリース、新機能の追加に伴う継続的な改善などが含まれます。活動の少ないコミュニティからコンポーネントを選択すると、開発者が自ら問題を解決しなければならなくなったり、最悪の場合、コンポーネントのメンテナンスを余儀なくされたりする可能性があります。 5. ライセンスは弁護士によって審査されます。オープンソースソフトウェアのライセンスは複雑になりがちです。10種類以上のライセンススキームがあり、それぞれユーザーに対する要件が異なります。開発者が適切と判断したオープンソースソフトウェアを使用できる場合もありますが、ソフトウェア自体は使用できるものの、その他のソフトウェアもオープンソースであることが必須となる場合もあります。 近年、これらのライセンスはより分かりやすくなっていますが、製品開発者は事業を営んでいるため、ソフトウェアライセンスの確認のために弁護士を雇う必要があります。これは追加費用となりますが、全体的なコストの一部であり、長期的には節約につながる可能性があります。 結論はオープンソースソフトウェアを適切に活用することは、開発チームに大きなメリットをもたらします。しかし、成功するためには、開発者はオープンソースコンポーネントを慎重に選択する必要があります。これには、アプリケーションの柔軟性と保守性を維持するためにコンポーネントを抽象化することが含まれます。また、オープンソースソフトウェアが品質と一般的な要件を満たしていることを確認するために、慎重に検証することも必要です。 これらのベスト プラクティスに従うことで、チームは、製品の遅延、ソリューション アーキテクチャの不備、品質の問題、および製品開発中に頻繁に発生するその他の多くの問題につながるソリューションに行き詰まることを回避できます。 |