Aspect-Oriented Programming

[Ulbrec]

Non so se è un argomento che può interessare a qualcuno, ma stavo leggendo questo articolo che ho trovato interessante

http://dsheiko.com/weblog/aspect-oriented-software-development-and-php

che ne pensate?

[Fabrizio Callai]

Personalmente vengo dalla "vecchia scuola" (programmo dall'83 e dall'assembler)... ne ho viste di tutti i colori e la mia esperienza, per quanto discutibile possa essere, è che ciascun programmatore ha un suo metodo di sviluppare e semplificare i problemi che spesso va al di là delle "mode", dello "stato dell'arte" o altro. In sostanza non metto in croce chi utilizza ancora i "goto", a condizione che abbia un senso in quel contesto.
L'importante è arrivare presto e bene a un risultato stabile e che garantisca la manutenibilità del codice.
Il problema della metodologia dell'approccio invece si pone, in modo serio e pesante, in team.

Il mio ultimo studio, interrotto per esigenze di tempo, è Behat ( http://behat.org ) ovvero un approccio "Behavior Driven" per PHP. Sostanzialmente unisce le "stories" e il "test" in un'unico ambiente descrittivo che viene trasposto automaticamente in classi e test.
Personalmente, a un primo approccio basato solo sulla lettura della documentazione ufficiale, l'ho trovato il sistema più veloce e performante rispetto ad altri.
Prima di lasciare la mia strada attuale però voglio rifletterci un attimino di più non appena troverò del tempo da dedicargli....

Ciao

[liuggio]

Bell articolo grazie della condivisione

> --
> Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
> Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
>  
>  

[liuggio]

Dell aop se ne è parlato molto ma è ancora considerato una buona pratica e di motivi ce ne sono

[liuggio]

Scusate sto dal cell volevo.dire NON é considerato una buona pratica

[Fabrizio Callai]

Alcuni esempi + un framework

http://go.aopphp.com/

Il giorno venerdì 26 aprile 2013 12:43:34 UTC+2, Ulbrec ha scritto:

[Alessandro Nadalin]

2013/4/27 liuggio <liu...@gmail.com>

Scusate sto dal cell volevo.dire NON é considerato una buona pratica

On Apr 27, 20

Perche'?

--
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_

[Ulbrec]

è una cosa che interessa sapere anche a me, anche perchè, come dice l'articolo, è molto vicino all'OOP.

[Fabrizio Callai]

Una cosa non esclude l'altra ovvero puoi usare AOP con OOP ma anche AOP con procedurale.
E' un sistema di semplificazione del codice (da valutare poi realmente quanto semplifichi...).

Ulteriori info:
http://stackoverflow.com/questions/232884/aspect-oriented-programming-vs-object-oriented-programming


Una cosa che mi lascia MOLTO perplesso e della quale probabilmente sarà il caso di parlare ad uno dei prossimi incontri è "cosa si intende davvero per manutenibilità del codice" tanto declamata alla nascita dell'OOP.
A mio avviso (ma non solo mio...) per "manutenibilità" si intende non solo la possibilità di aggiornare il software a distanza di tempo effettuando un aggiornamento funzionale o un refactoring, ma anche la possibilità che al cambio di uno o più programmatori (o dell'intero staff) vi si possa comunque mettere mano agevolmente e in tempi economicamente convenienti.
A questo punto la domanda è: qual'è il comune denominatore, da intendersi come "massima complicazione attuabile", nella stesura di un codice? L'utilizzo dei pattern più astrusi ed "erotici per un nerd"? L'utilizzo di sistemi più o meno guidati di creazione del codice (VOP ovvero vattelapesca-oriented programming) ?
Ad oggi qual'è il rapporto costi/benefici che assegnate al tempo passato a studiare e testare le proposte più "esotiche" e i benefici che ne avete avuto?

Ciao
F.

Il giorno venerdì 26 aprile 2013 12:43:34 UTC+2, Ulbrec ha scritto:

[Fabrizio Callai]

Rilegendo mi sono accorto che non ho posto la domanda cruciale:
Posto di avere un software ben scritto (...e qui ci sarebbe da vedere.... ma sorvoliamo....) un programmatore per essere in grado di subentrare in un codice che skill dovrebbe avere a vostro parere, affinchè possa affrontare una modifica in modo professionale, economicamente equo e non creare casini che poi un terzo subentrante dovrà pagare?

Ciao

Il giorno venerdì 26 aprile 2013 12:43:34 UTC+2, Ulbrec ha scritto:

[liuggio]

L'AOP è superfico se si ha davanti un programmatore che sa come non passare al lato oscuro.

L'aop è molto potente ma si dovrebbe usare solo per aspetti che si contano sulle dita (logging, caching, security, plugin e pochi altri)

per tutti gli altri sicuramente va discusso del perche non gestirli con gli eventi.

Riassunto:
usato in modo estensivo l'AOP tende allo spaghetti code.

usato per niente dell'AOP non si sente la mancanza

usato come il sale QB(quanto basta) puo' velocizzare procedure e velocizzare il codice

Hook nelle funzioni in maniera estensiva cosa vi ricorda? dai è a forma di goccia inizia per Dru e finisce con spaghetti code...

un piccolo contro dell'aop non è tanto la testabilità ma il debugging ...

Super riassunto:

OOP >= Newbie

AOP >= Joda

2013/4/27 Fabrizio Callai <f.ca...@gmail.com>

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--
 __________________liuggio_________________________________
 
  __/|_      We reject kings, presidents and voting.
/o )   \/    We believe in rough consensus
)__ v _/\          and running code  (I.E.T.F. credo)
______________________________________________________________

