Cos’è il concetto di mantenibilità? E perché applicarlo?
Il concetto di mantenibilità, assolutamente irrinunciabile quando parliamo di programmazione, deve trovare uno spazio importante anche nella realizzazione di un sito tradizionale. Quando ci si ritrova (e ci si ritrova sempre prima o poi) a dover mettere le mani in un sito che abbiamo terminato sei mesi prima, potrebbe essere un vero e proprio incubo se non lo abbiamo progettato correttamente nella mantenibilità.
Di conseguenza potremmo perdere ore a cercare un file o a capire perché abbiamo scritto quella riga o dove agisce quella classe del foglio di stile.
Vale la pena dunque prendersi il tempo per osservare alcune regole basilari iniziando proprio da qualcosa che troppo spesso viene lasciato al caso: i files.
Perchè dovrei definire i namespaces per i files?
Questo termine -rubato alla programmazione- significa semplicemente attribuire uno standard uniforme ai nomi che utilizziamo. Un esempio sbagliato potrebbe essere questo:
loginArea.html
customer_area.html
User-profile.html
Meglio scegliere un modello ed applicarlo a tutti i files.
login_area.html
customer_area.html
user_profile.html
Sempre parlando di files e namespace, pensa a come saranno visualizzati i files quando apri una cartella e fai in modo che siano ordinati come ti risulterà più comodo, faccio subito un esempio:
delete_user.php
add_user.php
modify_user.php
Nella mia logica (e sottolineo mia in quanto la mantenibilità è soggettiva, ognuno vi applica una sua logica personale) preferisco assegnare i nomi in questo modo:
user_delete.php
user_add.php
user_modify.php
Così quando aprirò la cartella che conterrà altri trecento files (mostrati in ordine alfabetico), saranno raggruppati per “tematiche”. Come detto è una questione di preferenze; infatti qualcuno potrebbe obiettare che il primo modello è migliore se guardato da questa prospettiva:
add_user.php
add_page.php
add_section.php
È vero. L’importante è stabilire un criterio logico e mantenerlo in modo da rendere il più possibile omogeneo il contenuto delle cartelle. Ovviamente possiamo applicare lo stesso concetto anche per le immagini o per i file da scaricare. Ad esempio, nella cartella download non dovremmo trovare una situazione di questo genere:
catalogo_gennaio_2010.pdf
Catalogo_02_10.pdf
catalogo-mar-2010.pdf
La conseguenza, come negli altri casi, sarà una difficoltà a rintracciare i files. Pensate sempre che la cartella potrebbe diventare molto grande con il passare del tempo.
Perchè devo preoccuparmi di applicare una corretta indentazione?
Un codice bene indentato è molto leggibile e facilmente comprensibile:
<div>
<ul>
<li>elemento 1</li>
<li>elemento 2</li>
</ul>
</div>
Mentre pasticci di questo genere:
<div> <ul><li>elemento 1</li><li>elemento 2</li> </ul> </div>
in una pagina magari lunga e complessa fanno perdere tempo in fase di aggiornamento/manutenzione.
Perchè dovrei perdere tempo a commentare il codice?
Inserire dei commenti nel codice che stiamo sviluppando, sia che si tratti di programmazione che di semplice markup (XHTML/CSS), è un’azione che troppo spesso viene trascurata. Inutile dire che, di questa dimenticanza, paghiamo le conseguenze in fase di aggiornamento.
Imponiamoci di commentare il codice. Lo so, quando stiamo realizzano un lavoro ci sembra tutto chiaro. Ma già dopo qualche settimana possiamo avere difficoltà ad individuare i punti sui quali agire. Commentiamo l’inizio e la fine delle varie sezioni. Soffermiamoci sui passaggi particolari, su quel frammento di codice che abbiamo messo per risolvere una compatibilità con Netscape 2.4.3.
#container{
margin: 0 auto;
width: 960px;
}
/* risoluzione della compatibilità con vecchie versioni di IE*/
.ie{
text-align: center;
}
.content{
text-align: left;
}
Organizzare il foglio di stile
Nello sviluppo di layout moderni, dobbiamo spesso confrontarci con fogli di stile complessi; È dunque indispensabile organizzarli in modo molto ordinato. In questo ambito ci sono due scuole di pensiero: ordine alfabetico o ordinamento per sezione (header, navigazione, eccetera). Come ho già avuto modo di dire, non c’e’ un metodo giusto e un metodo sbagliato: l’importante è che voi vi riconosciate una logica e che essa venga rispettata sempre.
Inoltre, anche nei fogli di stile i commenti possono aiutarci a fare chiarezza ed a velocizzare un futuro intervento sugli stili del layout.
Prevediamo inoltre un’ottimizzazione finale. Se riguardiamo attentamente un foglio di stile, troveremo certamente delle righe ridondanti che possiamo eliminare, oppure un mancato sfruttamento delle caratteristiche di ereditarietà del CSS. Facciamo un esempio banale:
body{
font: 14px arial;
}
a:link{
color: green;
text-decoration: none;
font: 14px arial;
}
a:visited{
color: green;
text-decoration: none;
font: 14px arial;
}
a:hover{
color: gray;
font: 14px arial;
text-decoration: none;
}
.link_2 a:link{
color: blue;
font: 14px arial;
text-decoration: none;
}
.link_2 a:visited{
color: blue;
font: 14px arial;
text-decoration: none;
}
.link_2 a:hover{
color: gray;
font: 14px arial;
text-decoration: none;
}
Questo codice è molto ridondante e non utilizza le caratteristiche dei CSS. Possiamo compattarlo in questo modo:
body{
font: 14px arial;
}
a:link, a:visited{
color: green;
text-decoration: none;
}
.link_2 a:link, .link_2 a:visited{
color: blue;
}
a:hover, .link_2 a:hover{
color: gray;
}
Una cosa che invece trovo scomoda (ma come sempre è personale) è il suddividere il foglio di stile in diversi file.
La navigazione: un elemento fondamentale che va studiato nella mantenibilità
In caso di aggiornamenti/aggiunte di contenuti, un problema che si presenta frequentemente è quello della navigazione.
Avevamo creato una bellissima navigazione orizzontale, prevista al massimo per sei voci. Ed ora arrivano decine di nuovi contenuti suddivisi in quattro nuove sezioni. Magari è quel cliente che quando ti ha contattato ti ha detto: “Ma sì, mi serve un sito con due o tre pagine. Sai, la presentazione, i contatti, e nella terza non so ancora bene cosa mettere. Non ti preoccupare.”. E adesso siamo a 4TB di contenuti. È capitato a tutti almeno una volta. Quindi, dal momento che sappiamo che un sito è quasi sempre destinato a crescere (anche quando il cliente ci ha assicurato il contrario), quando è possibile cerchiamo di progettare una navigazione estendibile e mantenibile.
Immaginiamo già possibili sotto-menù, pensiamo a come potrebbe crescere e a come potrebbe essere modificata ed estesa senza perderci una settimana. E cosa fondamentale, separiamola dal contenuto (per favore non con i frame). Due righe di PHP bastano, e il loro utilizzo è relativamente semplice, anche se la programmazione non è il tuo forte.
<?php
include "navigazione.html";
?>
In questo articolo trovi una spiegazione dettagliata di questa procedura.
Oltre alla navigazione, dovremo naturalmente immaginare anche la possibile crescita dei contenuti e di conseguenza come organizzarla in modo ordinato.
Se il sito non é gestito con un CMS, prevediamo delle sezioni ed eventualmente sottosezioni con relative cartelle e, come già detto precedentemente, l’applicazione dei namespace ai files sarà di grande aiuto.
Utilizzare le convenzioni e l’approccio semantico
Io sono un programmatore, ambiente nel quale le convenzioni salvano la vita. La colonna di un database che contiene la chiave primaria, per convenzione si chiama “id”. Posso chiamarla come voglio, posso chiamarla “Ezechiele“, ma perché dovrei? Servirebbe solo a creare confusione.
Similmente, ad esempio, il div utilizzato per contenere i diversi elementi del documento, per convenzione si chiama “container” o “wrapper“, quindi utilizziamo i nomi convenzionali, perché dovremmo inventarne altri?
Sempre parlando di nomi arriviamo all’approccio semantico nel quale un esempio vale più di mille parole:
Consideriamo questo schema di layout
Sembra andare benissimo. Ma cosa succererebbe se, in corso d’opera, decidessimo che la migliore impostazione fosse questa?
Ci troveremmo nella spiacevole situazione di dover modificare i nomi utilizzati nel foglio di stile. Con un approccio semantico invece non avremo nessun problema.
Utilizzare i CMS
Quando i contenuti sono molti e/o gli aggiornamenti sono frequenti, considerare di basarsi su un CMS è d’obbligo. L’utilizzo di uno di questi software risolve in un colpo solo la maggior parte dei problemi di mantenibilità che abbiamo visto in questo articolo. Ma chiaramente anche in questo caso, oltre a scegliere il CMS giusto per le nostre esigenze, dovremo comunque prestare attenzione alla mantenibilità nella prima fase di impostazione.
Conclusione
Molto probabilmente ognuno di noi ha avuto modo di scontrarsi in più di un’occasione con problemi di mantenibilità; quanto esposto in questo articolo non costituisce di certo una grande novità ma i punti trattati possono comunque esserti utili per fare un po’ di ordine durante la fase di progettazione del tuo prossimo sito.
E tu, quante volte ti sei maledetto per non aver tenuto conto della mantenibilità in un tuo sito?
L'autore
Articoli correlati
Potresti essere interessato anche ai seguenti articoli:
32 commenti
Trackback e pingback
-
Tweets that mention Cos’è il concetto di mantenibilità? E perché applicarlo? | Your Inspiration Web -- Topsy.com
[...] This post was mentioned on Twitter by Antonino Scarfì, Nicolas Gutierrez, nando pappalardo, Your Inspiration Web, mtx_maurizio and others.…
si, commentare è veramente utile…
ma una volta pubblicato il sito non fa un pò brutto lasciare i commenti in modo che gli utenti (designer, non utenti normali) li possano vedere?
(con FF basta una mela+U per vedere il markup…)
No anzi. Io quando vedo un codice commentato mi fa pensare che chi lo ha scritto sia una persona molto ordinata e professionale.
mh… ci devo pensare sopra…
però hai dato consigli molto utili… :D grazie!
Condivido in pieno l’articolo e il commento :)
Chi cerca un web designer e guarda i suoi lavori presta attenzione anche a questo.
Già, era proprio questo il mio penseiro
clap-clap … Parole Sante Maurizio.. tutti ottimi punti.. in particolar modo l’indentazione… essenziale… uno “script” senza la corretta indentazione è come un tema scritto senza utilizzare spazi e punteggiatura…
Ancora, ottimo articolo!
Esempio azzeccatissimo, Nic, condivido pienamente!
Grazie Nicolas. Sono un fanatico dell’indentazione prolissa; a capo prima della parentesi graffa.
Per me, vedere la nidificazione delle strutture é essenziale.
Purtroppo, a volte, ci si imbatte in alcuni script dove non vi é nessun tipo di indentazione e per capirci qualcosa bisogna correggerli.
Ottimi consigli Maurizio, mi trovi pienamente d’accordo su tutto. Per quanto riguarda i commenti, forse sarò esagerato, ma io li reputo fondamentali tanto quanto il codice.
Non credo sia esagerato, anzi… spesso quando si va a prendere un vecchio lavoro, o un lavoro di un altro, i commenti possono far risparmiare un sacco di fatiche :)
Sono concorde, ma bisogna sapere dove commentare. Mi é capitato di vedere script del genere
$x = 1 // Valorizzo la variabile "x" a 1
Ecco, forse dobbiamo capire quali sono i passaggi da spiegare (commentandoli) e quelli invece dove é ovvio quello che succede.
Sviluppando applicazioni piuttosto grandi sono abituato ad inserire anche commenti temporanei.
function Test()
{
return TRUE; //Questa funzione é da sviluppare
// per il momento ritorna TRUE per poter testare
// l'applicazione
}
if(Test())
{
echo "hello world";
}
else
{
die;
}
Ecco, parlavamo di indentazione… ma il tag code non me la tiene buona…
Maurizio, utilizza il tag pre al posto di code.
Ottimo articolo!
Anche io, sono un fissato di queste cose, forse anche troppo a volte, perchè quando scrivo del codice, voglio che sia scritto in modo tale che se lo devo modificare, ci impiego 2 secondi.
Quindi, ogni tanto mi capita che quando programmo so che posso farlo in 2 secondi facendolo male, però voglio perderci più tempo e voglio complicarmi la vita, perchè so che almeno poi posso modificarlo tranquillamente in 2 secondi, invece di riscriverlo nuovamente, soprattutto quando so che può capitare.
Grazie Antonio del tuo intervento. E’ il giuto approccio. Ordine e metodo nei codici = codici migliori
Parole sante condivido con te i punti dei commenti ( che a volte per pogrizia non li netto nel codice che programmo), dell’indentazione del markup.
Più lo seguo da ieri e più mi piace questo blog.
Allora benvenuto nella community. Un’altro lettore contento. Un’altra soddisfazione per noi :-)
Pienamente d’accordo… Con un codice pulito, con indentazione e commenti è molto facile e veloce lavorare, non solo per se stessi ma anche per altri che dovranno mettere le mani sul codice.
Sì, questo è un aspetto importante. E’ già difficile lavorare su codici scritti da altri in quanto vi è sempre una differenza di stile. Ma se il codice è disordinato diventa quasi un’impresa impossibile.
AVETE MESSO LO SPUMANTE IN FRIGO?
SIETE PRONTI PER STAPPARE?
DOMANI SI FESTEGGIA, VIETATO MANCARE!!!
ma cosa si festeggia che sono sempre pronto èer festeggiare!
Ti dico solo una cosa, NON MANCARE…!
Sono già col bicchiere in mano!!!
Non vorrei passare da mosca bianca, ma preferisco ripulire il codice da commenti e spazi inutili prima di mandarlo in produzione…Diciamo che sul web pubblico pagine con codice “minified” poi è chiaro che quando devo fare una modifica, andrò ad agire sul mio codice ben indentato e commentato…Sarà perchè adesso presto molta più attenzione alla velocità delle pagine che creo e quindi vedo ogni spazio superfluo come un byte risparmiato… Ah quando parlo di codice naturalmente mi riferisco non solo ai css e i js ma anche all’html… Sbaglio forse a fare così?
P.S. complimenti per il sito… sono un vostro lettore affezionato e trovo sempre degli ottimi spunti e/o consigli..
Continuate così! ;-)
Ciao Cardy e grazie.
Dal momento che quello che fai ha uno scopo ben preciso, non credo che sbagli. Ad esempio anche jQuery rilascia la versione “minified” per la produzione e quella standard per lo sviluppo.
Solo mi chiedo una cosa: Quanto incide risposrmiare quei, esageriamo 10k?
Beh, io non guarderei i 10k risparmiati sulla singola pagina, ma considero il risparmio “globale” visto che solitamente poi il sito non è composto di una sola pagina…. e poi quando ottimizzo un sito, non mi limito a togliere gli spazi e gli “a capo” dal sorgente, anche perchè molte volte di testo ce n’è ben poco… e poi ad ogni modo se anche risparmissi un solo secondo ( il tempo poi è in funzione della velocità di connessione, un secondo su un’ADSL a 7Mbit non è lo stesso secondo di una connessione a 56k) non vedo perchè non dovrei farlo.. Non so se hai mai provato a collegarti tramite internet key o cellulare in una zona non UMTS… ecco io quando realizzo un sito cerco di tenerlo a mente, e applico tutte le tecniche che conosco per ridurre i tempi di caricamento. Google poi da quando ha introdotto il nuovo algoritmo caffeine per l’indicizzazione dei siti, sembra che tenga sempre più conto della velocità di un sito (avrei anche un’interessante case history a riguardo). Se già andava fatta prima, figuriamoci adesso…. naturalmente IMHO ;-)
Ah dimenticavo…. tra l’altro una volta “assimilati” i vari meccansimi di ottimizzazione non si perde nemmeno tempo a implementarli, visto che sarà una cosa automatica…. e poi ci sono numerosi tools che fanno il lavoro sporco… P.S. questa pagina in particolare sarebbe da ottimizzare… magari se ho tempo potrei anche scrivere un articolo a riguardo….
Certamente. Mi domandavo soltanto: minifiedare il markup ti fa risparmiare x, ottimizzare un’immagine ti fa risparmiare 10x (magari per 20 immagini). Mi chiedevo solo se vale la pena.
Inoltre considera che tutto dipende ancora delle prestazioni del server e non da ultimo dal browser. Si notano delle differenze importanti caricando la stessa pagina con un browser piuttosto che con un altro.
Non dirlo due volte. Un articolo su questo argomento sarebbe interessantissimo. Magari con dei confronti, dei test di caricamento, verifiche, tabelle e grafici.
Poi continueremo questa discussione nei commenti di quell’articolo, visto che adesso siamo un tantino OT :-)
Ciao ragazzi, anche se questo post è abbastanza vecchiotto volevo chiedervi un consiglio: secondo voi è più ordinato un foglio di stile con le dichiarazioni a cascata oppure su un’unica riga?
Io trovo migliore la seconda opzione, riesco a rintracciare meglio i selettori ed a gestire meglio tutte le varie proprietà. Voi che ne dite?