Correzione di un bug mentre si lavora su una parte diversa della base di codice

Questo è successo almeno una volta a me. Sto lavorando su una parte della base di codice e trovo un piccolo bug in una parte diversa, e il bug mi impedisce di completare ciò che sto attualmente cercando di fare. Correggere il bug potrebbe essere semplice come cambiare una singola istruzione.

Cosa fai in quella situazione?

1. Correggi il bug e commettilo insieme al tuo lavoro attuale
2. Salvare il lavoro corrente altrove, correggere l'errore in un commit separato, quindi continuare il lavoro [1]
3. Continua quello che dovresti fare, impegna il codice (anche se lo è rompe la build fallisce alcuni test), quindi correggi il bug (e la build fare passare i test) in un commit separato

[1] In pratica, ciò significherebbe: clonare il repository originale altrove, correggere il bug, eseguire il commit / push delle modifiche, eseguire il commit nel repository su cui si sta lavorando, unire le modifiche e continuare il lavoro.

Modifica: ho cambiato il numero tre per riflettere ciò che intendevo davvero.

Ho fatto 1 e 2 e alla fine, penso di preferire il n. 2. Consente una maggiore visibilità per la correzione dei bug, che può essere importante per QA / note sulla versione / altri sviluppatori.

Mi sono anche imbattuto in una situazione in cui quello che pensavo fosse un bug non lo era (non dire che qui è il caso), e "risolverlo" in un commit separato ha permesso a un altro sviluppatore di contattarmi e spiegare cosa fosse invece della "correzione" mi sto solo perdendo nel mio normale check-in.

In genere vado per # 2. Rende il repository più pulito e rende i log più comprensibili. Lo odio quando altri sviluppatori con cui lavoro eseguono il commit di 15 diverse correzioni di bug, funzionalità e refactoring nello stesso commit.

Inoltre, a seconda di come il tuo team effettua il rilevamento dei difetti, potrebbe essere necessario cercare il repository dei difetti per assicurarsi che se il difetto che stai correggendo sia presente, contrassegni l'articolo come completo. In alternativa, potrebbe essere necessario creare un nuovo elemento e contrassegnarlo come completo in modo che il sistema difettoso e il repository di codice coincidano.

Faccio # 2. L'uso di strumenti come git rende banale dividerlo in più commit. Se non riesci a convincere il tuo team a passare a strumenti più moderni, git-svn ti darà una buona parte di ciò che useresti per risolvere questo problema. Questo post sul blog offre una buona panoramica del flusso di lavoro che stai cercando di risolvere: The Thing About Git

Scelgo l'opzione non scritta (4): Dividi il tuo progetto in assiemi / librerie altamente specializzati, in modo che i bug non correlati siano sempre in una posizione diversa nella struttura di controllo della versione.

Mi scuso se quanto sopra sembra snarky, ma lo dico sinceramente. Mi arrabbio ogni volta che vedo un progetto monolitico con un centinaio di forme e spazi dei nomi che non hanno nulla a che fare l'uno con l'altro. Ero solito affrontare questo stesso dilemma spesso, chiedendomi se e come avrei dovuto sciogliere gli impegni che avevano a che fare con diverse aree funzionali; non molto tempo dopo mi sono reso conto che avere tutte queste diverse aree funzionali in un unico progetto commitabile era, di per sé, un grave difetto di progettazione.

Spesso trovo ancora bug totalmente non correlati mentre sto lavorando su una funzione specifica. Potrei lavorare sull'interfaccia utente e trovare un bug in alcune logiche aziendali e dovrei risolverlo prima di poter andare avanti. La differenza è che la logica di business si trova sempre in un assembly / progetto diverso dall'interfaccia utente, quindi tutto ciò che devo fare è apportare una modifica molto piccola al BL e procedere con un commit molto minore, quindi continuare a lavorare.

Avere una buona organizzazione del progetto rende non solo possibile, ma abbastanza facile gestire questi problemi senza seppellire un cambiamento, interrompere la costruzione o essere impantanato in un ramo / unione irritante (anche se stai usando un DVCS non è del tutto indolore ).

Se manchi di questa opzione, ovvero sei uno sviluppatore junior che non ha voce in capitolo nell'organizzazione del progetto, allora andrei semplicemente con il n. 1 e prenderei le note appropriate nel registro in modo che altre persone sappiano perché hai fatto quello che hai fatto. Se hai apportato una modifica importante, invia anche una segnalazione di bug nel tuo sistema di tracciamento dei problemi per dare visibilità a ciò che hai risolto e al perché.

