it-swarm.dev

Wie kann ich meine Teamkollegen davon überzeugen, dass wir Compiler-Warnungen nicht ignorieren sollten?

Ich arbeite an einem riesigen Projekt (eher wie eine verworrene Kombination von Dutzenden von Miniprojekten, die aufgrund eines schlechten Abhängigkeitsmanagements nicht einfach zu trennen sind, aber das ist eine andere Diskussion) in Java mit Eclipse) Wir haben bereits eine Reihe von Warnungen in den Compilereinstellungen deaktiviert und das Projekt enthält immer noch über 10.000 Warnungen.

Ich bin ein großer Befürworter für den Versuch, alle Warnungen zu adressieren, wenn möglich alle zu beheben und sie für diejenigen zu unterdrücken, die untersucht und als sicher eingestuft werden. (Gleiches gilt für meine religiöse Besessenheit, alle implementierten/überschriebenen Methoden als @Override zu markieren.) Mein größtes Argument ist, dass Warnungen Ihnen im Allgemeinen helfen, potenzielle Fehler während der Kompilierungszeit zu finden. Vielleicht 99 von 100 Mal sind die Warnungen unbedeutend, aber ich denke, das Kopfkratzen, das es für das eine Mal spart, dass es einen großen Fehler verhindert, ist alles wert. (Mein anderer Grund ist meine offensichtliche OCD mit Code-Sauberkeit).

Viele meiner Teamkollegen scheinen sich jedoch nicht darum zu kümmern. Ich behebe gelegentlich Warnungen, wenn ich über sie stolpere (aber Sie wissen, dass es schwierig ist, Code zu berühren, der von einem Kollegen geschrieben wurde). Mit buchstäblich mehr Warnungen als Klassen werden die Vorteile von Warnungen sehr minimiert, denn wenn Warnungen so häufig vorkommen, wird sich niemand die Mühe machen, sie alle zu untersuchen.

Wie kann ich meine Teamkollegen (oder die vorhandenen Kräfte) davon überzeugen, dass Warnungen behandelt (oder unterdrückt werden müssen, wenn sie vollständig untersucht wurden)? Oder sollte ich mich davon überzeugen, dass ich verrückt bin?

Vielen Dank

(S. Ich habe vergessen zu erwähnen, was mich schließlich dazu veranlasst hat, diese Frage zu stellen, ist, dass ich leider bemerkt habe, dass ich Warnungen langsamer behebe, als sie erzeugt werden.)

51
user32020

Sie können zwei Dinge tun.

  1. Weisen Sie darauf hin, dass Warnungen aus einem bestimmten Grund vorhanden sind. Compiler-Autoren setzen sie nicht ein, weil sie gemein sind. Menschen in unserer Branche sind im Allgemeinen hilfreich. Viele Warnungen sind hilfreich.

  2. Sammeln Sie eine Geschichte spektakulärer Fehler, die sich aus ignorierten Warnungen ergeben. Eine Websuche nach "Compiler-Warnungen beachten" gibt einige Anekdoten zurück.

Ihre Besessenheit mit @Override ist keine "Besessenheit". Das ist eine gute Sache. Haben Sie jemals einen Methodennamen falsch geschrieben?

37
Ray Toal

Relevante Lektüre hier . C++, aber immer noch relevant. Dieses Beispiel gefällt mir besonders gut (Codekommentar gehört mir):

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)
}

In den meisten Fällen bedeutet eine Warnung den Unterschied zwischen dem Absturz der Anwendung mit einem Fehler, der Ihnen tatsächlich hilft, einen Konstruktionsfehler aufzuspüren und zu beheben (z. B. safe Typecasting) oder der Anwendung Annahmen treffen und sich dann tatsächlich falsch oder fehlerhaft verhalten (was bei unsicher Typecasting der Fall wäre). In ähnlicher Weise weisen sie auch auf Cruft oder toten Code hin, der entfernt werden kann (nicht erreichbare Codeblöcke, nicht verwendete Variablen), was als Codeoptimierung angesehen werden kann, oder auf nicht berücksichtigte Fälle, die beim Testen auftreten, wie im obigen Beispiel für C++. Beachten Sie, dass dieses Beispiel in Java zu einem Fehler bei der Kompilierung führt.

