プロジェクトで未使用のコンポーネントを使用しても構いませんか？

Question

一般的に未使用/デッドコードは悪いですが、未使用のコンポーネントをどうすればいいのでしょうか。 通知をユーザーに送信すると、EmailNotificationが送信されますが、しばらくしてSMSで通知を送信するように切り替えるアプリケーションがあるとします。私はインターフェイスを作成する代わりにEmailNotificationクラスを削除するのは、通知言わせて、私は、このような構造を持っている：私はいくつかの時間後、我々はEmailNotificationsに戻ることができ、この変更は、同じくらい簡単になりますので、EmailNotificationを削除したくない

Notification 
--SmsNotification 
--EmailNotification 

をEmailNotificationクラスを@Primaryとしてマークします。 そのような場合、実装のうちの1つは常にデッドコードであり、それは大丈夫か、それとも対処するのが一般的かと思います。

Answer 1

実際これはベストプラクティスではありません。 この練習の代わりに、コードを2つの異なるモジュール（コンポーネントごとに1つずつ）に分けることができます。このようにして、ビルド自動化ツール（たとえば、mavenやgradleなど）を使用して、必要に応じて2つのモジュールのいずれかを利用できます。したがって、生成されたjarにはデッドコードは含まれません。

Answer 2

将来再利用可能になるかもしれない古いコードを保持する上で問題はありません。実際、設計自体は、重大な影響を与えることなくコンポーネントの変更に対応できるようにする必要があります。 しかし、到達可能なコードブロックがあると、現在または将来の製品に価値を追加することはできませんが、コードの行数が不必要に増加し、テスト、究極的に配信に影響を与えます。さらに、この未使用のコードブロックは、最終的な製品（JAR/WAR）のサイズを望ましくなく増やします。

私の場合は、静的コード解析にSonarQubeを使用していましたが、テスト時にしか表示されないコードブロック、メソッド、および時にはファイルブロックがありました。プロセスの速度を落としているだけでなく、不要なヒープスペースを取っていました。これらのブロックを除去することは、プロセスのスピードアップに貢献しました。

Answer 3

私はこれがデッドコードではなく、未使用のコードであることに同意します。しかし、プロダクションのコードはできるだけクリーンでなければならないので、gitなどのバージョン管理を使用している場合は、gitリポジトリの履歴に常にあるようにコードを削除します。これをやりたくない場合は、なぜコードがそこにあるのかを説明する方法を提案します。java docやreadmeファイルのようなものです。

Answer 4

注意する必要があることは、未使用のコンポーネントでも維持する必要があることです。私の心に来ていくつかの例：

• Notificationインタフェースが変更された場合、EmailNotificationがあまりにも変更する必要があるが
• あなたは複数のコンポーネントで使用される依存関係を更新した場合、かもしれないことであなたも
• あなたの場合EmailNotificationを変更する必要が（例えば、コードカバレッジのx％、特定のコードスタイル、警告なしのポリシーなど）に適用されます。追加作業につながる未使用コンポーネントにも適用されます。

（まだコンパイルされていないため）、または微妙に（まだコンパイルされていますが、使用されていないため、実行時に失敗することに誰も気付かない）コンパイルエラーが修正されても、正しくテストされていない可能性があります。

未使用のモジュールを保管することで、特定の変更に必要以上に多くの作業をしなければならず、必要なときにオンにできないモジュールが壊れてしまう危険性があります。 は、実際に必要なときにコンポーネントをリタイアして復活させ、更新するのが簡単です。実際には大きな変化があるまであなたは退職を待つことができます。あなたが運が良ければ、コンポーネントが再び必要になる前に大きな変化は起こりません。

近い将来コンポーネントが再び必要になることが確かな場合は、そのまま使用してください。しかし、それを適切に維持してください。