Provo a fare il n. 2. Se si tratta davvero di un problema separato, è probabile che si trovi in ​​un file diverso da quello su cui stai lavorando. Dovresti essere in grado di controllare il file come commit separato, anche se è fatto nello stesso repository su cui stai lavorando. Per tutti i motivi già indicati, ha senso avere impegni il più indipendenti possibile, per il monitoraggio e per ripristinare la modifica se è errata.

Di solito correggo solo il bug e poi continuo su quello su cui stavo lavorando. Quando è il momento di eseguire il commit, supponendo che la correzione di bug sia in un file separato, eseguo due commit simultanei: il primo è un commit parziale contenente solo la correzione di bug, e il secondo è tutto il resto.

Risposta breve: # 2. Volete davvero quel bugfix (con la sua nota nel tracker!) Taggato nella cronologia delle versioni come entità separata.

Risposta più lunga:

• Inciampare nel bug
• Scrivi un test o più dimostrando il bug
• Fai passare il test
• Commit solo che il cambiamento e le sue prove ( git add --interactiveo darcs record -io comunque il tuo VCS lo fa) (*)
• Torna a quello che stavo facendo.

(*) In CVS (no, davvero) a volte ho un albero pulito estratto e una copia su cui lavoro. Quindi uso un'unione - winmerge, nel mio caso - per inserire solo il bugfix nell'albero pulito in modo da poterlo commettere separatamente. (L'altra opzione è quella di rinominare i file modificati cvs updatee unirli. Dopo aver eseguito il commit della modifica, rimuovere il file e rinominare i file spostati con i nomi originali.)

Qualcosa da notare è che di solito trovo solo bug che sono correlati a ciò su cui sto lavorando o che sono in stretta prossimità lessicale. Sarei sorpreso se fosse normale per le persone trovare bug in parti non correlate della base di codice - perché leggi il codice non correlato quando correggi il bug? (Sì, questo è esattamente l'opposto di quello che dice Aaronnaught!)

Risolvo il bug e eseguivo commit separati , uno per ogni correzione / funzionalità.

La maggior parte delle volte, le modifiche non sono nello stesso file, quindi è facile separare le commit. Se le modifiche si trovano nello stesso file, utilizzo TortoiseHg (un front-end della GUI meccanico) per selezionare con precisione le differenze che voglio commettere (penso che sia possibile farlo sulla riga di comando con l' estensione Record , ma è meno conveniente ).

Alcune persone usano le Mercurial Queues per isolare le correzioni minori mentre lavorano su una funzione. Le correzioni minori vengono raggruppate in MQ e, quando la funzione è terminata e impegnata, viene anche eseguito il commit del contenuto della coda (un gruppo di modifiche per ogni voce nella coda).

Di solito faccio il n. 2. Salvare il mio lavoro attuale altrove: di solito funziona bene creando una patch. Inoltre alcuni IDE (IntelliJ) consentono di archiviare i cambiamenti, che è esattamente questo: salvare il lavoro corrente altrove.

Quello che faccio dipende dal fatto che il bug sia veramente in una parte diversa. In tal caso, il check-in è indipendente dalle modifiche apportate a metà. Apporto il cambiamento, costruisco quella parte diversa per essere sicuro di non aver commesso un errore banale, lo collaudo (forse facendo qualunque cosa mi impedisca di fare) e lo controllo spiegando cosa stava succedendo. Spesso realizzerò un oggetto di lavoro per esso, e dopo il checkin / risoluzione, assegnerò il WI a un tester. Poi torno a quello che stavo facendo.

Se è tutto sommato con i file che ho modificato per metà, non posso costruire e testare quella parte in modo indipendente. In tal caso, creo un altro WI per esso e quando accedo alle mie modifiche risolvo entrambi i WI con lo stesso check-in, che di solito è contrario ai miei principi, ma si applica bene in questo caso.

In entrambe le circostanze il bugfix finisce per essere testato da me, verificato con una sorta di traccia, così la gente capisce perché quel giorno ho cambiato a caso quel codice e un WI è assegnato a qualcun altro per confermare che ora è corretto.

Facciamo # 1. Il n. 2 suona bene, ma non posso dire che abbiamo avuto problemi con il n. 1 che il n. 2 avrebbe risolto.

Un altro fattore nella mia azienda è che costruiamo app Web e i nostri test avvengono quasi interamente attraverso l'interfaccia Web, più o meno quello che la gente chiama test funzionale piuttosto che unit test. Prima del check-in abbiamo superato tutti i test. Dividere i commit in bit più piccoli significherebbe eseguire i test una volta per ogni bit, e ciò richiederebbe più tempo. Mi piacerebbe avere una suite di test molto più veloce, che ci permetterebbe di fare piccoli commit, ma non ce l'abbiamo.