Rss Aggregator e Refactoring Game

Federico Lunardi ha contribuito con un suo aggregatore RSS, ben
funzionante ma non ancora rifattorizzato.

Ho pensato potrebbe essere divertente e educativo fare un esercizio di
refactoring collettivo, elencando e giustificando i refactorings.

La versione originale è puntata da:
http://ruby-it.org/pages/Aggregatore+RSS

Da lì punto a una mia versione modificata, dove giustifico alcuni
cambiamenti fatti.
Non si tratta volutamente della versione finale, ma ho fatto alcuni
cambiamenti che rendono ancora possibile passare dal primo al secondo
codice senza problemi.

Se volete raccogliere la ‘sfida’ potete continuare sia dal mio codice
che dall’originale se non vi piaciono i miei refactorings…

Possiamo usare la mailing list per dichiarare su cosa stiamo lavorando…

passo la palla.
chi la prende?


Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

vedo su ruby-it che il refactoring è cominciato :slight_smile:

On 5/3/06, chiaro scuro [email protected] wrote:

Federico Lunardi ha contribuito con un suo aggregatore RSS, ben

Ho pensato potrebbe essere divertente e educativo fare un esercizio di
refactoring collettivo, elencando e giustificando i refactorings.

La versione originale è puntata da: http://ruby-it.org/pages/Aggregatore+RSS

passo la palla.
chi la prende?


Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

Alle 02:28, mercoledì 3 maggio 2006, chiaro scuro ha scritto:

Federico Lunardi ha contribuito con un suo aggregatore RSS, ben
funzionante ma non ancora rifattorizzato.

Ho pensato potrebbe essere divertente e educativo fare un esercizio di
refactoring collettivo, elencando e giustificando i refactorings.

ehm ehm ehm… è vero che mi vergogno un po’ del mio codice come avevo già
detto in email precedenti, ma non così tanto da dover usare un nome
falso :-))
Il nome giusto è Francesco L…
A parte questo, sono felice che il mio codice venga strizzato sminuzzato
ritoccato fino a trasformarlo in qualcosa di decente, così forse un po’
alla
volta imparerò anch’io a programmare.
Ciao a tutti
P.S. Se vi serve codice funzionante ma orribile ne produco parecchio
temo :smiley:

Che figuraccia ho fatto! :frowning:

Ecco cosa succede a lavorare di notte.
Scusami, non so come sia potuto accadere… ma si ho capito.

è imbarazzante… stavo scrivendo a Federico F. e vi siete magicamente
fusi… francesco lunelli è diventato un Federico Lunardi!

Alle 11:46, giovedì 4 maggio 2006, chiaro scuro ha scritto:


Chiaroscuro

Non preoccuparti, può succedere :slight_smile:
Volevo solo che il mio codice non fosse imputato a persone innocenti :slight_smile:
ciao
Francesco L.

Questo fa il paio con quando Roberta (qui in lista) ho iniziato con
convinzione a chiamarla Rosa. Deve essere una forma tutta personale di
dislessia.

Questo fa il paio con quando Roberta (qui in lista) ho iniziato con
convinzione a chiamarla Rosa. Deve essere una forma tutta
personale di
dislessia.

Quando comincerai a chiamare “Perl” il Ruby, allora cominceremo a
preoccuparci :slight_smile:

alf

On 5/2/06, chiaro scuro [email protected] wrote:

Se volete raccogliere la ‘sfida’ potete continuare sia dal mio codice
che dall’originale se non vi piaciono i miei refactorings…

Possiamo usare la mailing list per dichiarare su cosa stiamo lavorando…

Visto che si tratta di un esperimento di gruppo, mi permetto due
appunti:

  • Il codice, per quanto intuitivo, non è commentato
  • Non vedo test cases

Magari chi ha un po’ di tempo libero, può lavorare anche su questi aspetti
che ritengo comunque importanti.

Ciao, :wink:
Antonio

My Ruby blog: http://www.antoniocangiano.com
My .NET Community: http://www.visualcsharp.it

Io ho aggiunto tutte le basi per fare un mock del caricamento delle
pagine,
non voglio togliere a nessuno il gusto di implementarlo :slight_smile:

Antonio, per quanto riguarda i commenti cosa intendi? in quale
‘filosofia
dei commenti’ credi tu? io cerco di vedere i commenti come indizio che
altro
refactoring è necessario.

On 5/5/06, Antonio C. [email protected] wrote:


Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

On 5/5/06, chiaro scuro [email protected] wrote:

Io ho aggiunto tutte le basi per fare un mock del caricamento delle
pagine,
non voglio togliere a nessuno il gusto di implementarlo :slight_smile:

:slight_smile:

Antonio, per quanto riguarda i commenti cosa intendi? in quale
'filosofia

dei commenti’ credi tu? io cerco di vedere i commenti come indizio che
altro
refactoring è necessario.

Non ho opinioni troppo forti in merito, cerco di far prevalere il buon
senso.
Credo sia importante inserire dei commenti anche se il codice e’
leggibile
e ben refactored. Non dico di scrivere poemi. Commenti succinti… :wink:

Antonio

My Ruby blog: http://www.antoniocangiano.com
My .NET Community: http://www.visualcsharp.it

mi sono accorto che forse il mio tono suonava polemico.
scusami. a volte le email non vengono come le pensi.

sono seriamente interessato alla tua opinione sulla ‘filosofia dei
commenti’.

la dottrina xp dice di evitarli (in retorica questo si chiama
‘argomento per autorità’ :wink: e quindi volevo capire quale fosse la tua
regola. mi interessano molto questi argomenti “soft” della
programmazione.

On 5/8/06, Antonio C. [email protected] wrote:

e ben refactored. Non dico di scrivere poemi. Commenti succinti… :wink:

Antonio

My Ruby blog: http://www.antoniocangiano.com
My .NET Community: http://www.visualcsharp.it


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

Rimane però l’argomento (questa volta serio e non retorico) che se il
codice ha bisogno di commenti allora è troppo complicato e necessita
refactoring.

Io in questo mi ritrovo abbastanza perchè mi scopro a commentare
soprattutto quando mi si è incasinato il codice.

Un punto in cui non riesco a fare a meno di commentare è quando vado
sull’algoritmica. Poca struttura a oggetti e molti loop, if, etc…

Credo bastino dei semplici commenti per chiarire il significato di
alcune
parti del codice.
Mettendomi nei panni di un utente che vede per la prima volta il codice
mi
piacerebbe vedere qualche comento che mi spieghi che cosa fanno le due,
tre
righe di codice sottostante :slight_smile:

Dopotutto si tratta di un gioco, quindi la programmazione agile la
possiamo
anche snobbare :stuck_out_tongue:
L’imporatante in queste situazioni è far entrare nel gioco più persone
possibili.

–Andrea R.

Il giorno lun, 08/05/2006 alle 16.47 +0200, chiaro scuro ha scritto:

mi sono accorto che forse il mio tono suonava polemico.
scusami. a volte le email non vengono come le pensi.

sono seriamente interessato alla tua opinione sulla ‘filosofia dei commenti’.

la dottrina xp dice di evitarli (in retorica questo si chiama
'argomento per autorità ’ :wink: e quindi volevo capire quale fosse la tua
regola. mi interessano molto questi argomenti “soft” della
programmazione.

Attenzione: la “dottrina” XP dice di evitare i commenti inutili. Se il
commento serve per spiegare le tre righe successive, allora in genere si
è in una di queste due situazioni:

  • il codice è inutilmente complesso, e va sostituito con qualcosa di più
    semplice che non richieda commenti per essere compreso.
  • il codice andrebbe isolato in un metodo a parte che abbia un nome
    significativo
    . A quel punto, è il nome stesso del metodo a fare da
    commento :wink:

I commenti utili, invece, sono ammessi. Ma spesso i test unitari, se
scritti bene, possono comunicare meglio che non il commento stesso.

La pagina http://c2.com/cgi/wiki?MethodCommenting riporta su un po’
di… commenti sui commenti.

Ciao,

	Giovanni

Io ho dato i miei 2c per iniziare a coprire di test il codice che abbiam
fatto finora.
Il prossimo refactoring che vorrei fare è quello di spostare la dipendenza
al loader nel costruttore per esplicitarne l’obbligatorietà (vedi
anche
quihttp://martinfowler.com/articles/injection.html#ConstructorVersusSetterInjection
).

Ciao!
Antonio

Che lavorone! complimenti. altro che 2c.
Quando ho un pò di energia mi ci metto.

Mi chiedo, potremmo mettere uno zip con i sorgenti da qualche parte.
Non
vedo come fare uploads al wiki, ma forse possiamo usare qualche altro
posto
in rete… idee?

Antonio, tu proponi di mettere la dipendenza nel costruttore, ma io non
ne
sono così sicuro. l’ho lasciata esterna apposta, per poter avere un
default
‘leggero’, che non necessita di specificare il tipo di loader, con in
più
la
possibilità di specificarlo se necessario.

Ho usato il termine ‘inject!’ per rendere esplicito il fatto che si
tratti
di un’azione in qualche modo artificiosa…

In java ho sempre fatto come proponi tu, ma qui mi sembrava più rubesquo
avere un costruttore semplice semplice che coprisse la maggioranza dei
casi. Ho seguito più che altro una sensazione di pancia.

Tu cosa ne pensi?

On 5/8/06, Antonio C. [email protected] wrote:

Ciao!

di… commenti sui commenti.


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Chiaroscuro

Liquid Development: http://liquiddevelopment.blogspot.com/

è piuttosto interessante. questa sera me lo leggo e poi commento al
tuo commento sui commenti.

Beh anch’io sono fortemente influenzato da linguaggio con cui lavoro
(c#) ma
l’ho proposto perchè per me è stato un punto di arrivo per riuscire ad
applicare TDD con il minor numero di frizioni possibili.
Devo dire che da questo piccolissimo esempio ho potuto apprezzare con
quanta
facilità sia possibile stubbare in ruby, no need of intefaces, prendi il
metodo che ti serve, lo stubbi e voilà, un incubo che avevo/ho nello
stubbare oggetti con interfaccie era di dover implementare tutto anche
quello che non mi serviva creando tantissimo rumore intorno.

Cmq tornando alla tua domanda, mi sta bene tenere il metodo per
iniettare lo
stub ed avere un default, penso che crei proprio un pelino di rumore
nella
classe (ma spesso sono soltanto mie pippe mentali).

Avanti col mal di pancia! Ahem… no dai così fa proprio brutto! :stuck_out_tongue:

Avanti con le ispirazioni!

— Antonio C. [email protected] ha
scritto:

mh… scusate ma provo a infilarmi anche io che
finalmente ho un momento libero… avrei una idea
semplice semplice che non posso provare in quanto non
ho un proxy… eliminando l’uso di “basso livello” di
Net::HTTP e passando direttamente ad open-uri possiamo
semplificare il codice e la gestione del proxy diventa
implicita (basata sulla variabile d’ambiente
http_proxy, he � una convenzione comune a molte
cose)

Inoltre mi sono perso un passaggio: perch� per le
regex usiamo dei metodi invece di semplici costanti?
Patch allegata con cambiamenti suddetto :slight_smile:


icq: #69488917
blog: http://riffraff.blogsome.com

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com

On 5/9/06, gabriele renzi [email protected] wrote:

— Antonio C. [email protected] ha
ho un proxy… eliminando l’uso di “basso livello” di
Net::HTTP e passando direttamente ad open-uri possiamo
semplificare il codice e la gestione del proxy diventa
implicita (basata sulla variabile d’ambiente
http_proxy, he � una convenzione comune a molte
cose)

si potrebbe, ma non è un pò barare, così? :wink:

a me è piaciuto molto anche il ducktyping di massimiliano nell’ultima
versione!
è bello vedere uscire queste cose perchè a chi ha ancora istinti java
non
sempre viene naturale… ti muovi all’interno di un’interfaccia che è
solo
‘mentale’, non esiste… e ti poni limiti artificiali. come un koan zen
che
mi hanno fatto una volta sul fenicottero nella bottiglia (ma che ci fa
un
fenicottero in un bottiglia?)

Inoltre mi sono perso un passaggio: perch� per le
regex usiamo dei metodi invece di semplici costanti?
Patch allegata con cambiamenti suddetto :slight_smile:

mi viene + naturale estrarre metodi al primo colpo. lì sono poi rimasti.
come giustificazione postuma posso dire che ho il sospetto che come
variabili sarebbero meno distinguibili/isolati visivamente.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs