Il mio collega non capisce le cose con cui lavora. Cosa fare? [chiuso]


13

Ho trascorso 3 giorni a eseguire il debug di un bug molto oscuro in una libreria creata dal mio collega, questo bug si verifica molto raramente. Dopo tutto ho scoperto che questo errore si verifica a causa dell'accesso cross-thread a un oggetto senza alcun blocco. In realtà questo non è un primo bug di questo tipo, prima c'erano bug simili. Esegue i suoi test unitari e se qualcosa non riesce mette da qualche parte un lucchetto. E se nulla fallisce, allora il suo codice è perfetto. Sembra che non abbia idea della sicurezza del threading. Sono sicuro al 100% che ci sono molti bug simili che non sono ancora emersi. Sembra che PM non capisca anche le cose di threading.
Il problema è che lavora molto più tempo in azienda di me. Ad ogni modo, non posso semplicemente dire "questo ragazzo è incompetente in quest'area", perché questo ti mostra sempre come un "cattivo giocatore di squadra", ecc.


Che paese è questo?

È una compagnia internazionale.
domenica

2
Se è davvero un grosso problema e sei sicuro al 100% che il tuo collega stia commettendo un errore, la prima cosa è segnalarlo educatamente in modo tale da non essere minacciato. La seconda cosa è, se il tuo collega non ascolta, è solo quello di evidenziare i potenziali danni in contanti. Questo è ciò che tutti i manager ascoltano e con molta attenzione. Avere un problema di threading come quello che hai descritto è potenzialmente molto dannoso e, a meno che tu non sia sicuro al 100% nelle tue dichiarazioni, vai avanti con loro.
NB

Probabilmente appartiene al sito di Project Management SE.
Bernard,

1
Il sito di Project Management SE non ha un tag "Multithreading", che dovrebbe avere questa domanda.
RalphChapin,

Risposte:


13

Convincere PM che per evitare tali bug, il know-how del team sulla discussione di cose dovrebbe essere migliorato e dire loro che sei disposto a organizzare qualcosa come un seminario o una presentazione al riguardo. Non renderlo una cosa personale tra te e il tuo collega.


Ho paura che questo non sarà il benvenuto da quel ragazzo, perché pensa che è professionale in questo settore (e può insegnare a tutti se stesso). Ma ci posso provare.
domenica

Ah sì, e un grosso problema: l'inglese non è la mia lingua madre, non parlo molto bene.
domenica

Se sia il collega che il PM hanno una conoscenza limitata del threading e della sicurezza del thread, l'addestramento è sicuramente l'approccio migliore. Non è l'incompetenza di un ragazzo - è la competenza della squadra che è il problema.
boisvert,

1
Un seminario è qualcosa in cui tutti voi potete mettere a loro conoscenza e tutti voi dovreste imparare qualcosa da esso. Se il tuo collega pensa di sapere qualcosa sul threading, forse puoi imparare anche alcune cose da lui.
Doc Brown,

8

Scrivi un unit test che mostra il bug e chiedigli di risolverlo.


1
È già a conoscenza di questo errore. Non riesce a trovare il motivo.
Tika,

Non hai trovato il motivo nella sessione di debug di tre giorni? O leggo la tua domanda in modo errato?

