Java DevTools：ファッションは良いことを意味しない

本日、ZeroTurnaroundのJRebel製品の開発者兼マネージャーであるanton Arkhipov、別名antonarhipovがいます。適切な開発ツールとその誤用についてお話ししています。 アントンは10年以上にわたり専門的にJava開発に携わってきました。 彼の主な関心は、プログラミング言語とソフトウェア開発ツールに関連しています。 vimとIntelliJ IDEAが大好きです。 彼は国際会議で頻繁に講演しています-JAX、JavaOne、Joker、JPoint、GeeCON、Jfokus、JavaZone、EclipseConなどの会議での講演の背後にあります。


-アントン、Java開発の分野で何をしていますか？

-過去6年間、私はZeroTurnaroundで働いていました。義務として、私はJava開発者向けのツールを開発するのが大好きです。 私たちのよく知られている製品はJava開発者向けのJRebelであり、2番目の主要製品はXRebelです。これもJava開発者向けですが、Web開発に携わる人向けです。 私はJRebelの最初の3年間に関与し、最後の3年間はXRebelの作成に関与しました。

開発環境について

-IDEAの人気は高まりつつあり、あなたの会社のウェブサイトで実施された調査によると、今年はEclipseを追い抜いたことに驚きました。


zeroturnaround.comでの回答者間のさまざまなIDEの位置

-私は認めなければならない：すべてのアンケートが嘘をついています。 これらは統計であり、ご存知のように、「嘘があり、大きな嘘があり、統計があります。」 このアンケートに回答した人の中で、IDEAは最も人気のあるIDEですが、これはすべてのJava開発者の間で最も人気があるという意味ではありません。 JRebelユーザーの統計を見ると、Eclipseはまだ自信を持って主要なIDEであり、Eclipseのシェアは60％以上です。

実際、IDEAに参加しているユーザーの割合だけでなく、この割合がどのように変化したかが興味深いです。 これらの調査を実施したのは今回が初めてではなく、IDEAの人気指標は常に上昇し、Eclipseの下落は続いています。 また、NetBeansの場合、常に非常に疎外されています。 10％が限界と考えられるわけではありませんが、それでもかなり低いため、もちろんNetBeansチームは同意していません。 彼らは、そのようなことはアンケートではまったく研究できないと考えています。 しかし、とにかく誰にとっても興味深いものであり、これは常に行われます。
IDEAが成長している傾向が見られます。 そして、これはIntelliJ IDEAとJetBrainsが新しいバージョンをリリースするための戦略を変更することを決めたという事実によるものと思われます。 より頻繁にアップデートがリリースされ、より頻繁にバグ修正がリリースされ、常に「初期リリース」を見ることができます。

そして、製品が非常に活発に開発されているとき、それは開発者を引き付けます。 私たちは子供のようで、新しいものすべてが大好きです。 そして、ツールが強力であればあるほど、それが必要になります。 たとえば、このツールの能力の95％を使用しているという事実にもかかわらず、おそらく必要になることはありません。

IDEAの大きな利点の1つは、外観と製品の外観を1つの視点で1つの会社が開発したことです。 Eclipseではそれを観察しません。 単一の「パーティライン」はありません。 したがって、一部は一貫性があり、一部は完全に、まるでシステム内でアドホックであるかのようです。 私はこれがIDEAに当てはまらないと言っているわけではありません-いくつかの場所で問題がありますが、コミュニティがresり始めると修正されます。 そしてそこで、彼らはこれらの粗さを素早く修正しようとします。 残念ながら、Eclipseではこれを観察していません。

Eclipseは、背後に大きな力がありますが、まだコミュニティプロジェクトです。 彼はかなり保守的なリリース戦略に従います。 さらに、数年前にはリリースにかなり大きな問題がありましたが、私の知る限り、パフォーマンスと安定性に問題がありました。 しかし、これは多くの製品で起こります。 IDEAにはリリースがあまり良くない時期があり、NetBeansもそうでした。

「単一ライン」を重視するEclipseでの唯一の大きな貢献者は、Red Hatとその配布キットJBoss Developer Studioです。 彼らはあなたがインストールした、動作するディストリビューションを構築しようとしています。 そして、それらはEclipseを改善するためのそのような「モーター」です。 Eclipseの最新の改善点の多くは、特にRed Hatに関連しています。

-本質的に、IDEAプログラマーはEclipseより生産的だと思いますか？ ここでは、IDEAについて報告します。 確かに両方のIDEで作業しました。

-はい、私は2004年からIDEAで過去12年間働いています。 2006年から2008年にかけてEclipseを使用して密輸しましたが、どういうわけか定期的に少し使用しました。 ただし、当面はIDEのプラグインを作成します。 私たちの製品はプラグインとして埋め込まれており、私はプラグインを開発していました。 したがって、私は過去数年にわたって非常に多くのIDEを使用してきました。 Eclipseのさまざまなバージョン（約10個）を確認しました。

