要件が曖昧だったり複雑になるとライブラリの選定が一気に難しくなる気がする。
方法論を少し考えたい。
思想や手法のパターン
- 「もっと早く知っていれば...」とならないための、開発効率を最大化するライブラリとの向き合い方・探し方・使い方
- 非機能要件 - Wikipedia
- ソフトウェア品質 - Wikipedia
基準パターン
軸
- 依存度
- 責務・守備範囲
- 速度
- コントロールの見た目や機能性
- サポートの安心感
- メンテナンス性
- ベンダー製のコンポーネント故のブラックボックス化
- コンポーネント側に不具合があった場合の対応
- バージョンアップのたびに買い換えが発生するか
- 学習コスト
- 実行環境
- 言語
基準例（採用基準・不採用基準）
- GitHubにリポジトリを持つこと
- Starが100以上ついていること
- 直近1年でコミットがあること
- コミットの頻度が1回/月以上あること
- Issue/Pull requestが放置されていないこと
- ライブラリ依存が少ないこと
- アプリケーション本体と疎結合に導入できること
- ドキュメントが充実していること
- 検索エンジンで情報が十分に収集できること
- 必要としているテストケースにパスしていること
現状の考え
- 前提
- 個人レベル
- 技術力はそんなに高くない
- 要件が詰めきれていない
- 技術の進歩が早い
- 柔軟性、拡張性が求められる
- 機能要件や一般基準から逸脱した特性を洗い出してある
- 選定の考え
- 機能
- 特に気をつけるべき要件を満たすか
- 非機能
- 完全性
- 保守性
- コード品質
- 個人の手に負えるか
- 理解不足でもバージョン固定すれば済ませられるか
- セキュリティに懸念はないか
- ある程度カスタマイズできる（拡張API、シンプルな構造）
- 責務が小さく代替が考えられる
- 機能
まとまんね。個別の場合で考えた方がいいかな。。
非機能の品質の検討軸で初期段階で重要視しないものがあるけど、
それを重要視しなかったこととか、あとあと必要になったとかを記録していくといいのかもな。
参考
http://konifar.hatenablog.com/entry/2015/05/14/184237
http://www.buildinsider.net/pr/grapecity/wijmo/01
http://qiita.com/kentya6/items/731eba21a9802f606044