Diversi stili nello scrivere e testare il codice
Negli ultimi 3 giorni ho incontrato 3 approcci diversi su come scrivere il codice C# e su come testarlo mentre l’applicazione è sotto sviluppo. Io sono uno di quelli che scrivono buona parte del codice a design-time, mentre non è in esecuzione e quando credono di aver implementato una certa feature mettono un breakpoint su una riga, eseguono l’applicazione e seguono il flusso del codice per vedere come va. Questo ovviamente quando mi ritrovo a scrivere codice che so essere insidioso, o del quale magari non sono del tutto sicuro. La cosa davvero comoda è che gli strumenti di programmazione di oggi, gli IDE insomma, ci danno enormi possibilità: quando siamo fermi ad un breakpoint, possiamo ritornare indietro a step precedenti, possiamo ispezionare variabili ed oggetti di ogni tipo, possiamo modificarne il valore e via dicendo. Credo di passare molto del tempo (sparo: 20-25% del tempo) a scrivere codice mentre il codice stesso è in esecuzione: mi capitava più spesso anni fa, quando lavoravo con Visual Basic 6.0, ma anche oggi bene o male faccio così. La possibilità di lavorare con il codice in esecuzione dipende dagli strumenti che si utilizzano: con il .NET Framework e Visual Studio è uno scherzo, come credo in altri ambienti, ma da quando lavoro con il .NET Compact Framework ho notato una limitazione. Se l’esecuzione del codice di ferma ad un breakpoint e poi mi metto a modificare il sorgente – magari per correggere o sistemare qualcosa – il CLR dice chiaramente che le modifiche saranno rese attive solo aver riavviato l’esecuzione del progetto stesso. Nei primi giorni di lavoro perdevo un sacco di tempo, ma già da un po’ ho imparato a giocherellare con watches per evitare tutto questo.
Una cosa che davvero non sopporto è invece fare scrivere codice, rileggerlo per vedere se è stata scritta qualche cavolata e poi lanciare l’esecuzione senza alcun breakpoint. Se il risultato è quello atteso, allora ok, altrimenti si passa a controllare il codice con breakpoint e compagnia bella. Questo imho è un gravissimo errore, perchè anche se il nostro programma ci restituisce 5 se gli diamo come input 2+3, non è detto che il flusso del codice fa davvero quello che si aspetta. Mi è capitata una volta una situazione: avere un array con n-mila elementi e doverne cercare uno in particolare. Banalmente, avevo fatto un ciclo for…next per esaminare uno ad uno tutti gli elementi e quando trovavo quello che volevo settavo una variabile di ritorno. Il problema è che non avevo messo un break nel caso di ricerca conclusa con successo: il programma ricercava correttamente l’elemento, ma perdeva un sacco di tempo a scansionare l’array anche quando ormai non serviva più. Se avessi controllato almeno una volta l’esecuzione step-by-step, probabilmente me ne sarei accorto.
Technorati Tags: programming
Send to Kindle