Aggiunta di nuove funzionalità a una vecchia applicazione

Spediamo un numero di applicazioni Windows. Alcune parti di ciascuna applicazione utilizzano .NET2, alcune 3.5 e una applicazione è ancora VB6. Dobbiamo fare aggiornamenti annuali perché la legge fiscale cambia ogni anno (molti dei nostri utenti sono contabili e attuari). Il codice di refactoring ogni anno è una pratica standard per noi. Quando abbiamo aggiunto .NET 3.5, volevamo WCF e Linq e aggiungeremo altre cose con il passare del tempo (e abbiamo tempo per imparare cosa vogliamo aggiungere).

If I replace old classes with new ones, it risks functionality and need thorough testing again. If I don't, the project size is increasing.

Raccomando di aggiungere test delle unità alla soluzione. A molti sviluppatori non piace fare test, anche test automatizzati. Abbiamo alcuni che commentano i test che ora falliscono a causa del loro nuovo codice che rompe alcuni casi limite più antichi.

Tre buoni libri sono:
Sviluppo applicazioni brownfield in .Net e
Funzionante in modo efficace con il codice legacy
Sviluppo di software orientato agli oggetti, guidato da test

Se non ti puoi permettere le versioni di Visual Studio che includono i test delle unità, allora ti consiglio di consultare altri libri sull'utilizzo di strumenti esterni per il test:
Expert .NET Delivery che utilizza NAnt e CruiseControl.NET
Mentre questo libro è stato scritto per .NET 1.1, ha ancora alcune informazioni utili.

Una pratica che consiglio vivamente è "integrazione continua". Lo scopo di questo è per un processo che viene eseguito ogni volta che il codice viene archiviato per compilare e testare il codice. Sebbene sia laborioso e fastidioso da configurare all'inizio, rende le cose molto facili e ripetibili in seguito. Se stai mantenendo il punteggio, l'integrazione continua ti consente di rispondere "sì" alle domande 2 & 3 sul Test di Joel .

Se sei preoccupato per test approfonditi, probabilmente significa che il tuo test non è automatizzato a livello di codice. Nessun test automatizzato = molto dolore (e posso parlare per esperienza lì). Il tuo primo passo dovrebbe essere quello di mettere alcuni test di rilevamento di base intorno al codice esistente che stai pensando di modificare usando qualcosa come NUnit. Ora apporta le modifiche che desideri apportare sostituendo il vecchio codice con il nuovo codice e assicurati che tutto continui a funzionare.

Non confondere questi test di sensing con i test di unità - sono lì per verificare che il codice già in atto stia effettivamente facendo ciò che vuoi che faccia prima di iniziare e non hanno bisogno di seguire le solite regole di test . Spero che quando cambierai e aggiornassi il codice introdurrai test unitari significativi, a quel punto i test di sensing possono (e dovrebbero) essere cancellati.

Il libro Lavorare efficacemente con il codice legacy contiene molti dettagli sulle varie tecniche che puoi utilizzare in la tua situazione Potresti anche prendere in considerazione la possibilità di ottenere un sacco di copertura rapida del codice utilizzando uno dei framework di test di accettazione come Cetriolo o Robot Framework - o anche (se si tratta di un'app Web) qualche riproduzione di registrazione rapida e sporca selenium test (di nuovo, preparati a cancellare questi test iniziali una volta che hai una copertura di test significativa con test di accettazione più gestibili).

Infine non crucificare te stesso per ridurre le dimensioni del codice: concentrati sulla risoluzione dei problemi uno alla volta e rifatta le cose brutte via quando necessario.