Web: less is more
by Michele
Perché poco è meglio di tanto? perché quando realizziamo applicazioni web dobbiamo infilarci di tutto e di più? Sembrerebbe una vera patologia, infilare il maggior numero di elementi in tutte le componenti di un progetto. Nelle pagine web ci ritroviamo un numero elevato di elementi grafici, disposti nella maggior parte dei casi secondo opinioni personali (quasi sempre sbagliate). Lato server ci ritroviamo codice scritto “a torrente“, cioè un flusso di idee grezze così come arrivano dalla testa, senza un minimo di analisi a priori. Questo tipo di “non pratiche” nello sviluppo di un progetto portano a effetti devastanti sia nel flusso di lavoro dello sviluppatore sia nei risultati del lavoro stesso. È pratica comune produrre parecchio codice, come se ci fosse un nesso fra la lunghezza delle linee di codice e il buon funzionamento delle applicazioni.
In realtà, maggiore è la dimensione delle applicazioni minore sarà la sua manutenibilità, che inevitabilmente decrementerà ancora con il passare del tempo. In teoria c’è un punto del grafico dove la manutenibilità arriva a zero e ci si trova nelle condizioni di dover riscrivere l’applicazione da zero. Con una buona pratica di sviluppo e analisi possiamo solamente allungare questo tempo e comunque rendere la vita facile a tutti quelli che dovranno mettere le mani nelle applicazioni per apportare modifiche.
Uno dei motivi che rendono “more” più diffuso di “less” è la ridondanza delle azioni/informazioni. In un software eccellente nessuna cosa dovrebbe essere ridondata. Ogni componente dovrebbe gestire la propria logica andando a interconnettesi con gli altri. Ridondare significa aumentare le righe di codice, il livello di caos e di conseguenza complicare la vita ai manutentori. Inoltre si aumenta il rischio di comportamenti anomali del codice e di maggior lavoro durante la fase di debug del codice.
In sostanza, poco codice scritto bene è la soluzione migliore. Ovviamente si necessita di un grande lavoro di analisi e di modellazione OOP del problema ma dopo questa fase, la scrittura del codice viene da sè.
Commenti
[...] Approfitto della riflessione di Michele sull’dea che meno è più per infilarci un paio di idee mie. [...]
Per questo da quando ho scoperto la OOP non riesco più a farne a meno. Il codice diventa di più facile manutenzione e si elimina la ridondanza. Il php4 ormai è obsoleto (anche se usatissimo) e uso prevalentemente il 5. Se solo fosse più ad oggetti.. L’unico rischio è che a volte perdi il filo con tutti gli oggetti che hai creato.
@simotessa: chissa` quando scoprirai linguaggi come python e ruby che in quanto a OOP e feature esoteriche son proprio stupendi
Volendo “esordire” nel mondo dell OOP, dallo studio di quale linguaggio consigliereste di cominciare, privilegiando la versatilità in merito ai campi di applicazione?
Io sono dell’idea che le basi per ogni linguaggio siano C e C++. Non è solo una questione di OOP, sono linguaggi che ti danno le basi, di cui avrai sicuramente bisogno in futuro. Una delle migliori implementazioni dell’OOP è quella di Ruby. Anche l’implementazione di Python è abbastanza larga. Java invece ha una implementazone ridotta anche se supporta i concetti basilari di OOP.
Testi consigliati, risorse online a parte?
Per Python conprai “Programmare con Python” nell’autunno del 2004. Un buon libro che introduce alle basi ma che si riferiva alla versione 2.3 del linguaggio. Purtroppo dopo qualche mese uscì la versione 2.4
Grazie.
E per quanto riguarda C e C++?
Per C “Il linguaggio C – guida completa” di Herbert Schildt (Mc Graw Hill) e per C++ “Il linguaggio C++” di Bjarne Stroustrup (Addison-Wesley)