Newsgroup: it.lavoro.informatica
Titolo: [OT]Code Test :-D

Ma io mi chiedo ma come si fa a scrivere una roba del genere, mi ci sono 
imbattuto stamattina:
sara' che e' lunedi' , ma ci ho perso 2 minuti per capire che cavolo 
significava... :-D
if (!((0 < rowFetched) && (rowFetched <= 1))) === ???
se volete usatelo per testare i dipendenti(glielo fatto ai miei colleghi 
1 ha sbagliato e un altro mi ha detto che non lo sapeva che  faceva!)
  :-)
ciao
ps
Aiutino :-D
rowFetched e' un intero e restituisce numero di righe restituite dalla 
query e se entrava li dentro sollevava un exception che lanciava un 
messaggio con scritto:"il comando doveva restituire una riga!"

 if (!((0 < rowFetched) && (rowFetched <= 1))) === ???
Ammesso che rowFetched sia un intero, come il nome lascierebbe supporre,
dovrebbe essere equivalente a 
if(rowFetched != 1)
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 if(rowFetched != 1)
Supponendo che non possa assumere valori negativi; in alternativa
if (rowFetched <= 0 || rowFetched > 1)
Comunque, mi fa pensare a un controllo del tipo: "se restituisce più di
una riga, allora c'è qualcosa che non va".
Se la mia ipotesi, sarebbe IMHO più chiaro:
if (rowFetched == 1)
{
    //  faccio quel che devo fare
}
else
{
    //  C'è probabilmente qualche errore...
}
-- 
Ciao!
Luca

 if(rowFetched != 1)
yeah :-D
ciaooo

 }
si infatti era 1000 volte meglio!
ciao

 imbattuto stamattina:
Ogni tanto capita a tutti di scrivere cose del genere.
Come si evitano? Pair programming, code review ma soprattutto
refactoring, refactoring, refactoring ..
--
ale
http://ale.riolo.co.uk

 ciao
Alla faccia dell'ottimizzazione del codice :-(. 
Della serie: "basta che 'funonzia'".


 'funonzia'".
lì il problema non è certo l'ottimizzazione, ma la leggibilità.

 refactoring, refactoring, refactoring ..
E anche evitare la mortadella e la peperonata la sera... 
:-DDDDDD
-- 
Ciao!
Luca

 if (!((0 < rowFetched) && (rowFetched <= 1))) === ???
ipotesi di history delle modifiche:
"deve ritornare almeno una riga"
"no, scusa... aggiungi: le righe non possono essere più di una"
"contrordine! è esattamente il contrario"
il tutto condito da un programmatore (o un gruppo di programmatori) che 
non si azzarda a toccare il codice pregresso. refactoring, questo 
sconosciuto...

 lÃ¬ il problema non Ã¨ certo l'ottimizzazione, ma la leggibilitÃ .
E' anche un problema di ottimizzazione di codice, se consideri  che
quell'espressione deve essere scomposta dall'interprete a valutata pezzo
per pezzo ( se si parla di linguaggi interpretati). 
Quando ci sono due espressioni booleane composte tramite and, viene
controllata sempre prima quella a sinistra. Quindi è norma mettere più a
sinistra sempre quella per cui la sua falsità invalida tutte le altre. 


 non si azzarda a toccare il codice pregresso. 
infatti me ne son ben guardato dal cambiarlo, quella parte e' tested 
cioe' va bene, poi magari faccio una cappella e son caxxi! :-D
cya

 colleghi! :-D
Ti posso garantire che in circa 10 anni di C/C++ ho visto, visto fare
(e forse talvolta anche fatto) molto di peggio.
Personalmente se mi dicessero che questi sono i maggiori 
problemi di "incomprensibilita'" del codice che devo affrontare,
rispenderei
"dove si firma...".


 if (rowFetched <= 0 || rowFetched > 1)
Effettivamente avevo scartato tacitamente i valori negativi.
Pero' non ho capito bene l'espressione che scrivi sopra.
L'espressione originale era
if (!((0 < rowFetched) && (rowFetched <= 1)))
 se rowFetched  < 0 (e direi che il ragionamento seguente vale anche
se rowFetched=0)=> 
(rowFetched <=1) e' true *sempre*
mentre (rowFetched > 0) e' false *sempre*.
Quindi l'and e' sempre false. e il ! e' sempre true
Ma anche if(rowFetched != 1) e' sempre true in caso di rowFetched negativi
Per cui l'equivalenza tra le espressioni dovrebbe continuare a funzionare
anche in caso di valori interi negativi. Se poi logicamente
abbia senso non lo so. Forse avrebbe senso se il problema fosse "se torna
una ed una sola riga allora va bene, altrimenti, qualsiasi altra cosa
torni, compresi numeri negativi[che potrebbero essere codici di errore,
ad esempio] allora non va bene".


 E anche evitare la mortadella e la peperonata la sera... 
