Newsgroup: it.lavoro.informatica
Titolo: the world goes-lang

pare che in futuro si parlerà go-lang: 



http://bit.ly/1EaRYc5




poi è pure vero un altro fatto... avevo un amico che programma in 4GL e 

visto che i programmatori 4GL a piede libero sono meno dei quadrifogli 

lilla si poteva permettere il lusso di andare ai colloqui anche in 

mutandoni e con la canna accesa in bocca. 



Laonde e per cui, fintanto che i programmatori RPG e Cobol continueranno 

ad essere un numero esiguo, potranno sfamare anche loro le loro famiglie. 



-- 

Massimiliano Adamo



ma vai a cagare, pirla!

popularity non vuol mica dire piu usato!



-- 

(..) la rivoluzione non è un pranzo di gala, non è una festa letteraria, 

non è un disegno o un ricamo; non si può

fare con tanta eleganza, con tanta serenità e delicatezza, con tanta 

grazia e cortesia. La rivoluzione è un atto

di violenza, è l'azione implacabile di una classe che abbatte il potere 

di un'altra classe. (Mao Tze-tung)


 popularity non vuol mica dire piu usato! 



ti ho detto che sei a rischio disoccupazione e adesso ti brucia il 

peperone!! :) 





-- 

Massimiliano Adamo


 ha scritto nel messaggio 

news:md2a4i$q80$3...@dont-email.me...


ma vai Cagare, babbeo !



ciao

fm 






 
http://bit.ly/1EaRYc5




Mi pare una stronzata di classifica :)

A parte che non dici da dove sono estratti quei dati.



le classifiche sono mediamente *tutte* stronzate, questa inclusa e 

nessun'altra esclusa. Ma vuoi mettere che in una classifica dove compare 

addirittura Pascal, il Cobol non compare nemmeno dietro a bash? Dovevo 

pubblicarla per forza :) 





-- 

Massimiliano Adamo


 nessun'altra esclusa.



Scusa, ma se pubblichi una semplice immagine, senza dare alcuna fonte, a me questa sembra molto piu` stronzata delle altre :) Le classifiche possono non essere affidabili, ma qualcuna puo` essere piu` affidabile di altre. 


 Scusa, ma se pubblichi una semplice immagine, 



non l'ho estrapolata. L'ho trovata così su linkedin e anche io stavo per 

chiedere a quell'utente qual è il senso di una immagine estrapolata in 

quel modo. 

Ma non dargli troppo peso... è una cosa alla Deltì. Punto: tutti usano go-

lang convertiti finché sei in tempo!! 



p.s.: in alternativa, SERIO, i contesti per quella immagine trovali tu. Io 

ho veramente sentito parlare parecchio sulle possibilità di diffusione di 

questo linguaggio... in fondo stiamo parlando di Google, mica di 

Microfocus :) 



-- 

Massimiliano Adamo


 mica di Microfocus :)



ciò non vuol dire che io nutra simpatie per google o viceversa o qualsiasi 

altra cosa. 







-- 

Massimiliano Adamo


 Microfocus :) 



hai cinque anni di ritardo.



era il 2010 quando feci una valutazione in quanto pareva dovesse diventare

il linguaggio di punta dell'app engine. poi non se n'è saputo più nulla, 

ne del golang e ne dell'app engine.



vorrei proprio sapere oggi dov'è che ne senti parlare, addirittura

parecchio.





credimi se ti dico che a me della programmazione per il momento mi importa 

veramente poco. 

Casomai dovesse tornarvi utile, a livello di coding questo è il massimo 

che ho fatto in vita mia: 
http://bit.ly/17LyYEx




a tempo perso creo classi puppet, template erb... poca roba tutto sommato, 

ma non guadagno nemmeno poco con il lavoro che faccio. Ciò non vuol dire 

che non stia pensando di imparare altro ... ma di sicuro non Cobol :)



-- 

Massimiliano Adamo


 che ho fatto in vita mia: 
http://bit.ly/17LyYEx




ergo... roba di quel livello ne faccio a bizzeffe tutti i giorni, ma per 

queste cose un linguaggio semplice ed efficace come python BASTA e AVANZA. 

Oppure dici che dovrei usare Cobol? 



-- 

Massimiliano Adamo


 che ho fatto in vita mia: 
http://bit.ly/17LyYEx




Brrr....


 veramente poco. 



quindi deduco di aprire questa discussione te l'abbia prescritto il

dottore.



devo dire che ultimamente questo posto fa particolarmente buca.



si è una lista lunga che non finisce mai. Non ho usato classi. Fa cagare 

abbastanza, ma era appunto l'esempio di quanto *non* sono bravo. 

Per il resto: 

1. funziona. Credimi.

2. è roba di un 8 mesi. ho ricevuto una sola segnalazione di bug per una 

versione beta di galera che ho già chiuso un mese fa (l'ultimo commit).

2. sono ottimista. Continuo ad imparare in continuazione e confido nel 

fatto che diventerò più bravo. 





-- 

Massimiliano Adamo


 dottore.



avrai qualcosa su github,bitbucket,sourceforge,ndotepare da mostrar anche 

tu immagino ... 



-- 

Massimiliano Adamo


 



leggi la mia risposta (capirai bene che non mi vanto molto): 

https://github.com/maxadamo/galera-wizard/issues/1






-- 

Massimiliano Adamo


 tu immagino ... 



e di preciso a che giochino vorresti giocare? no perché quel link che

hai passato l'ho cacato meno di zero, non è che il codice di chi non

glie ne frega nulla della programmazione abbia molti motivi di interesse.






 ad essere un numero esiguo, potranno sfamare anche loro le loro famiglie. 



Hai usato il termine giusto, sfamare. Ma con un pugno di riso ed un pò di acqua di fiume, assolutamente niente di più :-)


On Monday, 2 March 2015 22:23:50 UTC, Max_Adamo  wrote:



<snip>



Altre puntate de "La vita di Massimiliano Adamo" previste per il futuro?

E` molto interessante.







ho capito...

fai parte di quelli che vogliono la fattura per far vedere il proprio codice.



Hai cliccato, hai guardato e hai scritto 'brrr'. Mi pare che fin qui ti sei 

interessato abbastanza.




Ah no? E cosa vuol dire? Che se ne parla nei salotti bene e nei talk-show?

O intendi usato-sicuro? Che potrei anche essere d'accordo: meglio un 

programming language nuovo di uno usato, anche se usato-garantito.


 fai parte di quelli che vogliono la fattura per far vedere il proprio codice.



casomai chiederò i soldi, mica le fatture <grin>



in ogni caso il mio codice su github è pubblico e visibile, semmai quello 

che non voglio fare è tirarlo in ballo in discussioni alla pene di segugio.

non ti torna?


 Hai cliccato, hai guardato e hai scritto 'brrr'.



E` perche` sono un inguaribile ottimista e mi auguro sempre che la gente impari a scrivere il codice. Rimango puntualmente deluso.





Andrea, per quale ragione dovrei imparare a scrivere codice, poniamo caso Java? 

Per guadagnare 40K adesso e 60K quando diventerei senjor? :)

Non sono motivato economicamente, ma lo faro' comunque per altre ragioni e 

perche' sento che le mie conoscenze zoppicano in alcuni campi. 

Ci sono tantissimi sistemisti che lavorano tutta la vita conoscendo solo bash 

e ne ho conosciuti alcuni che addirittura non sapevano nemmeno scrivere uno 

script shell. Per questo ti dico: non sento la necessita' ....





tuttavia, l'altro giorno si e' rotto un 'cazzillo' ed un collega ha risolto 

scrivendo al volo un plugin PAM in C in 15 minuti. In quel momento ho provato 

una sana invidia nei confronti del mio collega e mi sono reso conto che mi

farebbe piacere acquisire quelle conoscenze. 





mi torna: stai facendo una discussione a pene di segugio e non vuoi tirare in

ballo il tuo codice. 

dai rootkit faccelo vedere il tuo codicillo ;) Vuoi vedere che aveva ragione 

Albanese e ti vergogni a farcelo vedere... dacci 'sto link.


 script shell. Per questo ti dico: non sento la necessita' ....



