Newsgroup: it.comp.lang.delphi
Titolo: in merito alla consegna del sorgente ad un cliente

Salve, volevo una vostra opinione in merito alla seguente questione:
un cliente mi ha detto di volere la consegna del sorgente viste le sue
brutte esperienze degli anni precedenti, nell'aver acquistato due software
ed essendo ora vincolato a vita a queste 2 case software in merito ai prezzi
di abbonamento
o di modifihe agli stessi.
Dovendogli realizzare un database, mi ha chiesto anticipatamente di
consegnargli i sorgenti  in una busta chiusa e sigillata con cera lacca in
modo che se un domani avremo dei diverbi o ci saranno dei problemi, lui
potrà aprire la busta e farsi fare modifiche o altre cose da un altro
programmatore.
Ovviamente se lui dovesse aprire la busta io non risponderei più di
eventuali mafunzionamenti del programma e lui è vincolato a non poterlo
rivendere.
Quali sono le vostre personali opinioni su questo fatto?
Da una parte è vero che se io svolgo un lavoro ho il diritto di essee
l'unico a metterci le mani (diritto intellettuale), dall'altra però se io
dovessi cambiare lavoro o avere seri problemi, lui si ritroverebbe a piedi
con il programa e il suo investimento sarebbe buttato.
accetto commenti e considerazioni da tutti. grazie.

Lui da per scontato che un altro programmatore possa mettere le mani nel tuo
software. Non e' una cosa cosi' scontata, e probabilmente in quel caso gli
costerebbe meno farsi rifare il programma. Piu' utile dei sorgenti,
probabilmente, sarebbe per lui l'avere i tracciati record completi con la
documentazione relativa alle relazioni tra gli archivi, e qualche utility
per l'export/stampa raw dei dati cosi' da poterli eventualmente migrare, in
caso di necessita', su un'altra piattaforma.
Ribadisco il concetto che i sorgenti, senza il programmatore originale, a
mio parere, non servono proprio a nulla.
Ciao, Sandro

 ...


 ha scritto nel messaggio
news:2M2Q8.121909$g04....@tornado.fastwebnet.it...

Compliementi a entrambi per le risposte.

> Compliementi a entrambi per le risposte.
Complimenti a te per il quoting!!!! ;-DDD
--
Giulio Pipitone (
www.FIGHTERS4WEB.COM
)
#mirror italiano ufficiale 
http://spam.abuse.net#

 ha scritto nel messaggio
news:qV4Q8.122009$g04....@tornado.fastwebnet.it...


 ha scritto nel
messaggio news:De2Q8.38194$j65.8...@twister1.libero.it...


 costerebbe meno farsi rifare il programma. 
Molto discutibile.
Se il programma e' ben fatto e se il programmatore che riceve il codice
e' sufficientemente bravo, le modifiche sono fattibilissime.  
Il concetto che ci sia necessariamente bisogno del programmatore
originale
per portare avanti un progetto e' contrario alle regole con cui si
costruisce
il software.  Tra l'altro, ci sono dei vincoli precisi, a volte,
nell'ottenimento
del codice sorgente da parte del committente, come quelli di non
occultare
il sorgente.  Se un software, per le sue modifiche, richiede la presenza
del
programmatore originale, e' un software scritto coi piedi.
Concordo comunque sul fatto che occorrono, per la piena comprensione del
codice, altre informazioni come i tracciati record, le descrizioni
tecniche,
ecc... ecc....
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Nell'ambito di procedure complesse, o nel codice documenti variabili e
algoritmi, usi nomi leggibili e comprensibili, commenti i procedimenti,
ecc. - e quindi spendi almeno 5 volte il tempo necessario alla mera
scrittura del codice - oppure pensi alla consegna del sorgente punto e
basta. Generalmente non si commenta piu' di tanto il sorgente, perche' si
sa, a priori, che chi ci mettera' le mani sara' lo stesso programmatore che
l'ha fatto; probabilmente se si lavora fin dall'inizio con la logica
opposta, allora il codice sara' in qualche modo modificabile anche da terzi,
pur se con oggettive difficolta'.
Ti faccio un esempio di mio codice, estratto da una unit di 1500 linee, che
fa delle statistiche:
    // per ogni modello cerca tutte le combinazioni con tutti i colori
    s2:=CoordinateCelle;
    repeat
     n:=FastPos2(';'+s1+'+',s2); if n=0 then break;
     s4:=copy(s2,n+1,30);
     s4:=copy(s4,1,FastPos2(';',s4)); // a questo punto s4 contiene