In genere quelle cose derivato dalla "mutazione delle specifiche".
Prima ti dicono che il numero delle righe deve essere maggiore o uguale
a 12.
Allora tu controlli (o magari chi e' venuto nel frattempo
al posto tuo e si trovava davanti ad un software che, a parte questa nuova
spefica, per il resto funzionava) rowFetched < 12 (e consideri magari
"buono" per il controllo anche il caso in cui rowFetched sia 0 o < 0
[perche' magari
nel caso < 0 rowFetched contiene un codice di errore). Tu lo lasci
li' per mesi e il software funziona e dopo 3 anni e mezzo, quando
tu te ne sei andato o stai facendo altri, esce fuori un dirigente che si
accorge che di righe ce ne deve essere almeno 1 a allora tu controlli
non piu' < 12 ma <=1. Alla fine ti dicono che in caso di errore (valori
negativi) o in caso di nessuna riga restituita devi fare qualche altra
cosa per cui controlli che sia >0 e lo metti in "and". e cosi' via.


 sinistra sempre quella per cui la sua falsità invalida tutte le altre. 
li' c'era >0 e <=1 e mi pare che nessuna delle due invalidi l'altra.
Ciao,
Marco.


 Marco.
Ciao


 sconosciuto...
Qui, secondo me, ci sono alcune considerazioni da fare (senza contare
il caso che nelle specifiche potrebbe esserci scritto proprio "se i record
restituiti sono piu' di zero ma in numero <=1 allora fai questo, altrimenti
fai altro)"
1) il programmatore a cui vengono dette le cose di cui sopra e' sempre
lo stesso (deve ritornare almeno una riga. le righe non possono essere
piu' di una, ecc.).
1 a.)
Magari l'ultima cosa (l'aggiunta del "not") gli viene detta dopo 12 mesi
che non toccava piu' quel codice => non si ricorda piu' cosa faceva
quel codice, le specifiche non le ha piu' (ammesso che la abbia mai avute),
ha un progetto urgente da consegnare domani (ma il PM si sa..., "cosa vuoi
che sia fare una modifica") => se magari anche le trasformazioni
intermedie erano state suggerite con lo stesso metodo...
1 b.) Mi serve per ieri... (refactoring ? What is refactoring ?)
2) Il programmatore a cui vengono dette le ultime cose di cui sopra
non e' lo stesso a cui venivano dette le prime => vede che c'era una
espressione strana che faceva fare al software delle cose. Gli hanno detto
che quelle cose non le deve fare in quel caso ma esattamente nel caso
opposto... E si sa.. la modifica e' piccola... deve costare poco... (What
refactoring ?)
Personalmente una volta il refactoring lo facevo lo stesso, anche
se non richiesto, quando mi pagavano le ore che restavo in piu'... ora
come ora... Ma si'... mettiamoci un bel "not" e poi si va a 
leggere un libro di economia oppure, meglio ancora, a giocare a scacchi...
Poi domani arriva xyz_at_Work che non sa leggere il codice che ho
scritto io ?  "sticazz..." Hai deciso che non si possono fare
straordinari, che la modifica deve essere veloce, ecc (in altre parole hai
deciso
che la qualita' si deve abbassare )... beccati quello per cui paghi Full
Stop.
Se poi xyz_at_Work magari lo paghi per farti un bel refactoring, te lo
fara' lui, oppure se vuole farlo gratis lo fara' gratis, altrimenti....
In altre parole: se il lavoro e' riconosciuto *bene*, altrimenti bene lo
stesso...
Ciao,
Marco.




mi chiedo come puoi (potete) dire che è tested quando si fa fatica a 
capire quello che fa... 
comunque la ragione per cui nascono questi mostri è questa qua, è inutile 
girarci intorno.
 

 stesso...
Personalmente trovo questi post allucinanti.
E aggiungo :
- Un programmatore che scrive quel codice merita di essere trattato da
impiegatuccio sostituibile.
- Un programmatore che trova quel codice e lo lascia stare  merita di
essere trattato da impiegatuccio sostituibile.
- Un programmatore che lega correggere il codice al contratto di
lavoro o alle condizioni di lavoro non merita niente.
E questo salvo casi eccezionali.

 stesso...
che cazzata.
se mentre fai manutenzione trovi una stronzata del genere, che per giunta 
pregiudica la leggibilità del codice, a chi pensi di fare spregio 
lasciandola lì? a chi credi toccherà moccolare la prossima volta che c'è 
da rimettere mano a quel codice? 
spero tu non litighi mai con tua moglie, già ti vedo a tagliarti 
l'uccello per farle dispetto...

 Personalmente trovo questi post allucinanti.
sono un disco rotto. ma mica ce l'ho con loro, ce l'ho con me che mi ci 
metto anche a discutere...

 ha scritto nel messaggio 
news:c8ef710c-2db7-43b3...@u18g2000pro.googlegroups.com...

Io, tutto sommato, lo trovo ragionevole.
L'ipotesi considerata: mi hanno cambiato n volte le specifiche (altrimenti 
quella condizione, effettivamente, non si spiega), devo fare n mila altre 
cose (perchè probabilmente non è che mi pagano per manutenere quel codice), 
perchè devo lavorare gratis per correggere quello che è frutto di una 
cattiva organizzazione (tecnica ed economica) del progetto?
Ciao,
Alessio (a.k.a. Kinglion Il Meticcio) 

 negativi