[Giorgio Cefaro]

>un programmatore per essere in grado di subentrare in un codice che skill
>dovrebbe avere a vostro parere, affinchè possa affrontare una modifica in modo
>professionale, economicamente equo e non creare casini che poi un terzo
>subentrante dovrà pagare?

Deve saper lanciare i test? :-)

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--

Giorgio Cefaro
-------------------------
Developer
giorgiocefaro.com
twitter: @giorrrrgio
linkedin: it.linkedin.com/in/giorgiocefaro

[Giorgio Cefaro]

> Deve saper lanciare i test? :-)

Risposta estesa: a mio avviso se lo sviluppatore trova un ambiente sano (ben scritto, testato e conforme a tutte le buzzword del caso), avrà la strada spianata per produrre buon codice anche se non è Yoda. Certo, a patto che sappia capire il codice attraverso i test, integrare i test e avere una sufficiente preparazioni su come si programma a oggetti.
Nel caso trovi un ambiente malsano, deve essere necessariamente più preparato, per non infittire ulteriormente la trama degli spaghetti e riuscire a tenere a bada eventuali mostri presenti nel codice.

[Fabrizio Callai]

Giorgio sinceramente (forse è un mio limite) non ho capito la tua risposta.
Personalmente:

a) il fatto che un test passi significa solo che viene verificata una condizione iniziale nota con una finale nota, visto che statisticamente il 99% dei test verificano che 2+2 faccia 4 ma non che un 2+A => "gestione errore corretta" o un 2.0.4+2 = ... (notare il doppio punto). Lungi da me dire che i test non servono, ma limitiamoli al loro scopo.... e il loro scopo, a mio modesto avviso, non è "spiegare il codice" o, come dici tu un programmatore "sappia capire il codice attraverso i test", ma testarlo;

b) "sufficiente preparazioni su come si programma a oggetti"... ecco... qual'è la condizione minima per definire un programmatore "sufficientemente preparato"? Chi sa cos'è un design pattern o che li sa tutti a memoria? che sa programmare in AOP e in BD (e tutte le combinazioni a 2 e 3 lettere)? Definirlo non è importante solo per capire se sei Yoda o Yogurt, ma per garantire che il programmatore che subentra capisca realmente il codice e non faccia casini... non è questione di "lana caprina", ricordiamoci che esistono anche sistemi "mission-critical" (almeno a detta del cliente) che è meglio che non abbiano "downtime" non gestiti a modo... Esempio concreto: un software scritto in AOP (o BD, o...) è manutenibile da uno che conosce solo i principali patterns?

Ciao




Il giorno venerdì 26 aprile 2013 12:43:34 UTC+2, Ulbrec ha scritto:

[Alessandro Nadalin]

2013/4/27 liuggio <liu...@gmail.com>

L'AOP è superfico se si ha davanti un programmatore che sa come non passare al lato oscuro.

L'aop è molto potente ma si dovrebbe usare solo per aspetti che si contano sulle dita (logging, caching, security, plugin e pochi altri)

per tutti gli altri sicuramente va discusso del perche non gestirli con gli eventi.

Riassunto:
usato in modo estensivo l'AOP tende allo spaghetti code.

usato per niente dell'AOP non si sente la mancanza

usato come il sale QB(quanto basta) puo' velocizzare procedure e velocizzare il codice

Hook nelle funzioni in maniera estensiva cosa vi ricorda? dai è a forma di goccia inizia per Dru e finisce con spaghetti code...

Sinceramente mi trovo in forte disaccordo.

Nel senso, a tutto il discorso qua sopra potrei sostituire "AOP" con "PHP" che il senso rimane: non e' che perche' una cosa va usata nel modo corretto allora "NON é considerato una buona pratica".

L'AOP e' molto probabilmente uno dei pochi modi in cui eviti di sporcare il tuo dominio con monnezza tipo logger e cache - se ne parlava al php.to.start con la crew di Ideato.

Il fatto che sia potente e vada fatto in un certo modo non significa che non sia una buona pratica, altrimenti staremmo qua a dire che Symfony2 "NON e' considerato un buon framework" perche' comunque ci puoi scrivere procedurale dentro.

O no?

[liuggio]

quindi sei totalmente in disaccordo con la mia prima email
ma totalmente in accordo con la mia seconda email

o no?

 

2013/4/28 Alessandro Nadalin <alessandr...@gmail.com>

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

[Alessandro Nadalin]

2013/4/28 liuggio <liu...@gmail.com>

quindi sei totalmente in disaccordo con la mia prima email
ma totalmente in accordo con la mia seconda email

o no?

 

Sono molto contrario a dire che qualcosa non e' una buona pratica senza spiegarne il perche'

[liuggio]

Capisco il tuo punto di vista

era una frase scritta dal cellulare per comunicare che non è oro quel che luccica.

 

2013/4/28 Alessandro Nadalin <alessandr...@gmail.com>

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

[liuggio]

All inizio ero anche indeciso se mettere una slide sull aop al phpday dato che parlo di cache e logging poi mi son detto che gia se ne era parlato tanto ma questo thread mi ci fa ripensare

[Alessandro Nadalin]

2013/4/28 liuggio <liu...@gmail.com>

Capisco il tuo punto di vista

era una frase scritta dal cellulare per comunicare che non è oro quel che luccica.

immaginavo ;) Pero' per qualcuno che non conosce nemmeno per sbaglio l'AOP si ritrova disorientato...

