コンパイラの警告を無視するべきではないとチームメートを説得するにはどうすればよいですか？

私は、Eclipseを使用したJavaでの巨大プロジェクト（依存関係の管理が不十分なために簡単に分離できない数十のミニプロジェクトの絡み合った組み合わせに似ていますが、それは別の議論です）に取り組んでいます。コンパイラの設定からの警告を既にオフにしており、プロジェクトにはまだ10,000を超える警告があります。

私は、すべての警告に対処し、可能であればすべての警告を修正し、安全であると見なされていると思われる警告を抑制しようとすることを強く支持しています。（実装/オーバーライドされたすべてのメソッドを@Overrideとしてマークするという私の宗教的な強迫観念も同じです）。私の最大の主張は、一般に警告はコンパイル時に潜在的なバグを見つけるのに役立つということです。おそらく100回のうち99回の警告は重要ではありませんが、大きなバグを防ぐために一時的に保存することで頭を悩ますことは価値があると思います。（私の他の理由は、コードのクリーンさを持つ私の明らかなOCDです）。

しかし、私のチームメイトの多くは気にしないようです。偶然それらに出くわしたときの警告をときどき修正します（しかし、同僚が書いたコードに触れると注意が難しいことを知っています）。現在、クラスよりも文字通り多くの警告があるため、警告の利点は非常に最小限に抑えられています。これは、警告が非常にありふれたものであるため、誰もそれらのすべてを調べる必要がないためです。

チームメイト（またはその勢力）に警告に対処する（または完全に調査した場合は抑制する）必要があることをどのように納得させることができますか？それとも、私は自分がクレイジーだと確信する必要がありますか？

ありがとう

（PS私が最終的にこの質問を投稿するように私に促したことを言及するのを忘れたのは、私が警告が生成されるよりも遅く警告を修正していることに悲しいことに気づいたということです）

2つのことができます。

1. 警告には理由があることを指摘してください。コンパイラーの作者は、意地悪なためそれらを入れません。私たちの業界の人々は一般的に役に立ちます。多くの警告が役立ちます。

2. 無視された警告から生じる壮大な失敗の履歴を収集します。「コンパイラの警告に注意してください」というWeb検索では、いくつかの逸話が返されます。

あなたの強迫観念@Overrideは「強迫観念」ではありません。それは良いことです。メソッド名のスペルミスはありませんか？

関連する読み物はこちら。C ++ですが、関連性はあります。私は特にこの例が好きです（コードのコメントは私のものです）：

int searchArray(int to_search[], int len, int to_find)
{
    int i;
    for( i = 0; i < len; ++i )
    {       
        if ( to_search[i] == to_find )
        {
            return i;
        }
    }
    // should be returning designated 'not found' value (0, -1, etc)
}

多くの場合、警告とは、実際に設計の欠陥を追跡して修正するのに役立つエラーでクラッシュするアプリケーション（安全な型キャストなど）と、仮定を立てて実際に正しく動作しないアプリケーションとの違いを意味しますまたは誤った方法（安全でない型キャストの場合）。同様に、C ++の上記の例のように、削除できる不要なコードまたはデッドコード（到達不能なコードブロック、未使用の変数）も指摘します。この例では、Javaでコンパイル時エラーが発生することに注意してください。

そのため、警告を修正することには、（少なくとも）管理にとっていくつかの利点があります。

1. コードがユーザー入力データに対して不適切に動作する可能性が低いため、会社のイメージやクライアントのデータの処理方法が懸念される場合、Big Deal（tm）になります。ユーザーが何かおかしなことをしないようにクラッシュさせるのは、クラッシュさせずにユーザーにやらせるよりはましです。
2. スタッフを入れ替えたい場合、人々は警告のないコードベースに参加することができます（そして、それほど驚かないでください。これにより、不満の声が減り、プロジェクトYに対するチームXの貢献の保守性や品質に関する意見が減る可能性があります。
3. コンパイラーの警告を削除してコードを最適化すると、実行時間は大幅に改善されませんが、テストに関しては多数のスコアが改善されます。
   • コードカバレッジスコアは増加する可能性があります。
   • 境界および無効なテストケースのテストは、（上記の安全な型キャストなどにより）より頻繁に成功します。
   • テストケースが失敗した場合、そのソースファイルのコンパイラ警告の1つが原因であるかどうかを考える必要はありません。
   • コンパイラの警告がゼロであることは、数千よりも優れていることは簡単に議論できます。警告やエラーはコードの品質について言及するものではないため、コードの品質は警告が少ないほど改善されると主張できます。
4. コンパイラの警告がなく、1つ以上の警告が導入されている場合、コードベースに警告が表示される原因を誰が知るのがはるかに簡単です。「警告なし」のポリシーがある場合、おそらく適切に仕事をしていない人を識別するのに役立ちますか？コードを書くことは、何かを機能させることだけでなく、うまく機能させることでもあります。

私はまだプロジェクト管理についてほとんど知らないジュニア開発者ですので、何か間違ったことを言った場合は、私の考えを修正し、あなたが私を廃止する前に編集する機会を与えてください:)

私は過去に同様の特性を持つプロジェクトに取り組んできました。特に、これはもともとJava 1.4で作成されました。ジェネリックを含むJava 5が登場すると、Collections APIを使用するたびにコンパイラーによってスローされる警告の数を想像できます。