<rifmod>+<rifcol>=<rifgriglia>;
     delete(s2,1,n+length(s4)-1);
     // determina il rifcol
     s3:=copy(s4,FastPos2('+',s4)+1,30); s3:=copy(s3,1,FastPos2('=',s3)-1);
s5:=copy(IndexColoriOrdinati,FastPos2(';'+s3+';',IndexColoriOrdinati),length
(IndexColoriOrdinati));
     s3:=copy(s5,FastPos2('=',s5)+1,30);
     rifcol:=strtoint(copy(s3,1,FastPos2(#255,s3)-1));
     // determina il rifgriglia
     s4:=copy(s4,FastPos2('=',s4)+1,30);
rifgriglia:=strtoint(copy(s4,1,length(s4)-1));
     // qua somma g/o/c/v di CelleGriglia[posizione ricavata da rifgriglia]
alla struttura ListaLinMod
s4:=copy(IndexCelleGriglia,FastPos2(';'+inttostr(rifgriglia)+'(',IndexCelleG
riglia)+1,30);
     s3:=copy(s4,FastPos2('=',s4)+1,20); s3:=copy(s3,1,FastPos2(';',s3)-1);
     posiz:=strtoint(s3);
     if StatxModelli then QualeCella:=i else begin // in caso di statistica
per linee deve ricavare a partire dal modello la linea corrispondente e
sommare tutto su quella
      s3:=copy(s4,FastPos2('(',s4)+1,30); s3:=copy(s3,1,FastPos2(')',s3)-1);
s3:=copy(IndexLineeOrdinate,FastPos2(';'+s3+'=',IndexLineeOrdinate)+1,30);
s3:=copy(s3,FastPos2('=',s3)+1,30);
      QualeCella:=strtoint(copy(s3,1,FastPos2(';',s3)-1));
     end;
come vedi molte variabili di servizio, come s2, s3, s4, ecc. hanno nomi
"oscuri", eppure la comprensione di cio' che contengono (sono liste
temporanee usate durante l'elaborazione) e' fondamentale per capire la
logica della procedura, che a sua volta e' alla base per fare qualunque
eventuale modifica. Non e', evidentemente, questo di sopra, un pezzo di
codice fatto per essere modificato da un altro. E cosi' lavorano tutti.
Ciao, Sandro

 ha scritto nel messaggio
news:qV4Q8.122009$g04....@tornado.fastwebnet.it...

Quiting? scusa l'ignoranza cos'è?

 codice fatto per essere modificato da un altro.
Credo che la cosa più difficile della modifica al codice altrui sia quella
di capire come ha ragionato, quale strada ha preso il programmatore per
giungere al traguardo.
Reputo i programmatori in genere persone molto logiche e in quanto tali sono
in grado di risolvere lo stesso problema in 1000 diversi modi. Secondo me il
vero problema non è tanto nello stile di programmazione (ordinato,
confusionario, indentato e quant'altro) piuttosto che nei nomi assegnati
alle variabili (che dopo un po' che ci sbatti la testa ti ci abitui) ma è
proprio di entrare nella logica di qualcun altro. Credo che ci sia un buon
numero di casi in cui un programmatore preferirebbe riscrivere del codice da
zero piuttosto che cercare di rielaborare un codice altrui.
--
- Carlo -
cbertu81(at)libero(dot)it

E cosi' lavorano tutti.
Non e' affatto vero.


 zero piuttosto che cercare di rielaborare un codice altrui.
Sicuramente chi ha lavorato sul codice di Zortek ;)


 che cercare di rielaborare un codice altrui.
Sante parole. Nel mio caso, anche se il codice è mio ma l'applicazione ha 2/3
anni, rigetto la mia opera e piuttosto riscrivo tutto :)
--
Jax

 Quiting? scusa l'ignoranza cos'è?
No quiting, ma quoting! In italiano "quotare", ovvero riportare solo le
parti significative del messaggio a cui si risponde!
Molti non si rendono conto che rispondendo ad un messaggio lasciano tutto il
testo originale ai piedi (o in testa) della propria  risposta. Questo ha
principalmente due ripercussioni negative:
1 - Il testo perde in leggibilità.
2 - Il volume di dati da scaricare per poter seguire i thread raddoppia.


 Sicuramente chi ha lavorato sul codice di Zortek ;)
Aldilà della battuta credo che immedesimarsi nel ragionamento altrui sia un
compito veramente arduo!


 compito veramente arduo!
come ho sempre detto, programmare e' un'arte, e' qualcosa che va ben oltre
l'aspetto tecnico puro e semplice; scrivere codice vuol dire esprimere la
propria creativita' logica (sembra un controsenso in termini eppure e'
l'essenza della programmazione), quindi una cosa estremamente personale e
assolutamente non generalizzabile o sottoponibile a regole stilistiche o
pratiche.
Ora, scrivere codice leggibile, pulito, e ampiamente commentato, per quanto
mi riguarda, sarebbe una forzatura dal mio stile (e di chiunque altro; al di
fuori dell'ambiente universitario voglio vedere chi, professionista, si
mette a fare un lavoro certosino di documentazione interna, in termini di
nomi di variabili e commenti) che mi deconcentrerebbe, oltre a farmi perdere
tempo, e mi porterebbe ad allungare i tempi di sviluppo per via anche dello
"stress" aggiuntivo indotto alla variazione del mio metodo.
Nel mio metodo ci sono delle costanti personali di stile e di uso di
variabili che rendono perfettamente leggibile, comprensibile, e mantenibile
il codice scritto da me. Questo anche per confermare quanto detto da Carlo e
insieme il mio dissenso (ormai anche questo costante :D) da quanto
pomposamente affermato da Andrea.
Ciao, Sandro

> Quiting? scusa l'ignoranza cos'è?
APPUNTO! ROTFL! :)))

 Non e' affatto vero.
