Sviluppare software e app con qualità: dopo il recente articolo in cui illustriamo i principali strumenti utilizzati in Softfour, oggi lasciamo di nuovo la parola al nostro developer Marco Neè che ci racconta la sua esperienza e i vantaggi della metodologia Clean Design.
Clean Design: panoramica e principi
Cercando metodi per migliorare la leggibilità del codice, la modularità delle componenti e per ridurre il debito tecnico, Marco è entrato in contatto con un design pattern che fa largo uso dell’astrazione e della stratificazione del progetto: il Clean Design.
Mettiamo innanzitutto in luce alcuni principi fondamentali del Clean Design:
Dipendenze e Layer: un componente può dipendere solo da funzionalità presenti in un Layer più “interno” dell’applicazione;
Astrazione: i layer più interni dell’app devono mantenere un alto livello di astrazione rispetto alle funzionalità, mentre i layer esterni devono implementarle in maniera concreta.
Le 5 SOLID rules:
- Single responsibility: ogni componente deve avere una singola funzionalità e di conseguenza una singola ragione per essere modificato;
- Open/closed: i componenti devono essere aperti a future estensioni ma “chiusi” per quanto riguarda modifiche. L’idea sarebbe quella di creare classi che possono essere estese senza mai toccare il codice preesistente;
- Liskov substitution: prende il nome da Barbara Liskov e si riferisce alla capacità dell’applicazione di sostituire ogni istanza di una classe con quella di una sua sottoclasse senza che vi siano differenze di comportamento;
- Interface-segregation principle: una classe client non deve dipendere da metodi che non utilizza, pertanto vanno implementate interfacce specifiche e di piccole dimensioni;
- Dependency inversion: ogni dipendenza va risolta tramite astrazione in modo da disaccoppiare i layer esterni da quelli interni.
Riusabilità: ogni nuova modifica deve poter essere riutilizzabile all’interno dell’app, non sono accettabili fix o modifiche che andranno poi applicate altrove.
Riutilizzo totale delle componenti: ogni modulo deve contenere solo le funzionalità essenziali. Quando vado ad utilizzare un modulo ne utilizzerò ogni classe e, pertanto, solo classi strettamente legate potranno essere inserite in uno stesso modulo.
Evitare la “dipendenza circolare”, sfruttando la dependency injection.
Hexagonal Architecture (ports and adapters): ogni layer è reso modulare dall’utilizzo di “porte” (astrazioni). Gli adattatori fanno da collante fra i vari layer o fra i layer ed il mondo esterno interpretando i dati in entrata dalle porte.
TDD (Test Driven Development)
L’insieme dei principi alla base della Clean Architecture getta le basi per la realizzazione di app facilmente testabili e questo ci ha fatto muovere nella direzione del Test Driven Development.
Il Modello TDD prevede lo sviluppo di applicazioni seguendo cicli divisi in tre fasi e con la scrittura dei test prima della funzionalità vera e propria.
Le Fasi del TDD
- Fase rossa – viene definito un test per la funzionalità ancora da scrivere. Il test deve essere eseguibile e deve fallire;
- Fase verde – va definita la prima bozza della funzionalità. Il codice dovrà limitarsi a passare il test senza pretese di ottimizzazione o leggibilità. A questo punto il test dovrà passare insieme a tutti gli altri test presenti nel software cosi da mettere in evidenza eventuali ingerenze;
- Refactoring – a questo punto il programmatore passerà al miglioramento del codice, al termine del quale lancerà nuovamente tutti i test (che dovranno passare).
Invertire il processo di realizzazione del software ci dà un punto di vista diverso e aiuta ad evitare difetti logici nella progettazione dell’app oltre ad aiutare nella stima dell’avanzamento del progetto.
Approfondimenti e contatti
Per chi desidera approfondire questo mondo, suggeriamo il libro “Clean Architecure” di Robert C. Martin.
Se hai bisogno di un riferimento di qualità per lo sviluppo software in outsourcing, contattaci senza impegno!
