コンパイラの警告を無視してはならないことをチームメートにどのように説得しますか？
Java Eclipseを使用して、巨大なプロジェクト（依存関係の管理が不十分なために簡単に分離できない数十のミニプロジェクトの複雑な組み合わせのようですが、これは別の議論です）で作業しています。コンパイラ設定からの警告の多くはすでにオフになっており、プロジェクトにはまだ10,000件を超える警告があります。
私はすべての警告に対処し、可能な場合はすべての修正を試み、調査され、安全であると見なされた場合は、それらを抑制します。 （すべての実装された/オーバーライドされたメソッドを@Overrideとしてマークするという私の宗教的な執着についても同じです）。私の最大の主張は、一般に警告はコンパイル時に潜在的なバグを見つけるのに役立つということです。たぶん100回のうち99回のうち、警告は取るに足らないものですが、大きなバグを防ぐために一時的に節約できることは頭を悩ませていると思います。 （私のもう1つの理由は、コードのクリーンさを備えた明らかなOCDです）。
しかし、私のチームメイトの多くは気にしていないようです。警告を見つけたときは、ときどき修正します（ただし、同僚が作成したコードに触れると注意が必要です）。警告がクラスより文字通り多くなると、警告の利点は非常に最小限に抑えられます。警告があまりに一般的である場合、誰もそれらのすべてを調査する必要がないからです。
警告に対処する（または完全に調査した場合は抑制する）必要があることをチームメート（またはその権限）にどのように説得できますか？それとも、自分がクレイジーだと自分に納得させる必要がありますか？
ありがとう
（追記私が最後にこの質問を投稿するきっかけとなったのは、警告が生成されるよりも遅い速度で修正していることに悲しいことに気付いたことです）
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)
}
多くの場合、警告はアプリケーションのエラーによるクラッシュの違いを意味します。これは実際に設計の欠陥を追跡して修正するのに役立ちます（safe型キャストなど）または、アプリケーションが想定を行い、実際に正しくないまたは誤った方法で動作している（unsafe型キャストの場合）。同様に、彼らはまた、コードの最適化と見なすことができる、削除可能な残骸または死んだコード（到達できないコードブロック、未使用の変数）、またはC++の上記の例のように、テストで表示される原因不明のケースを指摘します。この例では、Javaでコンパイル時エラーが発生することに注意してください。
したがって、警告を修正することには、（少なくとも）管理上いくつかの利点があります。
- 会社のイメージとそれがクライアントのデータをどのように処理するかを心配する上級者にとっては、Big Deal（tm）であるはずのユーザー入力データでコードが正しく動作しない可能性が低くなります。ユーザーが愚かなことをするのを防ぐためにクラッシュすることは、クラッシュさせずにユーザーにそれをさせることよりも優れています。
- 要員を改造したい場合、人々は警告のないコードベースに入ることができます（そして、びっくりしたり、文句を言ったりしないでください。）たぶん、これにより、チームYのプロジェクトYへの貢献の保守性や品質についての不平の量や意見が減少するでしょう。
- コンパイラの警告を削除してコードを最適化すると、実行時間に大幅な改善はありませんが、テストに関して多くのスコアが向上します。
- コードカバレッジスコアは増加する可能性があります。
- （上記のsafe型キャストなどにより）テスト境界および無効なテストケースはより頻繁に成功する可能性があります。
- テストケースが失敗した場合、その原因がそのソースファイル内のコンパイラ警告の1つにあるかどうかを考える必要はありません。
- コンパイラの警告がゼロのほうが数千よりも優れていることは簡単に議論できます。警告やエラーがコードの品質について語っていないので、コードの品質は警告が少ないほど改善されると主張できます。
- コンパイラの警告がなく、1つ以上の警告が表示された場合、誰がそれらをコードベースに表示させたのかを簡単に知ることができます。 「警告なし」のポリシーがある場合、それはおそらく彼らが仕事を適切に行っていない人々を特定するのに役立つでしょうか？コードを書くことは、何かを機能させることだけでなく、機能させることでもありますwell。
私はまだプロジェクト管理についてほとんど知らないジュニア開発者であることに注意してください。何か間違ったことを言った場合は、私の考えを修正して、存在しないことを拒否する前に編集する機会を与えてください:)
私は過去に同じような特徴を持つプロジェクトに取り組んだことがあります。これは特に、もともとJava 1.4で記述されていました。ジェネリックを含むJava 5が出てきたら、コンパイラがスローする警告の数を、コレクションAPIの使用法。
ジェネリックを使用し始めて、すべての警告を取り除くのにかなり時間がかかるでしょう。これは考慮しなければならない要素ですが、修正する必要があることを誰か（特にマネージャ）に説得する必要がある場合は、次のようなハードデータが必要になります。
レガシーまたは非標準に準拠したコード（標準はプロジェクトのコーディング標準です）のバグに費やして回避できた時間。
「特定の」警告を無視することで、時間とお金を失う方法を示す法案を提示し続けることができ、誰かがアイデアを得るでしょう。重要なのは、すべての警告が一見の価値があるわけではないということです。少なくともすぐにではありません。簡単に言うと、すぐに対処する必要がある警告の優先順位を確立する必要があります。まず、プロジェクトで発生しているバグに関連するものを検討します。
また、バグを修正するときに、警告を無視しないことで（またはCIまたはビルドシステムがある場合はPMDまたはFindBugsを実行することで）バグを回避できたことを、バグトラッカーでメモすることもできます。コンパイラの警告に注意することで修正できるバグが十分にある限り、コンパイラの警告を見ることについてのあなたの主張は有効です。そうでなければ、それはビジネス上の決定であり、通常、この戦いと戦うために時間を費やす価値はありません。
成功し、チームが警告を順守することにした場合は、段階的なアプローチを取る必要があります。一度に1万件の警告を出すことはできません。したがって、最も重要なもの（高い確率でバグであるもの）を選択し、それほど重要でないものを無効にすることができます。修正されている場合は、警告レベルを再度上げてください。さらに、ほとんどの場合バグであるコードに対して警告を表示するFindBugsから始めることもできます。
あなたはすべての警告を取り除く2つの方法があります（そして私はそれが微妙なバグを隠すことができることに同意します）：
- これが最善の方法であることをチーム全体に納得させ、修正してもらいます。
- これが最善の方法であることを上司に納得させ、それを必須にします。次に、それを修正する必要があります。
あなたの場合、1はもう実行不可能だと思います。また、生産性の出力に表示される警告の数が多いため、おそらくこれには非常に時間がかかるため、経営陣はとにかく知る必要があります。
だから、私の提案は次のとおりです。ボスと一緒にそれを取り上げ、これがカチカチ音をたてる爆弾であることを彼に納得させ、それを公式の方針にした。
私はあなたに完全に同意します。コンパイル警告を可能な限りクリーンアップすることがベストプラクティスです。あなたのチームは開発ツールとしてEclipseを使用していると述べました。 Eclipseは、コードをクリーンアップしてコードスタイルの一貫性を保つのに役立つ非常に優れたツールです。
- 各Javaプロジェクト、フォーマットコード、未使用のローカル変数、インポートの整理などのプロジェクトの[保存アクション]を定義します（このようなクリーンアップに異論はないでしょう）。
- プロジェクトごとにプロジェクト固有のコンパイルオプションを定義します。たとえば、コンパイルレベル（コードがジェネリックに関連する警告をクリーンアップするために1.4と互換性がある必要がある場合）、割り当ては効果がありません（例： 'x = x'）など。あなたとあなたのチームメイトはこれらの項目について合意をすることができ、Eclipseはコンパイルエラーについて合意した後、開発段階でそれらを「エラー」として報告します。
Eclipseは.settingsフォルダーの下にそれらの設定のいくつかのプロパティファイルを作成します。それらを他のJavaプロジェクトにコピーし、ソースコードの一部としてSCMにチェックインできます。
Eclipseのコードを調べて、Eclipse開発者がどのように実行しているかを確認できます。
これらのほとんどは重要ではない警告であり、リストから削除することが不可欠であると私は彼らに言います。そのため、群集内の実際の重要な警告を見逃さないようにします。
あなたはそれらを説得しようとするのに多くの忍耐力が必要です、ペアプログラミングをするときに警告を取り除くことは他の人が習慣を身につけるのを助けるでしょう。効果的なJava 'Item 24：Eliminate unchecked warnings'（generic collectionの場合）を読むように彼らに勧めます。そして、人々があなたのアドバイスに従わない場合、おそらく多くのインスタンスを無視してください;）
ここでの効果的なアプローチは、プロジェクトを自動的にビルドし、コードがチェックインされるたびにテストを実行するContinuous Integrationサーバーをセットアップすることです。これをまだ使用していない場合は、使用する必要があります。使用するメリットを他の人に納得させることはそれほど難しくありません。
管理/チームがこれを行うことの利点を納得させる（悪いビルドが展開されるのを防ぎ、バグを早期に発見する、特にソフトウェアの他の部分に誤って影響を与えるもの、回帰テストを維持する、早期および頻繁にテストするなど）
すべてのテストに合格した状態でCIサーバーをインストールします（テストがない場合は、合格した簡単なテストを作成して、すべてが緑であることがわかるようにします）。
各ビルドのステータスに関するセットアップメールまたはその他の通知。ここでは、コードをチェックインしたユーザー、変更内容（またはコミットへのリンク）、およびビルドのステータス+出力を含めることが重要です。これは、成功と失敗の両方に対してチーム全体の可視性をもたらすため、重要なステップです。
警告がある場合にテストが失敗するようにCIサーバーを更新します。これは、経営陣およびチームリーダーから、体系的な方法でチームの規律を高めるものと見なされ、送信されるすべての失敗した電子メールに対して責任を負うことを望まないでしょう。
（オプション）目に見えるダッシュボード、溶岩ランプ、フラッシュライトなどを追加して、ビルドの状態とそれを壊した/修正した人を示すことで、これをうまく使いこなすことができます。