uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかReactとかFregeとかJavaとか -

Groovyの生産性

GroovyとJavaとの生産性の比較について、groovy-userのMLで報告してた人がいたので紹介。

groovy/javaの混合言語のプロジェクトで、Javaコードをgroovyにコンバートすることをやってた。たいていは、拡張したりバグ修正したり必要に応じてリファクタリングもしてた。
以下は私の経験。規模は95 KLOC。

コードサイズ: コード量はJavaの1/2になる。ときどき1/2以下になる。まれに1/2になるときもある。同じサイズになることは決してない。バグ件数はLOCに直接関係しているので、groovyのバグ数は少なくなる。

リファクタリングが少なくなる: Groovyではクリーンなコードを最初から書ける。Javaでは頻繁にリファクタリングすることがあった。コードをクリーンで保守可能な状態にするのに、リファクタリングを1回もしくは2回していた。

可読性向上: groovyコードはシンプルで読みやすい。私のプロジェクトではリストをフィルタリングしたり、ソートしたり、検索したり、他のリストとかからマップやリストを生成したりするのに多くの時間がかかっていた。groovyではfind(), findAll(), collect(), sort(), and inject()を使ってこれらをみんな関数型スタイルで書ける。関数型アプローチは短かく(経験上、一般にだいたい1/4になる)、より自然に書きやすく、一時変数をあまり使わずに書きくだせる。これは大きな利点だ。私にとっては、これはgroovyの一番売り込みやすいセールスポイントだ。だれかが自分のコード中のforとwhileループの数をすべて探し出して、それをgroovyで記述するとサイズが1/4になって読みやすくなる。

リソース管理が簡単: リソースの初期化と廃棄の管理が簡単になる。良い例は、java.io*のwithXメソッドだ。このリソースハンドリングスタイルを自分のコードに適用したところ、try/catch/finallyのボイラープレートが大幅に減った。コードはもっと読みやすくなり、保守しやすく、エラーが減る傾向がある。

とか、いくらでも続けられるんだが。私自身の生産性は、何をするかによる。通常は2倍ぐらいだが、ときどきgroovyは問題を単純化するので、3-5倍はより生産性があがるときもある。

だそうな。