ad ogni modo implementare AOP in php oggigiorno non e' molto semplice anche se onestamente lo consiglierei vivamente. Con Cirpo e Proietti si parlava di avere il logging in AOP, ma vorrebbe dire utilizzare un custom PSR-0 autoloader in modo da includere non le classi originali bensi i proxy. Michele (Orselli) discuteva del fatto che nonostante in linea di principio il fine sarebbe perfetto, l'implementazione rischia di lasciare a desiderare, almeno a livello di API finale dell'utente:

https://gist.github.com/odino/5476269

[Riccardo Bini]

Il giorno 28 aprile 2013 16:20, Alessandro Nadalin <alessandr...@gmail.com> ha scritto:

[...] Con Cirpo e Proietti si parlava di avere il logging in AOP [...]

Non per fare il pignolo ma la soluzione di usare AOP per il logging l'avevo proposta io.

Rick

[Alessandro Nadalin]

2013/4/28 Riccardo Bini <vald...@gmail.com>

Il giorno 28 aprile 2013 16:20, Alessandro Nadalin <alessandr...@gmail.com> ha scritto:

[...] Con Cirpo e Proietti si parlava di avere il logging in AOP [...]

Non per fare il pignolo ma la soluzione di usare AOP per il logging l'avevo proposta io.

Leggi il vecchio thread ("Dove monologgare?") e l'ultima frase del primo post :-) credo sia un'idea molto condivisa, anche perche' sparare il logger ovunque credo abbia fatto storcere il naso a tutti qui.

[liuggio]

@Riccardo aop per logging e caching è qualcosa di molto più vecchio del php.to.start

@odino con le annotation o XML si potrebbe anche ottenere un buon risultato, il vero problema è il PHP e che per implementare un Aspect si deve si deve proxare tutte le classi che lo utilizzano,

sarebbe divertente giocare con go!aop-php unito al proxyManager di Ocramius.

C'è tanto da copiare a Spring come casi di uso (http://www.mkyong.com/spring3/spring-aop-aspectj-annotation-example/)

2013/4/28 Alessandro Nadalin <alessandr...@gmail.com>

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

[Jacopo Romei]

Fabrizio,

> Lungi da me dire che i test non servono, ma limitiamoli al loro scopo....
> e il loro scopo, a mio modesto avviso, non è "spiegare il codice" o,
> come dici tu un programmatore "sappia capire il codice attraverso i test", ma testarlo;

Incredibilmente però il senso di una suite di test usata nel modo migliore possibile è proprio quello opposto: parlare *agli esseri umani* del valore di business offerto dal software testato:

- illustrare casi d'uso utente con test funzionali

- illustrare casi d'uso di aggregati con test d'integrazione

- illustrare caso d'uso di classi con test unitari

I test 'sterili' che descrivono una API metodo per metodo - non che questi fossero necessariamente implicati dal tuo commento, beninteso - non sono l'uso più potente che si possa fare dei test automatici, anzi in genere ne costituiscono un uso fragile: si rompono spesso, aiutano poco e quindi finiscono per essere vissuti come una rotura di palle dal team.

Io voglio che i miei test mi spieghino il codice.

Io voglio capire il lavoro degli altri nonché il mio tra 49 ore attraverso i test.

Lo voglio forte forte. :-)

--
Jacopo Romei
http://www.sviluppoagile.it/
http://twitter.com/jacoporomei
http://www.anonimarmonisti.com/

[Giorgio Cefaro]

Io voglio che i miei test mi spieghino il codice.

Io voglio capire il lavoro degli altri nonché il mio tra 49 ore attraverso i test.

Lo voglio forte forte. :-)

Ecco, mi ero scordato di replicare, dunque quoto.

[Fabrizio Callai]

Credo di capire il vostro punto di vista, ma non riesco (ancora) a condividerlo.

Personalmente quando approccio un nuovo sorgente cerco di farmi un'idea di massima sul come funziona, poi scendo nel dettaglio approfondendo se necessario le parti d'interesse e tralasciando le altre.

Ritengo, e correggetemi se sbaglio, che i test siano numericamente più numerosi delle classi.... seguendo il vostro approccio è come prendere un tomo da 500 pagine e pupparselo tutto, almeno fino a dove si necessita intervenire, personalmente (qui mi aspetto dei commenti, se lo ritenete opportuno) preferisco farmi prima un'idea generale utilizzando "un Bignami" (es. http://www.phpdoc.org/ ) e poi andare sul tomo e aprire solo il capitolo o paragrafo che m'interessa....

[alessandro cinelli]

2013/5/8 Fabrizio Callai <f.ca...@gmail.com>:

hai dato per assunto che lo sviluppatore si legga TUTTI i test?

Anche i test possono essere un "Bignami", dai una rapida occhiata ai
namespaces e poi ti scegli quali guardare.


cirpo

>
>
>
>
> --
> Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di
> Google Gruppi.
> Visita questo gruppo all'indirizzo
> http://groups.google.com/group/pug-roma?hl=it-IT.
>
>



--

@cirpo

[Alessandro Nadalin]

Esatto, questo paragone mi pare piu sensato :-)

[Fabrizio Callai]

Do per assunto che per studiare un codice, "leggerlo" per me è l'ultima cosa...

Personalmente (per ora, ed è per questo che ci stiamo confrontando) preferisco la scelta di passare da un linguaggio "umano" con un indice e vari riassunti descrittivi delle classi, nonché spiegazioni su eventuali layer "nascosti" come l'AOP e il "magic overloading", se utilizzati.

Sto parlando pertanto di codice "estraneo", non di un codice sviluppato "in-house" che, per sua natura, è già una rappresentazione implicita dei miei schemi mentali e permette dunque  un approccio molto più diretto quale quello da voi proposto.

[leonardo proietti]

>Sto parlando pertanto di codice "estraneo"

