Come comunico a un collega che il loro codice non fa nulla? [duplicare]

Il modo più semplice è chiedere da un punto di non capire e chiedere la loro opinione. Non va bene dire "il tuo codice fa schifo", è tutt'altra cosa da dire "Ehm, ho visto questo e davvero non riesco a capire cosa sta facendo, o perché lo sta facendo. Cosa ne pensi?" o simili - potresti dire qual è la tua preoccupazione e chiedergli di spiegartelo, o chiedere loro se hai ragione.

In questo modo, li fai diventare parte della soluzione e tipicamente realizzerà il problema e lo risolverà da solo (oppure puoi offrirti di farlo per loro).

Sono sicuro che hai scritto un codice del genere, ma non lo vedi fino a quando qualcuno lo indica e hai un momento d'oro. Tratta questo codice non come un errore enorme, ma solo come un altro piccolo gallo che tutti produciamo di tanto in tanto e sarai bravo.

Lo scopo di tutto il codice è in definitiva quello di influenzare il mondo al di fuori del programma in qualche modo. A nessuno importa del contenuto delle celle di memoria o dei registri della CPU; si preoccupano solo della pagina stampata o delle informazioni visualizzate su uno schermo. Se il codice non immette / restituisce nulla e non modifica lo stato del programma in alcun modo che potrebbe causare qualsiasi I / O, è per definizione superfluo.

Ma come vedere questo? Il modo più semplice è avere un test unitario. Questo codice non può soddisfare alcun test che verifichi la presenza di valori fattoriali effettivi, poiché l'unico valore che è calcolato non lo rende mai al di fuori della funzione. Basta scrivere un test case che codifica ciò che il codice dovrebbe fare, e diventa banale dimostrare che non lo è. (Certo, questo non è il motivo principale per cui le persone di solito sostengono lo sviluppo basato sui test, ma funziona molto bene anche per questo scopo.)

Stay with me here. When I say the code "does nothing", I mean something like the following function

Il termine corretto per questo tipo di codice sorgente è incomplete . Potresti dire a un altro programmatore "Dopo aver esaminato il tuo codice sorgente ho trovato una funzione incompleta. Puoi chiarire il suo intento?"

Il lavoro incompleto rende sempre più produttivi i prodotti di produzione. Ci sono molte possibili ragioni per cui ciò accada.

• Lo sviluppatore ha modificato queste modifiche per errore.
• Lo sviluppatore aveva bisogno della funzionalità mock fino a quando non può essere completata in seguito.
• Lo sviluppatore non è riuscito a terminare il lavoro, ma lo ha comunque spinto.

When I encounter such code, I often spend some extra time and go through it several times, because I worry that I might be missing something. I could just take the high road, or fix the bug and be done with it, but I worry that this slowdown would reflect badly on me and my performance.

La tua sicurezza e efficienza lavorativa non hanno nulla da fare con il lavoro prodotto da altre persone. I processi, la qualità del codice sorgente, la garanzia della qualità e lo stile di gestione di un'azienda sono fuori dal tuo controllo (a meno che non faccia parte del tuo lavoro cambiarli). Cerca di tenere queste cose separate da come percepisci le tue prestazioni e il tuo valore.

So, should I take the high road, and assume the team understands, or should I communicate that the code doesn't do much? If the latter is the better option, how do I do that without being condescending or disrespectful?

Ciò che stai chiedendo qui non ha nulla a che fare con la programmazione del computer.

Vorrei chiedere questo sul link

Probabilmente otterrai risposte su come lavorare efficacemente in un team.

• Metti il 100% del tuo impegno nel tuo lavoro. Nessuno può criticare se hai provato il tuo meglio. Aspettarsi più di quello che si è in grado di fare è solo una gestione folle. Cercando di lavorare velocemente ti fa fallire più velocemente.
• Comunicare in modo costruttivo con i membri del tuo team. Parla ed esprimi.
• Ascolta ciò che i membri del tuo team hanno da dire.
• Non essere un lupo solitario. Aiuta il team a risolvere i problemi.
• Condividi apertamente con i membri del tuo team. Condividi le tue idee, pensieri e preoccupazioni. Non aspettare finché qualcuno non chiede. Sforzati di condividere.
• Offerta di aiuto. Se trovi un lavoro incompleto. Offri di finirlo.
• Sii più flessibile. Piuttosto che lamentarsi dei problemi. Pensa al perché questi problemi esistono e accettali. La maggior parte delle persone stressate su un progetto lo fa per cose che non possono cambiare.
• Sii sempre rispettoso, solidale e onesto con gli altri membri del team. Potresti non ottenere lo stesso risultato, ma imparerai il valore di quei tratti.

Se nulla esce o viene fatto riferimento al di fuori dell'ambito del sistema rappresentato dal codice, non ha alcun senso. Devi solo tracciare una linea attorno all'intero sistema e sfidare l'ostinato dev per indicare dove è effettivamente attraversato.

Chiedi allo sviluppatore di guidarti attraverso il codice nella sessione di revisione del codice e di chiedere quale fosse il suo processo di pensiero attorno ad esso. Vedi se riconosce il comportamento superfluo. Se non lo fa, chiedigli espressamente. Forse un po 'più rotonda, ma non così conflittuale.

I worry that this slowdown would reflect badly on me and my performance.

Se il miglioramento del codice che trovi si riflette male su di te, allora hai un problema molto più grande nella tua squadra rispetto a come risolvi i problemi che trovi! OK, se non è rotto non devi avere per risolverlo, ma per un vero codice ridondante è probabilmente una buona idea semplificarlo rimuovendolo. Le stime di tempo dovrebbero essere basate sulla realtà pratica della comprensione del codice man mano che procedi e sulla risoluzione dei problemi che trovi. Se sei in modalità di crisi e non puoi farlo, la risposta sarebbe "metti giù la testa e spera per il meglio", ma dovrebbe essere raro.

