Avendo visto negli ultimi anni un bel pò di applicazioni .Net di ogni tipo, avendo partecipato ad un bel pò di progetti e conseguentemente visto una quantità considerevole di righe di codice, di seguito elenco (in ordine sparso) le mie considerazioni sulla qualità media del codice sorgente da me visionato e su cui spesso e volentieri sono intervenuto in prima persona per correzioni e/o nuove funzionalità (leggasi elenco di brutture e/o coding horror):
– La visibilità delle classi è una questione non tenuta nella giusta considerazione. Quando si crea una classe la si marca come “public”, e tale resta per sempre, anche se la classe potrebbe essere “internal”;
– il paradigma “Object Oriented Programming” è scarsamente applicato, ed anche scarsamente conosciuto, e cosi si finisce spesso per avere, solo a titolò di esempio, codice duplicato, scarsamente coeso e altamente accoppiato;
– Boxing e unboxing: concetto non conosciuto dai più, e cosi accade che il tipo “object” è usato a sproposito, e la tipizzazione dei dati diventa una rarità;
– Concatenazioni di stringhe a go-gò, anche se è arcinoto che questa operazione non è performante a causa dell’immutabilità dell’oggetto stringa che “stressa” parecchio il garbage collector;
– Utilizzo delle eccezioni nella logica di business dell’applicazione per notificare situazioni particolari;
– Utilizzo indiscriminato di Dataset/Datatable in ogni layer applicativo (front-end compreso), al posto di oggetti di dominio non anemici, cioè dotati di attributi e di comportamento (sì lo so, chiedo forse troppo, questo è Domain Driven Design…), con conseguente profilerazione di classi per la gestione delle entità trattate dalla applicazione, es. CustomerManager, OrderManager, ecc.
Su questo argomento potrei aprire una lunga discussione, circa colui che io definisco “il programmatore del dataset”;
– La modularità di una applicazione e il concetto di “Separation of Concern” (Soc) non attira l’interesse della maggior parte degli addetti ai lavori. Come già discusso qui, è più importante rispettare i termini di consegna puttosto che creare software di qualità, ed ecco che si finiisce per scrivere software quasi monolitici, dove le responsabilità si “accavallano” in modo netto ed evidente tra i vari moduli. In applicazioni ASP .Net il code-behind si è spesso rivelato una trappola, nel senso che la classe “pagina” contiene una quantità spropositata di codice, ad esempio negli event handlers, alla faccia del concetto di basso accoppiamento;
– Assenza di Unit Test, non nel senso che nessuno li scrive ma nel senso che il Test Driven Development per molti è una sigla non pienamente compresa; in quei pochi scenari in cui ho visto scrivere Unit Tests questi non erano mai strutturati nel modo corretto secondo lo schema arrange-act-assert ma erano per lo più invocazioni di metodi a scopo di debugging. In pratica, più che “Sviluppo guidato dal test” ho visto l’esatto opposto.
Fortunatamente ho anche visto codice scritto benissimo, bene, o almeno in modo decente