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

Un programmatore ha dedicato del lavoro al repository SVN, quindi è tornato a casa. Dopo che se ne andò, la compilazione automatica di Hudson fallì. Un altro programmatore lo ha visto 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 build successiva è stata completata correttamente.

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

Dipende in una certa misura da come la tua squadra di solito lavora, ma direi che andava bene. Mantenere la build funzionante consente di risparmiare tempo a tutti gli altri.

È educato che il secondo programmatore lasci cadere la prima e-mail per spiegare cosa ha fatto, nel caso in cui sia necessaria una versione specifica della libreria o ci siano altre complicazioni. È anche un modo leggermente più sottile per sottolineare che avevano rotto la build.

Dipende.

• Il bug è così ovvio che l'aggiunta di una libreria è il modo di risolverlo? A volte la soluzione sta 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? In tal caso, hai presentato un biglietto? Quel biglietto ti è stato assegnato?

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

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

La tua reputazione è al 100% sotto il tuo controllo. Roba del genere offusca la tua reputazione e cercare di lucidare una reputazione offuscata è molto difficile.

Comunicare

Non ci sono regole rigide (oltre alle regole della tua squadra) per quello scenario.

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 colpa, va sicuramente bene. Sebbene una compilazione non riuscita a causa della modifica della libreria sia piuttosto scadente e devi rimproverare lo sviluppatore per non averlo testato.

Si verificano errori di costruzione. Se è importante che avvenga una build giornaliera, lo riparerei e quindi richiederei allo sviluppatore che ha verificato il codice non funzionante di rivedere la correzione il giorno successivo e assicurarsi che il codice sia ora come dovrebbe essere.

Come è stato detto, il ragazzo che l'ha riparato dovrebbe probabilmente inviare un'e-mail al ragazzo che l'ha rotto e dettagliare quale fosse la correzione.

Il mio motto è di non impegnarmi in SVN dopo le 15:00 in questo modo puoi sempre correggere i tuoi errori di compilazione.

Se non risolvi l'errore di compilazione, anche la compilazione di tutti gli altri fallirà. Vorrei risolvere il problema per risparmiare tempo nel lungo periodo, ma assicurarsi che siano consapevoli che è necessario risolverlo.

Avere una sorta di script "punta il dito sulla colpa" è un buon modo per farlo, o per fare in modo che la persona che rompe la build comprino ciambelle !!

Qualcuno deve ripararlo e il primo programmatore non avrebbe dovuto tornare a casa senza prima essersi accertato di non aver rotto la build. Tuttavia, per un problema così facilmente risolvibile, richiamarlo per risolverlo da solo sarebbe estremo.

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

Sì sì sì! Promuove la proprietà del codice collettivo e imposta una sorta di sana pressione tra pari nel team per mantenere uno standard elevato e non lasciare che si sviluppi uno scenario di finestra rotta. Un po 'di comunicazione per far sapere all'altro sviluppatore è una buona idea.

Penso che sia corretto sistemare cose ovvie, ad esempio, se sei sicuro al 100% che il ragazzo il cui codice stai riparando farebbe lo stesso - o sostanzialmente lo stesso - aggiustasse. Se la correzione è più complessa, di solito è educato parlare con la persona di cui stai riparando il codice - potrebbe essere che hai frainteso l'intento o il motivo della rottura non è quello che pensavi, o forse intendeva un'altra correzione ma per qualche motivo non sono ancora riusciti a commetterlo (la vita succede, sai :).

In generale, la regola di solito è: rompi la build - correggi la build, ma ci sono eccezioni, specialmente se la correzione è ovvia e / o la persona responsabile non è raggiungibile.

Naturalmente, se si ha il caso dell'interrutore di build seriale, in particolare con il modello "check-in, andato a casa, build rotto per giorni" - la persona responsabile deve parlare del perché esistono sistemi e test CI e come si dovrebbe controlla prima di fare il check-in :)

Le cose accadono. L'incapacità di aggiungere un nuovo file di codice (sorgente o compilato) a Subversion è probabilmente la causa più comune di build rotte, supponendo che abbia funzionato sul computer dello sviluppatore. Nel mio ultimo lavoro con un ambiente CI, anche i ragazzi più anziani a volte hanno dimenticato.

Penso che se un'altra persona è stata in grado di correggere la build e quindi mantenere il team ronzio, va bene. Penso che il programmatore che è tornato a casa abbia bisogno almeno di un'e-mail amichevole che indichi cosa è successo e di ricordargli di assicurarsi che il nuovo codice venga aggiunto prima degli commit. Se succede spesso, forse rendi quell'offesa minore punibile con la "danza della vergogna", per aiutare a ridurre gli eventi (e alleggerire l'umore).

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

Va bene risolvere a meno che non si tratti di un evento regolare, nel qual caso vorrei che il capo lo chiamasse e lo facesse tornare e aggiustarlo 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 è risolverlo, o se non è ovvio, basta ripristinare le modifiche e far sapere al primo programmatore in modo che possa ripararlo in seguito.

Comunque, 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 scortese o atteso per pessime ragioni.

Dipende in gran parte dalla criticità di una build non funzionante rispetto alla criticità di una build corretta verificata. E in una certa misura, dipende da quanto era ovvio che la correzione era la correzione giusta e l'unica necessaria.

Innanzitutto, "tornare a casa" è un anacronismo. I programmatori non tornano più a casa - sono solo online o offline. Potresti fare un ping e aspettare.

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?