「しかし、大部分はIDEAで働いていましたか？」 そして、それで作業することがあなたにとってより生産的であることは明らかです。あなたはそれに慣れています。

-はい、もちろん、これは習慣の問題です。 しかし、これに加えて、タスクごとに独自のツールが必要だと思います。ツールはよく知っていて、それを使って何でも実行できます。 Java開発では、NetBeansを使用する方が便利な場合があります。このタスクにはNetBeansを使用します。 一部のタスクでは、Eclipseを使用する方が効率的です。Eclipseを使用します。

私にとって、IDEで最も生産的な部分は、ナビゲーションとショートカットシステムです。 多くの場合、ショートカットシステムで何らかの種類のロジックを探しています。 ロジックはありません、決してありません。 たとえば、「IDEAのこのようなショートカットのロジックは何ですか？」という質問がありました。これを尋ねるのは間違っています。ショートカットがどこにあるかを見ると、どこにでも奇妙なものが見えるからです。 EclipseでCtrl + Hが検索されるのはなぜですか？ ロジックはどこにありますか？ 明確ではありません。

-和音のようなショートカットは、筋肉の記憶によって記憶されます。

-はい、ここでは、脊髄、筋肉の記憶などを覚えておく必要があります。 そして、ここでの主なことは、システムをカスタマイズせずに、構成しなくても、できる限りすぐに実行できることです。

MacまたはGentoo Linuxのどちらかを選択します。すべてを自分用にカスタマイズするか、すぐに拾い上げてフェラーリに乗り、時速100キロメートルで織ります。

人が何らかのツールでこれを提供できるなら、彼はよくやった。 ここでは、IDEAでもEclipseでも構いません。 私はIDEAで自分でこれを見つけました。 誰かがEclipseでこれを見つけるかもしれません。

バージョン管理システムについて

-プログラマーの「聖戦」の永遠の理由は、バージョン管理システムの選択です。 私の話を共有したいです。 むかしむかし、当社はSVNに依存していましたが、現在、SVN、多くのトリック、機能を効果的に使用するように訓練された多くの従業員（ほとんどがJavaプログラマーでもプログラマーでもありません）がいます。 そして最近、Gitが人気のあるすべての人を破ったことがわかります。 そして、しばしば「上級の若い専門家 」 が来て、こう言います。 あなたは時代遅れです！ あなたはトレンドではありません！ どうして？」


バージョン管理システムの人気

-当社では、歴史的な理由により、多くのプロジェクトでGitを使用していません。 Gitに切り替えたいチームがあります-彼らは切り替えました。 しかし、SVNよりもさらに人気のない環境に含まれるプロジェクトの大部分と最も基本的なプロジェクトがあります。これはMercurialです。
Gitに切り替えてもメリットはありますか？

かつて、GitHubのトレーナーを招待してGitのトレーニングを行い、Gitに切り替えるかどうかを決定しました。 そして、この毎日の集中的な作業の後、私たちは座って考え、自分の仕事のやり方を考えると、Gitに切り替えるのは簡単ではないことに気付きました。 また、Gitのメリットを得るには、作業を変更する必要があります。

作業方法（ブランチの作成、これらすべてがすべて）がバージョン管理システムに適合し、それをサポートしている場合、それは良いことです。 多くのクールなことを実行できるツールを使用し、SVNのように使用すると、あまり意味がありません。

Gitの人気に関しては、ここがまさにその瞬間であり、開発者は非常に強力なものが大好きです。 この力がすべて必要でなくても、手に入れたいのです。この包丁。 機関銃でさえ、もはや包丁ではありません。 SVNは包丁であり、そこでコミットしました。 その後、SVNの場合と同様に、Gitマシンガンを使用して再度コミットを開始しました。 そして、疑問が生じます。なぜこれらすべてのものなのでしょうか？

-はい、うまく演奏する方法がわからない場合、なぜ良い楽器が必要なのですか？

-ええ、はい。 私は正直なところ、Gitに多くの時間を割くべきだとは思いませんでした。 しかし今日、もちろん、開発者が知っておくべきツールを誰かに聞かれたら、まずはGitに電話します。

-Gitの成功はGitHubサービスの人気によるものですか？

-もちろん、GitHubは最も人気があります。そのため、Gitも人気があるように思えます。 そして第二に、en望はここで機能します。 「隣人が力を持っているので、隣人と同じようにしたい。」 また、Gitの人気もこれに起因しています。

-多くのGitの謝罪者が地方分権化を推進しています。 SVNを3台のサーバーに複製し、十分な分散化があると答えました。

-さて、これは異なる地方分権です！ これは、分権化されたチームが存在する場所です。常に異なるプロジェクトがある場合、開発が中止されている場合など、ブランチはGitのパワーにすぎません。 SVNでブランチについて話している場合、これはまだ痕跡です。

