Un programmatore dovrebbe riparare la build fallita di qualcun altro? [chiuso]

45

Un programmatore ha dedicato del lavoro al repository SVN, quindi è tornato a casa. Dopo che se ne fu andato, la build automatica di Hudson fallì. Un altro programmatore ha visto questo e, dopo aver esaminato le modifiche al codice, ha rilevato che il problema era l'assenza di una libreria. Ha aggiunto questa libreria a SVN e la prossima build è stata completata con successo.

Il secondo programmatore ha fatto la cosa giusta o avrebbe dovuto semplicemente aspettare che il primo programmatore risolvesse il problema?

    
posta nahab 09.11.2011 - 11:53
fonte

16 risposte

87

Dipende in parte da come funziona la tua squadra, ma direi che andava bene. Mantenere la build funzionante fa risparmiare tempo a tutti gli altri.

È educato che il secondo programmatore scarichi la prima e-mail per spiegare cosa ha fatto, nel caso in cui sia necessaria una versione specifica della libreria o ci sia qualche altra complicazione. È anche un modo un po 'più sottile per indicare che hanno rotto la build.

    
risposta data 08.11.2011 - 10:48
fonte
12

Dipende.

  • Il bug è così ovvio che aggiungere una libreria è il modo di risolverlo? A volte la correzione consiste nel trovare una soluzione alternativa per non aver bisogno di quella libreria.

  • Il progetto è in una fase in cui tutte le modifiche devono essere collegate a un ticket esistente? Se sì, hai fatto un ticket? Ti è stato assegnato quel biglietto?

In ogni caso, concentrati sulla correzione del bug, non sulla responsabilità del responsabile.

    
risposta data 08.11.2011 - 10:52
fonte
11

Sì, va bene. Tuttavia, non è professionale che il programmatore originale torni a casa prima di testare la compilazione della compilazione.

La tua reputazione è al 100% nel tuo controllo. Cose come questa appannano la tua reputazione e cercare di lucidare una reputazione offuscata è molto difficile.

    
risposta data 08.11.2011 - 14:40
fonte
7

Comunicare

Non ci sono regole rigide (oltre alle regole del tuo team) per quegli scenari.

Dev2 dovrebbe essere in grado di dire a dev1 che può correggere il suo errore, nessuno dei due dovrebbe temere qualcosa derivante da questo scambio, fanno parte di una squadra.

    
risposta data 08.11.2011 - 14:42
fonte
5

Perché no? Se il tuo prodotto è più importante della correzione delle colpe, è certamente tutto a posto. Anche se una build fallisce a causa del cambio di libreria è piuttosto loppa e devi rimproverare lo sviluppatore per non testarlo.

    
risposta data 08.11.2011 - 11:03
fonte
3

I fallimenti di build avvengono. Se è importante che si verifichi una compilazione giornaliera, correggo il problema e richiedo allo sviluppatore che ha effettuato il check-in del codice danneggiato di rivedere la correzione il giorno successivo e assicurarsi che il codice sia ora come dovrebbe essere.

Come è stato detto, il tizio che l'ha riparato probabilmente dovrebbe mandare una e-mail al tizio che l'ha rotto e che ha specificato quale fosse la soluzione.

    
risposta data 08.11.2011 - 18:01
fonte
2

Il mio motto è non impegnarsi in SVN dopo le 15:00 in questo modo puoi sempre correggere i tuoi fallimenti di build.

Se non correggi il suo errore di build, anche la build di tutti gli altri fallirà. Lo aggiusterei per risparmiare tempo a lungo termine, ma assicurati che siano a conoscenza del fatto che dovevi risolverlo.

Avere una sorta di script 'puntare il dito sulla colpa' è un buon modo per farlo, o rendere la persona che rompe la build compra le ciambelle !!

    
risposta data 08.11.2011 - 10:45
fonte
2

Qualcuno deve sistemarlo e il primo programmatore non dovrebbe essere andato a casa senza aver prima assicurato che non avesse rotto la build. Tuttavia, per un problema così facilmente risolto, richiamarlo per ripararlo da solo sarebbe estremo.

Sono d'accordo con il suggerimento di Luke Graham di inviare una e-mail esplicativa, anche se direi che è più che educato - è una comunicazione di base.

    
risposta data 08.11.2011 - 11:41
fonte
2

