Newsgroup: it.lavoro.informatica
Titolo: Il codice buono e semplice è davvero conveniente per l'informatico ?

Piccola provocazione.



È il refrain che si sente sempre nel nostro lavoro, cercare di fare 

codice più semplice, leggibile, manutenibile, scalabile ecc. ecc. Sempre 

la stessa storia. Continui refactoring, restyling, adattamenti alle nuove 

librerie e tecniche ecc.



Poi vai a vedere e trovi realtà come SAP. Interfacce mostruose dal punto 

di vista dell'usabilità, protocolli obsoleti fermi a 30 anni fa, codici 

astrusi per fare le operazioni più semplici. Dal punto di vista 

dell'utente, l'inferno.



E SAP lo usano praticamente tutti, i consulenti SAP sono pagati a peso 

d'oro.



Per cui la domanda: dal mero punto di vista di auto-conservazione del 

lavoro dell'informatico, quanto è conveniente scrivere codice sempre più 

facile e manutenibile ? 

-- 

Soprano



Dipende da una sola cosa: monopolio. Se l'azienda ha il monopolio del 

settore, puo' fare quello che vuole, tra cui produrre software scadente 

e chiedere prezzi sconsiderati.



Questo non significa che convenga scrivere codice di merda. Dire che in 

questo modo ti puoi far pagare la manutenzione e' una stronzata: 

l'azienda puo' in ogni caso caricare il prezzo o costi di servizio 

(manutenzione o meno).



Ovviamente la domanda potrebbe avere molteplici risposte, magari piu' 

serie delle mie, dipendentemente dal committente dell'informatico, dal 

tipo di software che scrivi etc. etc.



Ad esempio, se sei uno che scrive per SAP, come ti sei gia' accorto, di 

cio' che scrivi non frega niente a nessuno: basta che respiri.



Se sei uno che scrive software importante difficilmente sostituibile, 

piu' lo scrivi incasinato e piu' sarai coinvolto nelle eventuali 

manutenzioni, in quanto non ci sara' nessuno in grado di metterci le mani.



Se scrivi librerie riutilizzabili implementabili da terzi, allora la 

qualita' potrebbe essere importante, perche' probabilmente chi utilizza 

il tuo software potrebbe essere invogliato a commissionartene altro.



In sintesi: "Te stà dentro che qua fuori è un brutto mondo" (cit.)

:-)



---

Questa e-mail è stata controllata per individuare virus con Avast antivirus.

https://www.avast.com/antivirus





 facile e manutenibile ? 



SAP e` solo una parte del mondo informatico. Esiste il resto del mondo in cui scrivere codice di alta qualita` e` assolutamente fondamentale. Esistono ambiti molto competitivi dove se produci "crappy code" troppo a lungo, ci sara` un fornitore pronto a rimpiazzarti.



Oggi ci sono metodologie di sviluppo software che sono inerentemente orientate all'alta qualita` e non le si puo` ignorare. Prima si scriveva codice e poi lo si testava; oggi (purtroppo non in tutti i contesti) si scrivono test e poi si sviluppa il codice. E questo e` uno skill che bisogna acquisire.



Tra l'altro trovo personalmente molto discutibile che la qualita' del

codice sia ad uso e consumo del solo datore, anzi, per quello che mi

riguarda non e' davvero cosi'.

Se una determinata specifica indica che il software deve fare a, b, c

che il codice sia bello o brutto per il datore e', alla fine dei conti,

abbastanza indifferente, basta che faccia a, b e c.

Quello che ci rimette e' sicuramente lo sviluppatore, che deve

districarsi nei suoi stessi casini, o alla peggio, nei casini degli altri.

SAP avra' presumo l'infrastruttura e i fondi per avere, tanto per dire,

QA e tester a libro paga. A me e' capitato una volta nella vita di avere

un tester, in ormai 13 anni di carriera.



  ngw


 Piccola provocazione ....



nel secolo scorso era un discorso quotidiano

nei primi anni di questo secolo io ho scritto quanto segue:

---------------------------------------------------------------------------

... Ma ora devo proprio riferire cosa ho letto in: “Non è vero ma ci credo” di John Brockman (ilSaggiatore) e che è la trascrizione di un forum ove si chiede a illustri scienziati cosa ritengono sia vero ma senza poterlo dimostrare. 

A pag. 124 trovate Charles Simonyi, “scienziato” informatico della Microsoft che scrive: “… ci siamo impantanati … i computer sono migliorati diecimila volte … eppure … per tradurre in un programma per computer un problema amministrativo, che si potrebbe descrivere dettagliatamente in cento pagine, … ci vogliono milioni di dollari e spesso il programma non funziona …”  

Evviva! Finalmente l’hanno capita !!! Volto la pagina convintissimo di trovar scritto che prima di scrivere un programma occorre diventare esperti nel problema da programmare (a meno che non si voglia insegnare la programmazione all’esperto stesso) e invece che ti leggo? Ti leggo: “… poi bisogna dare ai programmatori la possibilità di scrivere non un programma per risolvere il problema in sé, ma un generatore di programmi, che combinerà i contributi degli esperti sulla materia ai dettagli per l’implementazione …”.

Magnifico! Come rimedio al fallimento dei propri metodi, ne invocano un uso ancor più smodato ... 

-----------------------------------------------------------------------------



Il dr.ugo.gagliardelli pensa che oggi il problema sia assai circoscritto 

e mi ha chiesto chi altri si lamenti oltre a Simonyi. 

Mi permetto di sfruttarti a tal fine.



Ciao


On 11/05/2017 14:20, 
gin...@alice.it
 wrote:



[...]

Ancora? Ancora co' 'ste stronzate? Bisognera` leggerti ancora per molto?



-- 

4ndre4



---

This email has been checked for viruses by AVG.

http://www.avg.com





 facile e manutenibile ? 



metti caso che lo devi riprendere tra un anno o due. Scritto bene sai da dove iniziare, scritto male fai prima riscriverlo da zero. Per di piu' la reputazione di scrivere codice alla pene di segugio non fa granche' bene alla auto-conservazione.




On 11/05/17 08:56, Soprano wrote:


Aggiungo anche che da qualche tempo a questa parte Uncle Bob va in giro 

a dare questo talk:



https://www.youtube.com/watch?v=X31Jc6HQUcs




in soldoni, abbiamo il dovere morale di scrivere codice al meglio, e se 

non lo fai sei una gran testa di cazzo :D. Nel peggiore dei casi metti a 

repentaglio vite umano, nel migliore dei casi solo la vita della tua 

azienda.



Non c'e problema,il 99,99% e forse piu del codice scritto fa 

letteralmente schifo quando a manutenibilita e scalabilita per cui il 

problema non e' da porsi.

E non e' solo per colpa di programmatori incapaci ma anche dei tempi 

ristretti imposti.








Con questa valutazione spannometrica -99,99% e forse piu- vorresti dire 

che praticamente l'intera popolazione di programmatori dovrebbe cambiare 

mestiere? Secondo me dovresti smettere di bere.



Fara' schifo il codice che scrivi tu.



  ngw





No dovrebbe smettere di programmare. Sta parlando di se stesso credo.


 Non c'e problema,il 99,99% e forse piu del codice scritto

E com'e' composto il campione di riferimento che ha generato questa 

statistica?




Nessun campione, l'autorevole fonte e' un avventore del Bar sotto casa 

sua, tale Carlo Mottespiego.



beh da discussioni passate ha già candidamente ammesso di programmare in 

java ma non saperne sostanzialmente una ceppa, facendone anche motivo di 

vanto.

quindi non c'è da sorprendersi di questa valutazione. sicuramente il team 

che accetta lui come membro non può essere che come dice lui.


 ristretti imposti.



Boh, io sto andando di gran fretta, release aspettata per inizi di 

giugno con ancora molte cose da fare e testare. Ciononostante, ho 

passato la mattinata a curare gli unit test e ripulire codice.



Fossi andati in produzione con codice di merda perche' scritto di gran 

fretta, di certo nessuno ci avrebbe risparmiato tempo. Anzi.



Mo parte discussione delirio su chi scrive gli unit test degli unit test :D



  ngw



Perche', c'e' qualcuno che li scrive? :D






Non ho ben capito cosa intendi con "dal mero punto di vista di

auto-conservazione del lavoro dell'informatico"



Ho sempre cercato, nel limite delle mie possibilita', di rispettare

l' /etica/ del lavoro "informatico".

Farlo nel miglior modo possibile sia per me che per gli altri.

Anche per me. Mi e' capitato talvolta di ritornare su cose che

avevo scritto e maledire me stesso.

Disperdere nel codice /trappole/ di tutti i tipi lo ho sempre

trovato *sciocco*.

C'e' sempre qualcuno che abita + a Sud di te!

Chiarisco.

C'e' sempre qualcuno che sara' in grado di manutenere o riscrivere

il tu codice.

Un codice (applicazione) anche scritto inizialmente in modo perfetto

se e' sottoposto continuamente a modifiche (dico modifiche e non

evoluzioni) col tempo si degrada in modo evidente.



Ho un paio di "nanetti" sull'argomento ma in questo NG

i "nanetti" non sono graditi ;-)





-- 

ac (x=y-1)

Aborro il Killfile

(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)


 letteralmente schifo 



Del TUO codice, semmai.


 Fara' schifo il codice che scrivi tu.



Non avrei alcun dubbio a crederlo, peraltro.


 evoluzioni) col tempo si degrada in modo evidente.



Stronzata.



Al mio paese quando non si approva si dice perche' e si propongono

scenari alternativi.

Il tuo paese e' diverso dal mio.



Se hai bisogno di tenerezze affittati una (o un) escort.

Dietro compenso sembra facciano di tutto.

Ma non stai lavorando?

O il tuo line manager per  scrollarti dai suoi zebbedei ti fa

giocare con i NG's ?



 scenari alternativi.



se e' una stronzata dire che ogni modifica peggiora la situazione, 

rimane una sola possibilita': che ogni mofifica deve lasciare inalterata 

(se si parte dalla perfezione) o migliorare il codice.



Non ho capito perche' uno dovrebbe far marcire il progetto ad ogni 

modifica. E' vero solo se non si stanno seguendo certe buona pratiche di 

scrittura del software.


 Il tuo paese e' diverso dal mio.



E` il tuo paese ad essere diverso dal resto del mondo. Fino a che tu non saprai cos'e` uno unit test, un integration test, un automated test, un system test, un performance test (non mi serve conoscerti per sapere che non sai di cosa sto parlando), il tuo paese sara` sempre una capanna sperduta nei boschi e lontana migliaia di miglia da qualunque centro abitato. Esistono metodologie di lavoro, oggi, che tu NON conosci e che consentono di controllare l'evoluzione del software perche` si mantenga la qualita` del codice. Sto sprecando troppo sapone.



PS al mio line manager interessa che io produca, cosa che io faccio puntualmente. In attesa che Jenkins buildi, posso darti qualche altro cazzottino nell'angolo del ring. O ti dispiace?






Perchè vuoi infierire? Non credi che abbia già sufficienti problemi

per conto suo?






 un system test, un performance test



A parte quello che dice il tuo interlocutore preferito, :-) per pura 

curiosita', non hai citato i validation test, e' un caso o segui una 

metodologia particolare? Magari li valuti inutili o semplicemente 

ridondanti, nel qual caso mi piacerebbe sapere il per quale ragione.



 scrittura del software.



La questione, per come la vedo io, e' che le modifiche

(ripeto modifiche e non evoluzioni -nuove release per intenderci-)

sono talvolta dettate da specifiche esigenze spesso sia temporalmente

che economicamente critiche.

Se il codice e' inizialmente perfetto (caso di studio) e' ovvio che se

ne puo' mantenere solo lo stato.

L' /architettura/ del software puo' aiutare a non far /marcire/ ma,

ovviamente parlo di esperienze datate, le modifiche richieste sono

talvolta le piu' strane ed inaspettate. Spesso sono fatta da persone,

brave o meno brave non e' importante, ma che, di fondo, devono

"risolvere" nel modo piu' breve ed economicamente sostenibile.

Di norma tali persone non conoscono la logica dell'intero progetto o

anche della infima parte di cui si stanno interessando.

Quando parlo di software intendo tutte le componenti: ambiente, dati,

codice e documentazione a corredo.

Recentemente ho parlato con un ....vabbe' scrive ancora software...

che mi raccontava di come in questi ultimi anni le fasi di produzione

si sono /industrializzate/  cio', tendenzialmente,

rende meno artigianale anche gli interventi successivi e

contribuisce a mantenere il tutto /pristine/ .

L'ultimo progetto che ho visto (anni fa), sebbene sotto il cappello

di primaria azienda di pezzi di ferro, doveva ancora essere rilasciato

ma gia' odorava di obsoleto e malfatto e non a causa del /team/ di

sviluppo.



Il tuo nick (se non erro) me lo ricordo ,anni fa,java ng?

Ecco. Prendiamo Java. Si vantavano che dalla release 1.1(?)

alla 1.2(?) avevano inserito non so quante altre classi

/deprecandone/ parecchie altre. E ti vanti pure?




Non ho scritto solo di programmatori incapaci ma anche di tempi ristretti.

E comunque non in tutti i progetti si richiede codice manutenibile

Nei progetti dai clienti (banche,assicurazioni,ecc..) ad esempio 

l'importante e' finire nei tempi stabiliti con codice funzionante;

la manutenibilità passa in secondo piano





Io non programmo in java,ho solo modificato un po di codice java

Il mio linguaggio principale e' C++





Ha scritto l'esperto.





Ohhh, madonnina dei dolori (come cantava un grande)

La mia e la tua due famiglie rovinate.

Non parliamo di quello a cui rispondi.

Lui ha una famiglia allargata ;-)




In passato qualcuno qui, non ricordo bene chi, aveva questo amletico dubbio.



  ngw


 ridondanti, nel qual caso mi piacerebbe sapere il per quale ragione.



Validation testing non sono l'unione dei test sopracitati?



  ngw







quindi il target di programmatore a cui ti riferivi è quello del c++?


 metodologia particolare?



Seguendo Agile (Scrum/Kanban) validation e verification sono impliciti. Se mi dici pero` come vengono fatti da te, so dirti qual e` il nostro equivalente.



Puo' anche darsi, per questo chiedo.

Per quanto ne so io, i validation test dovrebbero riguardare in generale 

la verifica dei requisiti/specifiche del software, potenzialmente anche 

la qualità del software. In genere seguono gli unit test ed 

eventualmente gli integration test, intesi come unit test raggruppati.

Perdonami se sbaglio, ma nel mio ambito lavorativo, mi capita di rado di 

confrontarmi su questi argomenti, per cui e' possibile che abbia subito 

qualche deformazione.



 evoluzioni) col tempo si degrada in modo evidente.



mmm... no, sinceramente non mi è chiaro perché questo sarebbe il destino 

ineluttabile di un progetto.

succede quando la gente lavora con i piedi, modifica senza mai fare 

refactoring, senza rimuovere il codice obsoleto, senza risolvere 

definitivamente i conflitti, etcetera, etcetera.

certo capita, ma anche no. 



Da noi si usa cucumber per validare che il software risponda alle

specifiche: 
https://cucumber.io/


Le feature vengono scritte partendo dagli input del product manager che

poi li valida e inserisce in pivotaltracker.



E' anche appena uscito un testo per i pragprog:

https://pragprog.com/book/hwcuc2/the-cucumber-book-second-edition




  ngw




 /deprecandone/ parecchie altre. E ti vanti pure?



E perche`, secondo te "deprecare" la vecchia API significa far degradare la qualita` del software? Veramente non ci capisci un cazzo.


 Il mio linguaggio principale e' C++



Peggio me sento.




 Se mi dici pero` come vengono fatti da te, so dirti qual e` il nostro equivalente.



In generale seguendo come linea guida lo standard IEEE1012, anche se di 

per se' vuol dire poco.

Ad esempio verificare se un determinato software possa funzionare con 

diversi db indifferentemente, nel caso le specifiche lo richiedano.



 Fino a che tu non saprai cos'e` uno unit test, un integration test, un automated test, un system test, un performance test



se....se....

Parole...Parole....fra Mercuzio e Mina

hai dimenticato il behavioural!





Comunque questo e' un /performance test/ !



x: Domani siamo chiusi

Io:Perche'?

x:Dobbiamo fare i premi ed il calcolatore non e' disponibile.

Io:Quanti miliardi di polizze avete?

x:Circa un milione

Io: Mbeh? (Mumble....Mummbleeee) Un paio di orette?

x:Seeeee se ci dice bene 24 ore

Io:Maddai! Non ci credo!

x:Ma sai dobbiamo.....(e spiega)

Io: (c'erano ancora i nastri,mainframe IBM) Ma che, per caso, i nastri

partono veloci e poi rallentano?

x:Siiiii! E tu come fai a saperlo?

Io: Ho vaghezza della bestia  .....(mi dilungo...non erano richieste

modifiche di codice)

x:Ma dici sul serio!?

Io:No. Mi pagano per scherzare [ero li per altro].



Tempo netto di esecuzione 2h3/4 con "bonus" backup dei dati



Ecco! Questo e' un test di /risultanza/









PS:Non e' per te ma per i lurker.



 eventualmente gli integration test



Credo che tu stia parlando degli automated acceptance test. Di solito si scrivono in maniera behaviour-driven (come ngw giustamente dice, usando tool come Cucumber - a volte in congiunzione con Selenium per l'UI):



https://en.wikipedia.org/wiki/Acceptance_test%E2%80%93driven_development




In un modello waterfall, tipicamente la validazione avviene alla fine (ci sono anche oggi UAT che durano mesi lato cliente), ma con Agile, sia che tu lavori per sprint (Scrum) o flusso continuo (Kanban), quel tipo di validazione e` costantemente applicata (i nostri automated test vengono eseguiti dal Continuous Integration server ad ogni build - i piu` lunghi di notte).






Lo ripeto per il tuo bene, smetti di bere.


 specifiche: 
https://cucumber.io/




Anche da noi.

Interessante anche JBehave: 
http://jbehave.org/



 Ecco! Questo e' un test di /risultanza/



Esatto: risultanza che sei un chiacchierone che non ha la minima idea di come si scriva il sofware, ma blatera a vanvera.






 la manutenibilità passa in secondo piano



Ma non scrivere stronzate. Perche` parli di roba che non conosci? Ci tieni cosi` tanto a fare la figura dello scemo? Come fai a garantire che il codice sia funzionante se al tempo stesso non garantisci che sia manutenibile?




 Non ho scritto solo di programmatori incapaci ma anche di tempi ristretti.



Quando si hanno tempi ristretti, il compromesso non e` sulla qualita`, ma sullo scope del progetto.


 la manutenibilità passa in secondo piano



lol, codice non manutenibile non e' funzionante. A meno di non avere una 

botta di culo che vincere al superenalotto e' roba da sfigati.


On Friday, May 12, 2017 at 5:34:37 PM UTC+1, 4ndre4 wrote:



[...]

Ci tengo a precisare che gli automated tests sono di importanza fondamentale. Sono in sostanza quelli che garantiscono la non regressione del sistema. Una volta che ti corazzi di una struttura di test come quella che ti ho citato, puoi anche fare a meno di assumere tester. Io conosco aziende in cui il testing e` tutto automatizzato e non assumono proprio nessuno per il QA.








Poi  te lo spiego dopo nel frattempo succhiati un /lollipop/ o anche il 

pollicione fa lo stesso.







(*) Io li ho usati e sfido chiunque a dire che a lui non e' /mai/ capitato.



 
https://en.wikipedia.org/wiki/Acceptance_test%E2%80%93driven_development




In realta' no, sono molto piu' terra-terra. Il tool che uso io e' il 

JUnit di Eclipse, che e' piuttosto 'manuale'. Anche per quelli che io 

chiamo validation/verification test, spesso mi capita di lanciare gli 

stessi junit raggruppati, con file di configurazione diversi.

Vuoi chiamarlo lavoro artigianale? Beh, non ti sbagli!

:-)

D'altra parte, spesso mi trovo nelle condizioni di un one-man-band.



 pollicione fa lo stesso.



Io, eh? :)


 prassi.



Cazzo, che scopertona. L'hai fatta tutta da solo?



E quindi il punto (che ovviamente ometti puntualmente) quale sarebbe? Che siccome tempo e denaro sono limitati e che teoria e pratica sono differenti, bisogna dedurre che se hai poco tempo per fare un delivery, devi necessariamente scrivere codice a cazzo? Se la risposta e` si`, significa che tu, di informatica, non ci hai capito una beata fava.




 :-)



Semmai ne avessi bisogno, ci vuole un attimo ad ottimizzare quel processo, comunque. Con Maven si fa in 3 secondi, anche meno. 


  significa che tu, di informatica, non ci hai capito una beata fava.



Hai  completamente ragione.

Ora, per favore, mi ti scrosti dagli zebbedei?



 ci vuole un attimo ad *ottimizzare*



Intendevo *automatizzare*.




 Ora, per favore, mi ti scrosti dagli zebbedei?



Quali zebedei (una 'z' semmai), troll?


 Io, eh? :)



Malgrado tutti gli sghignazzi, reitero.

Ho pressanti richieste dai miei zebbedei di liberarli da

/trivial/ infestatori che rovinano codice perfetto.



P.S. anche La Palice e Lapalice erano gratis.

Superavano anche il "behavioural test"



 Ho pressanti richieste dai miei zebbedei 



Zebedei, una 'b', ignorante. 










No! lo smailino che fa tanto /jerk/

(in italiano fa rima)



I miei zzebbbedei continuano a chiedere pieta'.

Cominciano a guardarmi con fare disdegnoso /jerkizzandomi/

çi rispetto! Chiudo.



 I miei zzebbbedei continuano a chiedere pieta'.



Tagliateli. Tanto. 






 azienda.



Andiamo su, Martin, quello di chi non pratica TDD (secondo le sue 3 regole) 

non può considerarsi uno sviluppatore software professionista? Gimme a Break...


 Perche', c'e' qualcuno che li scrive? :D



Dopo aver testato la costante di Catalan, perché no

github.com/const-io/catalan/blob/master/test/test.js



 la manutenibilità passa in secondo piano



beh sì, dai, ci siamo capiti. sono quei progetti su cui sai di lavorare a 

tempo più o meno determinato dopodiché son cazzi di qualcun altro.

dici che c'è un'altra spiegazione? no perché un progetto che viene 

sviluppato ed evoluto negli anni è controsenso dire che non necessita di 

essere manutenibile, è una logica che si spiega solo con menefreghismo e 

malafede.



capite poi da queste parole perché c'è tanta merda in giro.


 Dopo aver testato la costante di Catalan,

Azz! cominci a intrigarmi!



 Azz! cominci a intrigarmi!



brà. mò si'pronto per scrivere i tests dei tests della costante di Catalan. Vai e stupisci



Bono. Siii bono!

Catalan e' un nome su cui sono capitato per caso.

Era un collaterale ai miei interessi

Immagino che stiamo parlando della stessa cosa

A meno che Catalan non sia in catalogna come Smith lo e' in usa.

btw

Io non faccio test! Do soluzioni! ;-)

Mi offendi e deprimi ;-)







Vero!

Siamo quasi pari.

Due giorni a te per avere n post.

5' minuti (mi allargo) a me per averne altrettanti.

La miseria e la nobilta sono, forse, paragonabili.

Talvolta, signori si nasce.

Tu sei un signore te ne fotti della plebe!




Avevo intuito. Anche con Maven, con un ambiente di test unico, devo 

comunque cambiare il classpath a mano se ad esempio voglio scambiare la 

cartella che contiene il file di configurazione che contiene la 

definizione del datasource. Operazione che si fa con due click, per cui 

non mi sono mai chiesto se potesse essere automatizzata anche quella.







Cosa ha a che fare il linguaggio con codice scritto bene (pur con tutte 

le limitazioni che un linguaggio puo avere) ?





Hai capito perfettamente

Non mi riferivo a progetti sviluppati da dipendenti aziendali che poi 

con il tempo devono riprendere in mano per aggiungere funzionalità o 

renderlo piu performante o correggere bachi ad esempio.

Mi riferivo a quei progetti che il consulente di turno fa,sviluppa e se 

ne va.

La prossima revisione sono affari di qualcun altro.








Di codice ne ho visto tanto e modificato tanto.

Pochissimi tra quelli ho preso in mano era scritto decentemente.

L'unico codice letto che e' scritto veramente bene e' il kernel linux 

pur con le limitazioni del C che non e' obj.




 sua, tale Carlo Mottespiego.





coda di paglia suppongo.

Ma non  ti preoccupare,mica avevo scritto che il codice scritto da 

Roberto Tempesti fa schifo.




 fretta, di certo nessuno ci avrebbe risparmiato tempo. Anzi.



Dipende da te o e' un requisito richiesto ?




 Pochissimi tra quelli ho preso in mano era scritto decentemente.



Capisco. Un campione basato sulla sfiga al 99.99%.

Ci vedo un pizzico di collinearita', sai?




Il contrario invece,se so giudicare codice.




>Andiamo su, Martin, quello di chi non pratica TDD (secondo le sue 3 regole) 

non può considerarsi uno sviluppatore software professionista? Gimme a Break... 



E perché non avrebbe ragione?


 Pochissimi tra quelli ho preso in mano era scritto decentemente.



capisco. ma se uno di mestiere fa lo spalatore di letame, difficilmente 

avrà a che fare con qualcosa di diverso dalla merda. mi rendo conto sia 

difficile lavorare ma alla tua età (non mi sembri giovanissimo) offrire 

un profilo basso di "manutentore occasionale" non ti darà certo 

l'opportunità di vedere la crème de la crème. i progetti di buona fattura 

hanno dei team affiatati che lavorano insieme per anni. 


 Il contrario invece,se so giudicare codice.



Non intendevo la capacita' di giudizio, ma la bonta' del campione. Dal 

mero punto di vista statistico, mille persone che valutano codice 

esprimono una statistica che meglio descrive il fenomeno, rispetto a 

cio' che puo' una sola persona.



Poiche' il mezzo non mi permette di disegnare, ti faccio un esempio.



Assumi un tot di termometri regolarmente funzionanti che misurano tutti 

la stessa temperatura al 99.99%, unico dato disponibile rilevato in un 

singolo esperimento.



Senza sbagliare e senza dati ulteriori, si puo' dire che:

- tutti i termometri abbiano misurato la temperatura dello stesso oggetto

- ovunque siano collocati i termometri, abbiano misurato la stessa 

temperatura.



In entrambi i casi con un margine di errore del 0.01%, che potrebbe 

essere compreso nella tolleranza dello strumento di misura, o da una 

perturbazione stocastica delle misurazioni.



In entrambi i casi, la varianza delle misurazioni non e' dovuta agli 

strumenti di misura, ma a cio' che il singolo strumento stesse misurando.



Infine, dire che si puo' predire la temperatura che misurera' qualsiasi 

termometro posto in qualsiasi luogo, in base ad un unico limitato 

esperimento, e' una generalizzazione arbitraria senza alcun fondamento.




eh ho capito, lo so bene che succedono queste cose, ma io stavo facendo 

del sarcasmo sul fatto che tu questi accadimenti li stessi approvando. 


 le limitazioni che un linguaggio puo avere) ?



Considerato che tu hai parlato del 99.99% del software e che una buona 

fetta di software, oggi, e` scritta in Java, stai parlando anche di 

Java. Ti confermi il solito chiacchierone da bar.



-- 

4ndre4



---

This email has been checked for viruses by AVG.

http://www.avg.com





 Hai capito perfettamente



LOL :) Anche tu devi aver capito perfettamente che tu, la produzione di 

merda, la avalli.

Se tu hai dei consulenti che arrivano in azienda, ti cagano nel codice, 

e vanno via, il problema e` TUO. Sei TU che non sai dettare le regole su 

come si produca software nel TUO posto di lavoro. Col cazzo che uno 

entra nel mio team e poi scrive codice come gli pare, fosse anche un 

contractor.



On 12/05/2017 16:50, enoquick wrote:



 >Ha scritto l'esperto.



Specchio riflesso. Sempre una piu` di te e non puoi aggiungere niente.



 Roberto Tempesti fa schifo.



Che culo! Cioe` e` nello 0.01%?



 Pochissimi tra quelli ho preso in mano era scritto decentemente.



A parte che bisognerebbe capire cosa intendi tu per "decente" (dubito 

fortemente sia la stessa definizione di Uncle Bob), e` chiaro che stai 

parlando del 99.99% del codice che vedi *TU*. E` ovvio che sia cosi` se 

avalli l'idea che, quando i tempi sono stretti, il codice debba 

necessariamente essere una merda. Chi ti passa del codice puo` sempre 

usare la scusa "eh, sai, non avevo mica tempo di aggiungerci frocerie 

come gli unit test!" e a te la cosa stara` bene.




A cosa ti riferisci con requisito richiesto?


 le limitazioni che un linguaggio puo avere) ?



niente. era solo per chiarire quale fosse il tuo punto di osservazione 

quando scrivi che il 99.99% del codice da te visionato fa cacare.


 Dipende da te o e' un requisito richiesto ?



Che cazzo di domanda eh?



La tua azienda ha necessita di produrre software, venderlo ai clienti e 

rispettare le hard deadlines imposte da governo, istituti regolatori, 

etc.. Nel mondo finanziario/bancario, per esempio, esistono scadenze 

fisse e non modificabili a cui tutti debbono attenersi.



Che cosa stai suggerendo per raggiungere quell'obiettivo? Che bisogna 

correre, scrivere codice alla chi-pijo-pijo, pur di impacchettare e 

rilasciare? Bella merdata. Il cliente passera` mesi di UAT a scovare 

bugs, ti chiedera` di risolverli a spese *TUE* e la sua sicurezza nelle 

tue capacita` di sfornare un prodotto di qualita` calera` sensibilmente, 

fino al punto, magari,  di rivolgersi ad altri. Fatto realmente 

accaduto: ho visto un grosso stockbroker inglese cambiare direzione, con 

il fornitore software spiattellato sul Financial Times come 

preracottaro. Conseguenza: bonus non pagato ai dipendenti, frustrazione 

generale, gente che andava via, nuovi clienti bruciati.



Il software deve essere di qualita`, scritto come si deve, testato 

durante lo sviluppo e *PRIMA* di raggiungere il cliente, e consegnato 

nei tempi giusti. Non e` utopia, si puo` fare. Gli spalamerda come te, 

ambienti del genere non li hanno mai visti.



 non mi sono mai chiesto se potesse essere automatizzata anche quella.



Si, si puo` fare. Ma quindi tu sviluppi principalmente localmente, no? 

Non hai un processo di Continuous Integration in piedi...



 diversi db indifferentemente, nel caso le specifiche lo richiedano.



Tipico integration test. Potresti anche farlo con ambienti virtualizzati 

(Docker e/o AWS). Nel nostro sistema, Jenkins si occupa di lanciare il 

build, e tramite Ansible si installa tutto sul sistema di integration 

test. Tiri su un'istanza con Oracle e testi; tiri su un'istanza con SQL 

Server e testi.







Non ho letto gli altri post, ma come direbbe un mio conoscente: "la 

risposta e' dentro di te". E,anche se se fosse "sbajata" come dice

questo mio conoscente, e' anche uno dei motivi (forse il principale) per 

cui personalmente non mi occupo piu' di informatica.



E la risposa e': "i soldi che entrano nelle tasche di dell'informatico X 

non dipendono nemmeno in piccolissima misura, dalle competenze 

informatiche di X, almeno nel caso in cui X lavori per il mercato

(ma presumo che anche se X fa il ricercatore sia cosi'. Anzi,

forse lo e' in misura ancora maggiore)."



Ciao,

Marco.







mi sa che per errore ti ho risposto alla tua email chiedo scusa.



Comuqnue il riassunto della risposta era che quello che si guadagna

come informatici non dipende dalle proprie conoscenze informatiche

(e forse questo vale anche per gli altri lavori. E' probabile che

i soldi che entrano nelle tasche di Tizio dipendano da quanto

Tizio e' abile "a fare soldi" piuttosto che dipendere da quanto

Tizio conosce bene il proprio lavoro).



 come informatici non dipende dalle proprie conoscenze informatiche



Questa e` un'enorme fesseria.




In genere no. Mi e' capitato, ma partecipavo ad una commessa con diversi 

contributors, il committente controllava, ma non conosco esattamente le 

modalita'.



 Server e testi.

Uso server virtualizzati, ma non nel senso e la complessita' che dici tu.



 forse lo e' in misura ancora maggiore)."



lasciando da parte il solito tono da "notte prima del suicidio" che ormai 

sappiamo è un tuo marchio di fabbrica, ma mi spieghi che c'azzecca con la 

sua domanda?


 A cosa ti riferisci con requisito richiesto?



Se la manutenibilità o la scalabilità fossero requisiti richiesti








Non ho scritto che non sviluppo sw

Ho solo scritto che di sw fatto da altri ne ho manutenuto parecchio

Sai,quando si lavora,si lavora e basta.

Mica si fa li schizzinosi solo perché un sw e' stato scritto da qualcuno 

d'altro








Ed ho visionato codice scritti in non so quanti linguaggi compresi i 

vetusti COBOL, Fortran e PL1




 botta di culo che vincere al superenalotto e' roba da sfigati.



Questo lo dici tu,ma non e' vero

Un sw puo essere scritto da schifo ma passare i regression test.








Non li approvo,ma li capisco

In passato mi e' capitato di girare un po di qua ed un po di la.








Capisco, la risposta e':

intuito




 intuito



Bene, ora sappiamo che a quel 99,99% possiamo sostituire un numero preso 

a caso tra 0 e 100.




Mica tanto,un bel po di codice l'ho letto e/o revisionato





eh? non ho mai parlato di scalabilita', per quanto riguarda la 

manutenibilita' serve un requisito?? Ci lavoro giornalmente su quella 

piattaforma, decido io quanto deve essere manutenibile (cioe' il piu' 

possibile relativamente alle mie capacita'), non certo il manager.



Cmq non ha senso la domanda, toy projects a parte, quando mai non si 

deve far di tutto per scrivere codice manutenibile?


 d'altro



certamente, questo era nelle mie premesse.

proverò a spiegare il concetto in altro modo. 



i progetti che fanno ricorso a manutentori esterni con turnover intenso 

sono in prevalenza i peggiori. il motivo l'hai ammesso anche te, 

manutentori scappa e fuggi non badano alla qualità del loro lavoro (di 

conseguenza neanche chi li recluta). quindi fintanto tu ti venderai con 

questo profilo ti ritroverai sistematicamente a visionare codice di 

merda, ma non perché tutto il codice sia sistematicamente di merda bensì 

perché sei te che, volente o nolente, fai una selezione. 



parafrasando un noto detto, non dovresti accettare quei progetti che sono 

disposti ad accoglierti come manutentore.


 di qua ed un po di la.



e da come parli deduco sarà capitato anche a te di comportarti così, 

immagino.











Certo, sopratutto dopo che te lo rimandano indietro una decina di volte. 

In quel caso proabilmente overfitta i regression test.



Cosa succede poi in produzione? Te lo dico io: altra cargata di bug, 

altra cargata di fix alla cazzo, e bug moltiplicati per 2. E cosi' via 

finche' il manager non decide che va riscritto da zero.



mi verrebbe da dire un software che passa i regression test e, 

soprattutto, li implementa, non è scritto poi così da schifo.


 PS al mio line manager interessa che io produca, cosa che io faccio puntualmente.



"line manager"?! E che è, uno stilista di moda?! X-D






 per conto suo?



Ma tu sei la sua ragazza, cioè quella che chiamava "codicini" quello che faceva

lui?









Intende i test fatti da JMarioRossi, punta e clicca :D


 Mica tanto,un bel po di codice l'ho letto e/o revisionato



Per cui e` il 99.99% del codice che hai visto tu.



-- 

4ndre4



---

This email has been checked for viruses by AVG.

http://www.avg.com





 Se la manutenibilità o la scalabilità fossero requisiti richiesti



C'e` bisogno che qualcuno ti *chieda* di scrivere codice manutenibile?







Che +/- simile a quanto scritto nell'altro post ;-)

"Quasi" completamente d'accordo nel senso che cio' che scrivi

e' il risultato di cio' che darebbe una "indagine" di mercato.

Poi, come qualsiasi curva a campana, ci sono gli estremi ;-)

Quell'altro che ti ha risposto sta nella parte /bassa/ della curva ;-)

-- 

ac (x=y-1)

Aborro il Killfile

(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)


 e' il risultato di cio' che darebbe una "indagine" di mercato.



Stronzata (come al solito). 

Da quel che vedo io, i bravi guadagnano bene perche` accedono a lavori di un certo livello per via delle proprie competenze. Capisco che per chi e` affetto da bias cognitivo come voi, le altre volpi raggiungono l'uva solo perche` l'uva pende troppo.






 E perché non avrebbe ragione?



Perché è un'affermazione da emerito cretino, plain and simple.



Scusa un attimo,ma a me risulta che esistono sw scritti anche molti anni 

fa (non con linguaggi obj quindi),magari in COBOL,Fortran,PL1,vb6 

(orrore),ecc.. che vanno avanti da anni.

Secondo te come fa un progetto fatto in questi vetusti linguaggi essere 

un progetto facilmente manutenibile,tenendo conto di quello che sono 

questi linguaggi e di quello che erano la media dei programmatori 

dell'epoca.

Eppure questi sw vanno avanti, in un ambiente di produzione, da molti anni.





No,mai





Ora non lo faccio piu,ma la pagnotta occorre sempre portarla  casa.





Perche il codice manutenibile (quello fatto ad ok,non sufficiente 

manutenibile) costa in termini di tempo.

Un sw fatto ad ok,passi la progettazione una volta,due,tre,ecc..

Ma si vede che tu quando progetti una classe va subito bene al primo 

colpo per la produzione.

Buon per te.




 Buon per te.



toglimi una curiosità, il tuo codice è leggibile come i tuoi messaggi? si 

spiegherebbero molte cose.





piu' che di leggibilita', io parlerei di crassa ignoranza.






Progetto una classe? Subito bene? Ma tu hai la benche minima idea di 

come si sviluppa software nel 2017 (ma anche da almeno una decina d'anni 

a questa parte)?






Se parli di progetti fatti da culo che vanno avanti da anni, e che 

"funzionano", stai omettendo due particolari



1. funzionano ora dopo anni di aggiustamenti e test, ma prima di 

funzionare sono costati uno sproposito in termini di figuracce con il 

cliente, tempo perso e gente che scappa



2. non li tocca piu' nessuno. Il mega modulo scritto con il culo che 

nessuno capisce cosa faccia realmente ma che tutto sommato "funziona", 

nessuno osa metterci le mani, o addirittura il manager vieta che 

qualcuno ci metta le mani.



Quello che ho riportato io e' esattamente quello che accadeva fino a 4-5 

anni fa in aziende come Ericsson, Telecom, Wind, H3G, Poste Italiane, 

aziende varie del Gruppo Finmeccanica, banche, assicurazionei, ecc.(per 

non parlare poi di aziende tipo Accenture e Reply). Ovvero e' quello che 

accadeva in aziende dove ai miei tempi lavoravano i 3/4 degli 

informatici in Italia (non perche' lo dico io ma perche' lo ha scritto 

qui sopra tempo fa qualcuno che si occupava di questioni sindacali)



Non so cosa tu intenda per "lavori di un certo livello". Per me

"lavori di un certo livello" sono ad esempio quelli che si fanno

nelle universita' (sostanzialmente la ricerca scientifica in genere,

anche in ambito informatico). Ma non mi risulta che i ricercatori

in Italia siano particolarmente ricchi grazie al loro lavoro

(che sicuramente richiede molte piu' competenze rispetto al normale

lavoro "per il mercato").



Per quanto riguarda volpe e uva, io non lavoro piu' come informatico da 

anni e al momento non mi interessa tornare a lavorare come tale.



  L'ultimo contatto che ho avuto e' stato l'anno scorso o due anni fa a 

settembre/ottobre perche' mi ha

telefonato una tizia che non ho nemmeno capito esattamente per conto

di quale azienda b.r. mi chiamasse (forse era la un tempo famosa

"archimede informatica", ma non ne sono certo). Mi ha detto piu' o meno:

"abbiamo una richiesta di un test engineer da parte di un nostro

importante cliente, ovvero Reply, blah blah blah".



Risposta:

"Grazie dell'offerta ma non mi interessa". Click.



Effettivamente potrebbe essere un atteggiamento da "volpe" nei

confronti dell'"uva", ma se per te andare a lavorare in un'azienda b.r. 

che ti manda a lavorare

presso Reply (o meglio un suo cliente, che probabilmente rientrerebbe 

tra quelli citati sopra)

rappresenta "l'uva" ovvero "un lavoro di un certo livello", siamo messi 

veramente bene





Ciao,

Marco.



 lavoro "per il mercato").



Ti risulta male:



https://www.reed.co.uk/jobs/java-developer/32160413#/jobs/java-developer-in-london




scua ma che c'entra un lavoro a Londra (che, tra l'altro non mi pare un 

lavoro da ricercatore) con quello che guadagna un ricercatore in Italia ?



Se intendi che i required skill sono tanti, ovvero



     Agile

     Finance

     Financial Markets

     Front Office

     Maven

     Pricing

     Risk

     TIBCO

     Trading

     Low Latency

     C

     J2SE

     FX

     DevOps

     Concurrency

     Quants

     Fintech

     Java 8

     OneTick

     Microservices

     SR Labs

     StreamBase

     Gradle Key Terms: Core Java

     High throughput



va bene ma prima di quell'elenco c'e' scritto



We're not necessarily looking for you to have worked with the below, as 

long as you are an outstanding J2SE Java Developer with good initiative 

and passion for what you do.



E ti secondo me  un ricercatore medio che scrive le sue cose in java

probabilmente conosce buona parte dei required skills

(tranne probabilmente

quelle legate al mercato come Finance, Finance market ecc.).



Immagino che un ricercatore italiano medio conosca bene



Agile, Maven, Low Latency, C, J2SE, FX, DevOps, Concurrency, Java 8, 

Microservices,  High Throuput



e in genere servono competenze analitico/matematiche che spesso non sono

richieste per il mercato



Quindi ha almeno la meta' delle competenze richieste, piu' altre 

competenze logico matematiche. Ma secondo me' 50.000 Euro/anno non li 

prende.



>Perché è un'affermazione da emerito cretino, plain and simple. 



Quanto detto da Martin ha assolutamente senso: uno sviluppatore software professionista, oggi, DEVE sapere cos'è TDD, DEVE saperlo appicare, e DEVE applicarlo nei propri progetti. Ci sono molti sviluppatori poco aperti all'apprendimento di concetti nuovi, che si trincerano dietro la classica zona di comfort "nel mio caso non si può fare".

Peccato che sia una scusa robusta come una bolla di sapone. 



Il punti è semplice: per scriverè il 99% del software (diamo il beneficio del dubbio all'1% giusto per evitare il solito scemo di ili che parte per la tangente su come certe cose non si possano fare nel suo piccolo contesto) DEVI definire degli acceptance criteria. Se hai degli acceptance criteria, puoi scrivere i test. E puoi fare tutto upfront. Non ci sono proprio scuse valide per non usare TDD.



Altro che cretino (prima di dare del "cretino" ad Uncle Bob, poi, ci penserei un milione di volte).


E chi te lo di che siano facilmente manutenibili?


>Perche il codice manutenibile (quello fatto ad ok,non sufficiente 

manutenibile) costa in termini di tempo. 

Un sw fatto ad ok,passi la progettazione una volta,due,tre,ecc.. 

Ma si vede che tu quando progetti una classe va subito bene al primo 

colpo per la produzione.



A parte che si dice ad hoc (ad ok) che cosa vuol dire che il codice manutenibile "costa in termini di tempo"? Passare la progettazione una volta, due volte, tre? Una classe che va subito bene per la produzione? Ma di che parli? Ma tu sai come si scrive il software oggi? Da quel che scrivi si capisce bene quanto tu sia solo un manutentore di vecchi sistemi scritti pure alla cazzo.


Da quel che scrive, è chiarissimo come lavora costui: scodella codice il più velocmente possibile, ed ovviamente il suo codice finisce per essere infognato di bug. Torna indietro, ritocca la classe. Nuovi bugs. La ritocca. Nuovi bugs. Ad libitum. E ovviamente fa di questo suo modo di lavorare quello del 99.99% degli informatici.


io non lavoro piu' come informatico da 

anni e al momento non mi interessa tornare a lavorare come tale.



Lo hai raccontato almeno venti volte.

E allora cosa segui a fare sto ng e cosa parli di informatica?  




 qualcuno ci metta le mani.



LOL! Magari il manager ci fa pure appioppare una targhetta sul modulo

con su scritto: "Vietato toccare!" X-D








e in genere servono competenze analitico/matematiche che spesso non sono 

richieste per il mercato 



Ma quando mai. Immagini. Ma parlare per dati reali e non per immaginazioni, no eh? O sei confuso su cosa significhi essere un ricercatore, o sei confuso su cosa Agile, Maven, DevOps, Microservices significhi. Scegli. Io ti chiedo: come pretendi di sapere certe cose quando sei lontano ormai dall'informatica da anni?


 A parte che si dice ad hoc (ad ok)

CUT



"ad ok"?!??!?!?!!?!?!??!?!?!?!?!?!?!?!?!?!?!?! O_o :-O



LOL!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!



Mai studiato il latino?!



"ad hoc" = letteralmente "per questo"



https://it.wikipedia.org/wiki/Ad_hoc







>non li tocca piu' nessuno.



Esatto. Ma la cosa bella è che spesso non sono neanche "toccabili". Non so se l'ho già raccontato (credo abbia un inizio di carite aka deltite aka selmite): un software di ordini in borsa; il cliente chiede di poter modificare le note attaccate ad un ordine senza che ciò  scateni un un nuovo processo di approvazione dell'ordine. Richiesta del tutto sensata visto che le note sono solo dati a margine dell'ordine. Gli dico che è ovviamente fattibile senza neanche consultare l'architect. Costui invece mi risponde imbarazzato che la cosa non si può fare perché troppo complicato. Si trattava di software che aveva sempre funzionato, per 25 anni e passa, scritto in RPG.


Demente, quale parte di "a parte che si dice ad hoc" non ti è chiara? "Ad ok" lo ha scritto enoquick, COGLIONE che non sei altro.


 Ma quando mai. Immagini. Ma parlare per dati reali e non per immaginazioni, no eh?



Uh... che bolas...

Ho lavorato 3 anni qui:



http://www.santannapisa.it/it




anzi in particolare qui



https://retis.sssup.it/
 (che e' uno dei lanboratori dell'ente di cui sopra)



pensi che di ricercatori non ne abbia conosciuti nessuno ?





maven l'ho usato anch'io (anche se in anni successivi).



Scegli. Io ti chiedo: come pretendi di sapere certe cose quando sei 

lontano ormai dall'informatica da anni?



come ho scritto negli altri post

e' possibile che negli ultimi anni sia cambiato molto,

ma quello che ho scritto e' basato sulla mia esperienza

In ogni caso, se tu conosci qualche ricercatore piu' "recente", magari,

invece di sparare minchiate sugli altri, perche' non scrivi cosa gli

e' richiesto oggi a un ricercatore e cosa e' richiesto a uno che lavora

per il mercato?



 per il mercato?



Datti una calmata. Le minchiate le stai sparando tu, ed anche perche` ormai di informatica non e` che ci acchiappi piu` molto. Non me ne frega un cazzo dei ricercatori. Li hai tirati in ballo tu. E a cazzo, come al solito. Il discorso era partito da lavori che richiedono competenze specifiche. Cosa cazzo c'entrano i ricercatori lo sai solo tu.






All'estero anche di piu'. Allora il problema e' l'Italia? Forse ma non 

proprio.



Anche in Italia le competenze impattano positivamente sul salario solo 

che la scala e' diciamo logaritmica. Per cui tra uno che sa molto e un 

cialtrone la differenza di salario c'e' ma meno di quello che dovrebbe 

essere in un mercato sano.


 essere in un mercato sano.



Questo e` vero un po' dappertutto. Ho sempre sostenuto che se dovesse lavorare solo chi sa lavorare (e non mi riferisco solo all'informatica, ma ad ogni tipo di lavoro) 3/4 di mondo dovrebbe stare a casa. Bisogna considerare che c'e` gente come ciccio che viene pagata per fare un lavoro in qualche modo informatico. Lo so che sembra incredibile, ma e` cosi`.


 contesti) si scrivono test e poi si sviluppa il codice. E questo e`



Test-driven development? E' un tipo di approccio che non sono veramente 

mai riuscito a fare mio. Ho anche visto in tempo reale della gente 

(molto più giovane di me) che lo faceva: troppo distante dalla mia forma 

mentis e da come ho imparato a programmare.



Anche io uso i test, specialmente di unità, ma scrivo sempre prima il 

codice, poi i test e man mano che il codice si evolve mantengo i test 

allineati con il codice. Ma quest'ultimo è sempre quello che cambia per 

primo.



TheStar


 Buon per te.



tornando a noi, siccome anch'io un po' di esperienza ce l'ho e non solo 

di lettura di codice ma anche con le persone, perdonami se sono *molto* 

scettico quando vedo codice ingestibile e l'autore si giustifica dicendo 

che gli è mancato il tempo per scriverlo meglio.



lasciando da parte i test, che indubbiamente rappresentano la situazione 

ottimale ma non sono il requisito primo per la manutenibilità: ci sono 

persone che sanno programmare (conoscono i paradigmi, padroneggiano il 

linguaggio, sanno comunicare con il team, sanno semplificare i problemi, 

etc, etc) e persone che non sanno programmare (conoscono poco e male i 

paradigmi, inciampano sul linguaggio, comunicano poco e male con il team, 

complicano i problemi, etc, etc). i primi scrivono codice leggibile e 

manutenibile senza overhead, i secondi scrivono codice di merda e più 

tempo gli dai più scrivono merda (è proprio scientificamente provato).




Vedi cosa succede a dimenticarsi le medicine....? Devi stare piu' attento.




Visto che "medaglia" mi sono guadagnato?....mica pizza e fichi!


 mai riuscito a fare mio.



E` un peccato, perche` TDD, piu` che una tecnica di testi del codice, e` una tecnica di design del codice (molti lo chiamano test-driven design). Se si usa TDD, la qualita` del codice prodotto sara` quasi sempre migliore di quella di un codice non-TDD.



La fase piu` importante di TDD e`, infatti, quella del refactoring. Gli acceptance criteria li puoi soddisfare anche con codice mediocre, per iniziare. Potrai riscriverlo avendo la rete di sicurezza dei test.



Per istruire i miei colleghi junior, io ho persino scritto un Tetris in TDD :)


 primo.



Ho lavorato cosi' per anni. A mio avviso e' una mezza perdita di tempo,

nel senso che alla fine il codice cambia sempre, e la prima

implementazione viene sempre cestinata proprio per mancanza di focus e

prospettiva.



  ngw




 La fase piu` importante di TDD e`, infatti, quella del refactoring. Gli acceptance criteria li puoi soddisfare anche con codice mediocre, per iniziare. Potrai riscriverlo avendo la rete di sicurezza dei test.



Il TDD è una grande idea. Io, come lui, per i primi tempi ho avuto molte perplessità - probabilmente si tratta di resistenza a cambiare un metodo di lavoro che per decenni comunque risultati ne ha portati; arriva a un certo punto però una sorta di 'epifania', e da quel momento cominci a pensare esattamente al perché non hai usato quel metodo prima.



Io, confesso, ho ancora qualche difficoltà con la roba MOLTO passata. Capita di riprendere in mano codice - anche scritto da me - molto vecchio con lo scopo di aggiungere o modificare qualche funzionalità. Ecco, in questo caso, anche forse per la strutturazione del tutto, tendo a lasciar perdere. Tu, che hai più esperienza, come affronti / affronteresti la questione? Sapendo, ovviamente, che la riscrittura del tutto è fuori discussione.



Aggiungo, visto che ci sono, un'altra domanda. Come garantire in modo efficace che i test siano corretti? Mi spiego meglio. Tempo addietro mi è capitato di scrivere un test errato. Tenendo dimensionalmente piccolo quanto testato, lo si scopre velocemente (il codice, riletto tre volte, non aveva errori, per cui...). Però mi sono chiesto se non vi siano delle best practices anche per la scrittura dei test. Tu che dici?



-- 

Ciao!

Luca


 prospettiva.



Secondo la mia esperienza c'è anche un altro aspetto positivo. La modifica del test di da un extra tempo per pensare se veramente la modifica che stai facendo alla specifica funzionalità ha senso. Capita di rado, ma quando capita che per mille motivi (baruffa con la moglie) hai pensato a una modifica che di fatto non serve, recuperi il test senza aver toccato codice funzionante.



-- 

Ciao!

Luca



Appunto, cambia completamente la prospettiva. Quando scrivi il test fai

da client alla classe/servizio/funzione, e spessissimo quello che

sembrava geniale da implementor della classe e' inutile/dannoso fungendo

da client.

Sembra una scemenza ma e' sorprendente il numero di "ma a che cazzo

stavo pensando"?



  ngw




 Aggiungo, visto che ci sono, un'altra domanda. Come garantire in modo efficace

 > che i test siano corretti?



https://www.amazon.co.uk/Effective-Unit-Testing-Lasse-Koskela/dp/1935182579/ref=sr_1_1?ie=UTF8&qid=1494858430&sr=8-1&keywords=effective+unit+testing




 > Però mi sono chiesto se non vi siano delle best practices anche per 

la scrittura dei test. Tu che dici?



Ci sono, ma sono piu` che altro skill che si acquisiscono nel tempo. 

Scrivere test corretti (e sopratutto non banali) non e` affatto facile. 

Guardare al test coverage (alcuni IDE come Java ce l'hanno integrato) ti 

da` una buona idea di quanto i tuoi test coprano. Tool di analisi 

statica come SonarQube fanno lo stesso lavoro.



In realta`, per scrivere buoni UT, basterebbe partire da alcune piccole 

regole:



1) esprimere il nome del test correttamente - a me piace la convenzione:

    a) nomeMetodo_parametroOCondizione_risultatoAtteso()

       per le condizioni di errore o happy path specifici



    b) nomeMetodo()

       per l'happy path di default



Se, per esempio, voglio testare che il mio Calculator.divide(a, b) 

calcoli correttamente una divisione, creo i test:



        divide_negativeArguments_resultIsPositive()

        divide_zeroDenominator_throwDivideByZeroException()

        divide()



2) ogni metodo di test deve testare 1 cosa ed 1 sola:

    io suddivido sempre i test in "zone" Arrange / Act / Assert:

        divide_negativeArguments_resultIsPositive():

             // Arrange

             num = -3;

             den = -2;



             // Act

             res = Calculator.divide(num, den);



             // Assert

             assertThat(res > 0, is(true));



Questo aiuta a tenere lontana la tentazione di buttare assert() nel 

mezzo, per testare condizioni che non sono specifiche del test in questione.



3) i collaboratori di una classe sotto test NON devono essere concreti, 

per cui tutte le istanze devono essere mock con comportamenti prevedibili;



etc... etc... etc...



-- 

4ndre4



---

This email has been checked for viruses by AVG.

http://www.avg.com





 > Sembra una scemenza ma e' sorprendente il numero di "ma a che cazzo

 > stavo pensando"?



Quanto e` vero...







Di questo direi che nessuno te ne possa fare una colpa. Il problema e' 

quel 99.99%, drogato dalla tua attivita' prevalente.



 stavo pensando"?



Scemenza? Sapessi quanto spesso capita, e in modo indipendente dal contesto...



;-)



-- 

Ciao!

Luca


 qualcuno ci metta le mani.

!!



-- 

ac (x=y-1)

Aborro il Killfile

(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)


 qualcuno ci metta le mani.





Testina, cosa c'entra ?

In produzione ci sono e vanno.





Testina,non ho scritto che tu scrivi codice decente.

Semplicemente non lo so.




 In produzione ci sono e vanno.



Ah, pensavo si consumassero a forza di usarli.



D'altronde, a dirla tutta, solo un cretino poteva abboccare alle cagate 

noeuro. Ecco a voi un autentico cretino doc, o d'ok se preferite :D



uhm, quindi abbiamo ricostruito un paradosso. il codice del tempesti come 

il gatto di schrödinger, descritto come sistema quantistico è 

contemporaneamente schifoso e decente.



Beh, ti sei spinto un po' oltre l'asticella affermando che il 99.99% del 

codice e' scritto a cazzo. Ho reagito perche' e' molto probabile che 

possa rientrare in quel tuo numero e tu, e lo affermi tu stesso, 

"semplicemente non lo sai". In questo caso si tace.

P.S. Il termine "testina" usalo con tua sorella.






Ciccino, ma perchè insisti con queste figure di merda?

Hai bisogno che qualcuno si accorga di te?








 Datti una calmata. Le minchiate le stai sparando tu, ed anche perche` ormai di informatica non e` che ci acchiappi piu` molto. Non me ne frega un cazzo dei ricercatori. Li hai tirati in ballo tu. E a cazzo, come al solito. Il discorso era partito da lavori che richiedono competenze specifiche. Cosa cazzo c'entrano i ricercatori lo sai solo tu.



Come si dice dalle mie parti "son piu' bischero io che ti do' retta".



E con questo ti saluto.



 per cui tutte le istanze devono essere mock con comportamenti prevedibili;



Concordo. Tuttavia



https://8thlight.com/blog/uncle-bob/2014/05/10/WhenToMock.html




Robert C. Martin non sembra apprezzare questo stile. Quindi neanche 

quello divulgato da "Growing object-oriented software guided by tests". 

Lui i mock li concepisce solo per tagliare fuori dal test sottosistemi 

"lenti" e unpredictable che chiaramente non possono essere testati in 

uno unit test.



Alcune critiche le condivido, ad esempio sull'esplosione di interface 

(che comunque non sarebbero richieste per usare jmock ad esempio).



Pero' mi viene da dire, se non sono d'accordo neppure tra loro 

,influencer globali, e' dura divulgare uno stile.






 qualcuno ci metta le mani.



Qualcosa di simile, anche se non proprio cosi', mi fu detta quando mi

chiamarono ad un colloquio presso un'azienda che si chiamava Sofiter

nel 2009. Insistettero molto al colloquio a dire che per nessun motivo 

era ammesso aggiornare ad esempio la versione di java in uso ne'

  introdurre alcun tipo di innovazione.Alla fine io non ci andai, ma poi,

  quando lavoravo presso Postecom, nel 2010, conobbi alcuni che ci 

avevano lavorato e mi dissero che dopo che avevano scritto del normale 

codice java furono rimproverati perche' avevano usato delle 

caratteristiche del linguaggio che costituivano "un'innovazione" e che 

quindi non avrebbero dovuto essere usate (perche' appunto in

  quell'azienda non volevano assolutamente che nel loro codice fosse

introdotta alcuna "innovazione"). Putroppo non mi ricordo quali fossero 

queste caratteristiche "innovative" pero' ricordo che il programmatore 

java di postecom, che era presente al racconto, disse: "ma queste 

caratteristiche sono state introdotte  nel linguaggio nel 1992!!"



Ciao,

Marco









Nel 1992 non esisteva ancora, o forse esisteva solo nella testa di Gosling.


 Per istruire i miei colleghi junior, io ho persino scritto un Tetris in TDD :)



E i junior ci hanno giocato?! LOL! :-D






 in TDD :)



Hai ragione da vendere. E' che è un approccio così diverso dal metodo 

tradizionale, che hai per forza bisogno di formazione adeguata, non è 

una cosa che si riesce facilmente ad imparare da soli.



Specie se arriva in continuazione gente che ti dice che il software X 

dev'essere pronto dentro la data Y e soprattutto in un contesto in cui 

si fa fatica persino a diffondere l'uso di un programma di controllo di 

versione, e devi vigilare come un cane da guardia affinché la gente lo 

usi regolarmente...



TheStar


 Hai bisogno che qualcuno si accorga di te?



E tu hai bisogno che un 4-ndre-4 si accorga di te?!






 anni e al momento non mi interessa tornare a lavorare come tale.



Non credo che intendesse te come /volpe/ ma il sottoscritto.

Parafrasando Wittengstein, se il linguaggio che si usa e'

il mondo che si conosce, il mondo di 4ndre4 deve essere abbastanza

limitato.



 (che comunque non sarebbero richieste per usare jmock ad esempio).



Anche quella sull'eccessivo setup dei mock, e sul fatto che diventino 

molto fragili se "mockano" troppo, e` un problema che ho incontrato 

spesso. Non so pero` come scrivere i propri mock (come Uncle Bob 

suggerisce) possa risolvere questo problema. Ammetto di non averci 

ragionato troppo sopra.



 versione



'azz, questo e` grave.



 In questo caso si tace.



Hai centrato il problema.



 Come si dice dalle mie parti "son piu' bischero io che ti do' retta".



"do", senza apostrofo.



E "bischero" lo sei per quel che scrivi.



 caratteristiche sono state introdotte  nel linguaggio nel 1992!!"



Cazzo, un genio anche lui, eh? Visto che Java e` stato creato nel 1995.




Il problema poi e' che in ambiente JEE questi boundaries sono un po' 

ovunque. Per cui ogni volta devo testare uno statless bean, instanzio 

l'oggetto, assegno ai collaboratori i mock (non uso private per le 

dependencies), creo le expectations, chiamo il metodo da testare e via. 

Farlo a mano sarebbe francamente un inferno.



Comunque non credo che intenda dire che scrivere i propri mock risolve 

il problema. Dice semplicemente che non vuole librerie di mock fra i 

piedi perche' rallentano l'esecuzione dei test, introducono tecnicismi 

ulteriori (sono una sorta di DSL aggiuntivo), e che per l'uso che ne fa 

lui non valgono la pena.



Ma poi sono lenti davvero? Le ultime JVM dovrebbe aver fatto passi da 

giganti per quanto riguarda la reflection...






Non trovare scuse,scritto di fretta puo capitare (come scrivere codice 

di fretta).




 a questa parte)?



Non si scrivono piu le classi ?








Hai perfettamente ragione

Ma in un progetto veramente complesso (metti 1000 o piu classi)

ti voglio vedere il bravo programmatore che azzecca completamente bene 

la progettazione di tutte le classi al primo colpo.




 la progettazione di tutte le classi al primo colpo.



quindi? stai dicendo che solo alla prima stesura di getto scrivi codice 

di buona fattura?




Beh, non esattamente. Per quanto mi ricordi, nel '95 Sun annuncio' la 

general availability, ma il linguaggio esisteva gia' da qualche anno. 

Forse e' possibile che da qualche parte abbia ancora i reference in file 

.ps, precedenti la pubblicazione degli stessi da parte di Addison-Wesley.







Inutile discutere con chi intende fischi per fiaschi. Ad hoc, ad ok, 

sillogismo, progettare, scrivere....tu usi le parole a caso. Addio.



L'avevo gia' detto e continuo a pensarlo: questo enoquick non puo' 

essere vero.



Il fatto che dica cose diametralmente opposte a quelle corrette, mi fa 

pensare che sappia la risposta e che stia facendo la parte del cretino.



D'altronde uno che scrive ad ok invece di ad hoc, e te lo giustifica con 

"e' un sillogismo", neppure il piu' grande cretino sulla terra potrebbe 

arrivare a tanto. Involontariamente intendo.


 giganti per quanto riguarda la reflection...



Dipende da quali. Io uso prevalentemente Mockito e non mi sembra i test soffrano di particolare lentezza. Pero` sinceramente e` un aspetto che non avevo mai considerato. Faro` qualche performance test. 




 Non si scrivono piu le classi ?



Non come pensi tu.


 la progettazione di tutte le classi al primo colpo.



A parte che la complessita` di un progetto non si valuta dal numero di classi, il "bravo programmatore" non e` uno che scrive 1000 classi di botto, perfette, ma uno che sa far evolvere il proprio codice senza troppi problemi. Ed oggi ci sono strumenti (che tu evidentemente non conosci) per farlo.





La posizione di Martin e' molto comune nella comunita' Elixir, il

suggerimento e' tipicamente di usare i mock il meno possibile.

Questo per esempio e' Valim, che Elixir l'ha "inventato":

http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-contracts/




La velocita' e' l'ultimo dei problemi (i test poi si possono

parallelizzare pure in Ruby, figuriamoci su JVM o vm Erlang), il

problema e' che se ti distrai e passi il segno non stai piu' testando il

tuo software ma i mock :p



  ngw






On 17/05/17 06:41, rootkit wrote:


Fosse cosi' allora dovrebbe seriamente pensare di adottare TDD :P



  ngw





secondo me sta dicendo che lui di base scrive codice manutenibile, che 

però gli si incasina quando lo va a manutenere.

usando un eufemismo diciamo che è un po' confuso sul concetto di 

manutenibilità, ecco :P


 facile e manutenibile ?



Risponderei che e' conveniente: se lavori in

un ambiente dove lavorare bene e' importante c'e' il

vantaggio personale di migliorarsi sempre e tenersi

aggiornati ed e' piu' probabile che il ruolo ricoperto

sia riconosciuto come una professione di alto livello

(quale in effetti e') e dunque riconosciuta socialmente

e anche dal punto di vista retributivo.



E' vero che ci sono situazioni nelle quali la

qualita' del lavoro svolto non conta molto, e magari

qualche problema in piu' puo' perfino essere sfruttato

per fare piu' cassa (tipo gonfiare l'assistenza post vendita)

ma dal punto di vista dell'onesto lavoratore sono

situazioni in cui, avendo solo le sue mani

e il suo cervello da far valere, lui conta ancora meno



Estremizzo per chiarire:



se fai il muratore per un'azienda edile intrallazzata

che prende lavori per ammanicamento e fa le case di sabbia

per avere piu' margine di guadagno non impari a lavorare

bene e non conti nulla.



Se lo fai per un'azienda che deve fare dei lavori ben fatti

per stare sul mercato impari bene il mestiere e probabilmente

godi di maggiore considerazione e il resto di conseguenza.



Ed e' triste che alle persone venga da farsi certe domande,

ma purtroppo, anche io, so bene come mai accade.


 manutenzioni, in quanto non ci sara' nessuno in grado di metterci le mani.



Buone considerazioni, ma se uno e' costretto a fare "l'ortolano"

per mantenersi occupato mi sa che lavora in un brutto posto,

o se non e' costretto ma o fa lo stesso e' una viscida merdaccia

e se nessuno ci bada si torna al primo caso.

:-D


 general availability, ma il linguaggio esisteva gia' da qualche anno. 



E hai detto poco. La "first appearance" di Java e` del 1995 mentre il progetto Java e` nato nel 1991. E` impossibile che "certe caratteristiche" siano state "introdotte nel linaguggio nel 1992!!" se il verbo "aggiungere" presuppone l'esistenza di un linguaggio con certe caratteristiche che potesse evolvere in una nuova versione.


 arrivare a tanto. Involontariamente intendo.



Eh, ma il piu` grande cretino della terra e` Einstein rispetto a enoquick.




 noeuro. Ecco a voi un autentico cretino doc, o d'ok se preferite :D



E cosa ha che fare l'euro adesso ?

Se non lo sai sono anche uno studioso di macroeconomia

Per quello posso essere critico sull'euro

Ma e' un discorso che non c'entra una fava.

Si chiama Argumentum ad hominem

Ti metto anche il link cosi ti istruisci un po sulle cose da non fare:

https://it.wikipedia.org/wiki/Argumentum_ad_hominem









Fuori dai computer esiste anche un terzo stato oltre a vero o falso

Si chiama non si sa.

:)








Mica tanto,il sw visionato era sia open source che da quelli che chiami 

impiegati a tempo indeterminato.

Non solo i fai e fuggi,per capirci.





Rispondi alla domanda,le classi non si scrivono piu ?





Chi io ?

Figurati,in un progetto complesso le classi vengono viste e riviste 

varie volte.




 P.S. Il termine "testina" usalo con tua sorella.



Te la sei un po cercata se non avevi capito il senso.

Hai tutte le mie scuse comunque.




Si chiama Argumentum ad hominem 



Magari ad ok.


>La mia era solo una considerazione statistica



Ma statistica de che? 99.99% che cazzo di statistica sarebbe? Non ti lamentare se ti danno del cretino.


 Si chiama non si sa.



Esatto, e dovrebbe portarti a non emettere giudizi su tutto cio` che non sai.


 Magari ad ok.



Uno che vuole correggere un altro e non sa manco correggerlo... :-D






 Se non lo sai sono anche uno studioso di macroeconomia





apperň, "studioso di macroeconomia".

ci vai giů pesante con i titoli.


 Uno che vuole correggere un altro e non sa manco correggerlo... :-D



Intendi come quei coglioni che pensano di correggere qualcuno dicendogli che si scrive "ad hoc", quando quel qualcuno sta proprio dicendo che non si scrive "ad ok" ma "ad hoc"? Ma possibile che tu faccia la figura del cretino ogni volta che apri bocca?


 ci vai giů pesante con i titoli.



ANCHE studioso di macroeconomia. 





Combattere contro tre /pazzi/ da novanta e' cosa dura.

Ma te la stai cavando egregiamente ;-)



Comunque mi dicono che per fare applicazioni bisogna

assumere la posizione del loto.

Poi, mockeggiando un Tizio, si esclami:

- Sia fatta la applicazione

- Siano fatti tutti i testi presenti e futuri

- Sia il codice perennemente manutenibile

- Sia fatta la documentazione (se non e' gia' Domenica)



Ci ho provato.

Non mi riesce, sono (ed ero) /scarzo/ o non sono abbastanza

"pazzo" .



-- 

ac (x=y-1)

Aborro il Killfile

(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)


 "pazzo" .



Tranquillo, sei solo scarso.


 parallelizzare pure in Ruby, figuriamoci su JVM o vm Erlang)



Vero, anche in Java si puo` fare. In realta` la velocita` dei test e` un problema piu` per gli integration tests che gli unit tests. Ovviamente, parallelizzare gli ITs puo` essere un po' piu` problematico.



Beh, in Ruby c'e' una libreria piuttosto utile, VCR

(
https://github.com/vcr/vcr
) che "serializza" le chiamate HTTP (in yaml

se non ricordo male) la prima volta che le fa, poi richiama le chiamate

serializzate, che "scadono" dopo tot giorni in modo da accorgersi in

tempi ragionevoli se qualche servizio cambia una chiamata o da qualche

altro genere di problema.

Presumo ci sia qualcosa del genere anche su JVM, comunque dubito sia

cosi' problematico da implementare.



  ngw




 cosi' problematico da implementare.



Si`, certo, ma il problema e` che spesso gli ITs lavorano su dati reali, per cui bisogna stare attenti al fatto che, parallelizzandoli, non si pestino i piedi a vicenda.



2 Risposte.

una per il pirla;sei rientrato nel killfile quindi non  perdere tempo a 

rispondermi

Se lo fai tanto non leggo,e' tempo perso.





L'altra per te



Da wikipedia:

Ad hoc: letteralmente "per questo", l'espressione è utilizzata con il 

significato di "appropriato al contesto" oppure "per l'occasione".



Per esempio, "citare un verso ad hoc" significa riportare un verso 

appropriato al contesto del discorso. "Indossare un abito ad hoc" 

significa scegliere un abito per un'occasione particolare. 

L'espressione, in senso allargato, si usa anche per indicare qualcosa di 

calzante con la situazione, eventualmente concepita appositamente allo 

scopo specifico.



Cosa ha che fare la parola ad hoc nel contesto della frase da me scritta 

lo sai solo tu.






 lo sai solo tu.



A me di "ad ok", "ad hoc", "ad pizz" non me ne futte na cippa secca,

io ho solo detto che il sapientone non sa nemmeno usare il virgolettato

per citare testi provenienti da fonti altrui.








Rincoglionito, che cosa significhi "ad hoc" lo sanno tutti benissimo, meno che te. Si scrive appunto "ad hoc", non "ad ok". Ennesima arrampicata sugli specchi dalla quale vieni fuori TU come un pirla, non gli altri. Ovviamente attiri mosche come lo scemo del villaggio ciccio, che ha bisogno di posarsi sulla merda per dare un senso alla propria vita.


 



Ma avevi fatto una critica sull' uso di had hoc.

Ti assicuro che non avevo intenzione di usare quel termine di cui tra 

l'altro conosco perfettamente il significato.

E ne sono consapevole che il termine "ad ok" non e' di uso comune (ma 

non ci ho pensato quando l' ho scritto).

La citazione di wikipedia era  solo per dare un senso di autorita' al 

significato di "ad hoc".




 Ma avevi fatto una critica sull' uso di had hoc.



non ce la puoi fare...


 E ne sono consapevole che il termine "ad ok" non e' di uso comune



No, non e` proprio usato da nessuno.



Ma piu sotto l'ho scritto corretto

Segno che e' un refuso





Fifty-fifty







No.

Almeno non software della dimensione e complessita' citate nei post

precedenti(parlavo di Home banking e simulatori motociclistici come

progetti a cui ho lavorato o ho visto altri lavorarci).



Non ho letto tutti i post del thread, ma in quelli che ho letto

mi pare che fino ad ora

nessuno abbia fatto un esempio reale di progetto (di dimensioni

e complessita' del tipo sopra citato) a cui ha lavorato

e che faccia parte della categoria  "altri dove questo non succede".

D'altra parte anche nel tuo post non c'e' un esempio reale (io alcuni 

esempi di "altri dove questo non succede", tratti dalla mia esperienza, 

li avevo fatti, ma dicendo che erano software molto meno complessi di 

quelli citati sopra);



  quindi sono indotto a pensare che effettivamente gli "altri dove 

questo non succede" non esistano (almeno nel caso di progetti di una 

certa complessita') o, se esistono, siano in quantita' trascurabile 

(d'altra parte credo che oggi come oggi nessuno, almeno in Italia, 

finanzierebbe un progetto che abbia una durata di 3 anni, tanto meno di 

6, per cui forse il problema e' semplicemente che questi progetti oggi 

non possono proprio materialmente piu' esistere ne' fatti bene, ne' 

fatti male, per motivi meramente economici).





Ciao,

Marco.



 questo profilo



In genere ci si vende con il profilo che il mercato richiede.

Se il mercato per il 75% richiede quel profilo mi pare che

  ci siano solo 3 possibilita':



a- si accetta quel profilo

b- si entra nel 25% che richiede un profilo diverso

c- si esce dal mercato



Decidi pure te che probabilita' ha di realizzarsi ognuno dei punti a,b e 

c (possibilmente considerando una probabilita' "a priori", ovvero 

considerando un informatico generico, senza sapere cioe' che 

quell'informatico sono io o che sei te o che e' enoquick o che e' 

qualcun altro in particolare).



 deve far di tutto per scrivere codice manutenibile?



Non credo che nessuno dica che scrivere codice manutenibile non sia

una buona cosa in generale, ma un conto e' demandarlo alla buona 

volonta' del singolo programmatore, tutt'altra

cosa e' che sia un requisito richiesto dal committente



 cosa e' che sia un requisito richiesto dal committente



Ma non ha senso! E' il committente che deve fare una scelta a priori: 

rivolgersi a gente che sa fare il suo mestiere, che produrranno software 

manutenbile (o almeno cercheranno). Oppure rivolgersi a scalza cani, i 

quali ovviamente adotteranno sempre la scusa che non c'e' abbastanza 

tempo per scrivere codice come si deve. In realta' piu' tempo dai loro e 

peggio fanno.






Il senso era chiarissimo, come il numero espresso (99,99%).

Cosa c'era da "interpretare" in questa stupida affermazione?


 questo non succede" non esistano 



Deduci male, MOLTO male.


 cosa e' che sia un requisito richiesto dal committente



Non esiste la manutenibilita` richiesta dal committente. La manutenibilita` del codice e` un requisito implicito. E` una fortuna che non tu non lavori piu` in informatica, visto quel che scrivi ;)


 manutenibilita'. 



Diciamo che puo` non fregargliene una ceppa di quale metodologia e/o tecnologia usi per sviluppare il suo prodotto, ma gli effetti di un codice poco manutenibile li vede eccome. E se li vede, si incazza. E se si incazza, ti chiede di risolvere il technical debt a spese tue. E se continui a fare stronzate, magari si rivolge ad un altro.


 per cambiare una ruota, devi smontare tutto lo chassis?



Esempio al limite. Già oggi se devi cambiare una lampadina motu proprio 

non ce la puoi fare.

:-)



 peggio fanno.



non so come funziona dove sei tu, ma da quello che ho visto io la scelta

dei fornitori molto spesso non dipende da quanto il fornitore "sa fare

il proprio mestiere". Da quanto ho visto io spesso il fornitore e'

l'azienda  b.r. il cui titolare e' la moglie/il marito/l'amante

/l'amico/il parente del dirigente del committente. E, per la verita',

sempre da quanto ho visto io, piu' c'e' aria di crisi, piu' funziona

  cosi', almeno in Italia. Questo non vuol

dire che il fornitore non sappia fare il proprio lavoro e che tutti i

suoi dipendenti siano degli scalzacani;

potrebbero anche saper fare il proprio lavoro meglio di altri,

ma converrai che il metodo non da' garanzie in questo senso.



 



A ridaglie con queste cazzate. Se avevi voglia di rimanere nel settore 

ti sarebbe bastato cambiare aria. Invece si vede che trai piu' 

soddisfazione nel fare il piagnina a vita.

Io in 10 e passa anni di lavoro ho raramente visto le situazioni che 

descrivi (e sicuramente mai quelle dove tiri in ballo Mafia e 

ndrangheta), sebbene il livello tecnico fosse spesso non soddisfacente 

(e per questo me ne sono andato in uk dove pare i lavori siano piu' 

stimolanti).


 :-)



Ma io parlavo di ruote, non di lampadine :)




 non so come funziona dove sei tu, ma da quello che ho visto io



Da quel che hai visto TU. Parla della tua esperienza senza sintetizzarne la situazione universale.


 stimolanti).



Eh si'... questa e' proprio tutta un'altra cosa rispetto a quello che ho

scritto io. Proprio l'opposto si'...



Io faccio il piangina, tu vai all'estero, ma chi rimane deve essere 

bello contento e gaudente perche' io sono un piangina e tu vai all'estero.



Eppero' sono io che non capisco. Gia'! Capisco...

anzi, effettivamente hai ragione: non c'e' verso che io capisca.



 >

 > Se tu hai statistiche differenti secondo cui il 90% dei posti

 > di lavoro da informatici in Italia potresti riportare le tue 

statistiche e le tue fonti



intendevo



  Se tu hai statistiche differenti secondo cui il 90% dei posti

  di lavoro da informatici in Italia sono ottimi

posti di lavoro, potresti riportare le tue statistiche e le tue fonti





Ciao,

Marco



 posti di lavoro, potresti riportare le tue statistiche e le tue fonti



Cioe` dire che non e` vero che ovunque si scriva codice di merda significa affermare che il 90% dei posti di lavoro in Italia sono ottimi posti di lavoro? 




 informatici



Ma quale "descrizione della realta` della situazione della maggior parte degli informatici"? Ma cosa dici. Quali numeri hai? Di cosa stai parlando? Ciance buttate al vento come al solito.


 E sei veramente sicuro che non fossi proprio tu tra le cause di quel processo di merdizzazione? E` una domanda seria.



Lui e' sempre la vittima, ovviamente.



Comunque grazie del riassunto, non mi sognerei mai di leggere la 

pappardella originale :D


 posti di lavoro, potresti riportare le tue statistiche e le tue fonti



E' un misto tra falsa dicotomia

(
https://www.fallacielogiche.it/index.php?option=com_content&task=view&id=35&Itemid=49
)

e argomento fantoccio

(
https://www.fallacielogiche.it/index.php?option=com_content&task=view&id=32&Itemid=46
).

Tra l'altro quello che dici e' anche piuttosto privo di senso: che vuol

dire "ottimi posti di lavoro"? Per molti un ottimo posto di lavoro e' un

posto dove si fa poco e si studia meno, per altri l'esatto opposto; per

molti un ottimo posto di lavoro e' in una citta' esotica e lontana, per

altri a 20 metri da casa. Insomma, non vuol dire un cazzo.

E questo modo di affrontare qualunque argomento con cappio al collo e

nuvoletta fantozziana al seguito mi era sospetto ormai 10 anni fa, ormai

di dubbi ne ho pochi: la vita e' come una scatola di cioccolatini, se tu

hai scartato solo palle di merda forse non sei bravo a sceglierla, 'sta

scatola. O magari sei coprofago.



  ngw


 posti di lavoro, potresti riportare le tue statistiche e le tue fonti



senti, siccome ho dato una scorsa al tuo messaggio e ho letto diversi 

numeretti e percentuali, che ne dici se cominci te a riportare le tue di 

fonti?





ad hoc

2 - 1 :)





Cosa ha a che fare il numero 99.99% con:



 > Che culo! Cioe` e` nello 0.01%?

 >

 >  Visto che "medaglia" mi sono guadagnato?....mica pizza e fichi!





Roba tua



Ma sei veramente sicuro che il 99.99% del sw scritto abbia una 

percentuale piu bassa di chiamiamola 'scritto con i piedi' ?

Mettiti assieme al Dr Gagliardelli per trovare la percentuale giusta 

invece che darmi del malato di mente,piuttosto che criticarmi.



PS. solo COBOL esistono sul pianeta,,stimati, 400miliardi di linee di 

codice.

E scritte non in COBOL moderno (quella con l'obj,la  local storage 

ecc..) ma quasi tutti col vecchio metodo

Ora mi verrai a dire che e' possibile scrivere programmi un po complessi 

(> 1000 righe) perfettamente manutenibili con un siffatto linguaggio 

arcaico.

Ho messo 1000 righe perche' con un linguaggio di quella levatura gia 

scrivere piu di 1000 righe significa perdere la logica del programma 

(diventa quasi ingestibile).








A me, di cercare la percentuale giusta, non me ne frega un cazzo.

Certo e' che la tua valutazione "spannometrica" denota, quanto meno, 

ignoranza sul tema. E poi, non ho elementi per affermare che sei un 

malato di mente, infatti non l'ho detto, certamente sei uno che 

parla/scrive a vanvera. Infine, criticare e' un esercizio utile, si 

chiama confronto: esempio, tu fai un'affermazione, io la critico 

chiedendoti le prove, tu mi sbatti le prove in faccia e tutto finisce.

Nel tuo caso, alla richiesta di prove/fonti, hai balbettato qualcosa di 

incomprensibile, segno evidente che avevi pestato un merdone. Non 

preoccuparti, a volte succede.




 



Nessun problema.






 ho visto (e anche modificato) un sacco ...



significa che non hai fatto un'iperbole, cioè non hai volutamente 

esagerato per dare enfasi al concetto. ovvero ritieni il dato reale.

se lo ritieni reale, vuol dire affermi che anche i tuoi interlocutori 

scrivono per il 99,9% codice di merda, secondo te.

a questo punto permetterai che qualcuno abbia da ridire? 


99.99% non è una statistica, è una stronzata e quando fai un'affermazione sei tu che devi dimostrarla, non ribaltare l'onere dela prova su chi ti chiede di supportare quel che dici. Perché altrimenti basta una controaffermazione per sbugiardarti: non tutto il software che ho visto io faceva vagare. Ecco: hai torto.


 percentuale piu bassa di chiamiamola 'scritto con i piedi' ?



Ci tieni veramente cosi` tanto a fare la figura dello scemo?


 Dimostra il contrario delle mia affermazione se vuoi.



Sempre piu' convinto che sia troppo tonto per essere vero.


 dire "ottimi posti di lavoro"?



Se ti interessa la risposta a tale domanda, dovresti chiederlo a chi ha 

introdotto il concetto (quindi non a me).



Come al solito una serie di immani cazzate che nulla c'entrano con i 

post precedenti.



Va beh. Me ne faro' una ragione.

Saluti anche a te.



Ciao,

Marco.



 post precedenti.



Il problema e` che sei troppo poco avvezzo ai ragionamenti logici per capire che sono i TUOI post pieni di immagin cazzate. Di fallacie logiche (e appunto di immani cazzate), nei tuoi argomenti, ce n'e` piu` di una.




 Sempre piu' convinto che sia troppo tonto per essere vero.



Purtroppo di scemi del genere ne ho incontrati anche di persona. Sono veri, purtroppo.



Io veramente le mie fonti le riporto piu' o meno sempre. Magari

quando non le riporto le do per scontate e non le riporto

per non ripetere centomila volte le stesse cose.



Comunque se ci tieni le ripeto ancora:

La mia fonte per quei numeri (e solo per quelli) riportati nel post 

precedente, come scritto anche nel post  era un frequentatore del NG, 

anche se non avevo scritto chi.



Se non sbaglio era Francesco da Riva, in un thread di uno o due anni fa 

qui sopra (sempre se non sbaglio) che diceva che quei numeri risultavano 

dalle

sue conoscenze dovute alla sua attivita'

di sindacalista (*).





Se poi vuoi una fonte piu' generale che possa spiegarti

il motivo per cui anche negli altri settori e non solo

nell'informatica la situazione (in termini di occupazione) non si

prospetta molto diversa da quella detta per l'informatica

(e, almeno in parte, anche perche'

l'occupazione/disoccupazione degli informatici e non solo

degli informatici sostanzialmente

non dipendono in pratica

da quanto gli informatici [o gli altri]

sanno o non sanno fare il proprio lavoro, ma dipende

da parametri economici che piu' o meno nulla hanno a che vedere

con quanto uno sappia fare bene il proprio lavoro

  [visto ad esempio che se servono 400.000 informatici si

prenderanno tutti gli informatici dal primo piu' bravo di tutti

fiuno al 400.000-esimo mentre se ne servono 200.000 forse il

piu' bravo di tutti e altri continueranno a lavorare

ma 200.000 di quei 400.000 perderanno il lavoro(**)])



ti posso rimandare ad una serie di link

(ma per leggerli ci vuole ben piu' tempo che per leggere un post

di ILI)





Il piu' recente potrebbe essere il seguente ma li' in realta' si parla 

(piu' o meno) dei risultati delle elezioni in Francia e dei problemi

economici della Francia. Forse c'e' una sola frase significativa,

che ti riporto dopo il link



http://goofynomics.blogspot.it/2017/05/cinque-anni-dopo-macron-e-gli-squilibri.html




(l'affermazione li' contenuta e'

"L'incapacità della Le Pen di spiegare cosa volesse effettivamente fare 

dell'euro, la sua incredibile inefficacia di approfittare delle tante 

palle "alzate" da Macron (quando questi ha ammesso l'esistenza di 

disoccupazione di massa, ci voleva tanto a chiarire che questa è 

funzionale al progetto europeo?), hanno determinato un risultato 

peggiore del prevedibile" [Ndr: peggiore per la Le Pen, ovviamente ])



Se poi ti interessa capire perche'



"questa"

(cioe' la disoccupazione [sottintendendo livelli alti di disoccupazione])



"e' funzionale al progetto europeo"



(e quindi esiste [e probabilmente esistera' ancora di piu' in futuro ] 

non solo in Francia ma anche in altri stati, soprattutto periferici 

dell'eurozona [di cui Italia e Spagna sono forse i massimi 

rappresentanti, ovviamente dopo la Grecia] e ovviamente non solo

nel settore informatico ma in generale piu' o meno in tutti i settori)





probabilmente dovresti partire leggendoti i link (e gli articoli 

economici) citati qui:



http://goofynomics.blogspot.it/p/blog-page_18.html




ma sono tanti e richiedono un certo tempo









io ti posso consigliare di partire dai seguenti tre

(il terzo  richiede comunque un certo tempo [io non ho ancora

finito di leggerlo tutto] e forse richiede alcune conoscenze

di economia, ma e' molto piu' preciso e rigoroso degli altri due.



I primi due forse si leggono in meno tempo ma a una

prima lettura il primo potrebbe sembrare non basato su prove concrete

o su teorie piu' o meno dimostrate. Ma il pdf dovrebbe appunto chiarire 

anche gli aspetti piu' scientifici con esempi presi anche da

situazioni verificatesi in passato, del perche' la disoccupazione

e' inesorabilmente destinata ad aumentare ancora o almeno,

in una ipotesi molto ottimistica,

a non diminuire [non solo nell'informatica e non solo in italia])





Quindi per una prima "infarinatura" leggere



http://goofynomics.blogspot.it/2012/11/il-romanzo-di-centro-e-di-periferia.html




e



https://it.wikipedia.org/wiki/Ciclo_di_Frenkel






e per un approfondimento leggere il pdf (in inglese)

scaricabile a partire da qui



http://www.asimmetrie.org/working-papers/wp-201301-unhappy-families-are-all-alike/




pdf che contiene vari riferimenti ad articoli di altri economisti

(e anche a teorie economiche note e meno note).





Se poi proprio ti interessa, le stesse cose che sono scritte in quei 

link  (o cose molto

simili)



  mi furono dette (sia a me che a tutti gli altri che frequentavano

quella specie di seminari da loro tenuti) nel febbraio 2008

(quindi prima dello scoppio della crisi dell'estate 2008) da

almeno due docenti

di economia, uno  dell'Universita' di Perugia, uno dell'Universita'

di Roma (per la verita' questo secondo forse non era

a febbraio ma quando la crisi era appena scoppiata, tipo

a settembre 2008), i quali, come tutti gli economisti, sapevano 

perfettamente che nel lungo periodo la situazione sarebbe stata quella 

di oggi

Nel senso che si sapeva che la disoccupazione sarebbe aumentata

e che il capitale sarebbe finito sempre di piu' nelle mani di pochi



(semplicemente la crisi del 2008 e la successiva [per altro 

prevedibilissima, da parte degli economisti, come spiegato nei link

di cui sopra] crisi legata allo spread possono aver accelerato una 

situazione che ci sarebbe comunque stata prima o poi, a detta di tutti 

gli economisti [tranne quelli che vanno

in televisione, pagati per dire il contrario])





Ciao,

Marco.





(*) Purtroppo non riesco a fare ricerche dei post passati, visto che a 

quanto pare google groups non permette piu' di farle in maniera semplice

e quindi ho dovuto essere approssimativo sulle date e

aggiungere "se non mi sbaglio". Se riuscissi a fare ricerche dei post

passati in modo semplice (che non mi sottraesse troppo tempo) forse

riuscirei anche ad individiuare quei vecchi post, ma ora non ci riesco.

Pero' chi frequenta il NG da tempo dovrebbe ricordarseli



(**) converrari che l'affermazione "devi essere il primo

dei 400.000 per essere sicuro di continuare a lavorare

come informatico" e' un po' come dire ad uno che vuole

giocare a calcio: "devi giocare come maradona per essere

sicuro di fare il calciatore". Cioe' e' un'affermazione

che dimostra la pochezza di chi la fa.



PS: 'azz! sono gia' le 11.51 e mi sono perso in queste cavolate anche se 

devo attraversare praticamente quasi tutta Roma in macchina!



Va beh. Speriamo bene di non fare tardi.



Ciao,

Marco.



 Poi vai a vedere e trovi realtà come SAP.



E' da un po' che sono fuori dal giro.

SAP sta per:



https://en.wikipedia.org/wiki/SAP_SE




?


 





Si

Ne sono convinto


 qualcuno



Dipende.

Se uno e' effettivamente ubriaco, criticarlo potrebbe aiutarlo, se non 

altro, a risolvere il problema dell'alcolismo.

Se invece uno fa soltanto ragionamenti da ubriaco, allora hai ragione 

tu: qualsiasi critica non servira' a niente.




 qualcuno



Perche`, c'e` qualcosa di costruttivo nel buttare merda su tutto il codice scritto in giro? E` una critica costruttiva quella? O e` soltanto un buttare merda indistintamente su tutto e tutti? Poi, quando ti viene detto che e` una emerita stronzata, reclami rispetto. Buffone che non sei altro, se ragioni da ubriaco, la colpa non e`mica degli altri, sai?


 qualcuno



beh se ammettevi serenamente che si trattava di un iperbole nessuno 

avrebbe avuto da ridire. ma siccome insisti nel sostenere che è un dato 

statistico ti becchi quello che ti meriti.

d'altronde se io dicessi "sono secoli che non vedo codice scritto bene" 

di per se sarebbe normale dialettica, mentre se ti dicessi (insistendo) 

che intendo realmente centinaia di anni probabilmente qualche dubbio 

sulla mia lucidità mentale ti verrebbe.



Ho scritto di fretta prima e visto che mi hai fatto girare un po i 

cosiddetti ho buttato giu quella frase senza pensarci troppo.



Ma,magari i programmatori capaci di scrivere codice saranno il 10% 

(l'elite dei programmatori)

Ma la frase che tanto ha provato le ire dei benpensanti del codice non 

era riferita agli attuali programmatori ma al codice esistente.





Questa era la mia frase iniziale:

Non c'e problema,il 99,99% e forse piu del codice scritto fa 

letteralmente schifo quando a manutenibilita e scalabilita per cui il 

problema non e' da porsi.

E non e' solo per colpa di programmatori incapaci ma anche dei tempi 

ristretti imposti.



Ed aggiungo: e di linguaggi che sarebbe bene non usare piu (COBOL e' un 

esempio)



Quindi nessuna presa di posizione contro i programmatori di oggi.





Ti ricordo che in produzione esistono codici scritti in 

COBOL,FORTRAN,C,C++ e java

Se java e' recente gli altri no,alcuni sono in giro da 50anni come 

codice scritto ed attualmente in produzione.

E sopratutto di C e COBOL e' costituita una bella fetta di codice scritto.


 letteralmente schifo



Ah ecco, ora si che ha senso. Intendevi dire che il codice non scritto 

e' ottimo per il 10%.


 Quindi nessuna presa di posizione contro i programmatori di oggi.



Hai semplicemente scritto una cazzata. Prendine atto.



No,leggi bene










Semplice. Diciamo che SAP ha il monopolio della nettezza urbana di più 

mezzo pianeta (almeno di quello "industriale") e gli spazzini son pagati 

a peso d'oro. Tu lo andresti a fare lo spazzino?



E il paragone non è tanto lontato. Lavorare con SAP è un lavoro di 

MERDA, alla lettera.



E un'altra precisazione: uno sviluppatore "vero" (non un code monkey da 

quattro soldi) si attappa il naso e tecnicamente è già pronto per 

lavorare con SAP. Viceversa NO.




 Dimostra il contrario delle mia affermazione se vuoi.



Guarda, se proprio devo ragionare con una fava, preferisco ragionare con 

la mia. Per me l'argomento e' chiuso.