1
@scarfridge Dipende dalla piattaforma. Per Java è possibile utilizzare la strumentazione con codice byte o la programmazione orientata all'aspetto per inserire un'attesa esattamente nel punto in cui si trova il problema (o utilizzare JVMTI per controllare l'esecuzione). È possibile fare!

1
Non è solo questione di sequenza. Sono coinvolti molti altri fattori - quali core eseguono il codice, quando si verifica GC e come sposta gli oggetti, come i cambiamenti vengono propagati dalla cache di un core a un altro, ecc.
tika

1
In realtà è solo un insieme di metodi che chiamano miliardi di volte ripetute. Ma questo non ha molta importanza. Il vero motivo è l'accesso a un oggetto dizionario da 2 thread senza blocco (cioè senza barriere di memoria). Il thread A lo crea, il thread B lo legge.
Tika,

4
  • È compito di uno sviluppatore senior rivedere il suo codice e suggerire miglioramenti.
  • Non sei lì per controllare dopo il suo lavoro, personalmente oderei se qualcuno stesse ricontrollando tutte le mie modifiche per vedere se qualcosa si è rotto
  • Se non accetta il tuo consiglio, è compito del PM risolvere il problema di comunicazione.
  • Il problema del threading in un test unitario mi chiedo se questo test sia effettivamente un test unitario, piuttosto che un test di integrazione o componente.

Ho avuto la tua idea. Obbedisci al tuo comando.
domenica

2
Cosa importa se un test che mostra un problema si chiama "unit test" o "test di integrazione"? L'intera situazione rimane la stessa.
Doc Brown,

1
La mia preoccupazione è che il suo collega potrebbe non conoscere la differenza tra l'unità e il test dei componenti, quindi potrebbe essere necessario un ulteriore addestramento per affrontare questo problema.
CodeART

@CodeRush - Suppongo che non credi nella revisione tra pari? Cosa ci vorrebbe per apprezzare davvero che qualcun altro stava ricontrollando il tuo codice (al contrario di un arresto anomalo della produzione)?

Ho avuto l'idea, ma non l'ho visto funzionare in modo efficace nei miei precedenti lavori. Penso che le recensioni di uno sviluppatore senior siano un meccanismo di feedback migliore.
CodeART

-5

Penso che la tua azienda non dovrebbe utilizzare il multithreading.

Dopo aver fatto un progetto multithread su larga scala, ho scoperto che due tecniche erano fondamentali per far funzionare le cose. Innanzitutto , il codice doveva essere scritto correttamente. Ogni campo ha dovuto essere controllato manualmente per assicurarsi che fosse dichiarato correttamente e correttamente sincronizzato ovunque fosse referenziato. (Attenzione: sto semplificando un po 'le cose qui per mantenere la mia risposta breve - o comunque più breve.) In secondo luogo , il codice ha dovuto essere testato eseguendolo su macchine singole e multicore - molti minuti usando il 100% di ogni nucleo. (E se utilizza solo il 2% di ciascun core, come spesso accade per me, anche questo è un bug.)

Potresti riuscire a gestirlo, ma la tua organizzazione no. Anche se hanno capito il problema, cosa che non hanno, non hanno l'esperienza.

Molte lingue offrono modi per evitarlo. Se si dispone di un lettore socket, che di solito ha un proprio thread, fare in modo che ottenga le informazioni sul thread principale nel modo più rapido e semplice possibile. Meglio ancora, cerca le classi / funzioni di sistema che gestiranno la parte thread della lettura per te. Utilizzare una coda che esegue "eventi" uno dopo l'altro, come fanno la maggior parte delle API della GUI. (Usa la coda degli eventi dell'API della GUI stessa, per quella materia.) Se hai bisogno di un'elaborazione parallela, probabilmente troverai una sorta di "thread di lavoro" che ti permetterà di conservare i dati / i campi in un singolo thread, gestendo tutti i trasferimenti per te.

Sottolineare tutti i pericoli del multithreading. (Storie spaventose: il mio bug preferito riguardava un paio di righe come int i = 5; i = i * i;:, che ha portato ad iavere un valore di 35. Uno che ho visto molto è stato: if (thing != null) thing.reset();lanciare un'eccezione puntatore null.) Penso che la tua unica speranza sia far capire loro che stanno entrare in un mondo intero, nuovo, strano, e che forse dovrebbero fare un grande passo indietro.

Io non sono sicuro di come vero multithreading dovrebbero essere gestiti. Se il lavoro può essere assegnato a una persona, e tutto ciò che fanno viene gettato via se fallisce, va bene. Ma una squadra sarà forte quanto il suo membro più debole, e anche un buon programmatore avrà problemi con il multithreading completo. Spero che le persone linguistiche troveranno un modo per renderlo sicuro. Ho visto alcuni software utili là fuori. Ma penso che sia meglio evitare il multithreading a meno che il tempo di esecuzione non sia critico e che sia disponibile un buon programmatore o un team collaudato .


2
Non hai idea di che compagnia sia o di cosa stiano facendo, quindi il commento "Potresti essere in grado di gestirlo, ma la tua organizzazione non può" è un po 'infondato - per quanto ne sai, Tika potrebbe lavorare in Microsoft . Chiunque siano, il multithreading potrebbe essere il modo migliore per risolvere il loro problema; ci sono molte situazioni in cui si adatta. Mettendo da parte tutto ciò, la domanda non riguarda il multithreading, si tratta di gestire un collega che sta causando problemi a causa della mancanza di esperienza.
anaximander,

@anaximander: il multithreading produce bug molto difficili da riprodurre e molto difficili da rintracciare. Per produrre software MT utilizzabile e riparabile, è necessario disporre almeno di programmatori e gestori consapevoli dei pericoli. L'organizzazione di Tika chiaramente non poteva gestirlo. Ho visto persone di testing / QA forzare i programmatori a scrivere codice audio testando pesantemente e richiedendo correzioni per ogni errore. Questo non funziona con MT. Se il collega non ha abilità, interesse e motivazione, gestiscilo tenendolo lontano da MT.
RalphChapin,

@anaximander: devi avere avuto esperienze migliori con Microsoft di quelle che ho avuto. Anche se per essere onesti, non ho mai visto nulla di simile a un bug di mutlithreading. ....E grazie per il commento.
RalphChapin,

1
Indipendentemente da ciò, quando la domanda è "come posso gestire un collega a cui manca la competenza?", Non credo che "la tua azienda stia costruendo un software sbagliato" è una risposta valida. In qualsiasi organizzazione, non importa quanto vasta e ben informata, ci saranno sempre quelli con lacune nelle loro conoscenze. Senza sapere chi sia l'organizzazione o cosa stia facendo il software, non credo che si possa giudicare in modo affidabile che la società non sa cosa stanno facendo o che il loro problema può essere risolto senza il multithreading.
anaximander,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.