Lavorando come consulente mi sono trovato spesso di fronte a problematiche (a volte banali), ma che erano la causa di gravi problemi di performance dell'appliccazione realizzata, oppure più banali, ma che rendevano il codice meno manutenibile e gestibile, specialmente lavorando in team. Vedere che nel tempo, persone/realtà diverse, commettono gli stessi errori mi ha fatto pensare a questa sessione...dove intendo elencare i problemi più comuni, che per causa di tempo o scarsa conoscenza, vengono commessi, e proporre delle soluzioni semplici da poter applicare fin da subito. (ASP.NET, ma non solo)

1. Andrea Dottor – Microsoft MVP ASP.NET/IIS
IL BUON PROGRAMMATORE
consigli pratici per una vita felice

2.  Esperienze personali
 Da anni lavoro come libero professionista, e durante
le consulenze/sviluppo/formazione sono incappato
spesso in "errori" comuni
www.dottor.net
 Altre fonti:
 Damian Edwards: Don’t do that, do this!
Recommendations from the ASP.NET team
 http://vimeo.com/68390507
 What not to do in ASP.NET, and what to do instead
 http://www.asp.net/aspnet/overview/aspnet-45/what-not-to-
do-in-aspnet,-and-what-to-do-instead
Perché questa sessione?

3.  Inesperienza
 Si crede di conoscere completamente una
tecnologia
 Non si conosce l'esistenza di particolari
funzioni/metodi
 Fretta
 Un progetto "prototipo" sviluppato in fretta,
diventa la base per un "prodotto"
 Il budget/tempistiche non sono realistiche
 Pigrizia
 Si sceglie la strada più breve, perché fare le
cose nel modo migliore richiederebbe qualche
riga di codice in più
Da dove vengono gli errori?

4.  Riuso e manutenzione del codice
 Configurazione
 Prestazioni
 Produttività
Cosa vedremo in questa sessione?

5. Riuso del
codice e
manutenzione

6.  Framework Design Guidelines
 http://msdn.microsoft.com/en-us/library/ms229042.aspx
 General Naming Conventions
 http://msdn.microsoft.com/en-us/library/vstudio/ms229045(v=vs.110).aspx
 Namespace Naming Guidelines
 http://msdn.microsoft.com/en-us/library/893ke618(v=vs.71).aspx
 C# Reference
 http://msdn.microsoft.com/en-us/library/vstudio/618ayhy6(v=vs.110).aspx
 Non esistono line guida solo su come
scrivere il codice
 Es: Visual Studio Team Foundation Server Branching and
Merging Guide
 http://vsarbranchingguide.codeplex.com/
 E' importante che a livello aziendale venga
deciso quali standard e naming-convention si
debba adottare
Naming convention e linee guida

7.  Separare in progetti/assembly separati la
logica che può essere riutilizzata
 Helpers
 Accesso ai dati
 DTO
 Scrivere tutto in un unico progetto
significa dover riscrivere parte del codice
nel caso di nuova applicazione (simile)
 Dare nomi sensati agli assembly
 <Company>.<Component>.dll
 Le Portable Class Library permettono di
condividere codice tra progetti di tipo
diverso
Come strutturare i progetti di
un'applicazione

8.  I namespace permettono di
organizzare il codice all'interno di un
assembly
 Permettono di tenere separate classi
che hanno compiti/scopi differenti
 All'interno dello stesso namespace non possono
esistere più classi con lo stesso nome
CompanyName.TechnologyName[.Feature][.Design]
 Gli assembly separano il codice a
livello fisico, i namespace invece a
Cosa sono i namespace? A che
servono?

9. demo

10.  Il riutilizzo del codice vale anche per
gli stili, e per il codice JavaScript!!
 Non settare gli stili nei controlli, ma
bensì impostiamo delle classi css e
usiamo i fogli di stile
 Riutilizzo degli stili
 I file css vengono messi in cache dal browser
 Le pagine pesano meno
 Facilità nel seguire i repentini cambi idea del
cliente, senza doversi ripassare tutte le pagine
 In WebForm "avevamo" i temi, non
dimentichiamoci le buone abitudini
Centralizziamo gli stili

