Il modo migliore per evitare di dover rivisitare un cambiamento dopo il check-in

È impossibile quantificare. Ciò che è importante è l'impatto totale di questi bug, non il numero totale di bug.

Ti consiglierei di esaminare lo sviluppo Test Driven / Unit Testing se vuoi ridurre il numero di bug nel tuo codice.

Per quanto riguarda la tua domanda iniziale, ciò che è "accettabile" è impossibile per noi rispondere. Tu stesso devi decidere quanta rielaborazione puoi fare mentre procedi ancora al ritmo richiesto del nuovo sviluppo. Tale è stato l'obiettivo dei project manager per decenni.

Indipendentemente dal sistema di sviluppo che stai utilizzando (cascata, UML, Rational Rose, Agile), sono assolutamente necessarie due cose:

• Il client deve aver comunicato a te esattamente ciò che il codice dovrebbe fare nel caso generale durante l'esecuzione di alcune attività. Questo non è impossibile come sembra; di solito il "caso generale" si divide in un "caso nominale", in un "caso eccezionale" e in un "caso di errore". Le situazioni per queste devono essere descritte e il comportamento previsto del sistema in queste situazioni definito.
• Dati i requisiti a un livello di specificità che copre tutti gli scenari previsti, il codice deve rispettare i requisiti. Per i casi nominali, eccezionali e di errore, il sistema dovrebbe funzionare come definito prima di essere rilasciato al cliente.

Considerate queste due cose accadute per ogni compito che il sistema è in grado di eseguire in tutte le situazioni note, avete fatto tutto ciò che è umanamente possibile per garantire un prodotto di qualità. Tuttavia, ci saranno ancora "difetti"; non è possibile garantire che il codice esegua come previsto al di fuori degli scenari noti, il che potrebbe aver inavvertitamente escluso alcuni possibili scenari. Non è colpa tua come sviluppatore; o tu come analista non hai pensato di chiedere cosa dovesse accadere in qualche caso particolare (probabilmente perché sembrava rientrare in una situazione definita), o il cliente non ha definito correttamente i requisiti in modo tale che tutto il possibile casi sono stati coperti. Succede tutte le volte. Ciò che accade come risultato di una prospettiva di business dipende dalla metodologia di progettazione e dal modello di business, ma voi come sviluppatori probabilmente estenderete il codice per coprire le situazioni mancate, e quindi verificherete che il sistema funzioni ancora in tutte le altre situazioni.

Questo è dove TDD brilla davvero; se accetti che la regressione delle funzionalità dovuta all'introduzione di difetti nel lavoro futuro sia possibile, allora naturalmente segue che avere un test sempre disponibile per dimostrare che il codice soddisferà i requisiti (e quindi che hai scritto ciò che pensavi di aver ha scritto) è un mezzo inestimabile per evitare la regressione.

L'obiettivo è quello di arrivare a un sistema stabile, utilizzabile (o spedibile) il più rapidamente possibile.
Quindi non vedo alcun vero problema nel dover rivisitare un cambiamento, a condizione che ogni cambiamento sia spostare il sistema nella direzione corretta ed è non rendere più difficile per chiunque altro fare il proprio lavoro .

Il peccato peggiore è quello di rompere qualcosa che i clienti stanno già utilizzando, quindi la necessità di test di regressione automatizzati, i clienti sono molto più clementi se i nuovi bit non sono al 100% la prima volta che li vedono.

Verifica il tuo codice. Assicurati di avere almeno alcuni test unitari attorno al tuo codice per controllare i bit più difficili e, preferibilmente, coprire completamente tutti i componenti che i tuoi cambiamenti toccano. Esegui le storie degli utenti che hai implementato per assicurarti che funzionino come previsto. Scopri quali test eseguirà il team di controllo qualità per testare la modifica, quindi puoi provare questi test da solo.

Dipende davvero dalle tue pratiche di sviluppo e da dove stai effettuando il check-in. Quando si è impegnati in un ramo sviluppo / sperimentale, non è affatto importante. Ottieni il codice. Non importa se è complicato lavorare su di esso, così come non importa se un meccanico si sporca quando si lavora su un motore o si cambiano le ruote.

