Sono uno sviluppatore web e software coinvolto nella creazione di app mobili. Attualmente sto lavorando a un progetto con una scadenza incombente. Mi chiedo se dovrei commettere il codice rapidamente e in grande e testare più tardi, o eseguire piccoli commit e testarli ciascuno.
Grazie!
"Testiamo più tardi" significa sempre "non testiamo mai", perché non c'è mai più tempo per farlo in seguito. Ogni volta che si cambia qualcosa che vale la pena provare, provalo ora.
Non introdurrai meno bug solo perché fai più commit e meno test tra i commit. Invece, si accumulerà codice fasullo su codice falso che, dopo n modifiche, non diventa n volte difficile da correggere, ma 2 ^ n volte, perché si perde il feedback su quale delle modifiche è stata la causa principale del bug.
Should I be committing code quickly and testing later?
Una volta che un pezzo funzionale di codice è stato impegnato, è un buon momento da testare. In altre parole, se il codice di commit è verificabile, esegui il test e non rimandare .
Il posticipo del test (test dell'unità o manuale) su un codice impegnato è un po ' cattivo . Questo ti consentirà di raggiungerti in seguito. Accumulare i commit senza test non aiuterebbe a portare avanti il progetto.
Come accennato, tagliare gli angoli non finisce mai per essere produttivi. Cerca di non saltare i passaggi e fai il test dell'unità, prima di assumere che l'attività sia stata eseguita.
Domande relative allo scambio di stack correlate e post sul blog:
Come altri hanno già menzionato, il ritardo nel test spesso significa che il test viene interrotto, anche nel migliore dei casi, il test molto più tardi dall'implementazione porta a test meno efficienti.
Detto questo, ci sono dei vantaggi nel fare il check-in immediatamente. I check-in rapidi riducono il rischio e la dimensione dei conflitti di fusione, sia per te che per i tuoi colleghi. Se hai un processo di compilazione che ti impedisce di romperlo (rifiuta i check-in in caso di mancata compilazione o se l'errore del test dell'unità è il più comune), sentiti libero di registrarti.
Se stai percorrendo quella rotta, una volta che il codice è entrato, allora inizia i test dell'unità. Non ritardarli, non togliere altre cose ... non tagliare gli angoli.
L'ho visto in più aziende e funziona bene finché il tuo team (o il team leader) è sufficientemente disciplinato.
(nota: questo non è l'unico modo per sviluppare con successo il software.Tutte le piccole modifiche testate e verificate funzioneranno.) Test del primo sviluppo funzionerà. Ciò che funziona meglio per te varierà in modo significativo su chi sei, su cosa stai lavorando, ecc.)
Se hai un ramo di sviluppo privato assegnato solo a te, allora non è così male. Avrai bisogno di un modo diverso dal checkin stesso per indicare quali check-in funzionano correttamente e quali no, ma perderai il lavoro. Preferisco effettuare il checkin quando ottengo il successivo piccolo problema, in modo che nessun checkin rappresenti un codice rotto.
D'altra parte, se condividi un ramo con chiunque altro, allora ogni controllo parziale rischia di rompere le build di altre persone. Ciò si traduce in un sacco di altre persone che cercano di eseguire il debug perché qualcosa improvvisamente è andato storto. Questo è uno spreco di tempo importante, duplicazione dello sforzo di tutti coloro che eseguono il debug delle tue cose rotte invece di costruire o riparare le cose di cui sono responsabili.
Prova un ritmo rapido di:
In genere cerco di commettere solo codice funzionante. Per il nuovo codice posso essere abbastanza rilassato o la definizione di lavoro. Ai fini di un commit, un metodo che restituisce una costante ma ha un commento TODO (preferibilmente in un formato riconosciuto dal mio IDE) è considerato funzionante. Un nuovo metodo che genera un errore di compilazione non è sicuramente pronto per un commit.
Prova il codice che puoi completare in un'ora o giù di lì. Ripulisci il maggior numero possibile di tag TODO prima di passare al nuovo codice. I motivi legittimi per lasciare un tag TODO potrebbero includere:
Secondo la mia idea, tutto dipende. Molti altri fattori entrano in gioco:
Voglio dire, mentre esistono linee guida generali, nessuna prescrizione può essere fatta per tutti i team di tutto il mondo.
Sì, ovviamente i test e tutti i concetti correlati aumenterebbero la qualità del tuo prodotto in modo considerevole. Concetti come test di regressione, test unitari, test UI codificati, test di integrità, test di sicurezza, test delle prestazioni e tutto ciò fanno diventare il tuo software un cittadino di prim'ordine per competere sul mercato. Ma questa è solo la visione accademica.
La vista pratica è tuttavia a volte un po 'diversa. Se hai davvero bisogno di una demo, scrivi più codice e prova di meno.
Se hai un tester dedicato, affidagli la responsabilità dei test. Collabora, lavora insieme, ma passi più tempo a sviluppare e meno tempo a testare.
Prova anche a riutilizzare i test attraverso la scrittura di test automatici e il recupero dai test manuali.
Come ultimo suggerimento, ti consiglio di ridurre le funzionalità, perché come regola generale:
Leggi altre domande sui tag version-control programming-practices