Ognuno e` libero di scegliere di restare mediocre.


 No, perche` ad un codice scritto bene corrisponde quasi sempre un sistema che funziona bene, e lo scopo principale di uno sviluppatore dovrebbe essere quello di creare sistemi che funzionano, a beneficio di chi li usa. 



Parto dal principio: sono d'accordo in linea generale con te. Però ora son curioso: che intendi per 'codice scritto bene'? Hai qualche esempio da citare, anche non tuo?



-- 

Ciao!

Luca


 



Per scala basta che prendi un qualsiasi progetto famoso su github (ad es. il codice sorgente del linguaggio stesso: 
https://github.com/scala/scala
) . Magari può anche essere contestabile su qualche scelta ma è sempre scritto meglio rispetto a come lo scriverebbe un qualsiasi principiante.

Poi credo sia così per tutti i linguaggi.




 'codice scritto bene'? 



http://www.amazon.co.uk/Robert-Martin-Clean-Code-Collection-ebook/dp/B00666M59G/ref=sr_1_3?ie=UTF8&qid=1425389099&sr=8-3&keywords=clean+code




http://www.amazon.co.uk/Test-Driven-Acceptance-Java-Developers/dp/1932394850/ref=sr_1_7?ie=UTF8&qid=1425389225&sr=8-7&keywords=test+driven+development




http://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627/ref=sr_1_9?ie=UTF8&qid=1425389225&sr=8-9&keywords=test+driven+development




http://www.amazon.co.uk/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_4?ie=UTF8&qid=1425389099&sr=8-4&keywords=clean+code




http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672/ref=sr_1_7?ie=UTF8&qid=1425389099&sr=8-7&keywords=clean+code




...e cosi` via. Non credo che si debba spiegare ad uno sviluppatore attempato cosa "codice scritto bene" significhi. Dovrebbero essere concetti che ogni sviluppatore con un po' di anni di esperienza alle spalle, conosce gia`.






 famiglie.



sta classifica la vedo almeno da diec'anni e ancora il Go non se lo 

incula nessuno, tranne che il meraviglioso gioco da tavola giapponese 



-- 

Soprano


 ...e cosi` via. Non credo che si debba spiegare ad uno sviluppatore attempato cosa "codice scritto bene" significhi. Dovrebbero essere concetti che ogni sviluppatore con un po' di anni di esperienza alle spalle, conosce gia`.



OK. Però volevo un esempio, una ricerca su Amazon son capace di farla anch'io.

Voglio dire, se il codice di Max è criticabile - e in effetti ci sarebbe parecchio da dire, anche se funziona è abbastanza 'sfoltibile' - posta un esempio qualsiasi di codice scritto bene 'secondo te'.

NOTA: concetti a parte, la mia esperienza dice che la percezione di 'codice scritto bene' può anche variare.


 Albanese e ti vergogni a farcelo vedere... dacci 'sto link.



Personalmente non ho nessun problema a farti vedere il mio codice.

Qui: 
https://bitbucket.org/andrealaforgia/jbasic8000-public


trovi un repository pubblico per un interprete BASIC-8000 (quello che girava su Olivetti M20). E` un recursive-descent parser (non uno shift-reduce) ma fa il suo lavoro di parsing egregiamente, per quel che mi serve. Il codice e` ancora in costruzione (alcune classi sono ancora inefficienti e probabilmente molta roba verra` radicalmente cambiata).




 NOTA: concetti a parte, la mia esperienza dice che la percezione di 'codice 

scritto bene' può anche variare.



Se e` "concetti a parte", la nozione di "codice scritto bene" non ha senso.




 Soprano



in realtà il grafico deriva da un contest fatto l'anno scorso dove si poteva utilizzare uno di quei linguaggi per risolvere i vari problemi posti (in ambito gaming).


 trovi un repository pubblico per un interprete BASIC-8000 (quello che girava su Olivetti M20). E` un recursive-descent parser (non uno shift-reduce) ma fa il suo lavoro di parsing egregiamente, per quel che mi serve. Il codice e` ancora in costruzione (alcune classi sono ancora inefficienti e probabilmente molta roba verra` radicalmente cambiata).



Gia' il logger mi sembra alquanto inefficiente ;D


 Gia' il logger mi sembra alquanto inefficiente ;D



Ma vai a cagare :)




 Ma vai a cagare :)



Eh, la System.out rallenta un casino.


On Tuesday, 3 March 2015 15:39:59 UTC, Diego  wrote:



[...]



E` uno stub (come molta altra roba). Il vero logger verra` dopo. 





e dai diciamolo, ci saremmo aspettati che chi critica il codice altrui avesse detto: "ecco come di sviluppa! Guarda il mio codice su github..." :) 

invece c'e' rootkit che per farti vedere il suo codice vuole emettere 

fattura, andrea che se la tira e l'altro che ti dice che non va bene perche' 

hai dimenticato a inserire il caps-lock e a scrivere 01, 02, 03 all'inizio di

ogni riga :)


 ogni riga :)



Eh?!





uhm a me pare di vederlo in giro da un sacco di tempo quel grafico, ma 

puo' essere che mi sbaglio



-- 

Soprano


 Se e` "concetti a parte", la nozione di "codice scritto bene" non ha senso.



Non è vero, però c'è una cosa vera: non mi sono spiegato bene.

Esiste una concezione generale di 'scritto bene'. Poi ci sono alcune (per carità, lievi) differenze. Ti faccio un esempio, così capisci cosa intendo.

In generale, in Python meno è meglio: più conciso sei, più sei leggibile. Io trovo invece che in un ambito in cui qualcuno il mio codice lo dovrà manutenere, magari tra un paio d'anni, essere un pelo più prolissi (ove la prolissità è cosa voluta e studiata) sia opportuno.


 In generale, in Python meno è meglio: più conciso sei, più sei leggibile. 



Non e` propriamente cosi`. Se riesci ad essere conciso, senza perdere in leggibilita`, scegli questa strada. Ma questo vale per TUTTI i linguaggi. Python, poi, e` un linguaggio che ha un livello espressivo superiore a quello dei linguaggi di terza generazione. E` facile che tu scriva in una riga quel che in altri linguaggi scriveresti in 5 o 6. Ma non significa che piu` criptico sei, meglio e`. La prolissita`, a volte, puo` essere davvero odiosa. 


 Non e` propriamente cosi`. 



Lo so. non ho messo 'in generale' a caso... ;)



-- 

Vale!

Luca


 Eh?!



il cobol di deltì. 





-- 

Massimiliano Adamo


 Vedi che non hai capito? 



Secondo me sei tu che non hai capito. I concetti alla base della buona scrittura del codice sono sempre gli stessi: chiarezza, concisione, leggibilita`, organizzazione, separazione delle responsabilita`, progettare per interfacce, eccetera, eccetera, eccetera (anche solo se si applicasse un paio di principi S.O.L.I.D. esposti da Fowler nel suo libro, e un paio di concetti espressi da Martin nel suo, il codice in giro sarebbe molto migliore). Non si possono escludere questi concetti, quando si parla di buona scrittura del codice. Non c'e` una visione soggettiva della buona scrittura del codice, per il semplice fatto che il codice scritto da uno sviluppatore e` letto da altri, quindi necessariamente la buona scrittura e` oggettiva.


 Secondo me sei tu che non hai capito. 



Ma Santippe, era una battuta! Ci ho messo pure lo smiley! Che devo fare, aggiungere i sottotitoli?



E, prima che tu dica qualcosa, era una battuta su quel che ho scritto io all'inizio: come posso pensare che qualcuno capisca quel che ho scritto?


 Ma Santippe, era una battuta!



Non puoi scrivere stronzate e chiamarle battute :)



(ci ho messo lo smile)


 ballo il tuo codice. 



si si, ok. è come dici te.



la voglia di reagire alle tue provocazioncine infantili è pari solo

a quella di prendermi a picconate sulle rotule.


No. Però posso scrivere una stronzata incomprensibile, rendermene conto e farci sopra una battuta. Sono molto avanti, io! ;)



allora forse sapete spiegare cosa significa. non sapendo cosa ci sia

in ascissa, in ordinata e ne cosa rappresenti la dimensione delle

palle non capisco come si possa interpretare.