Verissimo. In effetti, in quel frangente pensavo (ma non l'ho detto,
mannaggia) a valori non interi. Talmente vero che, se guardi lo
sviluppo successivo, più avanti, ho scritto sostanzialmente la stessa
cosa che dici tu.
-- 
Ciao!
Luca

 girarci intorno.
Alla fine l'ho cambiato per i posteri, cmq non era un errore se c'e' un 
errore ok, ma se l'espressione, pur se contorta funziona non vedo 
perche' dovrei cambiarlo se non per una chiarezza semantica. :-D
In pratica dico che e' tested perche' e' codice del layer data di quel 
progetto e da svn ho visto che son piu' di 12 mesi che non viene 
modificato quindi significa che quel tier e' abbastanza stabile. siccome 
di quel progetto mi e' stato detto che devo fixare solo bug gravi(e non 
perderci tempo) non vedo perche' dovrei ottimizzare il codice col 
rischio di inserirci dei bugs visto che e' immenso e quella parte non la 
conosco manco bene. :-D
ps
Il linguaggio e' c#
pps
e' lunedi',nn ho dormito un caxxo e volevo solo condividere sta cosa con 
altri informatici perche' mi sembrava divertente. :-D
Ciao

 organizzazione (tecnica ed economica) del progetto?
perché quel codice bene o male *funziona*. quindi se lo correggi non fai 
un favore a nessuno se non a te stesso, visto che sarai te a doverlo 
manutenere. 

 conosco manco bene. :-D
non era una osservazione sul tuo comportamento personale, infatti avevo 
parlato al plurale rivolgendomi a tutto il team.

 cattiva organizzazione (tecnica ed economica) del progetto?
Perchè ci sono solo due stati : o sei un serio professionista che
lavora bene, o sei un cialtrone.
Nel primo caso ti darebbe fastidio che altri vedano un tuo lavoro che
fa schifo perchè potrebbero giudicarti un cialtrone, nel secondo caso
invece il problema non si pone.

 quella parte non la conosco manco bene. :-D
Ricorda la prima legge del sistemista (che si applica un po'
dappertutto):
"Se funziona quel che basta / non toccare che si guasta!"
:-DDDDDDDDD
-- 
Ciao!
Luca

 ha scritto nel messaggio 
news:cb2a5b1c-6fe7-4f16...@e1g2000pra.googlegroups.com...



Ma mica lo ho scritto io (o il poster nel caso specifico), perchè dovrebbe 
darmi fastidio se qualcuno giudica un cialtrone chi ha scritto quel codice?
Non so voi, ma io di solito non mi mettevo a correggere codice scritto da 
altri che funzionava, avevo già le mie rogne a scrivere NUOVO codice o a 
correggere quello che NON funzionava.
Ora che un po' dirigo, se ho in produzione del codice che è scritto male 
(perchè ereditato o frutto di codice sviluppato troppo in fretta), cerco di 
fare in modo di mettere a budget (in modo nascosto, perchè il cliente 
solitamente non vuole codice bello, ma codice funzionante) dei giorni per 
correggere quel codice, ma se il cliente non vuole scucire un euro in più di 
quanto è strettamente necessario per nuov codice o correzione bugs, allora 
quello se lo tiene.


 darmi fastidio se qualcuno giudica un cialtrone chi ha scritto quel codice?
Se non lo hai scritto tu, il motivo che ti spinge a metterlo a posto è
che qualcuno dopo di te dovrebbe passare lo stesso tempo a
decodificarlo.
E se poi quel qualcuno fossi io, e ci impazzissi per un po' e poi
saltasse fuori che tu lo avevi già fatto tu ma siccome sei troppo
pigro ed il tuo contratto non ha XX giorni di ferie come gli insegnati
allora lo hai lasciato così com'era, stai pure certo che ti alla fine
del conto ti conveniva correggerlo subito ;-)

 if (!((0 < rowFetched) && (rowFetched <= 1))) === ???
boh?!?
sarò strano io, ma IMHO la programmazione è una specie di arte, e
rispecchia l'animo di chi programma!
Ad esempio, la riga che hai postato, potrebbe essere stata scritta (ad
esempio) da uno che ragiona sempre usando le negazioni, cioè: se (NON
succede A) e (NON succede B), ALLORA ....
Il problema è INVECE quando i moduli non sono ben strutturati, un
sacco di persone ci hanno messo le mani dentro, e non si capisce un
XXX! La colpa non è allora del programmatore, ma di tutto il sistema
basato su rattoppi e instabilità!
IMHO

 scrivere NUOVO codice o a correggere quello che NON funzionava.
aspetta, aspetta... nessuno (o almeno non io) critica il comportamento 
dell'op. la discussione è stata "inquinata" da altre considerazioni come 
"non lo faccio perché non sono pagato per farlo" e su queste mi sono 
agganciato con le mie considerazioni.
un programmatore non corregge il codice perché non può o non è in 
condizione di farlo è diverso da un programmatore che, pur vedendolo 
sbagliato, lo ignora volutamente per una mera (e molto discutibile) 
questione di principio. 

 essere trattato da impiegatuccio sostituibile.
