Questo articolo descrive 10 fondamentali regole per creare un sito web o applicazione diminuendo il raggio di errori o bug. Durante il mio percorso professionale ho avuto la fortuna di incontrare professionisti del settore IT, programmatori esperti con anni di esperienze alle spalle. Il percorso di crescita professionale fa parte della vita di tutti noi ed è meglio conosciuta come esperienza. Nel mondo dell’informatica e nella fattispecie della programmazione, lavorare in team è un modo fondamentale per non perdere il contatto con il mondo esterno che corre sempre più velocemente; ci permette di non “standardizzarci” sullo stesso modus operandi.
Oggi ho stilato un decalogo di concetti tecnici e teorici che reputo fondamentali per lo sviluppo di un software (sito, web app, chiamatela come volete!) performante. Non c’è differenza se programmi PHP piuttosto che RUBY, se parti da zero o utilizzi un framework, se parli MVC oppure no. Le regole che faranno di te un ottimo programmatore saranno sempre le seguenti:
DRY: don’t repeat your self
Non ripeterti!
E’ un principio di progettazione sposato anche dalla metodologia AGILE secondo cui vanno eliminate tutte le forme di ripetizione e ridondanza all’interno del codice. A tal proposito consiglio di leggere “The Pragmatic Programmers” scritto da Dave Thomas:
Questo concetto è talmente generico che può essere sposato da diverse cause: Sviluppo Software, reti, database, ecc…
Un software scritto senza ripetizioni sarà veloce e leggibile.
Esempio ricorrente di ripetizione:
class Handler
{
public function handleStuff($a, $b, $c)
{
var_dump($a, $b, $c);
}
}
$handler = new Handler();
$a = 1;
$b = 2;
$c = 3;
$handler->handleStuff($a, $b, $c);
$a = 4;
$b = 5;
$c = 6;
$handler->handleStuff($a, $b, $c);
$a = 7;
$b = 8;
$c = 9;
$handler->handleStuff($a, $b, $c);
…quando potrebbe essere più semplice questo:
$sets = array(array(1,2,3), array(4,5,6), array(7,8,9));
foreach ($sets as $list)
{
list ($a, $b, $c) = $list;
$handler->handleStuff($a, $b, $c);
}
Rispetta gli stage di sviluppo
Development, test e production non devono essere un optional. Tutti i migliori framework offrono la possibilità di far girare l’applicazione su 3 ambienti diversi, chi ignora l’importanza dovrebbe fare più attenzione ed iniziare a far girare le proprie applicazioni su 3 stage:
- DEVELOPMENT: L’amebiente di sviluppo “locale” che darà vita all’applicazione e conterrà branch e merge delle funzionalità.
- TEST (o staging): E’ buona norma che tutte le nuove funzionalità implementate attraversino una fase di test per studiarne il comportamento e captare eventuali bug che andranno risolti in fase DEV. Immaginate questo stage come un limbo dove la nuova funzionalità è in attesa di sapere se tornerà a casa o sarà promossa.
- PRODUCTION: E’ la fase dove tutto deve andare per il meglio, è la fase operativa. Le nuove funzionalità sono ok e tutto è pronto per essere pubblicato ufficialmente.
Separare i file di configurazione
Non avvalerci di un framework o cms espone lo sviluppatore a una maggior scrupolosità. Indipendentemente dal tipo di applicazione realizzabile è consigliato sempre separare i file di configurazione da tutto il resto. In questa maniera è più facile reperire settaggi, password, costanti o file di lingua attenendosi ad una regola non scritta applicata da tutti gli sviluppatori. Ordine!
Esempio. Architettura di una web app custom:
/root
|---config/
|-------i18n/
|-----------it/
|-----------en/
|-----------es/
|-----------fr/
|-----------de/
|-------config/
|---webapp/
Usare l’indentazione e gli spazi
Ok, sei un professionista, leggendo questo punto probabilmente ti strapperò un sorriso, scrivere un codice pulito e indentato correttamente rientra nell’abc della programmazione, soprattutto se dobbiamo condividere le nostre informazioni all’interno di un team. Sembrerà strano ma ancora oggi, mi capita di ricevere o modificare progetti esistenti dal codice o markup assolutamente incomprensibile per via dell’assenza totale di indentazione.
Dare alle variabili o funzioni, identificativi “parlanti”
Una pagina che conterrà funzioni “parlanti” sarà automaticamente priva di commenti e di facile interpretazione sia per te che riprenderai il codice dopo 1 anno che per il team con il quale lavorerai.
Molto meglio scrivere una funzione del genere…
function ShouldBeInteger($number)
{
if(is_int($number)) return $number . ' is integer';
}
…piuttosto che
function my_function($number)
{
if(is_int($number)) return $number . ' is integer';
}
Siete d’accordo?
Non commentare qualsiasi cosa
Se il codice è scritto in maniera ordinata con funzioni e variabili contenenti nomi sensati (vedi su), lo capirebbe anche un bambino. Se c’è consapevolezza di rispettare molte delle regole descritte in questo articolo, scriverete un codice di facile interpretazione; inserite i commenti solo se indispensabile. Evitate di riempire il codice con ogni tipo di descrizione!
Esempio di commento inutile:
//funzione per il calcolo dell'iva!
var calcolaIva = function(imponibile){
var tot = ((imponibile / 100) * 22);
return tot;
}
Perchè? :/
Refactoring
Una tecnica molto importante per mantenere il codice pulito e funzionale è il refactoring. E’ un processo secondo cui semplifichiamo porzioni di codice non alterando il comportamento. Questo concetto è una colonna portante delle metodologie agili. Un esempio?
if (isIva()) {
var tot = ((prezzo / 100) * 22);
return tot;
} else {
var tot = prezzo;
return tot;
}
diventa
var tot = prezzo;
if (isIva())
var tot = ((prezzo / 100) * 22);
return tot;
Cosi facendo abbiamo semplificato e ridotto righe di codice rendendolo più leggibile e compatto. Nonostante questo, il comportamento non cambia.
TDD: Test Driven Development
Il TDD è una pratica agile diffusa da Kent Beck, rientra nelle 12 regole base dell’Extreme Programming.
In sigla TDD (in italiano: Sviluppo guidato dalle verifiche) è un processo di sviluppo del software in cui lo sviluppo vero e proprio è preceduto (e guidato, driven) dalla stesura di test automatici.
L’utilizzo del Test Driven comporta una probabilità minore di riscontrare bug o anomalie in fase di rilascio. Questo grazie al test di porzioni di codice, sostanzialmente un corretto approccio al TDD è il rifiuto di scrivere una nuova funzione finché non ci sarà prima un test che fallisce. La procedura è composta da tre fasi “Red-Green-Refactor” e si articola in questa maniera:
- RED: il programmatore scrive un test con l’unico obiettivo di farlo fallire;
- GREEN: il programmatore riscrive una quantità di codice sufficiente al superamento del test;
- REFACTOR: il programmatore effettua un refactoring (riscrittura) del codice.
Debug sempre attivo
Avere una console di debug a portata di mano è fondamentale. Oltre a comprende più velocemente potenziali malfunzionamenti ci permette di avere pieno controllo sull’applicazione, cosa di non poco conto. In questo blog ho parlato spesso di PHP o WORDPRESS, anche con i CMS più diffusi al mondo è possibile avvalersi di una console di debug. Qualche settimana fa ho scritto un tutorial che spiega come far funzionare correttamente un debug utilizzando Sublime Text 2.
Controllo di versione
Che sia centralizzato o distribuito, un software per il controllo di versione è d’obbligo! E’ impensabile non curare un progetto in team (ma anche da soli) senza l’ausilio di branch e tag prima del rilascio della funzionalità. E’ impensabile gestire manualmente tutti i probabili conflitti o recuperare una vecchia versione dell’applicazione senza creare confusione. Se c’è uno strumento che automatizza tutta questa roba (e per fortuna ce ne sono parecchi), utilizzatelo!
Vedi anche: GIT – Guida all’utilizzo di un repository locale
Quali altre regole non descritte in questo articolo ritieni fondamentali allo sviluppo di una buona applicazione?