tanto ho visto chiedere all'op mi pare tempo perso.




 tanto ho visto chiedere all'op mi pare tempo perso.



La dimensione della palla è la frequenza con cui è stato scelto il linguaggio, in ordinata invece c'è la media del punteggio ottenuto nel contest. Si ottiene quindi la media dei risultati del contest diversificati per linguaggio di programmazione.

Poi sono semplicemente ordinati sull'asse 'x' rispetto al risultato ottenuto.


 script shell. 



E magari alzano i loro 50-60000 dollari come niente. E poi contesti il Cobol... :-))





E certo, tutti sono buoni a riempire i programmi di "stub momentanei, che poi verrà il codice scritto bene" :-) 








questi concetti in effetti si applicano molto bene a un linguaggio

orientato agli oggetti come il java, che io uso per lavoro.

Però io all'elenco aggiungerei anche i commenti, che spesso

possono essere utili se devi leggere e interpretare codice

scritto da altri, o anche codice scritto da te molto tempo fa

(che tutto sommato non fa poi molta differenza).



Soprattutto per programmi lunghi e complessi: ok progettare bene

le classi e i metodi, e dare loro dei nomi il più possibile

"parlanti", così quando vedi una classe o un metodo già dal nome

capisci quale funzione svolgono: ma mettere ogni tanto, senza 

esagerare, un po' di commenti che riassumono brevemente cosa

fa il programma, è secondo me di molto aiuto, soprattutto

se poi c'è da fare manutenzione e/o cambiare delle funzionalità.



E, almeno a quanto vedo io, non è che ci si preoccupa molto

di mettere dei commenti in mezzo al codice, parlando in generale.




 E certo, tutti sono buoni a riempire i programmi di "stub momentanei, che poi verrà il codice scritto bene" :-)



Non hai guardato il codice a quel link.

E` evidente che quella classe in particolare e` uno stub. Non fa niente di particolare e a nessuno verrebbe in mente di scrivere un logger del genere (anche perche` si potrebbe usare il logging predefinito di Java). Al link che ho postato, esiste un progetto con decine di classi concrete.

La prossima volta parla con cognizione di causa :)




 La prossima volta parla con cognizione di causa :)



Ok, allora ci avviserai quando hai finalmente rilasciato l'intero progetto con "codice scritto bene", mi raccomando :-))


 Ok, allora ci avviserai quando hai finalmente rilasciato l'intero progetto con "codice scritto bene", mi raccomando :-))



Gran parte del progetto e` gia` li`, e se tu fossi meno stupido di quanto sei, te ne saresti accorto. Sei il solito coglione da it.lavoro.informatica che scrive tanto per scrivere, sparando cretinate, ma io ti perdono :)




 Però io all'elenco aggiungerei anche i commenti[...]



L'utilizzo sensato (e qui si potrebbe aprire un dibattito di giorni) dei commenti e` uno dei punti trattati da "Clean Code" di Martin. A mio parere, i commenti sono un'arma a doppio taglio: non devono servire da alibi al codice di merda (per la serie, "tanto lo commento"), non devono essere troppo invasivi al punto da intralciare la lettura del codice, ma andrebbero limitati a spiegare il funzionamento di una parte di codice. In sostanza, non il "cosa" ma il "come". 


 L'utilizzo sensato (e qui si potrebbe aprire un dibattito di giorni) dei commenti e` uno dei punti trattati da "Clean Code" di Martin. A mio parere, i commenti sono un'arma a doppio taglio: non devono servire da alibi al codice di merda (per la serie, "tanto lo commento"), non devono essere troppo invasivi al punto da intralciare la lettura del codice, ma andrebbero limitati a spiegare il funzionamento di una parte di codice. In sostanza, non il "cosa" ma il "come".



il problema dei commenti all'interno del codice è che ci si deve ricordare di versionare pure quelli mentre si cambia il codice, altrimenti servono solo a complicare le cose.


 linguaggio



quindi il contrario di quanto sostenuto da adamo



un nome una garanzia



-- 

So I throw the windows wide

And call to you across the sky


 che ho fatto in vita mia: 
http://bit.ly/17LyYEx




http://24.media.tumblr.com/tumblr_lmi0t9vjOG1qzfpi8o1_400.jpg




 
http://24.media.tumblr.com/tumblr_lmi0t9vjOG1qzfpi8o1_400.jpg




LOL :)


 il problema dei commenti all'interno del codice è che ci si deve ricordare di versionare pure quelli mentre si cambia il codice, altrimenti servono solo a complicare le cose.



Verissimo.




 il problema dei commenti all'interno del codice è che ci si deve ricordare di versionare pure quelli mentre si cambia il codice, altrimenti servono solo a complicare le cose.



Commentare è un'arte. Devono esserci quelli necessari e sufficienti. Niente di più.


 Commentare è un'arte. Devono esserci quelli necessari e sufficienti. Niente di più.



che non vuol dire nulla. 

io dico è meglio darsi e dare delle linee guida, lasciando perdere

l'opinabile vena artistica. per esempio commenti sono anche i javadoc e 

quelli producono documentazione, quindi devono essere fatti in un certo

modo.

in mezzo al codice meno commenti ci sono e meglio è: laddove si vede

necessario un commento per interpretare il codice è bene riflettere 

più di una volta sul perché è necessario.


 in mezzo al codice meno commenti ci sono e meglio è[...]



Il problema dei commenti e` quello della documentazione in generale: tenerli aggiornati. E un commento non aggiornato e` spazzatura...






 più di una volta sul perché è necessario.



Figlio mio, io inizio ad avere un'età, non ho più la memoria di un tempo! :-D

E' ovvio che quando commento non dico cosa è scritto (caspita, leggi!) dico perché è fatto così!



-- 

Ciao!

Luca






 Il problema dei commenti e` quello della documentazione in generale: tenerli aggiornati. E un commento non aggiornato e` spazzatura...



Vero. Però per me la revisione del codice include quella dei commenti.



-- 

Ciao!

Luca


 In quest'ambito, capita che in un metodo un pelo più lugo, diciamo una trentina di righe, sia necessario annotare perché un blocco di codice sia fatto in un modo piuttosto che in un altro. 



Bisogna fare molta attenzione. Un metodo lungo una trentina di righe e` ai limiti dell'accettabile. Secondo me, se un metodo lungo comincia ad aver bisogno di un commento esplicativo, c'e` qualcosa da cambiare nel design del metodo. 


 Gran parte del progetto e` gia` li`, e se tu fossi meno stupido di quanto sei, te ne saresti accorto. Sei il solito coglione da it.lavoro.informatica che scrive tanto per scrivere, sparando cretinate, ma io ti perdono :)



Nervoso, eh? :-)


 E' ovvio che quando commento non dico cosa è scritto (caspita, leggi!) dico perché è fatto così!



l'altro giorno ho dovuto riprendere in mano un pezzo di codice di un mio

giovane collega perché c'era un bug. si trattava di una 

trasformazione di un file, non semplicissima ma nemmeno trascendentale.



per farla breve la sua soluzione era a dir poco bizzarra; caricava le

righe in memoria, le ordinava secondo una certo criterio, le scorreva

due o tre di volte. 



ora lui ha anche spiegato per filo e per segno nei commenti cosa 

intendesse fare, ma questo non vuol dire che io che ci dovevo mettere

le mani l'abbia capito. chi manutiene il codice deve capire cosa fa

il codice, non cosa avrebbe voluto che facesse chi l'ha scritto.

se il codice è ben strutturato i commenti non perdi nemmeno il tempo

a leggerli, se è spaghetti-code non ti aiutano. 


 Nervoso, eh? :-)



Ma neanche un po'.




 Quindi artigianato, non arte.



Un po' di poesia, amico mio, un po' di poesia.

Secondo te, nel detto 'impara l'arte e mettila da parte', si parla di artisti o di artigiani? E quando da me si parla di 'arti e mestieri', si parla di artigiani o artisti?

Quando parlo di 'artigiano' parlo del senso nobile del termine, della capacità di una persona di costruire bene le cose.



-- 

Ciao!

Luca


 a leggerli, se è spaghetti-code non ti aiutano.



Vedo che non mi spiego (oh, dopo la terza volta, fanculo Montanelli, sei tu che non capisci! ;-) )



Spaghetti-code implica spaghetti-remarks. Che poi, vogliamo smetterla di copiare gli ammerigani? gli spaghetti sono ottimi, e sono loro, mica noi, a metterci sopra le meatballs!

Quando parlo di un commento all'interno del codice, mi aspetto NON che descriva il codice (se appena è scritto decentemente, non ce n'è bisogno, se è scritto coi piedi si ricade nel tuo caso), ma il PERCHE' di scelte effettuate. Per quel che mi riguarda, il tipico caso è quando il codice risponde a un ragionamento analitico: nel commento non metto la descrizione, metto la parte del ragionamento - che troverà corrispondenza nella documentazione - cui lo spezzone di codice risponde.




 Bisogna fare molta attenzione. Un metodo lungo una trentina di righe e` ai limiti dell'accettabile. Secondo me, se un metodo lungo comincia ad aver bisogno di un commento esplicativo, c'e` qualcosa da cambiare nel design del metodo.



Questo lo commento a parte, che merita.

La mia risposta è: dipende. In linea di principio, son d'accordo con te. Poi mi è capitato per le mani uno spezzone di codice Python in cui veniva scritto un documento Excel. Roba eterna, più di 1000 righe in un solo metodo. Io l'ho spezzato il più possibile, ma se per scrivere la sola intestazione di un foglio ti serve una roba di 40 o 50 righe, stante la prolissità del package che stai usando, ti tocca restare lungo. E non ha senso scendere ulteriormente: corri il rischio di perdere il senso dell'unità-header, separando cose che dovrebbero stare logicamente assieme e peggiorando la leggibilità del tutto.


 Quando parlo di 'artigiano' parlo del senso nobile del termine, della capacità di una persona di costruire bene le cose.



Hai la rara facolta` di "esserti spiegato male", qualsiasi cosa dici.


 Roba eterna, più di 1000 righe in un solo metodo. 

