この記事は？
使用するサードパーティライブラリをどう評価するか迷ってたときに、tenntennさんがGopher道場の動画(「4.1. パッケージ」というパート)でおっしゃっていたことが参考になったのでその際のメモ。
Gopher道場の動画は、専用Slack上にて配布されているので気になる方は、まずこちらからSlackにご参加ください。
選定の際に確認すること
GitHubのstarsを確認する
これは、Goに限らずあらゆる言語で適用できる方法であり、一般的にもよく知られていると思われる。
そのライブラリのGitHubリポジトリを見れば、Star数が確認でき、この数が大きいとちょっと安心できる。がしかし、これだけで決めてしまうのはまだ早い。
Go docを確認する
機能を確認する
Goにはgo docというパッケージのドキュメントをブラウザで確認できるようにする仕組みがある（例: https://pkg.go.dev/github.com/gorilla/mux）。
go docを見て、そのパッケージに搭載されてる機能が、自分の求めている機能に過不足がないかを調べる。備わっている機能が求めている機能よりも不足していたらもちろん選択するべきではないが、過剰すぎる場合も注意が必要とのこと。
そもそもサードパーティ製のものを使うということは、自分の（チームの）プロジェクトに、自分（チームメンバー）以外の誰かの事情が入ってくるということ。つまり、その運用保守のことも考える必要が出てくる。そのため、なるべき依存関係を増やしたくないので、不用意な依存関係が増えるものは、控えた方が無難。
依存関係を増やしたくない理由は、一度依存してしまうと、その依存関係を取り払うのが大変になる可能性が高いため。
ちょっとした機能であれば、下手に依存関係を増やすよりは自分で作ったり、コピペしたほうが良いとのこと。これは、Go言語の生みの親であるRob PikeさんもGo Proverbsで
“A little copying is better than a little dependency.”
と、同じようなことを述べている。
サードパーティのライブラリを増やすということは、依存関係を増やすことなので、選定は慎重に行うべきとのこと。
imported byを確認する
導入を検討しているパッケージのgo docのページにImportedByというタブが存在し、それを押すと、そのパッケージがどんなパッケージからinportされているかが確認できる（例: https://pkg.go.dev/github.com/gorilla/mux?tab=importedby）。著名な論文が、引用している論文は著名である可能性が高いように、偉大なパッケージで使われていればそのパッケージも偉大である可能性が高いと考えていいだろう。
その他の確認すること
上記の他にもREADMEは充実しているか。リリースサイクルは安定しているか。バージョンの更新が滞ってないかなどは確認すると良さそうとのこと。
最後に
今回はGoに限った話だったが、Go以外での技術選定をするときも肝となるところは同じなように思う。 目的の実現度や費用対効果、長く使い続ける場合は将来性なども含め、よく考えて技術選定を行い、高い開発効率を維持しながら楽しく開発をしたい。