Utilizzo delle best practice nello sviluppo del software

Gianluigi Salvi 6a UGI Alt.NET Conference

Di cosa parleremo
Esempi dei vantaggi concreti apportati ad un progetto dall'uso sistematico di code refactoring e l'impatto sul processo di sviluppo software. Come l'attenzione alla scrittura di un codice pulito si traduca in vantaggi reali sia nello sviluppo che nella manutenzione del codice I problemi provocati a lungo termine provocati da code smells e programmazione troppo procedurale.

Cosa dice la teoria?

Concetti di base dellIngegneria del software

Qualit del software Pattern Proggettazione: UML Framework Metriche software Processo di sviluppo del software Ciclo di vita del software ALM

Cosa dice la teoria?

Qualit del software

Qualit esterne
Correttezza Affidabilit Robustezza Efficienza Usabilit Scalabilit

Qualit interne
Verificabilit Manutenibilit Riparabilit Evolvibilit Riusabilit Portabilit

Cosa dice la teoria?

Design Pattern

Pattern creazionali
L'Abstract factory, Builder, Factory method , Prototype, Singleton

Pattern strutturali
Adapter, Bridge, Composite, Container, Decorator, Faade ("facciata"), Proxy

Pattern comportamentali
Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Visitor

Pattern architetturali
I pattern architetturali operano ad un livello diverso (e pi ampio) rispetto ai design pattern, ed esprimono schemi di base per impostare l'organizzazione strutturale di un sistema software. In questi schemi si descrivono sottosistemi predefiniti insieme con i ruoli che essi assumono e le relazioni reciproche.