a me risulta estraneo anche il codice che ho scritto io 3 mesi fa.

senza test davvero non saprei come recuperare informazioni vitali come i casi d'uso gestiti.

considerazioni sparse:

- i test di rendono coraggioso.

- i test permettono di pluggare a caldo nuovi programmatori sullo stesso progetto.

- se ti fai guidare dai test impari molto più velocemente (sia le buone pratiche che gli strumenti che usi).

- i test permettono a programmatori con skill diverse di collaborare.

- c'è un unica controindicazione: danno dipendenza :-)

per essere chiari: non sono i test a risolverti i problemi di comunicazione umana (che ci DEVE essere),

ma ti danno sicuramente una base oggettiva su cui discutere, sopratutto se hai dei test di accettazione.

personalmente sono arrivato a questo punto: toglietemi pure Symfony2, ma non toglietemi i test automatici.

Ciao

Leonardo

[Fabrizio Callai]

 > non sono i test a risolverti i problemi di comunicazione umana (che ci DEVE essere),

....appunto....  qui abbiamo codice scritto dalla ditta "X" che, finito il contratto e passati "tot" mesi, è stato consegnato alla ditta "Y". Comunicazione tendente a meno infinito.

> ma ti danno sicuramente una base oggettiva su cui discutere, sopratutto se hai dei test di accettazione.

 non è mai stata mia intenzione contestare ciò, anche perché avrei contestato i test in quanto tali.

Risposta alle tue considerazioni:

> i test di rendono coraggioso.

concordo

> i test permettono di pluggare a caldo nuovi programmatori sullo stesso progetto.

vero, ma ti avvali moltissimo anche del rapporto umano;

> se ti fai guidare dai test impari molto più velocemente (sia le buone pratiche che gli strumenti che usi).

Non concordo... se hai cattive abitudini te le porti anche dentro i test...

> i test permettono a programmatori con skill diverse di collaborare.

secondo me "agevolano", non "permettono"...

> c'è un unica controindicazione: danno dipendenza :-)

Concordo ^_^

[Fabrizio Callai]

Per la cronaca.... i test, non essendo normalmente previsti da contratto (...storia lunga da spiegare...), se te li lasciano (ammesso che esistano!!!) lo fanno a titolo di FAVORE.

In sostanza vengono trattati (giustamente o meno, se ne può parlare) come strumento di supporto al team di programmatori fino al rilascio, ma non come parte integrante dei sorgenti da consegnare anche perché funzionalmente non necessari per l'utilizzo dell'applicativo commissionato. Al massimo si potrebbero (forse) far ricadere nella "documentazione a corredo"... ma anche lì è difficile......

Spero che ora il quadro generale delle mie precedenti affermazioni ( ovviamente non necessariamente condivise ) sia quantomeno chiaro....

Ciao

[Alessandro Nadalin]

2013/5/8 Fabrizio Callai <f.ca...@gmail.com>

Per la cronaca.... i test, non essendo normalmente previsti da contratto (...storia lunga da spiegare...)

Io mi farei questa domanda: i controller sono messi a contratto?

 

, se te li lasciano (ammesso che esistano!!!) lo fanno a titolo di FAVORE.

In sostanza vengono trattati (giustamente o meno, se ne può parlare)

*meno*, perche' in questo modo il tuo cliente ti comunica che vuole spendere denaro in test manuali ogni volte che aggiorni il software - bugfix o nuova feature che sia.

 

come strumento di supporto al team di programmatori fino al rilascio, ma non come parte integrante dei sorgenti da consegnare anche perché funzionalmente non necessari per l'utilizzo dell'applicativo commissionato.

forse ti piacera' questa lettura http://www.sviluppoagile.it/il-codice-side-effect-un-fastidioso-contrattempo che va a scavare sul concetto di valore generato per il cliente

 

Al massimo si potrebbero (forse) far ricadere nella "documentazione a corredo"... ma anche lì è difficile......

