続き書きました。 続: Go入門したときに開発環境を考えた話
Goを初めて1時間の人間のメモです。ベストプラクティスやご指摘等あればよろしくお願いします。
Goを書き始めるにあたって以下のことがしたかったです。
- さっくり関数を書いて、単体テストを通すことでGoの勉強がしたい
- GOPATHに依存したくない
- 本コードとテストをキッチリ分けたい
まず、GOPATH自体には特に問題なく受け入れることができました。Goには、便利なCUIツールが多く存在するので、そう言った目的では、昔からGo(go get)を利用してきました。しかし開発時に、$GOPATH/src下にプログラムを書いていくのは、受け入れることができませんでした。常に本格的な開発をするならば、とてもいい機構だと思いますが、現状のような初心者ではグローバル空間を汚染しながらプログラムを書くのは気が引けます。もっと気軽に書いて消してを繰り返したいと考えました。
テストコードを書くに辺り公式マニュアルを漁っていたところHow to Write Go Codeという素晴らしいリンクを発見しました。そこには、局所的にGOPATHとコマンドサーチパスを変更・追加する手法が載っていました。しかし、気軽に作って消してを繰り返したい自分としては毎回、環境変数の「状態」を意識するのはツライなあと思いました。
$ export GOPATH=$HOME/work
$ export PATH=$PATH:$GOPATH/bin
さらに、ビルドやtestの度にパッケージを指定するのは面倒です。
$ go build github.com/user/stringutil
そして見つけたツールが、gbでした。とっても良いツールです。トップページにはシンプルに以下のような一文が書いてあります。
A project based build tool for the Go programming language.
これで、GOPATHから解放されて、テストを楽に書く生活ができそうですね？
gbはプロジェクトベースのツールなので、ディレクトリ構造を強制されます。と言ってもすごい単純です。srcを掘ってファイルを配置するだけです。
以下のように、依存ライブラリを管理することも出来るようです。
$ gb vendor fetch [依存ライブラリ]
$ gb vendor restore
配置が終えたら、テストを実行するだけです。特にテストの位置やbuildなどを気にすることなく、サクッと実行出来てしまいました。
$ gb test -v
stringutil
=== RUN TestReverse
--- PASS: TestReverse (0.00s)
PASS
最後になりますが、一つ不満が残りました。本コードとテストコードを分けて書くことが出来ませんでした。以下が理想の書き方です。しかし、現状では大きなものは書かずに、細々としたものを書かないので問題ないかもしれません。ある程度大きなものを書こうとしたときは、どうするんでしょう？と疑問は残っています・・・。
$ tree .
.
└── src
├── main
│ └── stringutil
│ └── reverse.go
└── test
└── stringutil
└── reverse_test.go