<snip su tutto il resto>



Mille righe in un solo metodo non sono giustificabili *MAI*. Cosi` come 30. Oggi si dovrebbe sviluppare con un approccio TDD, che comporta l'isolamento di ogni minimo pezzo di logica, perche` sia testabile. Se si scrive un metodo di mille righe, e` SOLO per pigrizia e perche` si sta disegnando male l'applicazione.


Mica colpa mia se hai un concetto limitato di arte. Credi, non credevo di dovertela spiegare. Comunque, nessun problema, lo sforzo è poco.


Vero, ma così come le megafunzioni sono il male, anche l'iperframmentazione, a qualsiasi titoli venga fatta, è male.


 Quando parlo di un commento all'interno del codice, mi aspetto NON che descriva il codice (se appena è scritto decentemente, non ce n'è bisogno, se è scritto coi piedi si ricade nel tuo caso), ma il PERCHE' di scelte effettuate. Per quel che mi riguarda, il tipico caso è quando il codice risponde a un ragionamento analitico: nel commento non metto la descrizione, metto la parte del ragionamento - che troverà corrispondenza nella documentazione - cui lo spezzone di codice risponde.



io lo reputo inutile. nel momento in cui andrò a fare manutenzione sapere

perché è stata fatta una scelta mi serve davvero il giusto. se il codice

è strutturato decentemente, cioè in unità testabili (classi, metodi, 

funzioni), a me occorre sapere *cosa* fa quella singola unità in modo che

possa verificare, magari con i test, se veramente lo fa.



spiegare il "perché" di una scelta nei commenti mi suona come giustificarsi

con i posteri delle proprie cagate :-) posso capirli nel caso in cui si

stia scrivendo un workaround dove effettivamente per chi ci mette le mani

è importante poi saperne il perché, ma a cose normali non serve a nulla.






 è importante poi saperne il perché, ma a cose normali non serve a nulla.



Io non credo si riesca a capire di primo acchito quale problema risolve un certo spezzone di codice. In mancanza di commenti e di documentazione adeguata (e me ne è capitata di roba del genere, eh, se me ne è capitata), capire il perché dell'esistenza di certo codice può diventare un casino. Per me, proprio in ottica di maggiore velocità di comprensione, ok la documentazione esterna, ma qualche spunto che ti consenta di capire lo schema logico senza scendere riga per riga non è male, anzi.

Il problema è che capita spesso di avere a che fare con cose non normali. Almeno negli ambiti che frequento io. Esempio: sistema di analisi della produzione di una teleferica di trasporto carbone, divisa in tre sezioni. Si, ma certi allarmi che sono della seconda sezione in realtà arrivano dalla prima. Si, ma non sempre vedi gli arresti corretti, però li puoi dedurre da... Si, ma l'allarme delle bilance di carico arrivano da PLC generale e non da quello della sezione di linea. Si, ma quando vedi gli allarmi devi ricordare di eliminare questi e questi altri, che in realtà sono segnalazioni anche se sono nel vettore degli allarmi.

Se fossimo in un mondo ideale, i clienti avrebbero le idee chiare sugli obiettivi dagli inizi, e non si sveglierebbero la notte con nuove idee da realizzare per ieri, impattando su tutta la catena successiva (in fin dei conti gli eurozzi te li danno loro, per cui devi essere più compiacente possibile).



-- 

Ciao!

Luca


 Se fossimo in un mondo ideale, i clienti avrebbero le idee chiare sugli obiettivi dagli inizi, e non si sveglierebbero la notte con nuove idee da realizzare per ieri, impattando su tutta la catena successiva (in fin dei conti gli eurozzi te li danno loro, per cui devi essere più compiacente possibile).



Adesso non sei più un artigiano, sei un mercenario... :-)




 





sagge parole, caro Luca, davvero sagge parole.

Alla fine il problema è proprio quello.



E' chiaro, se tutto è già definito fin dall'inizio e così rimane,

al massimo con poche variazioni, scrivere bene il codice è

anche più facile, perché fin da subito puoi pensare a come

strutturarlo.



Ma se dall'oggi al domani bisogna mettere tre nuove funzionalità,

o cambiare quelle esistenti, allora bisogna implementare del

nuovo codice, e a quel punto è chiaro che può diventare disagevole

strutturarlo in modo simile a quello che è stato fatto prima,

vuoi perché il nuovo lavoro lo fa un altro, vuoi perché viene fatto

molto tempo dopo, anche dalla stessa persona, vuoi per altri motivi.

E in questo caso, qualche commentino breve può aiutare chi legge

a capire meglio che cosa fa (o dovrebbe fare) il codice.

E ovviamente più complesso è l'intervento, maggiore è la difficoltà.

E' questo che dico io.







Ma al di là di questo aspetto, che va preso in considerazione, io

ne faccio anche un discorso di complessità: se ho una classe

non eccessivamente lunga e complessa, con non troppi metodi e non

troppo lunghi (che ne so, una decina di metodi, lunghi non più di

qualche decina di righe, per dare un'idea), allora magari si 

possono anche lasciar stare i commenti, perché è una classe non

troppo complicata da capire.



Ma quando ti ritrovi davanti classi di migliaia di righe, con decine

e decine di metodi (o centinaia, magari), e alcuni di questi metodi

sono molto lunghi, ecco allora diciamo che non è che i commenti

sono assolutamente indispensabili, però possono aiutare chi ci

sta lavorando a capire meglio la situazione in cui si trova, questo

è il discorso.





Naturalmente, restando nel mio ambito, quello che dico vale sia

per il java che per il javascript: uno degli ultimi progetti su

cui sto lavorando, fatto con extjs, ha dei Controller javascript

lunghissimi, uno è arrivato credo a oltre 2.000 righe.

Ecco, io che ci ho lavorato mesi e che magari lo riprendo in

mano nelle prossime settimane, forse anche senza commenti mi

districo abbastanza bene; ma per uno che non ha mai visto quel progetto,

o io stesso tra un anno, che ricorderò ben poco di quello che

sto facendo adesso, un po' di commenti possono essere d'aiuto,

tutto qui.





Non dico che siano assolutamente indispensabili, né assolutamente

intendo dire che si può scrivere alla cazzo di cane, tanto poi

commento, visto che è venuto fuori anche questo discorso: lungi

da me voler dire queste cose, dico solo che in queste situazioni

un po' di commenti possono essere d'aiuto, tutto qui.





p.s.

sul compiacere i clienti perché sono loro a darti el dinero:

è vero, in effetti va fatto così, ma cerca di non compiacerli

troppo, perché oltre un certo limite aumenta il rischio di

restare fottuti, o che lo restino i lavoratori. Giusto ricordarlo,

dato che è venuto fuori il discorso. 


 Adesso non sei più un artigiano, sei un mercenario... :-)