eh gia', piacerebbe anche a me che non fosse vero :)
Ciao, Sandro

 sia un compito veramente arduo!
Non e' questione di "immedesimarsi".  Se si hanno delle linee guide
gia' tracciate da altri programmatori (commenti nel codice, descrizione
formale degli algoritmi adottati, tracciati record delle tabelle) la
modifica del codice non richiede sforzi titanici.
Se tutti programmassero come dite voi, a nulla varrebbe tutta la 
teoria alla base della *buona* costruzione del software, la cui
importanza, ti assicuro, si riscontra sul campo.
Programmare non vuol dire battere sulla tastiera, sono due 
attivita' molto diverse e la seconda e' solo una *piccolissima*
parte della prima.


 nomi di variabili e commenti)
Praticamente tutti quelli che lo fanno seriamente.
Che dire, evidentemente non hai mai partecipato allo sviluppo di
un software un po' piu' complesso che non il calcolo della somma
di due numeri ;)


 eh gia', piacerebbe anche a me che non fosse vero :)
Non lo e', te l'assicuro.


 Balle.
Beh, non sarei così categorico. Quello che ha detto Zortek non è l'assoluta
verità, ma è quello che secondo lui significa programmare. Trattasi di
opinioni; non esistendo scienza alcuna che provi la verità o la falsità di
quelle parole rimangono opinioni. Sinceramente anche io credo che
programmare sia un' arte e che il codice rispecchia la propria creatività
logica, ma questo non significa che uno tra noi debba avere per forza
ragione.


 quelle parole rimangono opinioni. 