Das Beheben von Warnungen hat also (zumindest) mehrere Vorteile für das Management:

  1. Eine geringere Wahrscheinlichkeit, dass sich der Code bei vom Benutzer eingegebenen Daten nicht ordnungsgemäß verhält, sollte für die höheren Unternehmen, die sich Sorgen über das Image des Unternehmens und den Umgang mit den Daten seiner Kunden machen, eine große Sache sein. Ein Absturz, um zu verhindern, dass ein Benutzer etwas Dummes tut, ist besser, als nicht abzustürzen und ihn dies tun zu lassen.
  2. Wenn sie Personal neu mischen möchten, können die Leute in eine warnungsfreie Codebasis geraten (und nicht so ausflippen oder sich beschweren). Vielleicht reduziert dies die Menge an Murren oder Meinungen über die Wartbarkeit oder Qualität des Beitrags von Team X zu Projekt Y.
  3. Das Optimieren von Code durch Entfernen von Compiler-Warnungen, ohne die Laufzeit wesentlich zu verbessern, wird zahlreiche Punkte beim Testen verbessern:
    • Alle Werte für die Codeabdeckung werden wahrscheinlich steigen.
    • Das Testen von Grenz- und ungültigen Testfällen wird wahrscheinlich häufiger erfolgreich sein (unter anderem aufgrund des oben genannten safe Typecasting).
    • Wenn ein Testfall fehlschlägt, müssen Sie nicht darüber nachdenken, ob dies auf eine der Compiler-Warnungen in dieser Quelldatei zurückzuführen ist.
    • Es ist leicht zu argumentieren, dass Null-Compiler-Warnungen besser sind als Tausende. Keine Warnungen oder Fehler sprechen für die Qualität des Codes. Sie können also argumentieren, dass sich die Codequalität verbessert, je weniger Warnungen vorhanden sind.
  4. Wenn Sie keine Compiler-Warnungen haben und eine oder mehrere eingeführt werden, ist es viel einfacher zu wissen, wer diese in der Codebasis angezeigt hat. Wenn Sie eine Richtlinie "Keine Warnungen" haben, hilft dies ihnen möglicherweise dabei, Personen zu identifizieren, die ihre Arbeit nicht ordnungsgemäß ausführen. Beim Schreiben von Code geht es nicht nur darum, dass etwas funktioniert, sondern auch darum, dass es gut funktioniert .

Beachten Sie, dass ich noch ein Junior-Entwickler bin, der wenig über Projektmanagement weiß. Wenn ich also etwas Falsches gesagt habe, korrigieren Sie bitte mein Denken und geben Sie mir die Möglichkeit, es zu bearbeiten, bevor Sie mich aus der Existenz herabstimmen :)

12
user31713

Ich habe in der Vergangenheit an einem Projekt mit ähnlichen Eigenschaften gearbeitet. Insbesondere dieses wurde ursprünglich in Java 1.4.) Geschrieben. Sobald Java 5 mit Generika herauskam, kann man sich die Anzahl der vom Compiler ausgegebenen Warnungen für jeden vorstellen Verwendung der Sammlungs-API.

Es hätte einige Zeit gedauert, alle Warnungen zu beseitigen, indem man anfing, Generika zu verwenden. Dies ist ein Faktor, der berücksichtigt werden muss. Wenn Sie jedoch jemanden (insbesondere Ihren Manager) davon überzeugen müssen, dass eine Korrektur erforderlich ist, benötigen Sie beispielsweise harte Daten

die Zeit, die für Fehler in Legacy- oder nicht standardkonformem Code (der Standard ist der Codierungsstandard Ihres Projekts) aufgewendet wurde, die hätte vermieden werden können.

Sie könnten weiterhin eine Rechnung vorlegen, die zeigt, wie Sie Zeit und Geld verlieren, indem Sie "bestimmte" Warnungen ignorieren, und jemand wird auf die Idee kommen. Der entscheidende Teil ist, dass nicht alle Warnungen einen Blick wert sind, zumindest nicht sofort. Mit einfacheren Worten, Sie müssen die Priorität der Warnungen festlegen, die sofort behoben werden müssen. Betrachten Sie zunächst diejenigen, die für Fehler relevant sind, die in Ihrem Projekt auftreten.

Sie können im Bug-Tracker auch Notizen machen, wenn Sie Fehler beheben, dass dieser Fehler vermieden werden könnte, indem Sie eine Warnung nicht ignorieren (oder PMD oder FindBugs ausführen, wenn Sie ein CI- oder Build-System haben). Solange es eine ausreichende Anzahl von Fehlern gibt, die durch Beachtung von Compiler-Warnungen behoben werden können, ist Ihr Standpunkt zum Betrachten von Compiler-Warnungen gültig. Ansonsten ist es eine geschäftliche Entscheidung, und normalerweise lohnt es sich nicht, diesen Kampf zu führen.

7
Vineet Reynolds

Wenn Sie erfolgreich sind und Ihr Team beschließt, die Warnungen zu beachten, sollten Sie schrittweise vorgehen. Niemand kann und wird 10000 Warnungen auf einmal. Sie können also die wichtigsten auswählen (Fehler mit hoher Wahrscheinlichkeit) und die weniger wichtigen deaktivieren. Wenn sie behoben sind, erhöhen Sie die Warnstufe erneut. Darüber hinaus können Sie mit FindBugs beginnen, das vor Code warnt, der fast immer ein Fehler ist.

2
Heiko Schmitz

Sie haben zwei Möglichkeiten, alle Warnungen zu entfernen (und ich stimme zu, dass dies einen subtilen Fehler verbergen kann):

  1. Überzeugen Sie das gesamte Team davon, dass dies das Beste ist, und lassen Sie es das Problem beheben.
  2. Überzeugen Sie Ihren Chef, dass dies das Beste ist, und machen Sie es obligatorisch. Dann müssen sie es reparieren.

