私のプロジェクトはゆっくりとJavaアノテーションを実装しています。開発者の半数(私も含めて)は、アノテーションを使用して複雑なことを行うと、全体的なメンテナンスの負担が増えるように思われることに気付きました。チームの残りの半分は、彼らがミツバチの膝だと思っています。
注釈付きコードを維持できる開発者のチームでの実際の経験は何ですか?
私のプロジェクトはゆっくりとJavaアノテーションを実装しています。開発者の半数(私も含めて)は、アノテーションを使用して複雑なことを行うと、全体的なメンテナンスの負担が増えるように思われることに気付きました。チームの残りの半分は、彼らがミツバチの膝だと思っています。
注釈付きコードを維持できる開発者のチームでの実際の経験は何ですか?
私の個人的な経験では、平均して、アノテーションの処理は、標準のJavaXML構成の地獄を処理するよりもはるかに簡単です。JPAやSpringテストのようなものにとって、それらは絶対的な命の恩人です。
注釈の良いところは、クラスの構成を自己文書化することです。これで、フレームワークがクラスをどのように使用しているかを把握するために巨大なXMLファイルを検索する代わりに、クラスが教えてくれます。
通常、このような変更の問題は、それらに慣れるのに時間がかかることです。開発者を含むほとんどの人は、変化に抵抗します。Springで働き始めたときのことを覚えています。最初の数週間、私はなぜ誰もがそれに関連する頭痛に我慢するのだろうかと思いました。それから、数週間後、私はそれなしでどうやって生きてきたのだろうと思いました。
アノテーションの2つの使用法に分かれていると思います。クラスの「説明」を提供するアノテーションと、クラスの「依存関係」を提供するアノテーションです。
クラスでのアノテーションの「説明」使用は問題ありません。これはクラスに属するものであり、アノテーションはその短縮バージョンを作成するのに役立ちます。JPAアノテーションはこれに該当します。
ただし、「依存性」アノテーションは、クラスのコンパイル時ではなく実行時にアノテーションから実行時に決定されたとしても、クラスに直接依存性を置く場合は、それほど重要ではありません。注入?(おそらくルールではなく精神で...)
個人的な好みかもしれませんが、アプリケーションのすべての依存関係情報を含む1つの大きなXMLファイルが好きです。これを「クラス構成」ではなく「アプリケーション構成」と見なします。アプリ内のすべてのクラスを検索するよりも、1つの既知の場所を検索したいと思います。
私は注釈が大好きです。私はHibernate/JPA、Seam、JAXBからそれらを使用しています....私ができることなら何でも。IMOは、クラスがどのように処理されるかを知るためだけにXMLファイルを開かなければならないことほど悪いことはありません。
私の目には、注釈を使用すると、クラスが自分で話すことができます。また、注釈は(うまくいけば)IDEコンテンツ支援の一部ですが、XML構成では、通常は自分で行います。
ただし、XML構成と注釈が特定のライブラリで実際にどのように使用されるか(ほとんどの場合、両方を提供するため)、およびどの種類の注釈が使用されるかによって決まる場合があります。ビルド固有のもの(ファイル/ URLパスなど)を定義するアノテーションは、実際にはXML構成の方が簡単かもしれないと想像できます。
IDEのサポートに大きく依存します。IDEのチェックを介して注釈をコードと同期させる必要があると思いますが、これに対するサポートはやや不足しています。
たとえば、古いバージョンのIDEAは、@ Overrideなしで関数をオーバーライドすると警告しますが、メソッドシグネチャ(またはスーパークラスシグネチャ)を変更して関係を壊した場合は@Overrideタグを削除しません。
サポートがなければ、メタデータをコードに追加するのが面倒な方法だと思います。
私は個人的に、あなたが言及した特定のユースケース(Webフォームの自動生成)が注釈の優れたユースケースであると感じています。単純化されたコードを記述し、いくつかの提案(別名アノテーション)に基づいてフレームワークに重い(多くの場合反復的な)リフティングを行わせることができるあらゆる種類の「フレームワーク」シナリオは、アノテーションの理想的なユースケースだと思います。
このような状況で注釈が気に入らない理由と、「メンテナンスの負担」とは何だと思いますか。(そして、私はあなたの立場を侮辱しようとしているのではなく、ただそれを理解しているだけです)。