Client-server, Model-View-Controller (abbreviato spesso in MVC

Progettazione e UML

UML
Diagramma di sequenza

UML
uno strumento straordinario a livello astratto, ma le esigenze concrete portano rapidamente a una divergenza tra il progetto (in uml) e il codice de facto. Microsoft con VS 2010 propone un meccanismo di reverse e forward engineering, che garantisce il sincronismo tra codice e modello, oltre a farne uno strumento di analisi del codice preesistente. Ma a livello pratico?

E la pratica?...
Molte aziende (e sviluppatori) vedono lingegneria del software come qualcosa di molto astratto e teorico. Difficile da comprendere, incapace di soddisfare le esigenze reali, e di essere messo in atto allinterno di tempi e budget reali.

Partire da un approccio pi soft

- Orientato al codice. - Partire dalla risoluzione delle criticit:
- Code smells - Antipattern Tramite refactoring e un tentativo costante di migliorare le qualit del software.

Strategia di risoluzione
Individuare il problema Risolverlo ed evitare che si proponga in futuro

Un caso di studio reale

Tool
Visual Studio* ReSharper NDepend

Esempi in C# .NET, Visual Studio

*Quanto conta lIDE per la scrittura e la manutenzione del codice?

Un caso di studio reale

Business Layer Data Model Layer (generico)

Table Type Data Access Layer

Business Layer Data Model Layer

Busines s Layer

Busin ess Layer

Application

Metodi troppo grandi

Un metodo molto lungo, soprattutto se scarsamente commentato, di difficile lettura. Le Region e i commenti sono fondamentali, ma isolare un pezzo di codice in una funzione ne determina in maniera chiara e formale le responsabilit, input e output.

Perch un metodo lungo non va bene?

- Esempio reale (700 righe): link - Cosa dice la teoria circa la qualit del software? - Codice procedurale: migliaia di righe di codice Qualit esterne Qualit interne inclusione di altro codice. Dati memorizzati in variabili Correttezza (???) Verificabilit locali alla funzione o globali. Affidabilit??? Manutenibilit - Codice ad Robustezza (???) oggetti: le funzioni (metodi) hanno acceso Riparabilit ai dati interni alloggetto e possono accedere alle Efficienza Evolvibilit??? propriet di altri oggetti solo tramite linterfaccia Usabilit Riusabilit publica.

Best Practice = minore libert?

- Aderire ad uno standard (implemendo uninterfaccia, seguendo un pattern, ecc.) corrisponde spesso a una rinuncia ad alcune libert implementative. - Ma significa anche maggiore leggibilt, maggiore standardizzazione, modularit e manutenibilit.

Metodi troppo complessi

METHODS WHERE ILCyclomaticComplexity > 40 are really too complex and should be split in smaller methods, or even types. (except if they are automatically generated by a tool).

Metodi con troppi parametri

Una funzione che accetta in input pi di 6 - 7 parametri inizia a perdere di leggibilit e anche in un linguaggio strong typed pu dar luogo a errori. Le variabili statiche o simil globali devono essere usate con la massima parsimonia. La soluzione potrebbe essere la creazione di un nuovo oggetto.

Metodi scarsamente commentati

Si noti che la query su Ndepend specifica: percentuale di commenti < 20 e linee di codice > 10

Metodi con troppi overload

Avere pi metodi con lo stesso nome comodo, ma implica una ricerca e pu dar luogo a un sistema di scatole cinesi dove un metodo non fa altro che richiamarne unaltro.

Classi troppo grandi

Se una classe inizia a diventare troppo complessa, occorre chiedersi se sufficiente spezzarla in pi file (keyword partial) o se spostare una parte delle responsabilit su altre classi.

Classi con troppi metodi

Spezzare il codice in pi funzioni infatti solo un primo step. Alla lunga si rischia di ottenere classi con centinaia di metodi, ma soprattutto

N di metodi per classe

Programmazione a oggetti? Di fatto no

Il concetto chiave in un linguaggio ad oggetti quello di avere un set di dati e metodi che hanno accesso a questi dati. Un oggetto un contenitore capace di gestire I dati che contiene. Se non ci sono campi e tutti i metodi sarebbero potuti essere statici, non sfruttiamo i vantaggi di questo modello di programmazione.

Metodi inutilizzati

Metodi che potevano essere private

Metodi che potevano essere internal

Classi pi utilizzate
Qualche statistica

Metodi pi utilizzati
Qualche statistica

Metodi che usano molti metodi

Qualche statistica

Come risolvere il problema?

Prestare attenzione anche alle qualit interne del codice Includere nel processo di sviluppo del software anche la formazione delle risorse umane Utilizzare Ide e tool che semplificano la scrittura di codice pulito Refactoring

Find Usage

Go to Type & Symbol

File Structure

Refactoring (1)
Extract Method Introduce Parameter Introduce Variable Extract Superclass Safe Delete Rename Encapsulate Field Extract Class from Parameters Extract Interface Inline Method

Refactoring (2)
Move Type to Another File or Namespace Move Type to Outer Scope Move Types into Matching Files Pull Members Up / Down Use Base Type where Possible Replace Constructor with Factory Method Add Property with backing field Code Template

Altri tool di Automated code refactoring

Many software editors and IDEs have automated refactoring support. Here is a list of a few of these editors, or so- called refactoring browsers. IntelliJ IDEA (for Java) Eclipse's Java Development Toolkit (JDT) NetBeans (for Java) and RefactoringNG, a Netbeans module for refactoring where you can write transformations rules of the program's abstract syntax tree. Embarcadero Delphi Visual Studio (for .NET) JustCode (addon for Visual Studio) ReSharper (addon for Visual Studio) Coderush (addon for Visual Studio) Visual Assist (addon for Visual Studio with refactoring support for VB, VB.NET. C# and C++) DMS Software Reengineering Toolkit (Implements large-scale refactoring for C, C++, C#, COBOL, Java, PHP and other languages) Photran a Fortran plugin for the Eclipse IDE SharpSort addin for Visual Studio 2008 Sigasi HDT (for VHDL) XCode Smalltalk Refactoring Browser (for Smalltalk) Simplifide (for Verilog, VHDL and SystemVerilog) Tidier (for Erlang)

Il refactoring in rete

Il refactoring in rete

Il refactoring in rete

Il refactoring in rete

Il refactoring in rete

Il refactoring in rete

Performance