Ich glaube, dass 1 in Ihrem Fall nicht mehr machbar ist. Auch dies wird wahrscheinlich aufgrund der Anzahl der Warnungen so lange dauern, dass dies in der Produktivitätsausgabe angezeigt wird, sodass das Management es trotzdem wissen muss.

Mein Vorschlag lautet also: Nehmen Sie es mit dem Chef auf, überzeugen Sie ihn, dass es sich um eine tickende Bombe handelt, und lassen Sie es offiziell festlegen.

Ich stimme Ihnen voll und ganz zu. Es wird empfohlen, die Kompilierungswarnungen so weit wie möglich zu bereinigen. Sie haben erwähnt, dass Ihr Team Eclipse als Entwicklungswerkzeug verwendet. Eclipse ist ein sehr gutes Tool, mit dem Sie den Code bereinigen und die Konsistenz des Codestils sicherstellen können.

  1. definieren Sie 'Aktion speichern' für jedes Java Projekt, wie Formatierungscode, nicht verwendete lokale Variablen, Organisation der Importe (ich denke, niemand hat Einwände gegen eine solche Art der Bereinigung).
  2. definieren Sie projektspezifische Kompilierungsoptionen für jedes Projekt. Beispiel: Kompilierungsstufe (wenn Ihr Code mit 1.4 kompatibel sein muss, um die Warnungen in Bezug auf generisch zu bereinigen), Zuweisung hat keine Auswirkung (z. B. 'x = x') und so weiter. Sie und Ihr Teamkollege können eine Vereinbarung für diese Elemente treffen, und Eclipse meldet sie in Ihrer Entwicklungsphase als "Fehler", nachdem Sie die Vereinbarung für den Kompilierungsfehler getroffen haben.

Eclipse erstellt einige Eigenschaftendateien für diese Einstellungen im Ordner .settings. Sie können sie in andere Java -Projekte) kopieren und als Teil des Quellcodes in SCM einchecken.

Sie können den Code von Eclipse überprüfen, um zu sehen, wie Eclipse-Entwickler dies tun.

1
Kane

Ich würde ihnen nur sagen, dass die meisten davon unbedeutende Warnungen sind und es wichtig ist, dass wir sie von der Liste entfernen. Damit wir die wirklich bedeutende Warnung in der Menge nicht verpassen, wie es passiert!

1
WinW

Sie benötigen viel Geduld, um sie zu überzeugen. Das Entfernen von Warnungen bei der Paarprogrammierung hilft anderen dabei, die Gewohnheit wieder aufzunehmen. Schlagen Sie ihnen vor, Effective Java 'Punkt 24: Ungeprüfte Warnungen beseitigen' (für die generische Sammlung) zu lesen. Und ignorieren Sie wahrscheinlich viele Fälle, in denen Personen Ihren Ratschlägen nicht folgen;)

0
Mehul Lalan

Ein effektiver Ansatz wäre hier die Einrichtung eines Continuous Integration Servers, der das Projekt automatisch erstellt und die Tests ausführt, wenn jemand Code eincheckt. Wenn Sie dies nicht bereits verwenden, sollten Sie dies tun, und es ist nicht sehr schwer, andere von den Vorteilen zu überzeugen.

  1. Überzeugen Sie das Management/die Teamleiter von den Vorteilen, die sich daraus ergeben (verhindern, dass fehlerhafte Builds bereitgestellt werden, Fehler frühzeitig erkennen, insbesondere solche, die versehentlich andere Teile der Software betreffen, Regressionstests durchführen, früh und häufig testen usw.)

  2. Installieren Sie den CI-Server mit allen bestandenen Tests (wenn Sie keine Tests haben, schreiben Sie einen kurzen Test, der erfolgreich ist, damit jeder sieht, dass er grün ist).

  3. Richten Sie E-Mails oder andere Benachrichtigungen über den Status jedes Builds ein. Hier ist es wichtig anzugeben, wer den Code eingecheckt hat, wie die Änderung war (oder einen Link zum Commit) und den Status + die Ausgabe des Builds. Dies ist ein wichtiger Schritt, da er eine teamweite Sichtbarkeit sowohl für Erfolge als auch für Misserfolge bewirkt.

  4. Aktualisieren Sie den CI-Server, damit Tests fehlschlagen, wenn Warnungen angezeigt werden. Dies wird von Management und Teamleitern als systematische Erhöhung der Disziplin des Teams angesehen, und niemand möchte für alle fehlgeschlagenen E-Mails verantwortlich sein.

  5. (optional) Werden Sie damit nett und geeky, indem Sie einige sichtbare Dashboards, Lavalampen, blinkende Lichter usw. hinzufügen, um den Status des Builds anzuzeigen und wer ihn kaputt gemacht/repariert hat.

0
Ben Taitelbaum