Si si si! Promuove la proprietà collettiva del codice e stabilisce una sorta di sana pressione tra pari nel team per mantenere uno standard elevato e non lasciare che si sviluppi uno scenario di finestre rotte. Un po 'di comunicazione per far sapere all'altro sviluppatore è una buona idea.

    
risposta data 08.11.2011 - 21:35
fonte
2

Penso che sia corretto sistemare le cose ovvie, ad esempio, se sei sicuro al 100% che il tizio il cui codice hai fissato potrebbe fare lo stesso, o sostanzialmente lo stesso, aggiustarlo. Se la correzione è più complessa, di solito è educato parlare con la persona di cui stai fissando il codice - potrebbe essere che tu abbia frainteso l'intento o che il motivo della rottura non sia quello che pensavi che fosse, o forse intendeva un'altra correzione ma per qualche ragione non potrebbe ancora commetterlo (la vita accade, lo sai :).

In generale, la regola di solito è: si interrompe la build - si corregge la build, ma ci sono delle eccezioni, specialmente se la correzione è ovvia e / o la persona responsabile è irraggiungibile.

Naturalmente, se si ha il caso dell'interruttore di generazione seriale - in particolare con il modello "archiviato, andato a casa, build rotto per giorni" - la persona responsabile ha bisogno di parlarne sul perché i sistemi CI ei test esistono e come si dovrebbe verificare prima di effettuare il check-in:)

    
risposta data 08.11.2011 - 21:47
fonte
1

Le cose accadono. La mancata aggiunta di un nuovo file di codice (sia esso sorgente o compilato) a Subversion è probabilmente la causa più comune di build danneggiate, supponendo che funzionasse sul computer dello sviluppatore. Al mio ultimo lavoro con un ambiente CI, anche i ragazzi più anziani a volte dimenticavano.

Penso che se un'altra persona fosse in grado di sistemare la build e mantenere così la squadra a canticchiare, va bene. Penso che il programmatore che è andato a casa abbia bisogno di almeno un'e-mail amichevole che dichiari ciò che è successo, e di ricordargli di assicurarsi che il nuovo codice venga aggiunto prima dei commit. Se succede spesso, forse rendilo un reato minore punibile con la "danza della vergogna", per contribuire a ridurre gli eventi (e alleggerire l'umore).

    
risposta data 08.11.2011 - 15:16
fonte
1

Dipende dalle dinamiche del Team, ma in un mondo ideale tutti i membri del Team dovrebbero "possedere" l'intero progetto, tutto il codice e, di conseguenza, tutti gli errori insieme. Quindi, se trovi un problema lo risolvi e comunichi con il creatore del bug solo se c'è qualche valore aggiunto specifico al codice nel farlo.

    
risposta data 09.11.2011 - 03:01
fonte
0

È corretto correggere a meno che non si tratti di un caso normale, nel qual caso il capo lo chiamerebbe e lo farebbe tornare e sistemarlo da solo.

    
risposta data 08.11.2011 - 15:24
fonte
0

Dipende, dipende ...

Come programmatori, il nostro lavoro è far funzionare le cose, non giudicare le persone. Quindi direi che la cosa migliore che puoi fare è aggiustarlo, o se non è ovvio, puoi solo ripristinare le modifiche e far sapere al primo programmatore in modo che possa ripararlo in seguito.

Ad ogni modo, avere l'ultimo ragazzo che ha rotto la build per indossare un cappello strano è sufficiente per prestare più attenzione la prossima volta ^ _ ^

    
risposta data 08.11.2011 - 17:21
fonte
0

In alcuni ambienti, questo è molto scortese e per buoni motivi. In altri ambienti, è previsto e per buoni motivi.

In altri ambienti ancora, è molto maleducato o previsto per ragioni molto cattive.

Dipende in gran parte da quanto è critica una build rotta rispetto a quanto sia critica una build corretta verificata. E in una certa misura, dipende da quanto fosse ovvio che la correzione fosse la soluzione giusta e l'unica necessaria.

    
risposta data 09.11.2011 - 06:08
fonte
0

In primo luogo, 'andato a casa' è un anacronismo. I programmatori non vanno più a casa: sono solo online o offline. Potresti eseguire il ping e attendere.

Più seriamente, ci sono in realtà due parti della domanda. 'guardare attraverso le modifiche al codice' va bene; il riposo potrebbe non essere la cosa giusta da fare. E se il suo giudizio su una biblioteca mancante fosse sbagliato?

    
risposta data 09.11.2011 - 11:49
fonte

Leggi altre domande sui tag