チームでの開発において、あらかじめライブラリの選定基準を決めておくことで、開発を円滑に進めることができます。 これは、経験の浅いメンバーがいるチームで特に有効です。 このことについて、例などを交えて解説します。

基準を決めておく理由

選定基準をあらかじめ決めておくことで、以下のようなメリットがあります。

1. 導入に関するコミュニケーションをとりやすくなる

「このライブラリ、どうでしょうか?」といった曖昧な議論ではなく、「この基準にだけ懸念があるのですが、どう思いますか?」といった、より具体的な話ができるようになります。

2. 使うべきでないライブラリの導入を未然に防げる

特に経験が浅い場合、なにがよくてなにが悪いかが判断しづらく、とりあえず相談、という流れになりがちです。

相談自体はもちろん悪いことではないと思います。 ただ、自分で判断した方が成長につながりますし、またフィルタリングされた上での相談の方が、受ける側もより的確なアドバイスができるでしょう。

3. リスクが明確になり、事前に対応できる

基準を決めておくことで、仮にその基準を満たさない場合でも、事前にそのリスクを想定した上で対応をとることができます。 例えば、有用なライブラリだが長い間メンテナンスされていない場合、forkしてパッチをあてる、といったコストが事前に想定できます。

基準例

以下に、例としてRailsアプリケーション開発におけるGemの選定基準例を示します。 これはチームの環境によって異なると思いますが、参考にしてみてください。

  • GitHubにリポジトリを持つこと
  • Starが100以上ついていること
  • 直近1年でコミットがあること
  • コミットの頻度が1回/月以上あること
  • Issue/Pull requestが放置されていないこと
  • ライブラリ依存が少ないこと
  • アプリケーション本体と疎結合に導入できること
  • ドキュメントが充実していること
  • 検索エンジンで情報が十分に収集できること
  • 必要としているテストケースにパスしていること

基準を共有する

基準を決めたら、それをチームのWikiなどにドキュメントとして落とし込みましょう。 また、READMEなどからリンクを張り、開発の際に参照しやすいようにするといいと思います。

おわりに

すべての基準を満たすライブラリ、というのはなかなかないでしょう。 ただ、「この基準だけは満たさない」といった議論になれば、それに対して事前に対応することができます。

スタートアップはスピードが重要なので、基準を設けた上で、柔軟に対応していければよいでしょう。