Negli anni 2003-2004 ho lavorato in una piccola
software-house a Milano. Per "piccola" intendo 3 sviluppatori, 1 segretaria, 2
venditori, 1 capo. Uno dei posti peggiori in cui abbia mai lavorato. E' stato -
professionalmente parlando - un periodo pessimo: tariffa giornaliera molto
bassa, discussioni e litigate quotidiane, sballottato da una parte all'altra
d'Italia per fare le demo del software che sviluppavamo, preparazione di decine
di CD d'installazione senza una procedura automatica, accuse continue per aver
cancellato il file xyz dal server, aperture sistematiche di SourceSafe
per andare a chiedere a Tizio-Caio-Sempronio la motivazione di una certa
implementazione a frmValuta (si lavorava con VB6), la Posta in Arrivo
costantemente piena di e-mail della solita persona. Insomma - non sto
raccontando frottole - è stato un vero incubo, un mobbing in pieno
regola.
Io in modo particolare, ed altri miei colleghi, venivamo sistematicamente
accusati di scrivere male il codice, di non testarlo, di riempirlo di bachi,
di non provarlo e di perdere tempo. Oggi pomeriggio, mentre seguivo il suo webcast, Lorenzo ha
letto una domanda di non-so-chi-fosse.
Ha senso per una piccola società investire del tempo per scrivere
codice per fare unit-testing?
La mia risposta è assolutamente SI',
almeno per due buoni motivi:
- Si incrementa drasticamente -
è ovvio - la qualità del codice
che scrivete: questo è il fine ultimo dello unit-testing, ci mancherebbe
altro!
- Una delle conseguenze del punto (1) è che è possibile dimostrare a chi di dovere che il codice è
testato, che funziona, che è tutto ok. Che lo unit-testing che
avete scritto copre il 60% o il 90% del codice che avete scritto
Quindi, anche se non avete Team System, datevi da fare con nUnit!!! E' un consiglio!
powered by IMHO 1.2