ライブラリの評価 (2)
あるライブラリをプロジェクトで使用するかどうか決める場合、まずはそのライブラリの合目的性や実績、サポート、ドキュメントの充実度、ライセンス、提供次期、価格などを検討しますが、私はその後で、そのライブラリの "C++ライブラリとしての素性の良さ" を検討することにしています。素性の良いソフトウェアかどうかを先に検討することで、
- 作成するアプリケーションの設計/実装に本来不要な制約をもちこまない
- 挙動不審なライブラリを採用しない
ことを可能にします。
なるべく客観的に評価したいので、次のようなチェックリストにしています。人材の採用や賃貸物件探し等と同様、条件を付けすぎるとヒット0件となってしまうので、ここだけは譲れない、というものを中心にリスト化してあります。
C++のAPIレベルの、少々泥臭い検査になりますが、それでも形式化しておいてイベントにしておく意味はあると思います。だってある規模以上のベンダさんの書くような、薔薇色の売り文句を見たら、中身がクソかどうかを確認する間もなくそのライブラリ、無条件で欲しくなっちゃうじゃん。
【チェックリスト1】
理由・目的：ライブラリがアプリケーションの設計・実装に制限を与えないことを確認
Requirements:
- 例外安全性について考慮された設計・実装である
- マルチスレッド環境での使用について考慮された設計・実装である
- 最低限、局所的静的変数を使用していない
- MT-unsafe なリファレンスカウントを行っていない
- etc..
- 型安全性について考慮された設計・実装である
- 最低限、総称ポインタを使用しない設計・実装である
- メンバ関数自体、およびメンバ関数の引数が、適切にconst指定されている
- LP64環境での使用について考慮された設計・実装である
- 標準C++との親和性について考慮された設計・実装である
- 非局所的静的変数を使用していない
- ライブラリ使用者を "static initialization order fiasco" に巻き込まない
- 広域名前空間を汚染しない
【チェックリスト2】
理由・目的：ライブラリ使用者が、ライブラリの挙動を読みやすいかどうかを確認
Requirements:
- 例外を投げるなら、その仕様が明記されている
- 時間のかかる処理については、処理のオーダーが明記されている*1
- メモリ使用量が明記されている
- 限界値付近での挙動が明記されている
- 数の数え方が一貫している(符号有無、ビット幅)
- インデクスの付け方が一貫している(符号有無、ビット幅、0 or 1オリジン)
- オブジェクトが状態遷移するなら、その仕様が明記されている
- 「メソッドBはメソッドAを呼んだ後でないと呼べない」ならマニュアルに明記されている、デバッグモードでは違反時に実行時エラーで止まる
- 状態遷移しないならなおよい
【チェックリスト3】
理由・目的：ライブラリの設計者・実装者のスキルを確認*2
Requirements:
- テストがきちんと行われている事が見込める
- 設計書に、次が記載されている
- データ構造(list, hash ...)、あるいは処理のオーダー
- メモリ使用量
- セキュリティホールがないことが見込める*4
- メソッドの事前条件、事後条件、クラスの不変条件が書かれている
如何でしょう。実際には、「Effecive C++ に書かれているような『常識』を全く知らない人が書いたライブラリは即刻却下」などの主観も交えてしまっているのが、多少悩ましいところではあります。
