[Php-it] [semi-ot] Programmazione

[Marcello Vezzelli]

Gianluca Baù ha scritto:
> Il mio problema principale è che sicuramente sbaglio l'approcio ad un 
> nuovo progetto, o meglio, mi trovo in situazioni dove quello che deve 
> essere fatto non è preventivamente ben definito ma viene fuori passo 
> passo.

Purtroppo è un problema molto diffuso, anche perché lo stesso 
committente non sa bene quello che vuole finché non comincia a premere i 
tasti su quello che gli consegni.
Queste cose vanno un po' come le ciliege, nel senso che una tira 
l'altra... fatta una cosa, vien voglia di averne un'altra (non è detto 
che sia sensata).
Ora è chiaro che il problema è a monte: un progetto definisce appunto i 
binari sui quali procedere nello sviluppo.
Se cambia il progetto, possono cambiare la struttura dati, il codice, in 
certi casi l'approccio stesso alla risoluzione del problema.

Nelle realtà medio-piccole che si basano sull'estemporaneità e sui tempi 
rapidi, dove non c'è tempo (o capacità reale) di fare un progetto ben 
dettagliato, dove non c'è la volontà di descrivere completamente quel 
che si vorrebbe ottenere (spesso non si sa cosa si vuole!), queste 
situazioni sono all'ordine del giorno. Pessimo modo di lavorare, ma alla 
fine si finisce sempre in questo modo.

E' molto difficile far capire ai non addetti ai lavori che (ad esempio) 
cambiare in una tabella una relazione da uno a uno a uno a molti è un 
cambio progettuale: è una semplice modifica funzionale... "ma scusa cosa 
ci vuole... anziché uno solo ne voglio mettere più di uno..."

L'arma vincente in questo caso, secondo me, è la modularità e la pulizia 
del codice.
Un codice pulito e leggibile, senza capriole e virtuosismi, è quello che 
ti salva in questi casi.

Quando si scrive codice, una buona prassi è pensare sempre "ma se lo 
legge un altro, cosa ci capisce?" quindi far finta di doverlo dare a un 
ipotetico collega che poi lo deve capire.
Tra 6 mesi, quel collega sarete voi stessi... e quel codice sarà per voi 
"mai visto" in quanto rimosso dalla memoria.

> A voi capita di avere lavori che richiedono praticamente ogni giorno 
> nuove funzionalità che magari il giorno prima non avreste neanche 
> immaginato di dover inserire?

Parliamo dell'immaginare.
Quando si prendono certe strade, bisogna avere la sensibilità di capire 
quali porte rimangono aperte, quali vengono chiuse, quali vengono 
sprangate a doppia mandata con le chiavi rotte dentro.
Bisogna allargare l'orizzonte oltre le "specifiche" del progetto e 
provare a immaginare in quale direzione ci si muoverà.
Se mentre lavori su una parte ti sembra ragionevole aggiungere una 
funzionalità che probabilmente sarà richiesta, tienla in conto e muoviti 
come se la dovessi implementare. Prendi appunti su come la vorresti 
strutturare e tienli da parte. Queste scelte "potenziali" devono essere 
tutte coerenti tra loro.

Man mano che le scelte aumentano, la libertà di movimento diminuisce... 
se il progetto per la sua natura, o per la natura del committente, tende 
ad uscire spesso dai binari e andare a spasso per la campagna, bisogna 
tenere aperte più strade possibili anche a costo di penalizzare il 
codice o la base dati. Quel che si perde qui, lo recuperi in flessibilità.
>
> Inoltre volevo chiedere: all'inizio di ogni script, fate una 
> dichiarazione globale di tutte le variabili che userete ?? O le 
> lasciate al caso durante la scrittura del codice?

Io vengo dalla scuola del pascal, ovvero "devi dirmi cosa vuoi usare 
prima di usarlo". A volte noioso, ma come forma mentis è molto educativo.
Quindi come fanno i bravi bambini programmatori, all'inizio delle 
funzioni si inizializzano le variabili... ottimo punto anche dove 
mettere commenti su quelle significative.

Se pensate che stia delirando, soccorretemi. ;)

Saluti
Marcello