Questo è più condivisibile, anche se dipende dai compiti, non è che sei 
sempre autorizzato a mettere mano nel codice di altri, casomai glielo 
fai notare.
ciao, U.

 fai notare.
E anche qui ovviamente sono d'accordo con te. Ma sempre qui si scrive
che questa correzione non si fa appositamente per motivi che niente
hanno a che vedere con la professione.


???
uno dei buoni motivi per avere i test e' proprio poter fare
refactoring senza paura di sputtanare tutto. modifichi, rilanci i test
e verifichi di non aver fatto puttanate.
La paralisi delle modifiche indica che quel software e ' gia ' in
decomposizione..

 ha scritto nel messaggionews:c8ef710c-2db7-43b3...@u18g2000pro.googlegroups.com...

se non ti pagano per la manutenzione di quel codice non vedo come si
possa
finire a leggerlo. Se il tuo capo non capisce che ci vuole tempo anche
per correggere
e modificare il codice vuol dire che non capisce una mazza di
programmazione e ti
tocchera' spiegarglielo

 Il linguaggio e' c#
non mi sorprende.. per qualche motivo che ancora mi sfugge lo sviluppo
su piattaforma  .net si fa spesso piu '' con i piedi che in ambienti
java. (nonostante c# sia un gran bel linguaggio e direi anche
superiore a java ormai come espressivita'.

 "Se funziona quel che basta / non toccare che si guasta!"
per un sistemista puo' anche essere una regola d'oro.. e scherzi a
parte capisco anche perche' abbia qualche fondamento... visto che le
configurazioni di sistema cambiano raramente.. ma per
il software che cambia e si evolve in continuazione... non modificare
e' un peccato mortale...

 ribadisco, meglio un "hack"/"patch" e un bel "who cares"...
le condizioni disumane nascono anche dal fatto che a forza di hack e
who cares
l'entropia del tuo progetto aumenta esponenzialmente fino ad arrivare
al punto in cui
ci vogliono tempi biblici per trovare e correggere i bug e magari
quando li correggi ne
introduci degli altri.
Questo per quanto riguarda le considerazioni pragmatiche.
Poi per c'e' anche una questione di gusto e di passione.. ora mi
lancio un po' in un volo
pindarico.. ma secondo me programmare non e' un lavoro qualsiasi..
devi avere passione
per quello che fai, devi avere gusto.. e vedere una riga di codice
orrido ti deve colpire come
una stonatura colpisce un musicista.. se uno abbandona questo modo di
lavorare o non
l ha mai sentito allora programmare diventa un lavoro freddo noioso  e
frustrante..

 essere trattato da impiegatuccio sostituibile.
 
Mmmm...
Adesso te lo faccio io il refactoring così sei contento.
 
[code on]
 
//MINEISBETTER if (!((0 < rowFetched) && (rowFetched <= 1)))
 
if (!(0 >= rowFetched) && !((rowFetched - 1) >= 0) ^ (rowFetched < (4-2))) {
   // a che sarà uguale rowFetched qui?
   // Don't care
}
else {
   // Here you can!
   switch (rowFetched) {
      case 1: { format(); break; } // format the storage!
      default: {
         // Questo è il punto in cui finiva la condizione originale
      }
   }
}
 
[code off]
 
 
Questo codice viene certificato come funzionante da "PaperinoN254", può essere
utilizzato con licenza free e sostituito con quello originale per una migliore
lettura del codice sorgente. ;-)
 
Ciao
 
 
-- 
Caronte
 
-- 
Inviato da 
Newsgate.Localinfo.IT
 
http://newsgate.localinfo.it
Powered by Localinfo.IT 
http://www.localinfo.it

 e' un peccato mortale...
Posso anche essere d'accordo, anche se bisognerebbe sempre vedere il
motivo di una modifica.
C'è però un problema: una volta che fai una modifica a qualcosa di
funzionante, lo devi ricollaudare completamente.
-- 
Ciao!
Luca

tocchera' spiegarglielo
Perchè sto magari aggiungendo nuove funzionalità o correggendo altri bugs e 
quindi mi ci sono imbattuto.
manutenzione (mi sembra proprio per definizione) è correggere ciò che non 
funziona o prevenire malfunzionamenti. Quella riga di codice, per quanto 
brutta, funziona e probabilmente non darà vita a malfunzionamenti.
Il capo non è che necessariamente non capisca, ma magari non ha la 
possibilità di mettere n altri soldi SOLO per quell'attività.


 e verifichi di non aver fatto puttanate.
ma che test quel prj non ha unit test(non sanno manco cosa sono i test 
automatici, loro per test intendono lancia applicativo e vedi se va )!!! :-D
Non volevo creare alcun vespaio e' solo una riga di codice "contorta", 
come avevo spiegato in un altro post! poi fate vobis! :-D
cya
ps
cmq si ormai e' in decomposizione e non vedo lora di scavarmelo dai 
maroni! :-D

 
Hai scritto "Un programmatore che scrive quel codice merita di essere 
trattato da impiegatuccio sostituibile." punto e a capo.
Poi se vuoi possiamo addentrarci in speculazioni filosofiche su quella 
frase, ma il senso mi pare univocamente interpretabile ;-)
ciao, U.

 voglia di fare le cose "bene".
