Newsgroup: it.comp.lang.delphi
Titolo: Gestire un grosso progetto in piccoli eseguibili

Salve a tutti, sono nuovo di questo news,
  spero qualcuno possa aiutarmi e spero l'argomento risulti interessante.
Sto creando un gestionale in D5 e mi accorgo che più il progetto si sviluppa
più problemi si incontrano nelle varie versioni già installate presso i
clienti.
A vostro parere come sarebbe meglio gestire progetti di grandi dimensioni:
da alcuni discussioni con miei colleghi sono nate diverse idee che vi
espongo.
1. Spezzare il programma in sottoprogrammi (tanti piccoli exe) ognuno
dedicato alla propria funzione es:
una form che gestisce inserimento, visualizzazione eliminazione e ricerca
clienti, una per i fornitori, una per la tabella iva ecc...
questo comporta però una dispersione di tabelle (uguali! la tabella iva è
sempre la stessa) con conseguente difficoltà di modifica in caso di
aggiornamento ai campi. Inoltre come ci si possono passare normali parametri
come il codice del cliente selezionato, oppure la verifica che il codice
digitato esista veramente ecc..
2. Di nuovo tanti piccoli exe che però si rifanno tutti allo stesso
datamodule, letteralmente copiato in ogni progetto, ma che dimensioni !!
3. Diverse DLL dedicate ognuna a Ins. visual, cancellazione ecc.. insomma
come gli exe ma con maggior semplicità nel passaggio di parametri
4. Altro ??
Non è da molto che programmo in delphi (2 anni circa) ma credo che sia un
problema non indifferente, inlotre lavorando in più persone sullo stesso
progetto si hanno un sacco di problemi e rischi di perdita di modifiche
durante la 'fusione' delle varie modifiche fatte da ognuno.
Qualcuno che magari ha più esperienza di me ha qualche dritta ???

 Qualcuno che magari ha più esperienza di me ha qualche dritta ???
Direi che la soluzione di mettere codice dentro delle DLL è la soluzione +
conveniente, e ti permetterebbe anche di aggiornare versioni o correggere
bachi abbastanza facilmente, senza redistribuire tutto il malloppozzo. Per
quanto riguarda il lavoro in team, credo sia difficilmente gestibile senza
un tool per il lavoro in team e gestione delle versioni. Dai un occhio a
FreeVCS, che è il tool che usiamo noi con soddisfazione. Tra l'altro è "a
gratis".
Ciao,
G.

Ciao, il mio modestissimo parere:
ancor prima di leggere le opzioni da te descritte, staveo pensando di
suggerirti l'uso delle DLL.
Ciao David

 come gli exe ma con maggior semplicità nel passaggio di parametri
Questa credo sia ottimale.
 
Riguardo il lavoro in team, qui usiamo Visual Source Safe di zio Billy.
Ogni tanto fa le cose strane tipiche di Microsoft, ma per il resto
funziona benino.
Bye
AS
"Se è Microsoft non funziona"
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

come gli exe ma con maggior semplicità nel passaggio di parametri
Secondo me l'utilizzo delle DLL puo' comportare un grosso problema di
versioning. Se non si sta molto attenti si rischia di trovarsi clienti
con DLL diverse. E poi, visto che nessuno è perfetto, la DLL ha il
problema, IMHO, di essere piu' difficile da debuggare.
Piuttosto prenderi in considerazione l'utilizzo delle BPL che possono
creare anche loro problemi di versioning ma almeno sono trasparenti in
fase di sviluppo/debug.
Massimo.
-----------
Ore 18.30: premo invio.

 Qualcuno che magari ha più esperienza di me ha qualche dritta ???
io, in un piccolo gestionale, ho fatto tutto ciò che ti ho detto sopra.
Ho separato il programma di magazzino da quello relativo a fatture, piano
conti ecc ecc..
Ovviamente le stampe tutte in una DLL, immagini e testo idem.
Però il programma di magazzino, non sono mai riuscito a farlo funzionare in
una DLL.
Ogni tanto capitavano errori strani. Non ho avuto modo di perderci tempo a
capire il perchè, anche perchè accadeva ogni tanto, quindi ho messo tutto il
programma in un eseguibile. Insomma un EXE per il magazzino che viene
richiamato dal programma di contabilità senza che l'utente si accorga di
nulla.
Ti saluto....ciao !!
Antonio Tarolla

 durante la 'fusione' delle varie modifiche fatte da ognuno.
Provate a stabilire un "protocollo interno" di nomenclatura di variabili
e funzioni. O ancora meglio, PRIMA di iniziare il lavoro riunitevi e
stabilite
in anticipo:
1) chi scrive cosa, e fate in modo che le competenze siano il più possibile
    indipendenti.
2) le "interfacce" interne fra i moduli: nel senso che, PRIMA ANCORA
    di scrivere il modulo fatturazione e PRIMA ANCORA che il modulo
    archivi esista, io che scrivo il codice per la fatturazione so già che
per
    accedere agli archivi dovrò chiamare la funzione X e passargli quei
    determinati parametri, e so già che otterrò in uscita i dati in quella
    determinata forma.
In questo modo i vari programmatori possono lavorare in modo
(relativamente) indipendente e senza vincoli all'interno del loro ambito
e sapendo già cosa deve scrivere per chiamare i moduli altrui (vantaggio
collaterale: non si deve aspettare che un modulo sia pronto per scrivere
il codice che lo usa. Per test & debug sì, ma quello viene dopo...)

Belfagor wrote:

... vuoi vedere che e' così che hanno scritto winzozz... =8^)
Albert ha detto (piu' o meno): "Un grande problema puo' essere considerato come
la somma di tanti piccoli problemi"; bello, ma il VERO problema diventa il
"director cut", che se e' per un film puo' valere l'oscar ma per un programma
non e' detto che valga l'impegno profuso...
Imho, le procedure contabili sono "generalmente" interdipendenti.
Ciao!
maurizio