11.  Fanno risparmiare un sacco di tempo
 Introduzione di funzionalità avanzate in tempi
ridotti
 Il costo dei controlli è sicuramente inferiore al
costo di uno sviluppatore (che implementi lo
stesso controllo)
 Ma non è tutto oro quello che luccica:
 se hanno un bug?
 se modificano il loro rendering?
 quanto JavaScript iniettano?
 Utilizziamoli solo quando è realmente
necessario
Controlli di terze parte

12.  Una classe per file
 Se una classe ha molte righe di
codice, è preferibile utilizzare le partial
class (e dividerla in più file) invece di
nascondere il codice con le region
 Cercate di essere il più "aderenti"
possibile a quello che è lo standard
della tecnologia che utilizzate
 Gli accrocchi, barbatrucchi, workaround non
sono sempre una soluzione ideale
Buone abitudini

13. demo

14. Configurazione

15.  Permette di applicare
modifiche/trasformazioni ai file di
configurazione in fase di compilazione
 Centralizzazione dei settings nel progetto
 Si può creare una "traformazione" per ogni
ambiente di pubblicazione
 Evitano allo sviluppatore il
copia&incolla o la modifica della
configurazione ad ogni pubblicazione
 Spesso capita che nuovi settings non vengono
riportati in produzione
Web.config transormation

16.  Offrono la possibibilità di specificare dei
parametri (key-value) che permettono di
parametrizzare l'applicazione senza
dover ricompilare
 Vengono letti come String
 Non sono validati
 Nessuno ci avvisa della mancanza di un AppSettings
 Attenzione a modificare/disabilitare
parametri di sicurezza (in produzione)
 http://msdn.microsoft.com/en-us/library/hh975440
 ES:
<add key="aspnet:MaxHttpCollectionKeys" value="1000" />
<add key="aspnet:MaxJsonDeserializerMembers" value="1000" />
Uso corretto degli AppSettings

17.  Il framework permette di avere
all'interno dei file di configurazione
delle proprie sezioni di configurazione
custom.
 A differenza degli AppSettings, queste
possono essere tipizzate, e validate
 Valori obbligatori
 Valori di default
 Limiti, min max
Sezioni di configurazione custom

18.  Se i file di configurazione hanno
grosse dimensioni, è possibile
suddividerli in più file
 E' utile quando si lavora in team
 Ad esempio, le ConnectionString possono
essere diverse per ogni dev
Suddivisione della configurazione in più
file
<appSettings configSource="AppSettings.config" />

19. demo

20. prestazioni

21.  Il Viewstate non è il male
 E' utile, ma va utilizzato con cognizione di causa
 L'abuso del Viewstate causa un degrado
delle performance della pagine
 Tempo di serializzazione/deserializzazione
 Dimensione della pagina
 Tempo di trasmissione della pagina
 Invece di utilizzare
EnableViewState="false", preferire
ViewStateMode="Disabled" nella
direttiva di pagina, e settare
ViewStateMode="Enabled" solo nei
controlli che lo richiedono
 EnableViewState=false disabilita la ViewState anche
per i controlli figlio
Viewstate

22.  Da ASP.NET 4.0 è presente la
funzionalità di bundle & minification
 Permette di ottimizzare i file
JavaScript e CSS presenti
nell'applicazione
 Crea un file unico, che raggruppa più file js
 Lo riduce di dimensione, minimizzandolo
 Viene applicato quando si esegue
l'applicazione in Release
 Non deve essere presente Debug=true nel
web.config
ASP.NET bundle & minification

23. demo

24.  Ricordarsi sempre di pubblicare in
produzione compilando in modalità
Release
 Rimuovere dal Web.config l'attributo
debug="true" (presente nell'elemento
compilation) , oppure impostarlo a "false"
 In Debug gli assembly vengono arricchiti di codice
necessario al debug, che però causano rallentamenti
nell'esecuzione
 Il codice ritornato dagli handler axd non viene messo in
cache dal browser
Compilare in release & debug=false

25.  Il Trace raccoglie informazioni su ogni
richiesta fatta all'applicazione
 Oltre al normale tempo di esecuzione della