Grazie per avermi spiegato anche questo.
La prova che quelle parole non corrispondono a verita' deriva
dall'esperienza pratica.  Ad un cliente non frega nulla che tu
reputi il progetto che gli serve come un frutto artistico.
Gli serve che funzioni e per garantirne il "funzionamento" 
(termine generico che comprende anche la manutenzione di tutto il
sistema) serve che tu per primo non pasticci troppo coi colori
e con la tela.  La manutenzione occupa piu' del 70% del ciclo
di vita di un software ed e' quindi importante che *in progetti 
seri* si punti molto sulle regole di buona progettazione e
codifica.
 >Sinceramente anche io credo che programmare sia un' arte
Posso farti una domanda ? in quante aziende hai lavorato come
programmatore e a quanti progetti hai partecipato ?
Programmare e' un'arte, ma e' un'arte in senso lato. 
Alla realizzazione delle "opere" partecipano, generalmente, 
piu' persone, il che comporta che un programma sia qualcosa di 
molto piu' articolato rispetto a un quadro o una scultura.  
La programmazione viene definita "arte" proprio perche' richiede
bravura e la bravura si acquisisce dall'esperienza.  
L'esperienza insegna che il software deve essere costruito per 
essere manutenibile.  Chiunque se ne frega di questo principio
potra' continuare a scrivere il proprio "spaghetti-code", senza
preoccuparsi degli altri, ma non credo fara' molta strada in
un ambiente in cui e' richiesta la capacita' di lavorare in 
team.
Con questo ho simpaticamente concluso il mio intervento, 
consigliandovi un testo che vi fara' bene ;) :
"The practice of programming" - Brian Kernighan, Rob Pike.


allora l'open source ? non è possibile da realizzare ? e quella cosa
chiamata linux ?
non è che basta scrivere codice comprensibile e magari  commentarlo ?
Davide

Lascia perdere Carlo, discutere con LaForgia e' come discutere di religione
con un kamikaze islamico, ha le sue convinzioni incrollabili e non solo da
li' non esce, ma si permette pure di fare l'arrogante e di insultare chi non
la pensa come lui. In ogni caso dal suo discorso si evince che la
programmazione che intende lui, a differenza di quella che intendiamo noi,
e' quel lavoro pedissequo affidato ai "coder" che lavorano in team, che non
vedono i risultati del loro lavoro, e che devono seguire in modo rigido non
solo le regole di codifica del project leader, ma le analisi fornite loro
dagli analisti. Nelle aziende di una certa dimensione si lavora cosi', non
c'e' dubbio. Ci sono anche gli spazzini del codice e una miriade di altre
figure associate, tutti "operai", e quindi che nulla hanno a che fare con la
figura dell' "artista" del software che produce inventando. C'e' chi fara'
per tutta la vita il muratore, e chi fara' l'architetto e ingegnere. Per
LaForgia tutti dovrebbero essere muratori. Personalmente non mi ritengo tale
ne' riuscirei mai a inquadrarmi in una figura del genere, e mi pare di
capire che anche per te valga la stessa considerazione :)
Ciao, Sandro

 non è che basta scrivere codice comprensibile e magari  commentarlo ?
l'open source e' gestito da team di programmatori coordinati da leader che
dirigono i progetti. Siamo sempre nell'ottica di "operai" (volontari,
oltretutto) che si arrabattano su spezzoni di codice affidati loro piu' che
su progetti.

aumento dei costi di produzione).
Andrea, ho scoperto perche' e' da un po' non ti fai piu' sentire
su 
dedonline.com
:
Hai letto il libro di Ghezzi ! :)
Visto quello che _giustamente_ scrivi
suppongo che tu abbia capito che dato:
First: Smallint
Second: array[0..5] of Char
scrivere 
  Move(Pointer(Integer(ActiveBuffer)+SizeOf(SmallInt))^,
       Buffer^,
       6);
