Il buon programmatore - consigli pratici per una vita felice

1,602 views
1,524 views

Published on

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)

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,602
On SlideShare
0
From Embeds
0
Number of Embeds
727
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Il buon programmatore - consigli pratici per una vita felice

  1. 1. Andrea Dottor – Microsoft MVP ASP.NET/IIS IL BUON PROGRAMMATORE consigli pratici per una vita felice
  2. 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. 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. 4.  Riuso e manutenzione del codice  Configurazione  Prestazioni  Produttività Cosa vedremo in questa sessione?
  5. 5. Riuso del codice e manutenzione
  6. 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. 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. 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. 9. demo
  10. 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. 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. 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. 13. demo
  14. 14. Configurazione
  15. 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. 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. 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. 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. 19. demo
  20. 20. prestazioni
  21. 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. 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. 23. demo
  24. 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. 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. 26. produttività
  27. 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. 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. 29. demo
  30. 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. 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. 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. 33. demo
  34. 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. 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. 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. 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

×