a parte che a casa mia fra 1000 e 1600 euro c'è la sua porca differenza, 
ma questo è tipico del tuo personaggio/macchietta che non conosce il 
valore del denaro guadagnato. 
in ogni caso la risposta è sempre la stessa: se è vero quello che dici, è 
vero anche (e soprattutto) il contrario, e cioè quando qualcuno non fa le 
cose per bene passa la voglia di dargli più di 1000 euro al mese. lo so 
che questo punto di vista non ti è gradito ma prima o poi lo devi 
affrontare, se è dura guadagnare bene per chi è bravo figuriamoci per i 
cialtroni.
aggiungo poi una osservazione che vi ostinate a far finta di non sapere. 
a scrivere un software che funziona a forza di calci e pugni non è che 
fai un gran dispetto a chi ti paga, visto che bene o male il software 
funziona. semmai fai un dispetto a te stesso perché sei te che deve 
tirare i calci e i pugni per farlo funzionare. nel mondo reale queste 
sono proprio le condizioni che portano a lavorare di più e in modo 
qualitativamente deprimente, sei più prono a commettere errori, torni più 
volte sugli stessi bug, impieghi più tempo e più fatica a fare 
manutenzione.
questi sono ragionamenti che i programmatori cialtroni fanno per 
nascondere la verità, cioè che quello è l'unico modo di lavorare che 
conoscono, aka "arte di arrangiarsi". ogni programmatore intelligente e 
che conosca il suo mestiere sa bene che ogni scempiaggine sul codice se 
la ritrova sistematicamente e inesorabilmente dritta nel culo. 

 frase, ma il senso mi pare univocamente interpretabile ;-)
Infatti, se tu allarghi il discorso a "a tutti è capitato di scrivere
codice..." io ti seguo e preciso che l'errore ci sta.
Se invece torni nello specifico di quel codice.. confermo. Lo hai
lasciato o perchè non sai fare x =1  oppure (come si insinua qui)
perchè non hai avuto voglia di correggerlo. E se è così non sei un
professionista, sei inequivocabilmente  un impiegatuccio.

 a parte che a casa mia fra 1000 e 1600 euro c'è la sua porca differenza, 
Quoto. Quando ho letto questa frase mi sono cadute le palle. Mi sembra di
capire che per Osid il minimo per uno stipendio che lo gratifichi sia 2000
euro/mese. Si possono guadagnare queste cifre, non sono impossili, ma devi
anche accettare responsabilità che mal si conciliano con l'orario da
impiegato alla Fantozzi, e sicuramente non facendo sitini in php.
Per come la vedo io (da consulente) certe cifre le ottieni in progetti
enterprise e con skill non comuni e senza catene infinite di BR.  
PaF

 if (!((0 < rowFetched) && (rowFetched <= 1))) === ???
E' un controllo di range, scritto in modo da avvicinarsi il più
possibile alla notazione matematica usata per i limiti:
0 < rowfetched <= 1
Probabilmente rowfetched diventa -1 in caso di errore.
Però, essendo un campo intero, certamente è una forma un pò eccessiva
e contorta.

 per pezzo ( se si parla di linguaggi interpretati).
Però per un linguaggio compilato ci dovrebbe essere l'ottimizzazione
automatica.
Un buon compilatore C probabilmente ci riesce. Per altri linguaggi più
di moda chissà... :-)

Il Tue, 11 Nov 2008 04:25:12 -0800 (PST), ispas ha scritto:
[cut]
Penso che il tuo news server abbia qualche problema, gli ultimi tuoi post
li vedo in triplice copia...
PaF


Sto usando Google, e sono sicuro di dare solo 1 click per volta.
Nessun commento sui bug del "grande provider" :-)
PS: stavolta le altre 2 copie non le cancello

 wrote:

Sto usando Google, e sono sicuro di dare solo 1 click per volta.


 potrebbe spronarmi a lavorare bene questa disparità di trattamento?
ripeto il concetto: per chi sa programmare, lavorare bene costa meno che 
lavorare male. più insisti su questo piano e più dimostri di non saper 
lavorare bene.

 l'uccello per farle dispetto...
Sara' per questo che alla tenera eta' di 41 anni inoltrati sono ancora
single :-)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 E questo salvo casi eccezionali.
Che sarebbero ?
Ciao,
Marco


 impiegatuccio sostituibile.
Non avevo considerato attentamente questa frase.
Vedila cosi': fino a quando *non* mi trattavano da impiegatuccio
sostituibile
non gli scrivevo quel codice (salvo casi eccezionali, specificati
in post precedenti) e magari non lo lasciavo nemmeno stare quando
lo scrivevano altri.
Quando hanno iniziato a trattarmi da impiegatuccio sostituibile gli ho
dato esattamente quello che volevano... un impiegatuccio sostituibile.


 tocchera' spiegarglielo
Indovina cosa succede quando glielo hai spiegato ?


 questione di principio.