Pecunia non olet, et bollettae et conti pagandi sunt... :-D



PS. Giusto oggi sono andato a contrattare la revisione di un supervisore, scritto in VB6 da me ma su una base preesistente scritta coi piedi (e alcune cose coi piedi le ho scritte anch'io) e risalente al 2004. Lo ripeto: VB6, software del 2004 e revisionato (perché Siemens si può permettere di dire 'sta roba non la supporto più) nel 2007. Cosa non si fa per la pagnotta... ;)


 Mica colpa mia se hai un concetto limitato di arte.[...]



Eh, si`, sono gli altri che non ti capiscono.


 Vero, ma così come le megafunzioni sono il male, anche l'iperframmentazione, a qualsiasi titoli venga fatta, è male.



"iperframmentazione" non significa una ceppa.




 Se fossimo in un mondo ideale, i clienti avrebbero le idee chiare sugli obiettivi dagli inizi, e non si sveglierebbero la notte con nuove idee da realizzare per ieri, [...]



Non sarebbe affatto un mondo ideale. I clienti con le idee chiare sugli obiettivi dagli inizi? E` evidente che hai poca esperienza nel mondo dello sviluppo software. I clienti cambiano idea continuamente e vanno guidati; i requisiti cambiano continuamente ed e` normale.


 mantenere la coerenza e la pulizia assoluta del codice è del tutto fuori della realtà. 



Stronzata. E` evidente che sei abituato a lavorare col culo, pensando che sia la normalita`. Che il codice si sporchi, e` normale. Che non si possa fare refactoring continuo, non e` normale. 




 qualche decina di righe, per dare un'idea),



"Una qualche decina di righe" per un metodo (quante? 40? 50?) significa scrivere quasi sicuramente codice non manutenibile. 




 Il problema è che capita spesso di avere a che fare con cose non normali. Almeno negli ambiti che frequento io. 



se stai dietro a quello che sostengono i clienti, tutti ritengono di essere

unici al mondo o comunque dei casi particolari. vanno educati perché il

software non può essere scritto su loro dettatura. ce li ho anch'io dei

clienti che quando spiegano i requisiti si intendono di ragionare in 

pseudo-codice, ma ho imparato a fermarli perché nella loro testa i programmi

sono una serie di if-then-else e così te li sanno descrivere. dal momento

in cui applico la necessaria astrazione, con oggetti e interfacce, sarà

più facile anche modificare quando cambieranno idea o arriverà l'ennesima

eccezione. viceversa diventerà il solito accumulo di if-then-else e 

peciotte hard coded, che ovviamente diventeranno incomprensibili un quarto

d'ora dopo che l'hai scritte.


 Stronzata. E` evidente che sei abituato a lavorare col culo, pensando che sia la normalita`. Che il codice si sporchi, e` normale. Che non si possa fare refactoring continuo, non e` normale.



Ancora nervoso, eh? :-)))


 Ancora nervoso, eh? :-)))



Come prima: neanche un po'. Sai rispondere con qualcosa di sensato, oltre a finte faccine?




 "iperframmentazione" non significa una ceppa.



Si, come no.


 I clienti con le idee chiare sugli obiettivi dagli inizi? E` evidente che hai poca esperienza nel mondo dello sviluppo software. I clienti cambiano idea continuamente e vanno guidati; i requisiti cambiano continuamente ed e` normale.



Mamma mia, ma sai che sei uno scassapalle?

Guarda che so probabilmente da prima di te come sono i clienti. E 'vanno guidati'... Si, ciao, eh?


 unici al mondo o comunque dei casi particolari. 



Talora, purtroppo, lo sono. Quella macchina di cui parlavo in altro post è proprio unica al mondo (se la sono fatta in casa). Il problema? ci han messo le mani talmente tante persone che è un miracolo se riesce ancora ad andare.



-- 

Ciao!

Luca


 Vuoi perche` si e` incompetenti e pigri, e si pensa alla pagnotta ma non alla qualita` del proprio lavoro.



Vuoi perché magari ti arriva del codice scritto male, e non mi dire che esiste, e lo devi mettere a posto.

Dai, parliamo di cose reali, 3/4 del codice che ho visto finora ha un livello di manutenibilità bassissimo!




 Non è quello, è che io amo gli spaghetti. E' uno dei doni che l'umanità ha saputo creare. Associarlo a qualcosa di mal fatto proprio non mi viene!



Per fortuna allora non ti chiami cicciolina. Non potremmo altrimenti dire: ma questa cosa è fatta alla C***O!!


 > Non è quello, è che io amo gli spaghetti. E' uno dei doni che l'umanità ha saputo creare. Associarlo a qualcosa di mal fatto proprio non mi viene!



E' diverso.



Prendi un buon spaghetto, magari fatto a Gragnano. Buttalo in acqua.

Prendi dei cuori di bue maturi, non quelli rachitici da supermercato. Prendi dell'olio di oliva buono, magari delle mie parti, poi dell'aglio e del basilico dall'orto. Facci una pasta al pomodoro, tenendo lo spago al dente e saltandolo col sugo alla fine.

Buttaci sopra una bella grattata di Parmigiano, magari un 36 mesi.

Riesci ancora a dire che si tratta di roba fatta male e non di poesia? ;)








ma anche un po' meno, anche 20 o 30.

Secondo te un metodo dovrebbe avere meno righe di codice?


 





esattamente.

E' proprio a un contesto del genere che sto pensando io.



Come ho già detto, o si apre una commessa apposta per il

refactoring, o il refactoring non lo fai, punto.



Ciò non toglie che, se su quella macchina ci metto mano io,

cerco di scrivere il codice del mio meglio, sia chiaro,

ma non ho certo il tempo di toccare il codice scritto da altri

al solo scopo di fare refactoring.










senti, visto che vai sul culinario: per caso conosci piatti

come il risotto con le salamelle o la torta sbrisolona?

Li hai mai mangiati o sentiti nominare?

Una mia curiosità.




 Si, come no.



Se tu fossi aggiornato su come si sviluppa il software, sapresti che non significa una ceppa. Sei uno dei tanti che qua dentro parla per parlare.




E 'vanno guidati'... Si, ciao, eh?



Certo che vanno guidati, instradati. Se lasci fare al cliente, ti porta dove vuole. Circa 15 anni fa ho sviluppato un sistema interamente da zero per un cliente che, fino ad allora, si era arrangiato con carta e fogli Excel. Quando si discutevano i requisiti, il form di inserimento dati di un contratto doveva essere, per loro, l'equivalente di un foglio di carta riportato su schermo. Il cliente va aiutato a capire (ed accettare) il modo migliore di implementare i suoi requisiti.


 Vuoi perché magari ti arriva del codice scritto male, e non mi dire che esiste, e lo devi mettere a posto. Dai, parliamo di cose reali, 3/4 del codice che ho visto finora ha un livello di manutenibilità bassissimo!



Io parlo di cose reali. Mettere a posto il codice scritto male si chiama "refactoring", una delle regole della metodologia Agile. Il technical debt in un qualunque sistema software e` perfettamente fisiologico; cioe` che non e` normale e` lasciarlo stare o addirittura alimentarlo. Se 3/4 del codice che hai visto aveva un livello di manutenibilita` bassissimo, il tuo ruolo come sviluppatore e` di migliorarlo, non di mettere pezze perche` tanto e` codice di merda.




 Se tu fossi aggiornato su come si sviluppa il software, sapresti che non significa una ceppa. Sei uno dei tanti che qua dentro parla per parlare.



Si, come no.


 Il cliente va aiutato a capire (ed accettare) il modo migliore di implementare i suoi requisiti.



Vero, e questo è essere professionisti e non pigiatasti. Ma non devi MAI dimenticare che l'esperienza in molti lavori ce l'ha lui. E se questo non è sempre vero (anzi spesso è falso) per quanto riguarda un gestionale (che è il caso che mi hai citato), diventa più vero quando si tratta di sviluppare una macchina industriale che non esiste.