Dove è importante quando stai andando su una linea principale o su un ramo di supporto. Dovresti fare molta attenzione per assicurarti che prima di commettere il codice entrambi:

• Build e
• Passa alla sua suite di test.

Idealmente questo sarà un controllo in un solo passaggio guidato dal tuo sistema di build (se non lo è, sono troppi passaggi!)

Una volta passati questi controlli, che dovrebbero includere test sufficienti per mostrare che hai risolto il problema senza introdurre nuovi errori, allora esegui il commit. (Un buon metodo è quello di ottenere il codice in buono stato su un ramo di lavoro prima di unirli alla linea principale, un DVCS come Git lo rende molto più semplice.) Quindi avere un sistema di integrazione continua rieseguire la build e testare da un check-out pulito in modo che tu possa sapere di non aver perso nulla di stupido (i test di integrazione potrebbero essere eseguiti meno spesso, in quanto sono più costosi ma sono anche importanti); se questo mostra problemi, risolvili immediatamente e non essere imbarazzato per qualsiasi perdita di faccia. L'obiettivo dovrebbe essere quello di avere la linea principale (o le filiali supportate, in base al progetto / regole del sito) costruibili e pulite in ogni momento.

Quello che faccio è creare diagrammi di pacchetti e classi che rappresentano la struttura statica della mia applicazione. Non troppo solo la struttura e ho ottenuto il codice in sincronizzazione con il diagramma. I miei diagrammi non sono solo visioni del mondo reale ma sono il mondo reale !!

Una volta che ho terminato questa prima fase di modellazione della bozza, eseguo il codice, testare e distribuire. Nel progetto reale ho sempre bisogno di tornare al mio codice. Posso quindi cambiare a livello di codice o a livello grafico usando diagrammi di classe UML. La vista grafica è molto più veloce ed è fatta semplicemente disegnando o refactoring i miei diagrammi attuali. Ho quindi di nuovo codice, testare e distribuire. E ancora e ancora. Questo approccio di iterazione è molto veloce e molto efficiente perché non solo la struttura si sta creando a livello di oggetti usando il diagramma delle classi, ma anche il database che utilizza gli stereotipi di database e quindi iberna.

Funziona molto bene perché non utilizzo Model Driven Development con un generatore di codice ma solo mappatura diretta e sincronizzazione tra modello UML, codice e database. Non c'è anche alcun mix tra il mio codice e il mio modello come con EMF. Codice e modello sono sincronizzati su richiesta e conservati separatamente. Mi piacciono i diagrammi di classe UML, le iterazioni multiple e l'odio generatore di codice Model Driven Development perché se il codice viene generato, non è possibile cambiarlo manualmente a livello di test e di implementazione !!

Esiste una serie di pratiche che aiutano ad aumentare la qualità del codice:

1. Test delle unità è obbligatorio.
2. L'integrazione continua aiuterà a eseguire automaticamente i test unitari e fornirà rapporti utili.
3. Analisi statiche (ispezioni) aiuta a rilevare vulnerabilità del codice sorgente e frequenti errori di codifica che non possono essere rilevati in fase di compilazione.
4. Analisi dinamica - autotest, analizzatori di prestazioni, memoria e amp; analisi delle perdite, ecc.

Personalmente ho diversi tipi di rami (nel sistema di controllo delle versioni) con diverse politiche di commit e di qualità del codice.

• rami sperimentali non hanno alcun controllo sul codice. Un'eccezione è che il codice dovrebbe essere compilato prima del commit.
• trunk & rami di manutenzione hanno anche unit-test e integrazione continua abilitati.
• rami di rilascio hanno tutti i suddetti attivati: unit-test , integrazione continua , analisi statica , analisi dinamica e persino rilevatori copia-incolla .

Quindi, la raccomandazione è molto semplice: usa diverse politiche e strumenti per diversi tipi di rami del repository del codice sorgente.