Io ripeto che spesso qui mi pare di trovare persone che difficilmente
si sono imbattute in aziende con un grande numero di dipendenti.
La questione *non e'* di principio. E' di *tempo*
Ipotizziamo anche che ci sia quell'unica riga illeggibile (che 
poi per chi ha una buona esperienza non e' nemmeno difficilissimo
capire cosa faccia: ho visto migliaia di volte di peggio) e che non
ce ne siano altre centinaia di migliaia. E supponiamo che io,
ispezionando il codice, perche' non ho di meglio da fare
(come mi capitava una volta) mi accorgo che c'e' quella riga.
Nell'azienda (grande) dove lavoravo prima come bodyrentallato,
supponendo che io anche avessi voluto correggere quella riga
la questione si sarebbe svolta nei seguenti termini (dove sono
ora il problema non si pone, non avendo comprato il codice ma solo
le licenze):
1. Chiamare il CM per dirgli: mi dovresti "scongelare il codice" 
  In quella particolare azienda questo veniva fatto pagare dal CM alla
  divisione "tecnica" 3 giornate lavorative (ad oltre 60 Euro/ora a
persona).
  E devi effettivamente aspettare 3 giorni prima di poter accedere al
suddetto codice.
2. una volta scongelato puoi fare la modifica
3. una volta modificato devi rifare i test (non-regression). Poi 
   andare a rideployarlo sulle macchine del cliente (non il cliente del 
   bodyrentallaro ma il cliente del cliente di quest' ultimo. E secondo
   te questo ti fa rideployare un'applicazione perche' c'e' una riga 
   scritta in modo non leggibile ?) 
4. Devi dire al CM  che ri-congeli il codice (e non so quanto il CM
   ti faccia pagare)
Intanto... sai quanto tempo serve per tutti i passi 1...4 ?
Poi...se per caso ne trovi un'altra di quelle righe che fai, ripeti 1-4 ?
Nel caso in cui magari i passi suddetti li devi fare perche' il codice
lo stai gia' modificando perche' il cliente ti ha chiesto di modificarlo,
allora *se* nel codice che stai modificando c'e' 1 sola riga scritta
in quel modo puoi anche tentare di modificarla ma in genere se in un
codice c'e' 1 riga scritta in quel modo, non e' l'unica (almeno nella
mia esperienza). E se e' scritta in quel modo e' gia' "molto
comprensibile".
Se ti metti a modificare quelle *veramente* incomprensibili, poi non
sai piu' se il software modificato funzionera' o no.
Ciao,
Marco.


 dato esattamente quello che volevano... un impiegatuccio sostituibile.
E' una situazione perdi-perdi, la peggiore, uno di voi due dovrebbe
fare un passo per mettervi fine.
Personalmente credo che lavorare bisogna lavorare bene. Poi si può
lavorare poco, con lentezza, fare resistenza, perfino mettersi in
malattia, ma il lavoro si fa per bene.
Anche perchè con uno che lavora bene ma è arrabbiato si può parlare,
con uno che lavora male non c'è da spendere neppure una parola.

 frustrante..
Vedi amico.... si puo' anche scoprire, a poco meno di 40 anni (ora ne
ho di piu' ma quando l'ho scoperto ne avevo pochi di meno) che si puo'
anche fare altro nella vita, dopo essere usciti dall'ufficio.
E quella riga di codice che fino a due anni prima ti rendeva iperattivo
al limite della crisi epilettica, oggi ti fa l'effetto di uno psicofarmaco
tranquillante.
Ciao,
Marco


 con uno che lavora male non c'č da spendere neppure una parola.
Infatti alla fine dei suddetti 2-3 anni non ho piu' speso nemmeno una
parola
(visto che *lavorano* anche quelli che dovrebbero dire a te cosa fare e in
genere lavorano *molto peggio* di te, pur avendo un compito *estremamente
piu' facile*, anche se qui molti sembrano convinti del contrario
 e *meglio retribuito*. Se lavorano male e' inutile continuare a spendere
delle parole)
Ciao,
Marco.


 single :-)
spesso la responsabilità di una famiglia fa ragionare tout court in modo 
più pragmatico e costruttivo. sul lavoro non è male. 
mi sembra che qualcuno di voi si perda fin troppo nel dare la colpa agli 
altri pur di non prendere una posizione che sia di minimo di controllo 
della propria esistenza (lavorativa, s'intende).
ps: io di anni ne ho 42, non sono un illuso.

ispas wrote:

PPS: evidentemente la cancellazione su Google News non funziona, visto
che con il mio client solito vedo ancora le triplette di messaggi dopo
alcune ore

 basato su rattoppi e instabilità!
e chi l' ha costruito il sistema se non un gruppo di programmatori
alla pizzaiola..

 stesso codice avrei i coglioni decisamente gonfi :-)
beh come si diceva prima uno dovrebbe cercare di lavorare sulle cose
che lo stimolano di piu...
poi chiaro anche io so che non viviamo nel paese dei balocchi...

 Rispondo a te per rispondere a tutti.
 
Rispondo a me stesso visto che nessuno si degna di "prendere la vita più alla
leggera". Guardate che il codice funziona! :-)
 
Qui dentro non si può più neanche essere simpatici che subito mettete il muso.
Siete sempre pronti ad attaccare il minimo comportamento "not politically
correct" senza magari essersi trovati nella stessa di situzione di chi
racconta le proprie esperienze personali.
 