Per me, il compito del professionista non è 'guidare il cliente', è consigliarlo, talora spiegandogli che la strada che intende non è valida, talora adattando le soluzioni alle sue esigenze. That's it.


 Secondo te un metodo dovrebbe avere meno righe di codice?



Secondo me un metodo dovrebbe avere il numero minimo di righe per compiere UN solo compito, e questo . Se comincio a vedere un metodo piu` lungo di 20/30 righe, comincio a chiedermi se tutti i comportamenti di quel metodo sono testabili. Testare i metodi privati di una classe non e` normalmente possibile, per cui bisogna isolare i comportamenti in classi con metodi pubblici testabili con unit test. Tu puoi anche scrivere un metodo che legge un file, lo comprime, lo manda per ftp, aggiorna il campo di una tabella di un database e manda un'email, ma un tale metodo sarebbe sicuramente piu` lungo di 30 righe e, come hai la garanzia che tutti i comportamenti (leggere un file, mandare via ftp, comprimere, aggiornare il campo su tabella, mandare l'email) sono corretti?




 refactoring, o il refactoring non lo fai, punto.



E invece e` una cazzata, ed e` il motivo per cui i sistemi software continuano ad accumulare technical debt e arrivano al punto da scoppiare, essere tirati giu` e rifatti. 




 Si, come no.



Vedi?




 Per me, il compito del professionista non è 'guidare il cliente', è consigliarlo, talora spiegandogli che la strada che intende non è valida, talora adattando le soluzioni alle sue esigenze. That's it.



Si chiama "guidare il cliente". Adesso dimmi che non ti sei spiegato bene.


 Io parlo di cose reali. Mettere a posto il codice scritto male si chiama "refactoring", una delle regole della metodologia Agile. 



Bello. Chi lo paga?

Perché uno dei principi della metodologia agile è l'accettazione da parte del cliente. Ma se il cliente per principio non paga il refactoring (e anche qui, non mi dire che non ce ne sono) che fai, rinunci?

Se hai il lusso di poterlo fare, sono molto contento per te (e non sono ironico, in questo momento).






 Li hai mai mangiati o sentiti nominare?



Sentiti nominare, ovviamente si. Mangiato, solo la sbrisolona. Cucinato, nessuna delle due.





ascolta, mi conviene darti qui una risposta unica per tutto,

che faccio prima, e magari ci capiamo: in linea teorica quello 

che dici è corretto.





Però, vallo a dire al capoprogetto che ti chiede di iniziare

a lavorare sul Controller di 1500 righe, che tu vedi per la

prima volta (e ti ripeto che è uno degli ultimi contesti

su cui ho lavorato) per sviluppare un paio di nuove funzionalità,

e/o modificarne di preesistenti, e ti dà un certo tot di tempo

per farlo.



Digli che invece è il caso di riscrivere tutto il Controller perché

fa cacare. Poi ne riparliamo.



Tutto qui.

Tu stati facendo discorsi teorici, giusti e condivisibili, per

amor del cielo, ma teorici, mentre io sto analizzando la questione

dal punto di vista pratico. Punto.







Poi, ovviamente, io mi baso sulla mia esperienza, come tu ti

basi sulla tua.




 Si chiama "guidare il cliente". Adesso dimmi che non ti sei spiegato bene.



No, si chiama anche sapermi adattare al cliente se mi rendo conto che la sua soluzione, per una serie di motivi non strettamente o necessariamente tecnici, è più ragionevole della mia (vedi sopra). E stavolta no, sei tu che non hai capito (io correggo parzialmente Montanelli, dopo tre volte che spiego è il mio interlocutore che non capisce) .


Ma se il cliente per principio non paga il refactoring[...]



Il refactoring non c'entra una ceppa con quel che il cliente paga o non paga.










 Tu stati facendo discorsi teorici



Io non faccio nessun discorso "teorico". Io faccio lo sviluppatore da un ventennio e quel che dico lo metto in pratica tutti i giorni. 


 No, si chiama anche sapermi adattare al cliente se mi rendo conto che la sua soluzione, per una serie di motivi non strettamente o necessariamente tecnici, è più ragionevole della mia (vedi sopra). 



LOL... ma quando mai! Il cliente da` soluzioni? Il cliente presenta problemi; le soluzioni devi dargliele tu!


 Bello, chissa` com'e` contento quel cliente. Nel 2105 c'e` qualcuno che suggerisce la carta come alternativa al software. Complimenti.



Tu non hai idea di cosa sto parlando, io non posso entrare nei dettagli per motivi di riservatezza e tu hai già deciso che il software COMUNQUE è la soluzione migliore. No, guarda, sono io che ti faccio i complimenti.



E per me la questione finisce qui. La cosa sta diventando a chi ce l'ha più lungo, e vai tranquillo, ce l'hai più lungo tu.




 Il refactoring non c'entra una ceppa con quel che il cliente paga o non paga.



PREGO?!?

Sono curioso. Visto che un refactoring DEVE essere pagato, agile o non agile (la schiavitù è stata abolita), come ti comporti se il cliente dopo 4 anni ti dice 'mi servono queste modifiche' e ti accorgi che le modifiche, rebus sic stantibus, richiedono un paio di giorni di lavoro e un refactoring serio richiede almeno due mesi di lavoro che il cliente non ti paga?








creare dei metodi pubblici per comportamenti interni alla classe va 

contro l'incapsulamento che è uno dei principi della OOP che vai tanto 

acclamando.



che mi ricordo i metodi devono svolgere un COMPITO, non comportamento.

"inviare un file tramite ftp" è un COMPITO, poi che al suo interno sono 

richiamati altri metodi va bene, ma questi ultimi devono essere appunto 

PRIVATI, non devono essere richiamabili da altre classi se non servono 

per altri scopi.



altrimenti rischi di esporre la classe a possibili malfunzionamenti o 

comportamenti non voluti.



nel tuo caso rischi di far inviare un file senza comprimerlo o 

aggiornare su db senza aver inviato il file, perchè quei metodi per te 

sono pubblici e quindi richiamabili da altre parti.



se scrivi dei buoni casi di Test riesci a testare tranquillamente il 

metodo (il COMPITO) e con le asserzioni, vedere se il comportamento (la 

struttura interna al metodo) funziona regolarmente, utilizzando un event 

listener.



Ciao






io non posso entrare nei dettagli per motivi di riservatezza e tu hai già deciso che il software COMUNQUE è la soluzione migliore. 



Io dico che non mi fiderei di te come progettista software neanche se mi pagassero un miliardo. 


 Sono curioso. Visto che un refactoring DEVE essere pagato, agile o non agile



Il refactoring e` un'attivita` costante che ricade nell'attivita` quotidiana dello sviluppatore. Il refactoring che richiede un paio di mesi non e` il refactoring di cui parlo io, in contesto Agile.




 Io dico che non mi fiderei di te come progettista software neanche se mi pagassero un miliardo.



Vedrò di farmene una ragione. Sul serio.



:-D


 che mi ricordo i metodi devono svolgere un COMPITO, non comportamento.



Mai detto che un metodo debba "svolgere un comportamento". Il mio italiano non e` cosi` approssimativo.


 :-D



Mi segno il nome. Se il mio capo in futuro mi chiede di farti fare qualcosa come contractor esterno, gli dico di no ;-)




 Il refactoring e` un'attivita` costante che ricade nell'attivita` quotidiana dello sviluppatore. Il refactoring che richiede un paio di mesi non e` il refactoring di cui parlo io, in contesto Agile.



Il che vuol dire sostanzialmente due cose:

1) non sai che una macchina industriale non richiede PER DEFINIZIONE un'attività di refactoring costante, e che PER DEFINIZIONE il ciclo di vita di una macchina industriale è piuttosto lungo (10 anni e oltre) con interventi solo a spot;

2) fortunato tu, hai la possibilità di muoverti in contesto Agile e non devi sporcarti le mani con roba scritta in qualche modo (non sto scherzando, questa è roba che posso far vedere quando vuoi) 10 o 15 anni fa, che da 10 o 15 anni lavora e per la quale vengono richiesti aggiornamenti legati a cambio di normativa, richiesta di ampliamento o altro.