Il codice ridondante non è il problema peggiore che si possa trovare, ma indica un errore nel modo di pensare di chi l'ha scritto (o lo ha modificato per diventare ridondante). Pertanto merita almeno la stessa attenzione di qualsiasi altro refactoring che si trova nel codice che si visita, e forse di più.

should I take the high road, and assume the team understands

No. Fai parte della squadra, non capisci, quindi non tutti capiscono. Non dare per scontato che ci sia un mistero più alto a cui tutti gli altri sono a conoscenza. Molto più probabilmente, nessuno vorrebbe che fosse così e tutti gli altri non se ne sono accorti o non sono riusciti a migliorarlo. O ti sbagli. In quest'ultimo caso trarrai beneficio da una spiegazione del tuo errore, nel primo caso qualcun altro trarrà vantaggio dall'affrontarlo.

should I communicate that the code doesn't do much?

A seconda di come il tuo team pensa al "possesso" del codice, potrebbe essere che la cosa giusta da fare sia solo correggerla e (se la modifica non parla da sola) discuterla quando le tue modifiche sono riviste. In alternativa, potrebbe esserci qualcuno nella squadra che è la persona più ovvia con cui parlarne prima di andare avanti con un cambiamento, sia l'autore che qualcun altro con una particolare responsabilità. Quando parli con qualcuno, sia esso il proprietario o un revisore del codice, tutto ciò che rimane è decidere cosa dire.

Se sei a tuo agio a sparare direttamente dai fianchi:

"Questo codice non fa nulla"

"Hai dimenticato di restituire il risultato, devo correggerlo?"

"Questa funzione void non ha effetti collaterali, a cosa serve?"

Naturalmente questo potrebbe essere considerato maleducato, in realtà dipende dal tuo rapporto con la persona. Quindi puoi essere più diplomatico:

"Che cosa fa questo codice?"

"Il risultato è necessario ovunque o possiamo saltare questa parte?"

"Questo sembra sbagliato, quindi non sono sicuro di aver capito tutto"

"Mi dispiace terribilmente disturbarti, ma non sono stato in grado di capire queste poche righe di codice. Mi sembra che questa funzione non faccia nulla, quindi mi chiedevo perché fosse così. Molto probabilmente l'ho frainteso, o suppongo che potrebbe essere lì per supportare qualche direzione futura, nel qual caso mi chiedevo se avrei potuto aggiungere utili commenti per spiegare cosa ".

Naturalmente, l'ultimo esempio mostra una linea sottile tra ossequiosamente educato e semplicemente condiscendente. Alcune persone suonano bene in questo modo, altre suonano come dei sarcastici.

Personalmente, di solito vado con "Questo non dovrebbe restituire nulla?". Mi aspetto la risposta "no". È intenzionalmente un po 'maleducato / scherzoso, perché con i miei colleghi attuali posso esserlo, ma non accuserei nessuno di qualcosa oltre una svista. E se la risposta è "sì" con una ragione, allora è giusto. Un'altra opzione comune per me è "Penso che questo dovrebbe restituire qualcosa". Entrambe sono cose che sarei felice di avermi detto.

Avrei preferito postare questo come un commento ahimè, sono a corto di rappresentante.

Nel mio mondo, se non riesco a tracciare direttamente un pezzo di codice per un requisito documentato o un requisito derivato, lo contrassegno per una revisione del team che si verifica ogni due settimane o quando necessario.

    // REVIEW: 05/19/2015
    // Can't find the need for this code. Perhaps it's been orphaned? 
    // Need to identify the requirement associated or remove it.
    public static bool WouldYouLikeToDance(this Person you, Person dancePartner)
    {
        // determine minimum acceptable attractiveness
        int minAcceptable = you.SelfWorthAndRespect - (you.CountDrinksConsumed() * 0.10);

        return (minAcceptable <= dancePartner.Attractiveness);           
    }

Trovo che sia meglio non affrontarli direttamente, identificando anonimamente le preoccupazioni e aspettandosi che facciano lo stesso per te. Durante la revisione del gruppo, puoi valutare il team come un controllo per assicurarti di non identificare erroneamente qualcosa di valido. L'obiettivo generale è la qualità del codice e un effetto collaterale, migliorando il set di abilità di ogni sviluppatore e del team nel suo insieme.

Se questo codice viene presentato durante la revisione del codice, sembra che tu abbia pochi problemi; solo fornire un feedback che non è chiaro cosa fa e chiedere un test unitario.

Se non è durante la revisione del codice, potresti pensare non solo a come correggere il problema immediato, ma a cercare una soluzione più approfondita in termini di modifica del processo.

Qualcuno dei seguenti potrebbe capirlo:

• Livelli di avviso adeguati al momento della compilazione, insieme a un requisito di avviso zero sul codice.
• Un processo di revisione del codice
• Copertura sufficiente per i test delle unità.
• Commentando gli standard

Ora, il semplice fatto che tu abbia questo problema mi suggerisce che forse alcuni dei membri del tuo team non sono bravi a leggere il codice. Sfortunato, ma nel mondo reale è molto comune.

Vorrei sottolineare che le pratiche di cui sopra sono utili anche in una squadra molto strong (i commenti sono discutibili).

Tuttavia, la cosa utile delle pratiche di cui sopra sono particolarmente utili in una squadra più debole; forniscono una struttura per migliorare la qualità del codice senza che diventi personale.