私は現在、RMIサーバーと通信するRMIクライアントに取り組んでいます（私が働いている会社の別の部門によって開発されました）。他のチームがインターフェースを所有していますが、IMO は非常に複雑で、多くの異なる型が前後に渡され、不必要に (IMO) 複雑な例外階層が渡されます。
私は何度も、これが一種の不必要な複雑さであり、後で統合するときに問題の確実な原因になるという懸念を表明してきましたが、あまり注目されていません。IMO では、不必要に大量のコードが共有されることにつながります。さらに、共有するすべての異なるクラスは、監視が必要なバージョン管理要件の余分なセットです。
私の議論を補強するために使用できるリソース/議論を知っている人はいますか.
または、私が間違ったツリーを吠えていると誰かが納得させることができますか?
まず、あなたが説明した問題は、RMIだけでなく、プレーンJavaインターフェイスを含むコンポーネントのあらゆる種類のインターフェイスに関係していると言えますが、RMIの場合、設計が悪いとパフォーマンスなどの追加の注意事項が生じる可能性があります。
詳細がわからないので、自分の経験を見れば推測できます。インターフェイスのこのような不必要な複雑さは、多くの場合、コンポーネントに対して定義された無効または不十分なビジネス要件に関連しています。その場合、将来的には、他の部門の担当者がインターフェイスを頻繁に変更して、新しい機能に追いつく必要があります。これは通常、コンポーネントのユーザーにとって苦痛の原因です。もちろん、インターフェイスの変更は時間の経過とともに自然に行われますが、この場合、大幅な再設計が行われる可能性があります。
さらに、過度に複雑なインターフェースは通常、作成者が実装の詳細を公開することを意味します。言うまでもなく、これにより、実装の進化、別のテクノロジーへの切り替え、または最適化のみが原因で、不要なインターフェイスの変更が発生する可能性があります。
最後になりましたが、ユーザーに必要以上の機能を提供することは、使用することを意図していない、または存在することさえない機能をユーザーに使用させるための簡単な方法です。将来的には、ユーザーが予期しない方法でインターフェースを呼び出すことが判明する可能性があります。それはコンポーネントのメンテナンスを地獄にします。
まとめると、シンプルなインターフェイスの重要な議論は、コンポーネントの明確なビジネス定義、実装の柔軟性の向上、保守性です。そして、これらの利益はすべて、コンポーネント開発者とユーザーの両方にとって有益であることを忘れないでください。
やっていることを達成するためにデータを取得します。私は unforgiven3 に同意します -- それは良い戦いであり、あなたは間違った木を吠えているわけではありません -- 弾薬なしでよりクリーンなコードの提案を今すぐ提示すると、耳が聞こえなくなり、さらに悪いことになる可能性があります。「私の馬はあなたの馬よりも大きい」ようなコンテストを開始できますが、生産的ではありません。
私の提案です。
バグ、または非効率的なインターフェースに関連する、または指し示すその他のチケット項目の文書化を開始します
コード レビューの文書化を開始し、wiki (会社が認可した wiki -- 今は問題を起こさないでください) に入れ、とりあえず文書化します -- まだ判断を下す時ではありません。
これら 2 つのデータから十分なデータが得られたら、プログラマーの生産性が、非効率な設計上の決定によって失われたり悪用されたりしていると主張してください。コストが関係していると議論するのは非常に困難です。
それが役に立てば幸い。