richiesta, viene aggiunto il tempo necessario al
Trace per loggare
 Il Trace necessita di spazio in memoria per
mantenere le informazioni
 Abilitarlo solo in caso di debug
 Inserire una regola di trasformazione
che rimuova la sezione, oppure che lo
disabiliti per default
ASP.NET Trace

26. produttività

27.  Visual Studio permette di
allineare/indentare in modo
automatico il codice
 CTRL+K CTRL+D
 Le regole di formattazione del codice
HTML possono essere modificate dai
settings di Visual Studio
TOOLS -> Options -> Text editor -> HTML -> Formatting
 Il codice allineato correttamente facilita la lettura
del codice stesso
 A colpo d'occhio si riesce a capire come gli
elementi sono innestati
Regole di formattazione

28.  Utilizzare la tastiera invece di cercare il
commando nella toolbar è più veloce
 Quelli più frequenti sono:
 Commentare il codice
 CTRL+K CTRL+C
 Togliere il commento
 CTRL+K CTRL+U
 Formattazione del codice
 CTRL+K CTRL+D
 Aprire menu SmartTag (create Class, import using, ….)
 CTRL+.
 Selezione rettangolare
 ALT+selezione
 Visual Studio 2010 Keybinding Posters
 http://www.microsoft.com/en-
us/download/details.aspx?id=13189
Scorciatoie da tastiera

29. demo

30.  Il "var" non è il variant di Visual Basic
6
 Il "var" viene sostitutito in fase di
compilazione con il tipo corretto
 Personalmente lo trovo molto utile
quando utilizzo tipi (molto) complessi

 Es:
Non abbiate paura del "var"
List<Tuple<int, string, DateTime>> result =
new List<Tuple<int, string, DateTime>>();
var result = new List<Tuple<int, string, DateTime>>();

31.  Il Logging è FONDAMENTALE
 Quando si è in produzione (spesso) è
l'unica cosa che permette di
identificare un problema e la sua
causa
 Bisogna saper loggare
 Troppe informazione a volte equivale a non
averne nessuna
 Usare differenti livelli di log: INFO, DEBUG,
ERROR
 Esistono librerie che ci aiutano in
questo
 Log4net
Logging

32.  Chi utilizza WCF, oltre al proprio
logging può abilitare il Diagnostic
 Permette di loggare qualsiasi cosa
passi attraverso le classi di WCF
 Compresi i messaggi in ingresso ed uscita
 Permette di identificare errori che avvengono
ancora prima che il messaggio arrivi al nostro
codice
WCF diagnostic / logging

33. demo

34.  Da ASP.NET 4.0 il
SqlMembershipProvider è stato sostituito
dal UniversalProvider
 Supporta tutti i database supportati
dall'Entity Framework
 SQL Server, SQL Azure, SQL Compact, MySQL, …
 Disponibile su NuGet
 http://www.nuget.org/packages/Microsoft.AspNet.Providers
/
 Utilizzabile per
 Session
 Membership
 Roles
 Profile
ASP.NET membership -
UniversalProvider

35.  Un source-control non è fatto solo per
chi lavora in team
 Tenere una copia del codice (solo) in
locale è pericoloso
 Avere lo storico dei cambiamenti è un
aiuto da non sottovalutare
 Esistono soluzione gratuite che si
possono adottare
 http://tfs.visualstudio.com/
 https://github.com/
 http://subversion.tigris.org/
 …
Controllo sorgente

36.  Mantenere il codice semplice e pulito è
la prima regola per facilitare il lavoro di
manutenzione
 Ricordate sempre il "Principio KISS"
 Non complicate le applicazioni con
Pattern solo perché fanno figo/moda.
 Non servono sempre
 Sono fatti per risolvere determinate problematiche
 Over-ingegnerizzare una soluzione è il
primo modo per farsi del male
 Scrivete il codice come se lo doveste
manutenere voi
Conclusioni

37. feedback
10
o feedback su:
• http://xedotnet.org/feedback
• Codice: OCT68
• Materiale: http://slpg.org/xe102013
Email: andrea@dottor.net
Website: http://www.dottor.net
Blog: http://blog.dottor.net
Twitter: http://twitter.com/dottor
feedback