Come posso convincere i miei compagni di squadra che non dovremmo ignorare gli avvisi del compilatore?

Lavoro su un grande progetto (più simile a una combinazione intricata di dozzine di mini progetti che non possono essere facilmente separati a causa della cattiva gestione delle dipendenze, ma questa è una discussione diversa) in Java usando eclipse. Abbiamo già disattivato una serie di avvisi dalle impostazioni del compilatore e il progetto ha ancora oltre 10.000 avvisi.

Sono un grande sostenitore del tentativo di rispondere a tutti gli avvisi, correggerli tutti se possibile, e per quelli che vengono esaminati e considerati sicuri, li sopprimono. (Lo stesso vale per la mia ossessione religiosa di contrassegnare tutti i metodi implementati / sostituiti come @Override). La mia più grande argomentazione è che generalmente gli avvisi ti aiutano a trovare potenziali bug durante la compilazione. Forse su 99 di 100 volte, gli avvertimenti sono insignificanti, ma penso che il grattarsi la testa che salvi per una volta che previene un grosso bug, ne vale la pena. (L'altra mia ragione è il mio apparente disturbo ossessivo compulsivo con pulizia del codice).

Tuttavia, molti dei miei compagni di squadra non sembrano preoccuparsene. Occasionalmente correggo avvisi quando mi imbatto in loro (ma sai che è difficile quando tocchi il codice scritto da un collega). Ora con letteralmente più avvisi rispetto alle classi, i vantaggi degli avvisi sono molto ridotti al minimo, perché quando gli avvisi sono così comuni, nessuno si preoccuperà di esaminarli tutti.

Come posso convincere i miei compagni di squadra (o i poteri che sono) che gli avvisi devono essere indirizzati (o soppressi quando sottoposti a un'indagine completa)? O dovrei convincermi che sono pazzo?

Grazie

(PS Ho dimenticato di menzionare ciò che alla fine mi ha spinto a pubblicare questa domanda è che ho tristemente notato che sto correggendo gli avvisi più lentamente di quanto vengano prodotti)

Puoi fare due cose.

1. Fai notare che gli avvisi sono disponibili per un motivo. Gli autori di compilatori non li inseriscono perché sono meschini. Le persone nel nostro settore sono generalmente utili. Molti avvisi sono utili.

2. Raccogli una storia di fallimenti spettacolari derivanti da avvisi ignorati. Una ricerca web per "Prestare attenzione agli avvisi del compilatore" restituisce alcuni aneddoti.

La tua ossessione per @Overridenon è una "ossessione". Questa è una buona cosa. Hai mai scritto male il nome di un metodo?

Lettura pertinente qui . C ++, ma ancora rilevante. Mi piace particolarmente questo esempio (il commento al codice è mio):

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

Molte volte, un avvertimento significherà la differenza tra l'arresto anomalo dell'applicazione con un errore che ti aiuterà effettivamente a rintracciare un difetto di progettazione e risolverlo (come la tipografia sicura ) o l'applicazione che fa ipotesi e quindi si comporta effettivamente in modo errato o modo errato (che sarebbe il caso di un typecasting non sicuro ). Allo stesso modo, indicano anche cruft o dead code che possono essere rimossi (blocchi di codice non raggiungibili, variabili non utilizzate), che possono essere considerati ottimizzazione del codice o casi non contabilizzati che verranno visualizzati nei test, come nell'esempio precedente per C ++. Si noti che questo esempio provoca un errore di compilazione in Java.

Pertanto, la correzione degli avvisi presenta (almeno) numerosi vantaggi per la gestione:

1. Meno probabilità che il codice si comporti in modo improprio con i dati immessi dall'utente che, per i vertici interessati all'immagine dell'azienda e al modo in cui gestisce i dati dei suoi clienti, dovrebbe essere un grosso problema (tm). Arrestare per impedire a un utente di fare qualcosa di stupido è meglio che non arrestarsi e lasciarlo fare.
2. Se vogliono rimescolare il personale, le persone possono entrare in una base di codice priva di avvertimento (e non impazzire o lamentarsi tanto ..). Forse questo ridurrà la quantità di brontolio che continua, o opinioni sulla manutenibilità o qualità del contributo del Team X al Progetto Y.
3. L'ottimizzazione del codice rimuovendo gli avvisi del compilatore, senza apportare miglioramenti significativi al tempo di esecuzione, migliorerà numerosi punteggi quando si tratta di test:
   • Eventuali punteggi di copertura del codice aumenteranno probabilmente.
   • I limiti di test e i casi di test non validi avranno probabilmente esito positivo più spesso ( tra l'altro, a causa del summenzionato typecasting sicuro ).
   • Quando un caso di test fallisce, non devi pensare se è dovuto a uno degli avvisi del compilatore in quel file sorgente.
   • È facilmente discutibile che gli avvisi del compilatore zero siano migliori di migliaia. Nessun avviso o errore parla della qualità del codice, quindi puoi sostenere che la qualità del codice migliora meno avvisi ci sono.
4. Se non si dispone di avvisi del compilatore e ne vengono introdotti uno o più, è molto più semplice sapere chi ha causato la loro visualizzazione nella base di codice. Se hai una politica di "nessun avvertimento", ciò potrebbe aiutarli a identificare le persone che non svolgono correttamente il loro lavoro, forse? Scrivere codice non significa solo far funzionare qualcosa, si tratta di farlo funzionare bene .

Nota che sono ancora solo uno sviluppatore junior che conosce poco sulla gestione del progetto, quindi se ho detto qualcosa di sbagliato, correggi il mio pensiero e dammi la possibilità di modificare prima di declassare me fuori dall'esistenza :)

Ho lavorato su un progetto con caratteristiche simili in passato. Questo in particolare è stato originariamente scritto in Java 1.4. Una volta che Java 5 con generics è uscito, si può immaginare il numero di avvisi lanciati dal compilatore per ogni utilizzo dell'API Collections.

Ci sarebbe voluto un po 'di tempo per sbarazzarsi di tutti gli avvertimenti, iniziando a usare i generici. Questo è un fattore che deve essere preso in considerazione, ma quando devi convincere qualcuno (specialmente il tuo manager) che ha bisogno di essere riparato, avrai bisogno di dati concreti, come

il tempo speso per i bug nel codice legacy o non standard (lo standard è lo standard di codifica del progetto) che avrebbe potuto essere evitato.

Potresti continuare a presentare un disegno di legge che dimostri come stai perdendo tempo e denaro ignorando "certi" avvertimenti e qualcuno avrà l'idea. La parte fondamentale è che non tutti gli avvertimenti meritano di essere guardati, almeno non subito; in parole più semplici, dovrai stabilire la priorità degli avvisi che devono essere immediatamente indirizzati. Per cominciare, considera quelli pertinenti ai bug che vedi nel tuo progetto.

È inoltre possibile prendere appunti nel tracker dei bug, quando si correggono i bug, che tale bug avrebbe potuto essere evitato non ignorando un avviso (o forse eseguendo PMD o FindBugs se si dispone di un elemento della configurazione o di un sistema di compilazione). Finché esiste un numero sufficiente di bug che possono essere corretti ascoltando gli avvisi del compilatore, il tuo punto di vista sugli avvisi del compilatore sarà valido. Altrimenti, è una decisione commerciale, e di solito non vale la pena spendere tempo per combattere questa battaglia.

Se hai successo e il tuo team decide di osservare gli avvisi, dovresti adottare un approccio graduale. Nessuno può e sarà 10000 avvisi in una volta. Quindi puoi selezionare quelli più importanti (quelli che sono bug con alta probabilità) e disabilitare quelli meno significativi. Se sono corretti, aumentare di nuovo il livello di avviso. Inoltre, puoi iniziare con FindBugs, che avvisa sul codice che è quasi sempre un bug.

Sono totalmente d'accordo con te, è una buona pratica ripulire il più possibile gli avvisi di compilazione. Hai detto che il tuo team sta usando Eclipse come strumento di sviluppo. Eclipse è un ottimo strumento per aiutarti a ripulire il codice e rendere coerente lo stile del codice.

1. definire "Salva azione" per ciascun progetto Java, ad esempio formattazione del codice, variabili locali inutilizzate, organizzazione delle importazioni (penso che nessuno abbia obiezioni su questo tipo di pulizia).
2. definire le opzioni di compilazione specifiche del progetto per ciascun progetto. Ad esempio, livello di compilazione (se il codice deve essere compatibile con 1.4 per pulire gli avvisi relativi al generico), l'assegnazione non ha alcun effetto (ad esempio "x = x") e così via. Tu e il tuo compagno di squadra potete stipulare un accordo per tali elementi ed Eclipse li segnalerà come "Errore" nella fase di sviluppo dopo aver concordato l'errore di compilazione.

Eclipse creerà alcuni file delle proprietà per quelle preferenze nella cartella .settings, puoi copiarli in altri progetti Java e archiviarli in SCM come parte del codice sorgente.

Puoi controllare il codice di Eclipse per vedere come lo fanno gli sviluppatori Eclipse.

Hai due modi per sbarazzarti di tutti gli avvisi (e sono d'accordo che può nascondere un bug sottile):

1. Convinci tutto il team che questa è la cosa migliore da fare e falli riparare.
2. Convinci il tuo capo che questa è la cosa migliore da fare e rendila obbligatoria. Quindi devono ripararlo.

Credo che 1 non sia più possibile nel tuo caso. Anche questo probabilmente richiederà così tanto tempo a causa del numero di avvisi che questo mostrerà nell'output di produttività, quindi la direzione dovrà sapere comunque.

Quindi, il mio suggerimento è: accettalo con il capo, convincilo che è una bomba ad orologeria e fallo diventare una politica ufficiale.

Vorrei solo dire loro che la maggior parte di questi sono avvertimenti insignificanti ed è essenziale che li rimuoviamo dall'elenco. In modo che non ci mancherà il vero avvertimento significativo tra la folla, come accade!

Avrai bisogno di molta pazienza nel cercare di convincerli, rimuovere gli avvisi quando si fa la programmazione in coppia aiuterà gli altri a prendere l'abitudine. Consiglia loro di leggere l'efficace Java "Articolo 24: elimina gli avvisi non controllati" (per la raccolta generica). E probabilmente ignora molti casi in cui le persone non seguono il tuo consiglio;)

Un approccio efficace qui sarebbe quello di impostare un server di integrazione continua che costruisce automaticamente il progetto ed esegue i test ogni volta che qualcuno controlla il codice. Se non lo stai già usando, dovresti esserlo, e non è molto difficile convincere gli altri dei vantaggi di farlo.

1. Convincere il management / team leader dei vantaggi di ciò (prevenire la distribuzione di build errate, individuare bug in anticipo, in particolare quelli che incidono accidentalmente su altre parti del software, mantenere test di regressione, test precoci e spesso, ecc.)

2. Installa il server CI con il superamento di tutti i test (se non hai i test, scrivine uno veloce che passi, in modo che tutti vedano che è verde).

3. Configura e-mail o altre notifiche sullo stato di ogni build. È importante qui includere chi ha controllato il codice, quale era la modifica (o un collegamento al commit) e lo stato + output della build. Questo è un passo importante, poiché provoca visibilità a livello di team sia per i successi che per i fallimenti.

4. Aggiornare il server CI per non superare i test in caso di avvisi. Questo sarà visto dal management e dai team leader come aumentare la disciplina del team in modo sistematico, e nessuno vuole essere responsabile di tutte le e-mail di errore in uscita.

5. (opzionale) diventa simpatico e geek con questo, aggiungendo alcuni cruscotti visibili, lampade lava, luci lampeggianti, ecc. per indicare lo stato della build e chi l'ha rotta / riparata.