e' sbagliato ed e' meglio scrivere:
  Move(Pointer(Integer(ActiveBuffer)+SizeOf(First))^,
       Buffer^,
       SizeOf(Second));
Cosi' se durante il ciclo di vita del SW per caso cambia
il tipo di First o se cambia il tipo di Second 
devi cambiare solo la dichiarazione e non devi modificare anche il codice.
Cosi' garantisci un costo di produzione inferiore e tra l'altro
aumenta la leggibilita' (si capisce cosa fa' la linea senza dover
controllare la definizione della struttura) per chi, come giustamente dici, 
dovra' mantenere il codice al posto di chi lo ha scritto.
Ciao
Andrea
p.s. al DDay molti mi hanno chiesto chi eri perche' volevano
conoscerti, al prossimo ci vieni?
-------------------------------
Message Posted by  <dedGateway>
http://www.dedonline.com/forump

 di due numeri ;)
Ecco se programmiamo ad un livello ancora piu' professionale,
potremmo pensare che anche la struttura potrebbe cambiare
e potremmo scrivere la Move in modo che sia indipendente
dall'ordine di dichiarazione della struttura.
Otterremo cosi' qualcosa di simile a quanto suggeriva 
uno che sta partecipando ad un progetto piu' complesso di una
calcolatrice, Nando:
http://www.dedonline.com/scripts/nntp.exe/msgbody?ng=libero.delphi&id=%3CXns921DBCD...@193.207.46.9%3E
Ciao,
Andrea
p.s. al DDay molti mi hanno chiesto di te, volevano conoscerti,
al prossimo DDay ci sarai?


 al prossimo DDay ci sarai?
Allora dovrete trovare un parcheggio immenso. Se viene Laforgia si prevede
una grande affluenza di automobili: la macchina resta sempre il posto
migliore nel quale tenere un cric! :-)


 edtCodiceFiscale.Text := 'XXX';
infatti questo č un commento completamente inutile perchč ridondante.
non basta saper programmare, ma bisogna anche saper commentare.
Davide Consonni

 con un kamikaze islamico,
questa me la segno ROTFL.....
--
Davide Consonni
( 
davidec...@virgilio.it
 )

appunto, il codice si riusa tranquillamente e deve anche poter essere
compreso da altri no ?


 religione con un kamikaze islamico
LOOOOOOOOOOOOOOOOOOOOL !!!! ^____^
Ciao!
Davide DG.
-- 
Evvai!! Biochimica e' finita !!! finalmente ho dato quel f*****o esame!!

 compreso da altri no ?
sul fatto che si riusi sono abbastanza d'accordo; "tranquillamente" non e'
invece una cosa cosi' generalizzabile; il fatto, infine, che debba poter
essere compreso da altri, ripeto, non e' una cosa cosi' scontata..
comprendere un pezzo di codice, e addirittura modificarlo, significa aver
ben chiara l'analisi che vi sta alle spalle, cosa che generalmente non e'
inclusa nel codice stesso (nei commenti non si indica l'analisi) e che solo
nei progetti che partono gia' come "di team" viene messa a disposizione di
tutti e da tutti integrata. Ma il mondo del software non e' fatto solo di
team di sviluppo coordinati da project leader, con squadre di analisti,
debugger e coder.
Ciao, Sandro

 che non l'ha mai visto.
sarebbe impossibile, ovviamente, tenere a mente il codice per anni, ma un
programmatore di un certo livello e' quello che e' in grado di ricostruire
il processo logico dietro alle -sue- procedure semplicemente guardando il
suo codice, anche vecchio di anni, sempre che in questo abbia posto il suo
stile, la sua "impronta". Personalmente sarei in grado senza problemi di
modificare miei sorgenti vecchi di 15 anni in TP, e anche piu' vecchi in
altri linguaggi.
Chiaramente non e' una cosa che sono in grado di fare tutti, ma programmare,
si sa, non e' una cosa per tutti (e per fortuna ;) ).
Ciao, Sandro

 migliore nel quale tenere un cric! :-)
