09
10
06

Reinventare la Ruota, alla faccia del Riuso

23:28 Technocracy

Con riuso si intende il riutilizzo di componenti software autonomi per costruire qualcosa di più complesso. Ovvero, se c’è la stessa funzione svolta in due programmi differenti, allora è possibile che ci sia un unico componente, sviluppato una volta e riutilizzato in quella successiva (e ogni volta seguente). Nel mondo fisico è un concetto che non può esistere (salvo estensioni di significato) a causa dell’usura, dell’impossibilità di clonare oggetti, di limiti spaziali, etc.

E’ curioso che anche il concetto di riuso faccia riferimento alla fiducia, ci avete mai pensato?

Io posso realizzare componenti miei e riutilizzarli, perché so esattamente come funzionano e come utilizzarli, eventualmente modificandoli secondo necessità. Ma se il componente è di qualcun altro? Devo avere fiducia che il componente sia ben fatto, funzionante ed eventualmente supportato in eventuali sviluppi futuri. Perché il rischio c’è: potrebbe non funzionare, potrebbe smettere di essere aggiornato. E in tal caso il tempo che ho impiegato per imparare ad usarlo e integrarlo nel mio software è andato perso.

Ma qui abbiamo quindi un problema. Prendo a riferimento la rete e in particolare lo sviluppo di una parte dei software di gestione dei contenuti (CMS, per intenderci WordPress nel suo piccolo o cose più voluminose come Mambo, Drupal, lo storico PHPNuke o il mio phpGolem).

Tutti questo software sono sviluppati nello stesso linguaggio. Tutti sono, di fatto, adattamenti e percorsi differenti per fare, più o meno, la stessa cosa: pubblicare contenuti sulla rete. Semplificando, ognuno ha un sistema per scrivere contenuti, un sistema per organizzarlo in categorie (o tags), un sistema per visualizzarlo, un sistema per ricercarlo.

Il riuso si è sempre focalizzato sul livello microscopico, quando c’è stato. In buona misura questi software pur facendo cose simili (seppure con target diversi) non hanno a livello di componenti niente in comune. Nè vi è astrazione su quella che è la base dati.

Se vogliamo, oggi sta anche nascendo per altri versi il livello macroscopico, quello che Bru mi cita come ‘small pieces loosely joined‘. Ma quello intermedio?

Provo a chiarire il concetto: la base dati ‘astratta’ e il software, tipo Wordpress, che sia in realtà composta da moduli di editing, impaginazione, template, ricerca. Non mi sta bene? Ne cambio uno. Questi moduli devono poter astrarre la base dati e la presentazione, ma essere, se uno lo desidera, completamente a sé stanti. Wordpress a questo punto sarebbe solamente uno strumento che assembla pezzi e li visualizza in un modo particolare per un audience particolare, aggiungendo i pezzi che mancano.

Questi componenti che sto pensando dovrebbero essere indipendenti dalla base dati non solo come software, ma proprio come formato. Dovrebbero funzionare sia autonomamente (con al più una parte di scrittura codice minima) sia integrati in un sistema (disponendo quindi di API adatte). Essendo autonome dovrebbero essere non solo componenti ‘ingegneristiche’ ma anche interfacce idonee allo scopo che si prefiggono (ovviamente templatizzabili e rimpiazzabili ve ne fosse la necessità).

Questi componenti sarebbero più di semplici classi riutilizzate e meno di interi sistemi intercomunicanti. Sarebbero invece dei moduli intra|inter software (i|i-modules) e dovrebbero rispondere ai seguenti requisiti:

  1. Indipendenza dalla base dati, non solo come software ma anche come formato. Dovrebbero restituire delle chiamate che verrebbero mappate poi sulla base dati in rapporto al sistema in cui fossero inclusi.
  2. Funzionamento sia autonomo che integrato. Dovrebbero infatti poter funzionare (anche con lievissimi adattamenti di programmazione) sia a sé stanti sia integrati in un software più ampio.
  3. Interfacciamento con l’utente, non solo con il programmatore. Proprio in quanto autonome dovrebbero disporre di una interfaccia che è poi eventualmente templatizzabile o rimpiazzabile secondo le necessità.

Per ora invece, andiamo avanti a dover re-implementare un editor di news ogni volta in ogni software che sviluppiamo. E se ci piace quello di Wordpress non potremo usarlo perché in realtà si tratta di un monolite.

5 comments Add yours below

1

Lawrence Oluyede 2006 10 11 at 20:51

Eh eh qui però sollevi anche questioni squsitamente tecniche che hanno risvolti sul lato "meno" tecnico. Le pratiche di ingegneria del software che portano al riuso (o al non riuso nel caso siano fallaci) dell'architettura. Wordpress non m'è mai parso sto gran pezzo di software anche se fa la sua porca figura in quanto a funzionalità, plugin ecc. ecc.

Il problema del riuso è anche culturale e pratico. Culturale perchè come dici giustamente si basa su un contratto immaginario che il creatore del software A fa con il creatore del software del B che magari usa A all'interno di B. Mister B deve essere sicuro che Mister A ha prodotto un mattone e (teoricamente, ma non è quasi mai cosi) deve poterlo usare come una scatola nera. Inserire dati e aspettarsi risultati come descritto nella documentazione.

Qui entra in gioco il problema pratico. Esistono milioni di componenti per ogni genere di cose ma:

- uno sviluppatore umanamente non può conoscere tutte le varie componenti per fare la cosa che si appresta a fare
- uno sviluppatore umanamente non può nemmeno provare tutte le varie componenti per vedere se fanno la cosa che si appresta a fare. La fanno bene? La prima e la seconda cosa la fanno bene ma la terza no? Posso modificare il componente? Ho notato che A fa meglio 1 e 2, ma B fa meglio 3, posso integrare A e B?
- uno sviluppatore in alcune situazioni ha particolari esigenze di "adattamento" che magari non vengono coperte da questi componenti

Capisci che a volte reinventare la ruota è la soluzione migliore per esigenze particolari, anche se personalmente cerco di evitarlo se posso :-)
2

Folletto Malefico 2006 10 12 at 00:36

Si, sicuramente, la conclusione che trai è logica e sensata. Quello che mi domandavo però era se ci si fosse persi per strada un ipotetico pezzo intermedio, ovvero un mattone che non sia né troppo in basso (classi) né troppo in alto (webservices).

Se ci pensi, in parte i widget sono un po' questo, anche se non implementano la parte "utile" al programmatore (stupidamente).
3

Lawrence Oluyede 2006 10 12 at 01:31

Credo che il pezzo intermedio sia la nostra testa :-)

Sembra una stupidata ma in fondo gli strumenti già ci sono: linguaggi di altissimo livello, linguaggi di basso livello, linguaggi ad ogni livello. Ci sono i webservices, le FFI, le piattaforme, i framework, le architetture basate su OOP e quelle basate su linguaggi funzionali. C'è il networking e la concorrenza in ogni salsa e colore. Probabilmente bisogna capire cosa far sopravvivere... per questo dico che il pezzo in mezzo è la nostra testa.
4

Folletto Malefico 2006 10 12 at 03:05

Quello sempre e comunque, altrimenti non saremmo neppure qui, non trovi? :)
5

Lawrence Oluyede 2006 10 12 at 10:31

:-)

Leave your Comment

required

required, hidden, never shared

Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post ~ Subscribe to the comments via RSS Feed