ジェネリックの使用を開始することで、すべての警告を取り除くのにかなり時間がかかりました。これは考慮しなければならない要素ですが、誰か（特に上司）に修正が必要であると納得させる必要がある場合、次のようなハードデータが必要になります。

回避することができたレガシーまたは非標準準拠コード（標準はプロジェクトのコーディング標準）のバグに費やされた時間。

「特定の」警告を無視することにより、時間とお金をどのように失っているのかを示す法案を提示し続けることができます。重要な部分は、すべての警告を見るだけの価値があるわけではなく、少なくともすぐには見ないということです。簡単に言えば、すぐに対処する必要がある警告の優先度を確立する必要があります。まず、プロジェクトに見られるバグに関連するものを検討してください。

また、バグを修正するときに、警告を無視しないことで（またはCIまたはビルドシステムがある場合はPMDまたはFindBugsを実行することで）バグを回避できた可能性があることを、バグトラッカーでメモすることもできます。コンパイラの警告に注意を払うことで修正できるバグが十分にある限り、コンパイラの警告を見ることについてのあなたのポイントは有効です。そうでなければ、それはビジネス上の決定であり、通常、この戦いと戦うのに時間を費やす価値はありません。

成功し、チームが警告を観察することに決めた場合、段階的なアプローチをとる必要があります。一度に10000件の警告を出すことはできません。そのため、最も重要なもの（確率が高いバグ）を選択し、重要性の低いものを無効にすることができます。それらが修正されている場合は、警告レベルを再度上げます。さらに、ほとんど常にバグであるコードについて警告するFindBugsから開始できます。

コンパイルの警告をできる限りクリーンアップするのがベストプラクティスです。チームはEclipseを開発ツールとして使用していると述べました。Eclipseは、コードをクリーンアップし、コードスタイルの一貫性を保つのに役立つ非常に優れたツールです。

1. コードの書式設定、未使用のローカル変数、インポートの整理など、各Javaプロジェクトの「保存アクション」を定義します（この種のクリーンアップに異議はないと思います）。
2. プロジェクトごとにプロジェクト固有のコンパイルオプションを定義します。たとえば、コンパイルレベル（ジェネリックに関連する警告を消去するためにコードが1.4と互換性を必要とする場合）、割り当ては効果がありません（例： 'x = x'）など。あなたとあなたのチームメイトはそれらの項目について合意することができ、Eclipseはコンパイルエラーについて合意した後、開発段階でそれらを「エラー」として報告します。

Eclipseは、.settingsフォルダーの下にこれらの設定のプロパティファイルをいくつか作成します。それらを他のJavaプロジェクトにコピーし、ソースコードの一部としてSCMにチェックインできます。

Eclipseのコードを調べて、Eclipse開発者がそれをどのように行っているかを確認できます。

すべての警告を取り除くには2つの方法があります（微妙なバグを隠すことができることに同意します）。

1. チーム全体に、これが最善のことであると確信させ、修正してもらいます。
2. これを行うのが最善であることを上司に納得させ、義務付けてください。その後、彼らはそれを修正する必要があります。

私はあなたの場合、1はもはや実行可能でないと信じています。また、これは生産性の出力に表示される警告の数のためにおそらく非常に時間がかかりますので、管理者はとにかく知る必要があります。

だから、私の提案は次のとおりです。上司にそれを取り上げ、これがカチカチ音をたてる爆弾であることを彼に納得させ、公式の方針を立てさせてください。

これらのほとんどは取るに足らない警告であり、リストからそれらを削除することが不可欠であると彼らに言いたいと思います。群衆の本当の重要な警告を見逃さないように、それが起こります！

あなたは彼らを説得しようとするのに多くの忍耐が必要になります。ペアプログラミングを行うときに警告を取り除くと、他の人が習慣を取り戻すのに役立ちます。Effective Javaの「Item 24：未チェックの警告を削除する」（一般的なコレクションの場合）を読むように提案します。そしておそらく、人々があなたのアドバイスに従わない多くの場合を無視してください;）

ここでの効果的なアプローチは、プロジェクトを自動的にビルドし、コードをチェックインするたびにテストを実行する継続的インテグレーションサーバーをセットアップすることです。まだこれを使用していない場合は、そうする必要があります。そうすることの利点を他の人に納得させることはそれほど難しくありません。

1. 管理者/チームリーダーにこれを行うことの利点を納得させます（悪いビルドが展開されないようにし、バグ、特にソフトウェアの他の部分に誤って影響するバグを発見し、回帰テストを維持し、早期かつ頻繁にテストするなど）

2. すべてのテストに合格したCIサーバーをインストールします（テストがない場合は、合格した簡単なテストを作成して、すべてが緑であることを確認します）。

3. 各ビルドのステータスに関するメールまたはその他の通知を設定します。ここで重要なのは、コードをチェックインした人、変更内容（またはコミットへのリンク）、ビルドのステータスと出力を含めることです。これは、成功と失敗の両方についてチーム全体の可視性を引き起こすため、重要なステップです。

4. CIサーバーを更新して、警告がある場合にテストが失敗するようにします。これは、経営陣とチームリーダーが体系的な方法でチームの規律を強化するものと見なされ、すべての失敗メールの送信に対して責任を負わないようにします。

5. （オプション）目に見えるダッシュボード、溶岩ランプ、点滅するライトなどを追加して、ビルドの状態と誰がそれを壊した/修正したかを示すことで、これで素敵でオタクになります。