piu' che altro sara' necessario trovare una sala abbastanza grande per farci
entrare tutto il suo ego.
;)
Ciao, Sandro

Ciao a tutti, la discussione che e' stata portata avanti in questi giorni su
quale sia il metodo migliore o la filosofia migliore per scrivere programmi
e' molto interessante.
Avrei soltanto un appunto da fare, non sarebbe forse meglio discutere di
queste cose in un altro newsgroup?
Il rischio altrimenti e' di intasare un newsgroup specifico (per il Delphi)
con discussioni di carattere generale.
Questa e' la mia opinione.
Andrea
P.S. Ho notato che sta succedendo la stessa cosa con il post Service & Mysql
:-)

la discussione non mi sembra OT e poi se il flame è intelligente....



Grazie per l'intelligente ma il flame cos'č?

 anni, rigetto la mia opera e piuttosto riscrivo tutto :)
Appunto. Neanche tu riesci a capire quello che hai scritto. Dei miei amici
dicono che i commenti sono inutili perché tanto loro lo capiscono cosa hanno
scritto. Tu dimostri il contrario. Quanto tempo hai perso riscrivendo tutto?
Forse se documentavi il codice non ce ne voleva così tanto? Dovendo
modificare un progetto OpenSource, sono riuscito a capire da dove partire in
un paio di giorni(ammetto che avevo iniziato a guardare il codice un po'
prima, ma solo qualche occhiata). Si trattava di Java e io in Java avevo
scritto, prima di ciò, sì e no 20 righe di codice.
Per quanto riguarda LaForgia, concordo con le osservazioni sulla sua
presunzione(l'ho già apprezzata altre volte), ma ritengo che abbia ragione
in questo caso.

Mettiamoci d'accordo. LaForgia parla di grandi progetti, e voi mi pare di
no. Mettete le carte in tavola: quali sono le dimensioni dei vostri
progetti? Evidentemente siete abituati a lavorare in maniera diversa.

 capire che anche per te valga la stessa considerazione :)
Secondo me riscrivere da zero qualcosa perché non è chiara è un lavoro non
da muratore, ma (cosa c'è di peggio, con il rispetto per i muratori), da
cane, da zecca, da microbo... da co@@ione!

 cane, da zecca, da microbo... da co@@ione!
ognuno è libero di esprimere la propria opinione, ma se per te è meglio
modificare/ampliare del codice poco chiaro allora chissà che bel software!


 progetti? Evidentemente siete abituati a lavorare in maniera diversa.
scusa ma a parlare di grandi progetti siam tutti capaci, il discorso č poi
prender parte ai progetti.
Io posso dirti di aver sviluppato progetti che si sono estesi per 2/3 anni e
con milioni di righe di codice! Ci credi?
Poichč dal mio punto di vista non ho alcuna competizione con Laforgia mi
posso benissimo risparmiare (e di fatto lo faccio) di esporgli i miei
progetti (sia che siano composti da 5 righe di codice o che siano  piů
grandi) solo per avere ragione su qualcuno che parte col presupposto che gli
altri sbagliano.
--
- Carlo -
cbertu81(at)
libero.it

 ragione in questo caso.
No comment :)
--
Jax

 modificare/ampliare del codice poco chiaro allora chissà che bel software!
del codice poco chiaro? Allora non hai capito: devi evitare prima di
scrivere software poco chiaro! Rileggi la mail in quest'ottica, e forse
capirai. Non ho detto:"lavora su software poco chiaro", ho detto "scrivilo
chiaramente così non devi riscriverlo per ogni singolo errore"! È diverso!

 Beh, complimenti. Non posso che manifestare la mia nVidia ;)
Devo aggiungere che la tua nVidia non è tanto meritata,
a) perché quello che ho scritto è sì e no 40 righe(o meglio, ho preso 40
righe e le sto modificando un pochino), anche se ho dovuto capire qualcosa
sull'architettura;
b) il merito è di Java e di chi ha scritto il programma originale; quando le
funzioni si chiamano addJextKeyBindings, non ci vuole un genio(solo un po'
di inglese) per capire che è probabilmente là che devo inserire il codice
per far gestire da una certa classe un certo hotkey.
Ti posto un po' di codice:
public class TextUtilities
{
 public static int findWordStart(String line, int pos, String noWordSep)
 {
  char ch = line.charAt(pos);
  if (noWordSep == null)
   noWordSep = "";
  boolean selectNoLetter = (!Character.isLetterOrDigit(ch) &&
noWordSep.indexOf(ch) == -1);//&&=and
  int wordStart = 0;
  for(int i = pos; i >= 0; i--)//i--=decrementa i
  {
   ch = line.charAt(i);
   if (selectNoLetter ^ (!Character.isLetterOrDigit(ch) &&
noWordSep.indexOf(ch) == -1))  //lo ^ significa xor
   {
    wordStart = i + 1;
    break;
   }//end if
  }//end for i
  return wordStart;//il valore di ritorno va con return.
 }//end findWordStart
}
Molto probabilmente riuscirai a capire tutto il codice pur non avendo mai
programmato in Java(ho aggiunto commenti su punti oscuri della sintassi).
Inoltre, i javadocs, ovvero la possibilità di creare una reference
ipertestuale al tuo codice, non vanno sottovalutati.
Infine: qualcuno ha mai visto software GNU come gcc? Avete guardato la
test-suite? In pratica, metà del tempo viene usato per scrivere i test. Ma
poi il software è più sicuro(vedi eXtreme Programming, XP).
Ciao!
--
Paolo Giarrusso
Per rispondere togliere solo "TOGLIMI" dall'indirizzo, non _spam.

 altri sbagliano.
Ok, lui discute con un po' di presunzione, ma ritengo sia vero che in un
grande progetto si debbano seguire certe regole, almeno quando si lavora in
gruppo. O no? Lui dice che se si lavora in gruppo, il software deve essere
scritto seguendo certe regole. Nel tuo gruppo si riscriveva il codice
vecchio che non si capiva?
Ciao.


 test. Ma poi il software è più sicuro(vedi eXtreme Programming, XP).
Non sono esperto di tecniche di programmazione, ma non è certo un segreto che la
fase di test *dovrebbe* essere quella più sostanziosa. Ma again, dipende dal
tipo di progetto.
--
Jax
PS: Complimenti per il linguaggio e la coerenza, spesso si liquidano i giovani
come maleducati e irrispettosi, ma c'è sempre l'eccezione che conferma la
regola. Keep it up.

 vecchio che non si capiva?
E' ovvio che il codice va scritto seguendo certe regole, ma è altrettanto
vero che se uno lavora da solo come libero professionista è *libero* di
*scegliere* il modo in cui organizzare il suo software.
Io semplicemente condividevo alcuni punti di vista con Zortek, non ho mai
detto "Che la gente violi i principi di software engineering! Vedrete, poi
il software sarà migliore". Cmq stai attento a non lasciarti ingannare dalla
persona che ho più volte citato; a lui piace bagnarsi la bocca con termini
complessi, di "alta classe" ma ricorda che un vero programmatore non lo
scopri su un newsgroup, e sinceramente ancora non ho visto la sua firma in
quei grandi progetti a cui dice di appartenere.
Ciao!


 vecchio che non si capiva?
E' ovvio che il codice va scritto seguendo certe regole, ma è altrettanto


 dall'alto dei cieli a dircelo.
ROTFL...... questa frase direi che riassume in modo *perfetto* tutto questo
argomento :DDDDDDDD
--
Jax