Non e' documentazione, e' qualita'. Quando il tuo cliente *non vuole* test automatici gli puoi tranquillamente dire che in questo modo otterra' un prodotto (piu') scadente.

 

Spero che ora il quadro generale delle mie precedenti affermazioni ( ovviamente non necessariamente condivise ) sia quantomeno chiaro....

Ciao

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_

[Fabrizio Callai]

Ciao Alessandro, ti rispondo punto per punto "come funziona" dalle mie parti... anche se non credo ti piacerà.

2013/5/8 Fabrizio Callai <f.ca...@gmail.com>

Per la cronaca.... i test, non essendo normalmente previsti da contratto (...storia lunga da spiegare...)

Io mi farei questa domanda: i controller sono messi a contratto?

Controller??? Pensi che se lavori con i "goto", mischiando procedurale, functional e OOP o lavori in BASIC o Pascal importi a qualcuno? 

L'importante è: se l'applicativo funziona ok, se non funziona è colpa tua (dell'appaltato).

 

 

, se te li lasciano (ammesso che esistano!!!) lo fanno a titolo di FAVORE.

In sostanza vengono trattati (giustamente o meno, se ne può parlare)

*meno*, perche' in questo modo il tuo cliente ti comunica che vuole spendere denaro in test manuali ogni volte che aggiorni il software - bugfix o nuova feature che sia.

No. Il cliente ti comunica "mi serve tale cosa entro questo tempo, la penale per i ritardi è quest'altra. Mi devi includere x tempo di assistenza compresa. Chi mi fa il lavoro al minor prezzo?"

Il resto è un problema dell'appaltato il quale è libero di agire come meglio crede per arrivare al target. Non escludo che si arrivi a fare contratti "a progetto" (non ne so nulla della parte giuridico/legale per cui passatemi il termine forse non corretto) dove se il programmatore non finisce il progetto per tempo, lo deve portare avanti e concludere gratis, salvo penali. 

La consegna è quella prevista per far funzionare contrattualmente l'applicativo.

 

 

come strumento di supporto al team di programmatori fino al rilascio, ma non come parte integrante dei sorgenti da consegnare anche perché funzionalmente non necessari per l'utilizzo dell'applicativo commissionato.

forse ti piacera' questa lettura http://www.sviluppoagile.it/il-codice-side-effect-un-fastidioso-contrattempo che va a scavare sul concetto di valore generato per il cliente

 

Forse al cliente (vedi sopra) l'unico concetto che interessa si limita al "funziona =ok ; non funziona = è colpa tua e lo ripari di corsa" e il resto non è affar suo????

 

Al massimo si potrebbero (forse) far ricadere nella "documentazione a corredo"... ma anche lì è difficile......

Non e' documentazione, e' qualita'. Quando il tuo cliente *non vuole* test automatici gli puoi tranquillamente dire che in questo modo otterra' un prodotto (piu') scadente.

La valutazione il cliente la fa sul "funziona/non funziona", non sul "quanto è ben scritto il codice". E' un dato sul quale puoi anche non concordare, ma è oggettivo.

 

 

Spero che ora il quadro generale delle mie precedenti affermazioni ( ovviamente non necessariamente condivise ) sia quantomeno chiaro....

Ciao

Ho letto gli articoli ma non fanno parte della mia realtà.
Lì si parla di "seguire il cliente" ed implicitamente si intende "il cliente" non come un "l'insieme dei clienti" ma come "ciascun cliente". Si tratta in sostanza si "coccolarsi il cliente" facendo vedere che è stato "fatto un buon lavoro" e quindi si è "seri, bravi, professionali, ecc. ecc."... peccato che nel mio mondo al cliente importi solo il "funziona/non funziona"....

In sostanza se vuoi applicare un ambiente di "buona programmazione" buon per te (appaltato), altrimenti se non sei aderente nei modi e tempi paghi penali come se piovesse.... per cui la qualità è un "tuo" problema, non "suo".

Ciao

 

[Jacopo Romei]

Fabrizio,

ti rispondo solo al primo punto, tanto importante da rendere trascurabili i successivi:

Alessandro ha scritto:

> Io mi farei questa domanda: i controller sono messi a contratto?

Tu hai risposto:

>> Controller??? Pensi che se lavori con i "goto", mischiando procedurale, functional e OOP o lavori in BASIC o Pascal importi a qualcuno?
> L'importante è: se l'applicativo funziona ok, se non funziona è colpa tua (dell'appaltato).

Praticamente hai risposto portando l'argomento di Alessandro (e mio e di alcuni altri qui)!

*Proprio* perché *nemmeno* i controller sono aspetti su cui il cliente ha e debba avere visibilità, così il tuo argomento sul fatto che i test debbano essere "messi a contratto" [cfr. "Per la cronaca.... i test, non essendo normalmente previsti da contratto (...storia lunga da spiegare...), se te li lasciano (ammesso che esistano!!!) lo fanno a titolo di FAVORE." -- Callai 2013] è altrettanto sfilacciato!

I test uno li fa se pensa che servano, così come usare dei controller o dei goto selvaggi. Al cliente non importa e non deve importare, almeno in prima istanza.

Ne *consegue* che usare i test automatici è una decisione che spetta al solo sviluppatore e che lo sviluppatore può decidere di prendere *anche solo* per tutelare sé stesso, in modo completamente opaco al cliente e al contratto che stipula con questi.

Insomma, in buona sostanza, come spesso accade, il cliente è solo un alibi per una mancata auto-riforma.

Ciao!

--

Jacopo Romei

Agile Coach eBay Italia

www.sviluppoagile.it

[Alessandro Nadalin]

2013/5/16 Fabrizio Callai <f.ca...@gmail.com>

Ciao Alessandro, ti rispondo punto per punto "come funziona" dalle mie parti... anche se non credo ti piacerà.

2013/5/8 Fabrizio Callai <f.ca...@gmail.com>

Per la cronaca.... i test, non essendo normalmente previsti da contratto (...storia lunga da spiegare...)

Io mi farei questa domanda: i controller sono messi a contratto?

Controller??? Pensi che se lavori con i "goto", mischiando procedurale, functional e OOP o lavori in BASIC o Pascal importi a qualcuno? 

L'importante è: se l'applicativo funziona ok, se non funziona è colpa tua (dell'appaltato).

Stavo rispondendo anche su questo punto, ma Jacopo mi ha preceduto con una forma migliore. Per cui vado avanti sugli altri.

 

 

 

, se te li lasciano (ammesso che esistano!!!) lo fanno a titolo di FAVORE.

In sostanza vengono trattati (giustamente o meno, se ne può parlare)

*meno*, perche' in questo modo il tuo cliente ti comunica che vuole spendere denaro in test manuali ogni volte che aggiorni il software - bugfix o nuova feature che sia.

No. Il cliente ti comunica "mi serve tale cosa entro questo tempo, la penale per i ritardi è quest'altra. Mi devi includere x tempo di assistenza compresa. Chi mi fa il lavoro al minor prezzo?"

La risposta, Fabrizio, e' tanto semplice: chi ha voglia di sacrificare la propria professionalita' per clienti del genere.

Voglio dire: se fosse la Nasa, potrei anche capirlo, ma non credo che la maggior parte dei clienti che ti impongono le regole che hai citato siano veramente prestigiosi.

 

Il resto è un problema dell'appaltato il quale è libero di agire come meglio crede per arrivare al target.

AH-AH! Allora sei libero di agire come vuoi! E se lo sei, perche' non fare i test? Adesso i clienti cattivi stanno diventando un alibi :)

 

Non escludo che si arrivi a fare contratti "a progetto" (non ne so nulla della parte giuridico/legale per cui passatemi il termine forse non corretto) dove se il programmatore non finisce il progetto per tempo, lo deve portare avanti e concludere gratis, salvo penali. 

Ti rimando ancora da Jacopo: http://www.sviluppoagile.it/ho-avvistato-un-contratto-agile-sano-esistono

E dato che sta anche lui su questa mailing list, potresti chiedergli maggiorni informazioni sui contratti a costo obiettivo. Probabilmente l'argomento ti interesserebbe moltissimo, dato che i contratti tradizionali *non* sono fatti per certe metodologie di sviluppo.

 

La consegna è quella prevista per far funzionare contrattualmente l'applicativo.

 

 

come strumento di supporto al team di programmatori fino al rilascio, ma non come parte integrante dei sorgenti da consegnare anche perché funzionalmente non necessari per l'utilizzo dell'applicativo commissionato.

forse ti piacera' questa lettura http://www.sviluppoagile.it/il-codice-side-effect-un-fastidioso-contrattempo che va a scavare sul concetto di valore generato per il cliente

 

Forse al cliente (vedi sopra) l'unico concetto che interessa si limita al "funziona =ok ; non funziona = è colpa tua e lo ripari di corsa" e il resto non è affar suo????

Li ho visti clienti cosi', per quello non ci lavoro piu' :)

 

 

Al massimo si potrebbero (forse) far ricadere nella "documentazione a corredo"... ma anche lì è difficile......

Non e' documentazione, e' qualita'. Quando il tuo cliente *non vuole* test automatici gli puoi tranquillamente dire che in questo modo otterra' un prodotto (piu') scadente.

La valutazione il cliente la fa sul "funziona/non funziona", non sul "quanto è ben scritto il codice". E' un dato sul quale puoi anche non concordare, ma è oggettivo.

Il problema di fondo, Fabrizio, e' che non ci capiamo su molte cose. Se tu devi fare un sito per un panettiere di quartiere, tutto il tuo discorso ci sta: non esiste futuribilita' sul progetto quindi esticazzi della qualita' - per dirla alla romana.

Ma se lavori su progetti gia' di medie dimensioni, quelli che non durano due settimane, quelli che richiedono manutenzione evolutiva dopo un anno, quelli in cui i requirements sono volatili e dovresti poter stravolgere tutta l'applicazione in due giorni sapendo che ancora funziona (grazie ai test), ecco, se lavori su questi progetti il tuo cliente sa' che la futuribilita' dell'applicazione e' molto, molto importanto.

Se non lo sa, tu stai agganciando i clienti sbagliati.

[Eugenio Pombi]

Fabrizio se i presupposti sono la separazione che delinei tra cliente e chi sviluppa e la burocrazia è quella tra appaltatore a appaltato è chiaro che i margini per migliorare lo sviluppo del software si assottigliano parecchio.

Non è un caso che a sottendere quel tipo di rapporto c'è il vecchio sistema di scrivere documentazione per n pagine, per poi passare a sviluppare per n mesi, per poi vedere se il tutto funziona o non funziona, per poi dare l'inizio ad un tira e molla su come funzionano le cose o avrebbero dovuto funzionare nelle intenzioni di chi mesi prima aveva scritto la documentazione. 

A queste condizioni cercare di migliorare il codice è uno sforzo simile a cercare di far diventare tutte le macchine delle jeep per non riparare le buche sulle strade. Può sembrare privo di senso all'inizio ma se tu hai una jeep poi te ne fotti di come stanno messe le strade.

Fuor di metafora se produci codice di qualità, testato, e ben disaccoppiato, poi dovresti essere in grado di gestire meglio le situazioni più stressanti, e il tempo che impieghi in più a scrivere un test automatico ad inizio progetto te lo ritrovi ben ripagato quando il software va online e ci trovano un decimo dei problemi a cui sono abituati.

Il problema vero è che -e qui regà casca l'asino- quando tu dici che il committente dice:

"mi serve tale cosa entro questo tempo, la penale per i ritardi è quest'altra. Mi devi includere x tempo di assistenza compresa. Chi mi fa il lavoro al minor prezzo?"

in quel "x tempo di assistenza" si partorisce il mostro di cose tipo questa che mi sono sentito dire per davvero:

"a noi non ce ne frega un cazzo dei test. Noi ai clienti vendiamo un prodotto e poi lunghissimi contratti di manutenzione e debugging; non è nel nostro interesse fare software senza buchi perché il grosso del guadagno lo facciamo con la manutenzione".

Se sei in un contesto in cui sviluppi con una dirigenza che ragiona così, o se sei in un contesto in cui fai parte di una entità che permette a gente così di lavorare (magari coi soldi pubblici) è chiaro che se ci tieni a sviluppare software di qualità devi letteralmente scappare :)

ma il mondo in questo senso sta migliorando, sappi che esistono clienti anche grandi che hanno imparato il valore di un software sviluppato a piccole iterazioni, pulito, disaccoppiato, e testato che gli permetta di seguire una rotta dettata dall'esperienza che mano a mano si fa col software invece di dire "mi serve questo ci rivediamo tra tre mesi sennò ti faccio un culo così" :D

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--

Eugenio Pombi
Developer

tel:      +39.329.5455797
mail:    eux...@gmail.com
twitter: @euxpom
skype: euxeux

it.linkedin.com/pub/eugenio-pombi/3b/28b/99a

[Fabrizio Callai]

Temo che abbiamo perso il filo del discorso e credo sia anche da un bel pezzo... 
Cerco di riassumere brevemente e se ci sono state incomprensioni cerchiamo di chiarire prima quelle, poi se è il caso andremo avanti su altro...

Personalmente sono a favore del test-driven.
Questo è però, per la discussione, è insignificante.

Si parlava qualche giorno fa di "lettura del codice" e, in particolare, quello ALTRUI. 

Dopo vari scambi di email siamo approdati, con mio disappunto, a un concetto dove la lettura di "cosa fa un programma" lo si evince dai test.
Il mio personale pensiero è che lo dovrebbe evincere dal codice, considerato che la presenza dei test assieme ai sorgenti non è cosa garantita.

Come ho spiegato la mia situazione è che IO sono il CLIENTE, ma senza possibilità di definire le condizioni contrattuali... divento "programmatore" in alcuni casi in cui vi sia da apportare modifiche a del codice pre-esistente, creato tramite terzi (aziende), ma non si ritiene di dover contrattualizzare ulteriormente fonti esterne.

Visto che contrattualmente NON vengono chiesti i test, è chiaro che NON li ho... viene meno quindi, dal mio punto di vista, che la "lettura del codice" vada fatta partendo dai test, come asserito da qualcuno, ma da altri presupposti.

Ritengo pertanto che la leggibilità di un software debba esser fatta DI BASE "old-style" ovvero "inline", nel sorgente o con documentazione a parte. 

Se poi EVENTUALMENTE ci dovessero essere i test, tanto di guadagnato, ma rimangono concettualmente FACOLTATIVI.

E' chiaro che se mi vogliono fottere basta utilizzare un offuscatore che mi faccia un banale search/replace dei nomi delle classi e dei metodi che vado a gambe all'aria... ma lì sarebbe facile dimostrare la malafede del fornitore lì avrei vita facile a scrivere a chi di dovere.

E' altresì possibile che io non intervenga MAI coinvolto, ma che un eventuale update dell'applicativo venga assegnato ad un'altra azienda aggiudicataria di un nuovo contratto... la cosa concettualmente cambia poco perchè anche essa avrà i miei stessi problemi.

Se sono stato chiaro, riprendiamo da qui.

Ciao

F.

[Fabrizio Callai]

Eugenio, credo che tu abbia capito fin troppo bene il problema... ^_^
Purtroppo io non vedo nessuna delle migliorie di cui parli.... speriamo bene!

Ciao

F.

[Jacopo Romei]

OK, proposta accolta, riprendiamo dal tuo riassunto:

> Visto che contrattualmente NON vengono chiesti i test, è chiaro che NON li ho... viene meno quindi, dal mio punto di vista, che la "lettura del codice" vada fatta partendo dai test, come asserito da qualcuno, ma da altri presupposti.

"è chiaro che NON li ho" non è chiaro affatto!

Qui si sta scambiando un assunto (legittimo magari, ma non necessariamente condivisibile) con un passaggio logico automatico: se non esplicito i test automatici nel contratto non li avrò. Ma questo non mi impedirà di lavorare solo con chi invece me li darà e in modo scontato! Esattamente come valuterò se lavorare con chi scrive codice strutturato o basato su una selva di 'goto' senza per questo parlare di 'goto' nel contratto.

Io (anche da cliente) faccio lavori *solo* con gente che sia scontato mi consegnerà test automatici e scritti pure bene!

Quindi, poiché quel tuo "è chiaro" è premessa del resto del ragionamento, sei qui di nuovo invitato a discutere (se ti va) questo singolo punto prima di procedere oltre.

--

Jacopo Romei

Agile Coach eBay Italia

www.sviluppoagile.it

[Fabrizio Callai]

OK, proposta accolta, riprendiamo dal tuo riassunto:

Grazie ^_^

 

> Visto che contrattualmente NON vengono chiesti i test, è chiaro che NON li ho... viene meno quindi, dal mio punto di vista, che la "lettura del codice" vada fatta partendo dai test, come asserito da qualcuno, ma da altri presupposti.

"è chiaro che NON li ho" non è chiaro affatto!

Qui si sta scambiando un assunto (legittimo magari, ma non necessariamente condivisibile) con un passaggio logico automatico: se non esplicito i test automatici nel contratto non li avrò.

Obiezione accolta ed è logicamente corretta, ma la mia rappresenta un dato di fatto.

 

Ma questo non mi impedirà di lavorare solo con chi invece me li darà e in modo scontato!

Errato. Non sono nelle condizioni di scegliere. La gara si vince per specifiche e al ribasso sui costi (ergo su materiale fornito e tempi di lavorazione). 

Io posso richiedere un prodotto (es. un CMS, un sistema per fare le pizze, ecc. ecc.) ma non posso vincolare a darmi materiale non indispensabile al funzionamento del sistema stesso, perchè alzerebbe i costi.

Se alla domanda "è possibile modificare il software senza avere i test?" la risposta è "si", allora non posso inserirle come obbligo.

Punto.

 

Esattamente come valuterò se lavorare con chi scrive codice strutturato o basato su una selva di 'goto' senza per questo parlare di 'goto' nel contratto.

Io (anche da cliente) faccio lavori *solo* con gente che sia scontato mi consegnerà test automatici e scritti pure bene!

Evidentemente sei nelle condizioni di poterlo fare. Io no. :(

 

Quindi, poiché quel tuo "è chiaro" è premessa del resto del ragionamento, sei qui di nuovo invitato a discutere (se ti va) questo singolo punto prima di procedere oltre.

Ovvio che mi va. Stiamo facendo un confronto civile...

 

--

Jacopo Romei

Agile Coach eBay Italia

www.sviluppoagile.it

Ciao 

[Jacopo Romei]

> Evidentemente sei nelle condizioni di poterlo fare. Io no. :(

Operiamo in mercati diversi? Siamo abitanti di pianeti lontani? Viviamo in due universi paralleli? :-)

Cmq OK, non insisto.

Fabrizio, sarai al PHPDay sabato pomeriggio?

[Fabrizio Callai]

> Evidentemente sei nelle condizioni di poterlo fare. Io no. :(

Operiamo in mercati diversi?

Teoricamente il "mercato è unico"... ma ho l'impressione che io e te operiamo con regole diverse ;-)

In generale vale la legge che più un'organizzazione è grande, tanto più è refrattaria al cambiamento... valutalo ;-)

 

Siamo abitanti di pianeti lontani? Viviamo in due universi paralleli? :-)

Cmq OK, non insisto.

Credo molte cose le possa capire leggendo l'email di eux (Eugenio).... qualcosa mi dice che lui ha vissuto la mia realtà (o qualcosa di molto simile)....

@Eugenio, in merito al tuo "se ci tieni a sviluppare software di qualità devi letteralmente scappare" Sara *SA* che sto provando a farlo... fatti raccontare qualcosa da lei ;-)

Il problema è che devo recuperare (parecchio?) in certi settori.... sto cercando di capire "quanto" e "cosa"....

 

Fabrizio, sarai al PHPDay sabato pomeriggio?

No caro, avremo modo di conoscerci e parlare in qualche altra occasione :-)

Ciao

[Alessandro Nadalin]

2013/5/16 Fabrizio Callai <f.ca...@gmail.com>

> Evidentemente sei nelle condizioni di poterlo fare. Io no. :(

Operiamo in mercati diversi?

Teoricamente il "mercato è unico"... ma ho l'impressione che io e te operiamo con regole diverse ;-)

In generale vale la legge che più un'organizzazione è grande, tanto più è refrattaria al cambiamento... valutalo ;-)

l'hai detto ad uno che lavora ad eBay :-D

[Fabrizio Callai]

Mavvà ^_^

[Fabrizio Callai]

Intendo "lascia perdere".

eBay è un'altra realtà rispetto la mia.... molto diversa per tanti motivi.....

Il giorno giovedì 16 maggio 2013 16:26:53 UTC+2, Fabrizio Callai ha scritto:

Mavvà ^_^

[Jacopo Romei]

Fabrizio mi ha chiamato al telefono. :-)

Con grande senso di sintesi, riporto qui solo che la discussione per ora è in "stand by", perché al mio appunto "ma non potrebbe [la committenza pubblica] includere nelle gare di appalto una regola relativa alla documentazione in formato *eseguibile* (leggasi 'test automatici')?" Fabrizio stesso non ha saputo negare questa chance con certezza, ripromettendosi di investigare in tal senso.

A prescindere dall'esito della sua investigazione, però, quello che vorrei fosse già emerso da questo lungo scambio è che è molto diverso dire

"Da noi non si può fare"

e dire

"Non sono ancora riuscito a trovare un modo di farlo da noi"

*perfino* a parità di insuccesso nella stessa unità di tempo.

Ciao!

--

Jacopo

2013/5/16 Fabrizio Callai <f.ca...@gmail.com>

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

[Fabrizio Callai]

Intervengo solo per dire: ottima sintesi.

Buona giornata

[Alessandro Nadalin]

2013/5/16 Fabrizio Callai <f.ca...@gmail.com>

Intervengo solo per dire: ottima sintesi.

+971 55 7627451

Se c'hai coraggio de menatte co telecom per la bolletta poi

A parte gli scherzi, viva il dialogo :)

 

Buona giornata

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_

[Yari Serra]

Suggerirei l'utilizzo di skype :)

Yari Serra

[Fabrizio Callai]

ahhhhhh... io l'ho chiamato... sul cellulare!!!!
Mi ha risposto con voce impastata, sentivo schiamazzi di fanciulle e rumore di tappi di spumante che salvano, non vi dico poi la musica a palla..... dice che lavora, LUI...... secondo me la chiamata viene reindirizzata da qualche parte in un girone infernale dove non esiste nè OOP nè TDD ma solo quanto sopra descritto... :D

Buona serata

[Fabrizio Callai]

"tappi di spumante che saltavano"

...fra poco sto pc lo frullo giù dal balcone....

Ariciao

[liuggio]

bellisima conversazione sull'aspect oriented programming.

2013/5/17 Fabrizio Callai <f.ca...@gmail.com>

"tappi di spumante che saltavano"

...fra poco sto pc lo frullo giù dal balcone....

Ariciao

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--
 __________________liuggio_________________________________
 
  __/|_      We reject kings, presidents and voting.
/o )   \/    We believe in rough consensus
)__ v _/\          and running code  (I.E.T.F. credo)
______________________________________________________________

[Alessandro Nadalin]

Giuro che ha chiamato veramente, e m'ha pure svegliato :-)

Altro che programmazione orientata agli aspetti, questa proprio non me la sarei aspettata :-P

[Fabrizio Callai]

...ed erano le 10:15... ora locale (tua), non lo dici???? E' così che si lavora???? :D
Ah ho capito: è l'"aspetto del programmatore sdraiato"....

...inisto che era in compagnia, musica e spumante.... mi pare addirittura di aver sentito in sottofondo qualcosa tipo "alla faccia di quelli del PUG di Roma"....

^____________^