-しかし、それは非常に大規模なチームと非常に大規模なプロジェクトのときにのみ始まります。 そして、それが小さな会社のフレームワーク内にあり、十分に集中化されている場合、Gitは利点を与えませんか？

「じゃあ、もちろん。」 小規模なチームで、多くのブランチを作らないようにする場合、または、たとえば、機能フラグと呼ばれる1つのメインブランチのみですべてを開発する場合、Gitの利点は失われます。 特に小さなチームの場合。

アセンブリ自動化ツールについて

-グラフを見ると、Maven Gradleの人気が高まっているため、やや恐ろしいです。 私の意見では、Gradleはどこにでもあり、多くの人が彼について話しています。 MavenユーザーはGradleへの切り替えを検討する必要がありますか？


アセンブリ自動化の人気

-このテーマに関して、今年の最後のJPoint会議で、Baruch jbaruch SadogurskyとEvgeny Borisovとともに素晴らしい報告を行いました。 そこで、Maven、Gradle、SBTという壮大な戦いがありました。 ちなみにSBTはありますが、主にMavenとGradleです。 そして、レポートの最後に、バルクは非常によく、Mavenは膨大な数のプロジェクトとシナリオの目にとって十分であると要約しました。 そして、Mavenは、いわゆる「柔軟性に欠ける」ため、単にそれをつかんで手を入れてビルドのロジックを修正することはできません。これがまさにそれです。 保守的で安定しており、人々はそれを「調理」する方法を知っています。 したがって、70％に保持されます。 そして彼はしがみつき、これはあまり変わらないように思えます。 それはそのアンケートにあります

-Gradleは成長し、Mavenの分を食べ尽くします。

-ええ、はい。 ただし、主要なエンタープライズプロジェクトは引き続きMaven上にあります。 おそらく、Antで書かれた古いプロジェクトは、そのロジックで開発され続けるなら、Gradleに目を向けるでしょう。

-アセンブリの宣言的ではなく命令的なロジックで？

-はい、はい。 このため、Gradleは非常に優れたオプションです。 しかし、Gradleには独自の問題があります。そこに「パスタ」を書くのは非常に簡単です。 これらの「パスタ」の多くは、アセンブリ言語であるGroovyが静的ではなく、型付けされているという事実によって説明されています。
「エンタープライズモード、オン！」キーがGradleに表示され、ビルドファイル内のスクリプトが禁止される場合、これがエンタープライズの世界への彼の最初のステップになると思います。 原則として、多くの人がそう思います。 そして、バルクはそう考えており、私は彼に同意します。

私には、Mavenはまだ堅実で、事実上の標準であるように思えます。 誰もが彼を知っている必要があります。
Gradleは、それ以上のビルド要件を本当に持っている人向けです。 Gradleは、私にとっては、単なるアセンブリ用のツールではなく、もう少し、自動化のためのツールであり、単なるアセンブリ以上のことをするようです。 彼はMavenからすべての良さを引き出し、Groovyが追加しました。そして、私たちは今、そのような強力なツールを手に入れました。 繰り返しますが、その人気は強力であるという事実によるものです。 繰り返しになりますが、開発者は常に必要であるとは限らず、本当に力が欲しいという議論に戻ります。 そして、多くの人々がMavenと比較して利点をもたらさないいくつかの新しいプロジェクトのために今Gradleを取っていると確信しています。
これは私たちが慣れているある種の慣性だと思います。 私たちは常に改善しなければならないことに慣れています。

-しかし、私たち開発者は常に改善する必要があり、私たちにはそのような職業があります。

-たぶん、私たちはすでに持っているものとすでに知っていることをやめ、改善する必要があり、新しいフレームワークやツールなどを見逃さないようにする必要があります。 私たちには、可能な限り使いこなせる優れたツールがあり、私たちが持っているものから最大限の効率を引き出すことができます。 そして、これらのツールの少なくとも90％を圧迫していない未到達の私たちは、すでに新しいツールに急いでいます。それは誰かがそれがよりトレンドで、より美しく、より興味深いと言ったからです。

-さて、最後の質問ですが、Joker 2016カンファレンスで何に対処しますか？

-私は会議で2つのレポートを持っています-1つはJavaバイトコードに関するもの、もう1つはIDEAの効果的な使用に関するものです。

---

Joker 2016のツールに興味がある場合は、既に承認されているレポートへの便利なリンクを次に示します。

• キリル・トルカチョフ「Gradleによるリリース管理」
• マーティン・トシェフ「Spring RabbitMQ」
• Vladimir Tsukur 「CRUDからSpringによるHypermedia APIへの道」
• アレクセイ・ジノビエフ「私たちのために準備しているスパークの未来は？」
• ウラジミール・クラシルシュチク「Vert.x：美女と野獣」