Sarete tutti vecchietti? Mah....
 
Buona litigata.
 
-- 
Caronte
-- 
Inviato da 
Newsgate.Localinfo.IT
 
http://newsgate.localinfo.it
Powered by Localinfo.IT 
http://www.localinfo.it

 "rinunciare" alla metà delle risorse.
hai mai lavorato in pair programming? Io si' e la mia esperienza e'
che si lavora
molto piu velocemente. Anche gli studenti dei corsi che tengo lavorano
e imparano
in maniera piu' veloce se sono in coppia.
Ci sono moltissime ragioni evidenti per questo superficiale
paradosso..ad es..
1) nessuno lavora a palla otto ore al giorno... pair programming ti
permette di non fonderti
il cervello in quattro ore/
2) se fai pair programming non puoi cazzeggiare su msn o google talk o
leggendo le tue mail etc
3) due paia di occhi sullo stesso codice scovano bug ed eventuali
strade senza uscita molto piu'
velocemente..
4) lavorare cosi e' molto piu divertente e rilassante
senza contare condivisione del codice, continua code review,
formazione etc etc etc..
e tutto questo rimane vero per aziende piccole o grandi.

 Qui dentro non si può più neanche essere simpatici che subito mettete il muso.
a chi ti riferisci (riguardo al "simpatico incompreso", intendo)?

 a chi ti riferisci (riguardo al "simpatico incompreso", intendo)?
 
a me ;)


 a me ;)
e come sai che ti hanno messo il muso, se nessuno ti ha risposto?

 e come sai che ti hanno messo il muso, se nessuno ti ha risposto?
 
Non è che il muso l'hanno messo a me. E' questo thread che ha preso una brutta
piega. Io ho solo cercato di sdrammatizzare. Evidentemente non avete
apprezzato il tentativo...
dato che nessuno è in grado di analizzare il codice che ho scritto io,
specialemnte "enricoe" a cui era destinato il messaggio :-)))))))))))


 valere 2000 Euro al mese (anzi a mensilità)...
"seniority" da solo non significa nulla. Puoi avere anni alle spalle di
sviluppo di siti in php ma non avere idea delle problematiche legate a
progetti di livello enterprise, sia a livello puramente tecnico sia
applicativo. Il tuo valore dipende anche dall'ampiezza delle tue
esperienze, non solo dagli anni passati a fare le stesse cose.
PaF

 della propria esistenza (lavorativa, s'intende).
Per la verita', dal mio punto di vista e' proprio per ri-prendere 
un minimo di controllo della mia esistenza (lavorativa e non solo) che ho 
cominciato  a ragionare in un certo modo (visto che a cercare di proporre
soluzioni win-win, molto molto semplici non si veniva ascoltati).
 Prima (quando credevo ancora che proporre soluzioni win-win avrebbe 
potuto essere un'idea vincente) mi lasciavo abbastanza trasportare dal
lavoro e non facevo altro (non che mi dispiacesse ma
se per caso avessi voluto "cercare moglie" non avrei avuto il tempo di
farlo: avevo da fare il refactoring del codice). 
Almeno fino a qualche anno fa pagavano bene
(in rapporto al costo della vita).
Nel momento in cui hanno smesso di pagare => mi voglio riappropriare
del mio tempo, nel quale tempo "cercare moglie" o fare altro.
Ciao,
Marco.


 Tizio di turno a cui si rifilano le "sole" del codice...
in ogni team di cani...(senza offesa per le bestiole..)

 lavorare bene.
straquoto

 Indovina cosa succede quando glielo hai spiegato ?
se vieni insaccato ogni volta che fai una proposta costruttiva e'
chiaro segno i programmatori si devono mettere d'accordo per far
liquidare il loro pm, o se questo non e' possibile andarsene..

 a Ryhad alla fine dello stage...)
continui a non voler capire.. e' ovvio che la maggior parte delle
miopi societa' italiote mirano
a farti lavorare il piu' possibile pagandoti il meno possibile. E'
ovvio che ce la mettano tutta per sfruttarti.
Ma e' altrattanto ovvio che questo non significa che tu debba
lasciarti sfruttare.
E lavorare con scazzo NON E' UNA DIFESA dallo sfruttamento.
Come e' gia ' stato detto .. sarebbe come dire.. "mia moglie e' una
stronza e io allora per vendicarmi non scopo piu' "

 valere 2000 Euro al mese (anzi a mensilità)...
questo e' un punto fondamentale. Un programmatore che sis rispetti non
doverebbe prenefdere meno
di 2000  al mese nemmeno al primo incarico. Piuttosto si dovrebbero
assumere meno programmatori,
ma buoni e pagati giustamente.

 apprezzato il tentativo...
chi sdrammatizaa e' semepre il benvenuto..se pensi che questo sia un
gruppo serioso sei qui da poco.. ti sarai perso
le storie sui guga guga...
In ogni caso a parte qualche risosta un po' brutale questa' mi sembra
una thread interessante... poi e' chiaro che siamo seri fino a un
certo punto.. alla fine si tratta pur sempre di cazzeggio..

 liquidare il loro pm, o se questo non e' possibile andarsene..
Il problema non sono i PM, ma i clienti! Quale PM non proporrebbe una 
integrazione della propria offerta per migliorare quanto già in essere che 
funziona (che, in pratica, vuol dire non avere stress troppo forte sui 
rilasci, visto che l'applicazione in esercizio continua a funzionare già 
così come è)? Credo nessuno.
Il fatto è che la risposta del cliente (al 99%) sarà del tipo: "per me 
funziona, tanto mi basta..."
Ciao,
Alessio (a.k.a. Kinglion Il Meticcio) 

 stronza e io allora per vendicarmi non scopo piu' "
Non mi sembra calzante...è più appropriato quello "mia moglie è una stronza, 
ne cerco una meglio, ma finchè non trovi di meglio almeno cucina..." (è un 
bruttissimo paragone, estremamente maschilista, ma era solo per rimanere 
sulla tua linea).


 cambiarla...".
