35

私は、プラットフォームから長い間離れていた後、Java で LoB アプリケーションを開発しています (過去 8 年ほど Fortran、C、C++ の smidgin、そして最近は .Net に固執していました)。

言語であるJavaは、私が覚えているものとあまり変わっていません。私はその長所が好きで、その短所を回避することができます.プラットフォームは成長しており、互いにほとんど同じことを行うように見える無数の異なるフレームワークを決定することは別の話です. しかし、それは別の日に待つことができます-全体として、私はJavaに慣れています. しかし、ここ数週間で私は Groovy に夢中になりました。これは純粋に利己的な観点からです: JVM に対する開発をより簡潔で楽しい (そして、「グルービー」な) 命題にするという理由だけではありません。 Java（言語）よりも。

Groovy について最も印象に残っているのは、Groovy 固有の保守容易性です。私たちは皆 (願わくば!) 十分に文書化された、理解しやすいコードを書くよう努めています。しかし、私たちが使用する言語自体が私たちを打ち負かすことがあります。例: 2001 年に、EDIFACT EDI メッセージを ANSI X12 メッセージに変換するライブラリを C で作成しました。これは特に複雑なプロセスではありませんが、多少の関与はありますが、当時はコードを適切に文書化したと思っていましたが、おそらく文書化していたと思いますが、6 年後にプロジェクトを再訪したとき (そして C# に順応した後)、私は見つけました。私自身、C のボイラープレート (malloc、ポインターなど) に夢中になりすぎたため、6 年前に自分が何をしていたかを最終的に理解するまでに、3 日間の思慮深い分析が必要でした。

今夜、私は約 2000 行の Java を書きました (結局のところ、今日は休みの日です!)。私が知っている限りの方法で文書化しましたが、Java の 2000 行のうち、かなりの部分が Java ボイラー プレートです。

これが、Groovy やその他の動的言語が、保守性とその後の理解で勝利を収めているところです。Groovy を使用すると、プラットフォーム固有の実装に行き詰まることなく、目的に集中できます。それはほぼ自己文書化されていますが、完全ではありません。これは、数年後に現在のプロジェクト (Groovy にできるだけ早く移植する予定です) を再検討するとき、そしてそれを継承して良い仕事を続ける後継者にとって大きな恩恵であると考えています。

では、Groovy を使用しない理由はありますか?

4

5 に答える 5

26

Groovy（またはJython、またはJRuby）を使用しないと考える理由は2つあります。

  • あなたが本当に、本当にパフォーマンスが必要な場合
  • 静的型チェックを見逃す場合

それらは両方とも大きなifです。ほとんどのアプリでは、パフォーマンスはおそらく人々が考えるよりも重要ではなく、静的型チェックは宗教的な問題です。とは言うものの、これらすべての言語の1つの強みは、ネイティブJavaコードと組み合わせることができることです。両方の世界とそのすべてのベスト。

私はあなたのビジネスに責任がないので、私は「それのために行きなさい」と言います。

于 2009-01-19T00:11:02.093 に答える
13

Groovy を使用すると、基本的に型に関する有用な情報を捨ててしまうことになります。これにより、コードが「グルーヴィー」になります。素晴らしく簡潔です。

Bird b

になる

def b

さらに、Java では厄介なすべてのメタクラスと動的メソッド呼び出しで遊ぶことができます。

ただし、IntelliJ、Netbeans、Eclipse を広範囲に試しましたが、Groovy では本格的な自動リファクタリングはできません。IntelliJ のせいではありません。型情報が存在しないだけです。開発者は、「でも、コード パスごとに単体テストがあれば (うーん)、リファクタリングがもっと簡単になる」と言うでしょう。しかし、誇大宣伝を信じてはいけません。コード (単体テスト) を追加すると、大規模なリファクタリングの安全性が向上しますが、作業が容易になるわけではありません。ここで、元のコードと単体テストを手動で修正する必要があります。

つまり、特にプロジェクトが成熟している場合は、Groovy でそれほど頻繁にリファクタリングしないことを意味します。コードは簡潔で読みやすくなりますが、毎日、毎時間、毎週自動的にリファクタリングされるコードほど優れたものにはなりません。

Java のクラスによって表される概念が不要になったことに気付いたら、それを削除することができます。Eclipse や Netbeans などでは、プロジェクト階層がクリスマス ツリーのように光り、この変更で失敗したことを正確に伝えます。def thing変数がどのように使用されるか、メソッドが存在するかどうかなどについて、コンパイラ (したがって IDE) に何も通知しません。また、IDE は非常に多くの推測しかできません。

結局、Java コードは「ボイラープレート」でいっぱいですが、多くのリファクタリングを経て最終的な形に練り込まれています。そして私にとって、将来のプログラマーが将来のあなたである場合を含め、将来のプログラマーが高品質で読みやすいコードを取得するには、それが唯一の方法です。

于 2010-05-09T21:26:12.850 に答える
9

ScalaがGroovyの魅力的な代替手段になる可能性がある2つの理由：

  • Javaと同等のパフォーマンス
  • 煩雑さのない静的型付け
于 2009-01-19T00:15:31.990 に答える
7

特に大規模なコードベースで動的言語を使用するときに失われる最大のものの 1 つは、IDE を使用してリファクタリングする機能です。オブジェクトにコードを動的に追加できる言語は、今日の IDE では単純に解析できず、Java や C++ などの Eclipse などから取得できるような簡単なリファクタリング メソッドを使用できません。

「動的言語は静的言語よりも優れている」というケースではありません。あなたに最適なものを使用してください。特に Groovy の優れた点は、同じプロジェクト内で Java と Groovy を組み合わせて使用​​でき、すべて VM 上で実行できることです。はい、Scala は別の例です。

于 2009-01-23T06:25:03.647 に答える
2

最大の問題は Java に比べて IDE のサポートが不足していることだと思いますが、Eclipse と Netbeans のプラグインは常に改善されています。また、私の記憶が正しければ、Groovy は、何らかの理由で本当に必要な場合、匿名の内部クラスをサポートしていません。個人的にはいつでもGroovyを選びます。

于 2009-01-19T04:47:13.847 に答える