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

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.

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.

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.

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.

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.

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.

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 !!

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.

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.

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

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

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.

È 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.

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 ^ _ ^

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.

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?