Sei tutto sommato in un'isola felice, per cui seriamente ti invidio (e giustifico in effetti molti dei tuoi discorsi così assoluti).


 Mi segno il nome. Se il mio capo in futuro mi chiede di farti fare qualcosa come contractor esterno, gli dico di no ;-)



Caspita, e io ora come dormo, questa notte? ;-)


 Sei tutto sommato in un'isola felice[..]



Ma quale isola felice. Io mi sporco le mani col software tutti i giorni. Sei tu che sei chiuso nel tuo piccolo mondo dove il software di merda regna sovrano. E vorresti far credere che e` per tutti cosi`?


 Caspita, e io ora come dormo, questa notte? ;-)



Dormi tranquillo. Non credo ti capitera` mai di trovarti a lavorare nel mio stesso contesto, a giudicare da quel che scrivi. Potresti invece impegnarti per mettere a frutto quel che ti riesce meglio: convincere i clienti a passare alla carta! LOL...




 Sei tu che sei chiuso nel tuo piccolo mondo dove il software di merda regna sovrano. E vorresti far credere che e` per tutti cosi`?



Mi spieghi dove l'avrei scritto? Perché sai, pure io sono piuttosto preciso, con l'italiano.

Sto dicendo che quella roba esiste - e l'hai appena detto pure tu. Quel supervisore di cui parlavo è fatto in quel modo. Mi piace? spero tu non sia scemo da credere che la mia risposta sia si. Ora, ho due scelte: soddisfare il cliente turandomi il naso e facendo le due modifiche che chiede, oppure battere i piedi per terra finché non mi danno i soldi per buttare a mare tutto e rifare tutto come deve essere fatto; budget per la prima soluzione, un paio di migliaia di euro; budget prevedibile per la seconda soluzione, una trentina di migliaia di euro. Sapendo in partenza che la opzione 2 non è nemmeno da proporre, tu che faresti al mio posto?


 Potresti invece impegnarti per mettere a frutto quel che ti riesce meglio: convincere i clienti a passare alla carta!



Eppure, guarda te, conoscendo il contesto, conoscendo la proposta e gli aspetti negativi che aveva, e sapendo cosa intendo per 'carta' (sai, può essere tante cose, la carta, non solo fatture, ordini o roba del genere...) son certo che avresti dato la stessa risposta anche tu. E mi rode, non hai idea quanto, non poter entrare nei dettagli.












e bene, hai più esperienza di me, io sviluppo da sei anni.

Come ho già detto, ognuno si basa sulla sua esperienza.





allora ti consiglio assolutamente di mangiare anche il risotto

con le salamelle, se ti piace la cucina devi colmare questa

lacuna.



Senti, ma la sbrisolona l'hai mangiata a Mantova o altrove?

Così eh, per curiosità.










è questo infatti il punto!!!!!!!!!!!!!!!!




 Talora, purtroppo, lo sono. 



dal punto di vista della progettazione del software? io ci penserei molto

bene, prima di arrivare a questa conclusione.

nessuno dice che valga per tutti la stessa soluzione, dico che se dai

retta al cliente lui non ti dirà mai che le sue casistiche sono

generalizzabili. ma mica perché è cattivo, perché non lo sa e perché

pensa che se consideri le sue come casistiche particolari gli fai un 

software per lui migliore. il che non è vero.


Ora ho due scelte: soddisfare il cliente turandomi il naso e facendo le due modifiche che chiede, oppure battere i piedi per terra finché non mi danno i soldi per buttare a mare tutto e rifare tutto come deve essere fatto



Se si arriva al punto che i sistemi software vanno buttati giu` e rifatti e` perche` esiste gente come te, che accetta di aggiungere merda alla merda preesistente, senza preoccuparsi di migliorare un prodotto. Fare modifiche in maniera approssimata, di fretta, in un tempo limitato, significa creare technical debt. Significa soddisfare il cliente al momento, con un delivery nei tempi, ma farlo piangere alla lunga perche` il sistema, prima o poi, si ferma.


 son certo che avresti dato la stessa risposta anche tu



Certo, come no. 




 un bel po' di tempo, e la main activity è un'altra.



E infatti non penserai mica che io stessi suggerendo di riscrivere tutte le logiche preesistenti, vero?


 anche i casini a guardar bene non sono poi dei luoghi così detestabili.



In effetti, manco tu hai tutti i torti! :D


 è questo infatti il punto!!!!!!!!!!!!!!!!



Il punto e` che ne` tu ne` Menegotto avete capito cosa si intende per "refactoring" in un contesto Agile. 



Riporto di nuovo il link: 
http://www.versionone.com/agile-101/refactoring.asp



 Farai bene ad isolare ogni singolo comportamento in una classe che lo isola.



  Per cui, verosimilmente, avrai una classe FileCompressor con un metodo 

PUBBLICO compress()



che sara` testabile dalla classe FileCompressorTest, di unit test.





E' proprio qui che non concordo e che verosimilmente non sposta di una 

virgola il mio discorso, stai creando un metodo pubblico su un qualcosa 

che NON deve essere pubblico, mo che tu lo faccia in una classe apposita 

o all'interno di una classe più ampia SEMPRE DI UN METODO che NON DEVE 

ESSERE RICHIAMATO stai facendo, PUNTO.



sempre parlando nel tuo caso quel metodo non solo viene richiamato da 

processFile attraverso il metodo privato compressedFile che richiama la 

il metoto publico compress della classe FileCompressor , e allo stesso 

modo da FileCompressorTest , ma nessuno mi vieta di poterlo richiamare 

da un altra classe e proprio li che potrei creare dei danni.



se quel comportamento COMPRESS mi serve SOLO per inviare un file tramite 

FTP e poi MAI più usato, ma perchè cavolo lo devo rendere pubblico ed 

esporlo al mondo intero.



tu non lo stai isolando, stai semplicemente staccandolo dalla classe 

dove deve essere utilizzato.



Ciao










  ma farlo piangere alla lunga perche` il sistema, prima o poi, si ferma.



Uhm... tu scii? se si, allora scia preoccupato, che c'e' roba mia che gira sugli impianti da una ventina d'anni... ;)






 Certo, come no.



Andrea, ti sfido. Ci si vede e si beve una birra insieme. De visu posso spiegare di cosa sto parlando (mentre qui, ovviamente, no). Se ho ragione io, paghi tu, se hai ragione tu, pago io.


 Il punto e` che ne` tu ne` Menegotto avete capito cosa si intende per "refactoring" in un contesto Agile. 



Se io ti dico che l'ho capito, sei disposto ad accettare che esistano contesti in cui il refactoring in ambito Agile non è applicabile?


 Sono curioso. Visto che un refactoring DEVE essere pagato, agile o non agile (la schiavitù è stata abolita), come ti comporti se il cliente dopo 4 anni ti dice 'mi servono queste modifiche' e ti accorgi che le modifiche, rebus sic stantibus, richiedono un paio di giorni di lavoro e un refactoring serio richiede almeno due mesi di lavoro che il cliente non ti paga?



eh come vuoi che si comporti uno quando vede che tutto il software da lui

scritto è da buttare e riscrivere da capo? 

solitamente non è che devi rifattorizzare tutto, se devi fare una

modifica ti limiti a ciò che impatta quella modifica. si parla di ore,

mica di mesi. lo fai con continuità e ottieni che la qualità del

programma avanza senza che ci sia bisogno di chiedere soldi al cliente.



certo che se accatasti peciotti su peciotti arrivi al punto di non ritorno,

ovvero quando qualsiasi intervento strutturale diventa invasivo e 

insostenibile. ma non è che devi prendertela col destino inesorabile del

mondo reale perché non è così. 




 insostenibile.



Ma infatti interventi strutturali non se ne fanno, punto. Ricorda, è sempre una macchina finita, non ha senso un intervento strutturale se non in ambito di revamping. Si aggiunge qualche feature, nulla di che. Roba qualche giorno di lavoro, di cui parte spesi a ricordare come era fatto.

E la cosa divertente è che il cliente - è cliente del mio cliente, e io ho detto: perché non lo buttate a mare? - pretendeva di farlo rientrare nel contratto di manutenzione hardware.






 dove deve essere utilizzato.



Niente affatto. Io sto isolando un COMPORTAMENTO, non un metodo. Purtroppo hai difficolta` a capire la differenza.


 Uhm... tu scii? se si, allora scia preoccupato, che c'e' roba mia che gira sugli impianti da una ventina d'anni... ;)



Per fortuna, non scio.




 Andrea, ti sfido.



Ma cosa sfidi :) Ma sparisci.


 Se io ti dico che l'ho capito, sei disposto ad accettare che esistano contesti in cui il refactoring in ambito Agile non è applicabile?



Non "non applicabile", ma "non applicato". Sono due cose molto diverse. 

Lo so gia` che esistono certi contesti. Di sistemi scritti col culo ne ho visti a centinaia.




 LOL. A me non infastidisce proprio niente, avendo lavorato negli ambiti piu` disparati, e ti assicuro che in OGNI ambito dello sviluppo software il refactoring quotidiano esiste eccome.



ROTFL! E io ti assicuro che è una puttanata intergalattica.

Ora, visto che ci stiamo avvitando, che io sulla base della mia esperienza mi son convinto che l'ambito industriale non lo conosci manco un po, mentre tu, sulla base della tua esperienza, sei convinto che io faccio le cose peggiori della terra, e che alla fine sempre li restiamo, per me la questione finisce qui.


 Ma cosa sfidi :) Ma sparisci.



ROTFL! Modo, lo risonosco, molto elegante, per non pagare una birra! :-D


 ROTFL! E io ti assicuro che è una puttanata intergalattica.



Le puttanate megagalattiche le stai scrivendo tu. Te lo ripeto: il fatto che tu, in ambito industriale, lavori col culo, non significa che si debba lavorare col culo. Il fatto che, in ambito industriale, esistano sistemi che debbano restare in piedi ventiquattr'ore al giorno, sette giorni su sette, richiedere manutenzione minima, e non evolvere piu` di tanto una volta rilasciati, NON significa che il software sviluppato per l'automazione industriale non debba o non possa seguire una certa metodologia di sviluppo. Qui, il vero inesperto, dimostri di essere tu. Non tirare fuori gli anni di esperienza, perche` (e` evidente, a questo punto) non sono prova di un bel niente. Hai dimostrato, in tutto il thread, di essere un programmatore (?) che pensa piu` a guadagnarsi la pagnotta che alla qualita` della roba (avevo scritto "software", pensa un po') che produce. Per cui non venire a fare lezioni agli altri su come il software si debba, o non si debba sviluppare.



Ti piacerebbe. E` un modo per non fartene pagare 10.


 E la cosa divertente è che il cliente - è cliente del mio cliente, e io ho detto: perché non lo buttate a mare? - pretendeva di farlo rientrare nel contratto di manutenzione hardware.



se domattina si rompe il pc dove gira codesto programma passa dallo stato

di "gira perfettamente" allo stato di "non parte nemmeno". la riscrittura

è nell'interesse suo, non tuo. uno lo spiega, poi la responsabilità della

scelta è sua, quando succederà l'inevitabile (perché succederà) ciò che

poteva essere pianificato in mesi avrà bisogno che venga fatto dalla sera

alla mattina. è conscio di questo? se sì, affar suo. se no, probabilmente

quel giorno darà la colpa a te ma come ex cliente non sarà una gran perdita.


 scelta è sua, 



Nel caso specifico il problema è proprio il finanziamento. L'azienda con cui collaboro avrebbe davvero bisogno di una svecchiata dei suoi software. Da un lato però non c'è l'interesse, i suoi sistemi, tamponature occasionali a parte, son destinati a essere rimpiazzati - si sta passando a sistemi SCADA evoluti, cose molto belle, sofisticate e integrate con i pannelli operatore che fanno impallidire di vergogna quelli che ho visto 10 anni fa - ; dall'altro i tempi sono magri per cui un ridisegno complessivo, almeno per mettere in piedi una spina dorsale su cui poi poter lavorare decentemente, non è finanziabile nemmeno per ipotesi.



Tornando al caso generale, sai dove vedo MOLTO bene tutto l'approccio Agile? In tutti gli ambiti in cui si sviluppa prodotti a ampia diffusione - posto che ancora abbiano senso - o in quelli SAAS. Li il miglioramento continuo non è solo una buona pratica, è fondamentale per continuare a mantenere l'appeal presso l'utente.


 Tornando al caso generale, sai dove vedo MOLTO bene tutto l'approccio Agile? In tutti gli ambiti in cui si sviluppa prodotti a ampia diffusione - posto che ancora abbiano senso - o in quelli SAAS. Li il miglioramento continuo non è solo una buona pratica, è fondamentale per continuare a mantenere l'appeal presso l'utente.



ma anche no. a parte che il refactoring continuo non è peculiare

della metodologia agile ma anche del buonsenso, ma nella metodologia

agile c'è anche il coinvolgimento del cliente, per cui se c'è un ambito

in cui calza meglio è proprio il software su commissione.

in ogni caso il miglioramento continuo di cui si parla è a livello

di qualità di codice, l'utente vede poco o nulla.


 di qualità di codice, l'utente vede poco o nulla.



Sai che io resto convinto che il miglioramento della qualità del codice abbia come effetto collaterale il miglioramento dell'efficacia e delle performances? Non sempre, sia chiaro, ma a me è successo spesso.




 Sai che io resto convinto che il miglioramento della qualità del codice abbia come effetto collaterale il miglioramento dell'efficacia e delle performances? Non sempre, sia chiaro, ma a me è successo spesso.



vuol dire che a maggior ragione il refactoring continuo è pratica

opportuna e di buon senso.


 opportuna e di buon senso.



Certamente, per qualcosa destinato a evolvere nel tempo è così.


 Ecco il perché del mio ragionamento sopra.



Riepilogando, la situazione su cui si discute del "refactoring continuo" sarebbe questa:

- una macchina industriale, quindi anche con un certo grado di pericolo per l'incolumità se comandata male

- un software di comando fatto da qualcuno 10-15 anni fa, in VB6

- tale software non è fatto bene

- però ha subito solo 2 manutenzioni evolutive, non correttive, in 10-15 anni, per il resto ha fatto il suo dovere, nessun morto, nessun ferito, nessuna produzione da buttare

- per quel software l'azienda non ha un contratto di assistenza/manutenzione regolare con nessuno

- dopo diversi anni dall'ultima manutenzione, ti hanno chiamato per farne una nuova, sempre evolutiva

E' così?




 - un software di comando fatto da qualcuno 10-15 anni fa, in VB6



Ecco, vero tutto il resto, va detto che in VB6 hanno fatto il supervisore, non il firmware ne i sistemi effettivi di controllo.




 Ecco, vero tutto il resto, va detto che in VB6 hanno fatto il supervisore, non il firmware ne i sistemi effettivi di controllo.



Ok. Tanto per capire che minchia c'azzecca il "refactoring continuo" con sw senza una qualche forma di assistenza/manutenzione continua: assolutamente niente.




 Ecco il perché del mio ragionamento sopra.



sono obiezioni che non stanno in piedi neanche coi fili.

le iterazioni *sono* il processo di sviluppo, non un qualcosa in più

che deve essere finanziato. 

quando alla partecipazione del cliente non si tratta di chiedergli di

lavorare per te; le famose iterazioni prevedono analisi e rilasci

frequenti, il cliente è semplicemente partecipe dell'analisi e fornisce 

i feedback. che  questo sia inapplicabile per una pmi veramente non 

sta ne in cielo ne in terra e non si capisce da dove venga fuori, visto

che le metodologie agili si pongono proprio l'obiettivo di formalizzare

processi che sono propri delle piccole realtà. sarà più facile avere

rapporti a quattrocchi e continui con una piccola azienda o con telecom

italia?


 che  questo sia inapplicabile 



Ocio, ho parlato di probabilità di trovare disponibilità, non di inapplicabilità. In molte PMI, nel mio tessuto - e, per dirla chiara, è stato in passato il motore potente e ora è un limite - 'el paron', magari un po' attempato, talvolta vive l'informatica come una fastidiosa necessità. Ribadisco, talvolta.