un buon modo di cominciare a cambiarla probabilmete passa attraverso
le presa di coscienza
da parte dei programmatori di essere professionisti e non tecnici da
quattro soldi

 stronza e io allora per vendicarmi non scopo piu' "
Ammettiamo (ma *non* concediamo) che quello che dici possa avere un
senso (non che possa essere vero. Questo non lo ammetterei nemmeno.
Ma che possa avere un senso, ammettiamolo pure)
Ok. Quale sarebbe la corretta "difesa dallo sfruttamento" ?
Anche perche' in molti sembrate dire quello che dici tu. Ma l'alternativa
non viene fornita (parlarci ? fare un passo indietro ? Secondo te in 2-3
anni non sono state tentate le varie strade ? E una volta che le varie
strade non portano a niente che si fa ?).


riccardo...@gmail.com
 ha scritto:



Non avevo visto questo post. E secondo te cosa e' successo alla fine ?
Comunque il problema non sta esattamente nei termini che dici tu.
Il problema non e' *tecnico*. E' molto piu' *logistico* (vedi il
post in cui parlavo del CM). Sembra che ancora i programmatori non
abbiano capito che, almeno nelle grandi aziende,
 non lavorano da soli, ma sono inseriti in una organizzazione che ha
delle regole. La correzione anche di 1 singola linea di codice, se fatta
"appositamente" per mantenere "leggibile" il codice stesso scatena
tutta una serie di processi aziendali che vanno dal PM al cliente della
multinazionale passando per i vari dirigenti responsabili sia del cliente
sia del PM (e anche per i dirigenti della multinazionale) nonche' per i
dirigenti dei gruppi che fanno i test e il deployment (che potrebbero
essere diversi da chi sviluppa il codice. E spesso sono diversi
davvero)


 progetti di livello enterprise, 
Effettivamente leggendo le risposte di alcuni che farebbero
 pensare  che secondo loro modificare
una linea di codice, sia pure scritta male, significa "solo" ricompilare
il codice e rideployarlo "al volo" viene da pensare che le problematiche
non strettamente tecniche che si affrontano in certi contesti aziendali
siano oscure ai piu'. Magari e' solo
un'impressione, visto che siamo su un ng. Pero' 
e' un'impressione che io sinceramente ho.
Ciao,
Marco,


 strade non portano a niente che si fa ?).
Questa cosa è degerata.
Ma tanto per riportarla sui miei binari, e per precisare il perchè del
mio j'accuse :
Come un architetto che "ci tiene" alla pulizia dei suoi disegni, o un
giornalista che "ci tiene" alla sintassi dei suoi articoli, o un
saldatore alla perfezione delle sue saldature, io "ci tengo" che il
mio codice sia pulito e l'applicazione stabile. Non sono affatto un
nerd patito che vive con la maglietta di matrix, ma ci tengo al mio
lavoro, tutto qui.
Questo va oltre il rapporto di lavoro, oltre i problemi organizzativi,
perfino oltre l'etica stessa della professione. Se in un posto lavoro
male me ne vado, se non posso andarmene subisco, ma di sicuro non
scrivo codice instabile o arrabattato come quello in oggetto perchè
non posso andare contro quello che ho studiato da tutta la vita.

 ma buoni e pagati giustamente.
Io posso essere anche d'accordo sulle due righe che ho lasciato. 
Poi pero' nella realta' in cui vivo
io c'e' la legge Biagi e molti di quelli che professano il concetto
da te espresso poi votano a favore di chi ha approvato la legge Biagi.
Ovvero a favore di un mondo in cui il programmatore viene acquistato del
cliente finale (ovvero da colui che teoricamente dovrebbe averne bisogno)
tramite un'asta al ribasso. Tra l'altro un'asta alla quale i programmatori
stessi *non* sono nemmeno autorizzati a partecipare.
Io vivo in questo mondo qui. Gli altri non so...
Per quanto mi riguarda sono talmente d'accordo con il concetto da te
espresso che quelli che hanno approvato la legge Biagi si sono guadagnati
l'onore di non essere votati da me e di non essere mai piu' votati da qui
all'eternita'.
Ciao,
Marco.


 quattro soldi
Come dicevo nell'altro post, io ce l'ho eccome. E tale presa
di coscienza la metto in atto nell'unico momento che ho a mia disposizione
per metterla in atto: quando vado a votare.
