[Generale - JAVA] Sviluppare software con Upgrade Facili

[franksisca]

Che regole seguite quando sviluppate un software che prevede, nel tempo, degli aggiornamenti continui???
vi spiego il mio problema:

ho sviluppato un software e a meno di una settimana dal "rilascio", già mi hanno commissionato dei cambiamenti che mi vanno a cambiare tutti gli "oggetti" che salvavo su disco.

Voi come affrontate questo problema? Anche eventuali evoluzioni grafiche ovviamente!

[demos88]

Originariamente inviato da franksisca

Che regole seguite quando sviluppate un software che prevede, nel tempo, degli aggiornamenti continui???
vi spiego il mio problema:

ho sviluppato un software e a meno di una settimana dal "rilascio", già mi hanno commissionato dei cambiamenti che mi vanno a cambiare tutti gli "oggetti" che salvavo su disco.

Voi come affrontate questo problema? Anche eventuali evoluzioni grafiche ovviamente!

- Modulare: separa le varie funzioni, non avere paura a usare più metodi del minimo necessario.
- Generico: rendi minime le modifiche da apportare al resto del software quando cambi qualcosa => usa le interfacce.
- Routine di test: quando vai a modificare qualcosa, puoi scazzare qualcos'altro, con le routine di test (per esempio usando JUnit) individui i blocchi che non funzionano più a dovere
- Commentare: ma non troppo! Usa lo stile javadoc se ti piace, commenti fra righe di codice ci stanno per passaggi importanti ma non esagerare.
- Nomi: variabili e metodi dai nomi chiari e intuitivi, non troppo lunghi.

Queste sono linee guida che mi hanno propinato a Ingegneria del Software

[ndakota]

Open closed principle e decorator patterns are my 2 cents

[franksisca]

Originariamente inviato da demos88

- Modulare: separa le varie funzioni, non avere paura a usare più metodi del minimo necessario.

ok, quello già lo faccio

Originariamente inviato da demos88

- Generico: rendi minime le modifiche da apportare al resto del software quando cambi qualcosa => usa le interfacce.

mmm, questo di solito non lo faccio....quindi mi consigli di usare più interfaccie e classi astratte?

Originariamente inviato da demos88

- Routine di test: quando vai a modificare qualcosa, puoi scazzare qualcos'altro, con le routine di test (per esempio usando JUnit) individui i blocchi che non funzionano più a dovere

mai usato junit...devo studiarmelo...lo consigli "vivamente"?

Originariamente inviato da demos88

- Commentare: ma non troppo! Usa lo stile javadoc se ti piace, commenti fra righe di codice ci stanno per passaggi importanti ma non esagerare.

questo di solito lo faccio in fase di postproduzione del codice proprio per ricordarmi "a mes stesso" cosa fanno i vari metodi

Originariamente inviato da demos88

- Nomi: variabili e metodi dai nomi chiari e intuitivi, non troppo lunghi.

Queste sono linee guida che mi hanno propinato a Ingegneria del Software

anche il mio prof di IS ha dato le stesse direttive quando lo feci, ma ho chiesto per avere un resoconto diretto da chi già sviluppa

Originariamente inviato da ndakota

Open closed principle e decorator patterns are my 2 cents

il decorator in effetti può essermi molto utile, come il visitors in questo caso, visto che mi hanno chiesto di aggiungere 4 modelli di filtri differenti!!!

[demos88]

Io attualmente collaboro allo sviluppo in ambito accademico un software abbastanza grosso.
JUnit è utile per progetti grandi anche se ha una sua filosofia di utilizzo che forse non ne rende così determinante l'uso nel tuo caso. Scrivendo delle classi di test, di permette di testare singoli metodi e sezioni di programma confrontando l'esito di ogni segmento di codice con un valore atteso.
Mentre per quanto riguarda le interfacce, sono un modo pratico per aiutarti a sviluppare codice nelle situazioni in cui per esempio vai a modificare il comportamento di alcune classi. L'uso di strutture definite su interfacce permette di usare quella struttura con qualsiasi oggetto che implementa quell'interfaccia, ovvero qualsiasi oggetto che garantisce la possibilità di essere trattato in un certo modo (definito dall'interfaccia appunto).
Può tornare utile in caso di strutture a diverso livello di astrazione o di oggetti che devono essere trattati in egual modo anche se appartenenti a classi diverse.

[franksisca]

il problema è che io ho attulamente un "cliente" con dei suoi parametri, e ora questo cliente deve essere modificato.

se vado a modificarlo, salvo creare routinei per la trasformazione dei vecchi clienti, perdo i clienti già salvati, in quanto giustamente vado a modificare la struttura.

ovviamente con le interfaccie risolverei questo problema, e non ci avevo pensato.

il tutto condito da una fase di progettazione pari allo zero, e siccome sono SICURO che tra 1 mese ci saranno altre modifiche, prima di ricominciare a leggere il calendario, o voluto chiedere a voi lumi. volevo creare una classe "cliente"esteso", che ereditasse semplicemente pla classe cliente. il concetto è simile alle interfaccie, ma credo che in questo modo incorrerei in rischi di incongruenza dati...che dite?

[VICIUS]

In genere il problema è dovuto a classi/funzioni che cercano di fare troppo. Scrivere test con junit e cercare di avere una copertura che si avvicini il più possibile al 100% è un buon modo di scrivere del buon codice facile da modificare. Se non vuoi impazzire a scrivere i test sei costretto a creare metodi semplici e classi con dei compiti ben precisi. Con il vantaggio che quando poi sarai costretto a fare la modifica puoi controllare che tutto funzioni ancora come prima.

[U-Boat]

In che modo salvi gli oggetti su disco?

[franksisca]

Originariamente inviato da U-Boat

In che modo salvi gli oggetti su disco?

con i classici metodi di scrittura degli oggetti. in attesa del database che dovrò sviluppare e che già mi sta facendo piangere al solo pensiero.

ObjectOutputStream output = new ObjectOutputStream(file);

come faccio a spiegare che sviluppare un programma vuol dire avere tutti i campi sensibili in fase di partenza?
Pretendono che sviluppa una programma talmente flessibile che se un giorno dovrà aggiungere il codice fiscale lo potrà fare senza modifche.

[U-Boat]

Il problema è qui, la serializzazione di default non è il massimo quando gli oggetti che vai a manipolare vengono modificati spesso.

Io mi sono trovato a dover salvare le impostazioni salvate dall'utente, con il limite di non poter usare librerie esterne perchè ero alle prese con un sistema embedded.
Questi dati hanno una struttura parecchio stabile, ma ho avuto bisogno almeno 2 volte di modificarla.

Soluzione 1: visto che le modifiche la prima volta hanno riguardato solo una classe con poche dipendenze, ho mantenuto la versione vecchia, creato quella nuova e fatta una piccola utility di conversione, però continuavo a non amare il formato binario non leggibile direttamente

Soluzione 2: ho realizzato a mano i metodi di serializzazione, non usando più quella fornita da Java; dovendo fare questo lavoro su un numero limitato di classi ci ho messo davvero poco tempo, ma ho avuto il vantaggio di ottenere un formato leggibile e di poter resistere bene alla maggior parte delle modifiche che mi troverò a fare.

In base alla complessità della tua applicazione puoi scegliere se usare librerie esistenti o formati di serializzazione standard (xml/json...). Nel mio caso la parte di salvataggio dei dati è una porzione molto piccola del software, trattandosi di un sistema di controllo di impianti, in sostanza mi serve solo per ricordare le impostazioni o preferenze.
Da quello che mi pare di capire invece la tua applicazione è più simile a quelle orientate ai dati che si appoggiano sui database "classici"; potresti valutare l'uso di un ORM, ma attenzione a valutare bene le controindicazioni. In ogni caso crea il classico layer di gestione della persistenza.

[demetriol]

Caro collega, perchè non provi ad usare l'ereditarietà? Hai la necessità di aggiungere campi, o anche modificarli/eliminarli? Certo che per quanto riguarda i dati salvati su disco un db è molto molto più flessibile rispetto alla serializzazione di oggetti java...

[franksisca]

Originariamente inviato da U-Boat

Il problema è qui, la serializzazione di default non è il massimo quando gli oggetti che vai a manipolare vengono modificati spesso.

Io mi sono trovato a dover salvare le impostazioni salvate dall'utente, con il limite di non poter usare librerie esterne perchè ero alle prese con un sistema embedded.
Questi dati hanno una struttura parecchio stabile, ma ho avuto bisogno almeno 2 volte di modificarla.

Soluzione 1: visto che le modifiche la prima volta hanno riguardato solo una classe con poche dipendenze, ho mantenuto la versione vecchia, creato quella nuova e fatta una piccola utility di conversione, però continuavo a non amare il formato binario non leggibile direttamente

Soluzione 2: ho realizzato a mano i metodi di serializzazione, non usando più quella fornita da Java; dovendo fare questo lavoro su un numero limitato di classi ci ho messo davvero poco tempo, ma ho avuto il vantaggio di ottenere un formato leggibile e di poter resistere bene alla maggior parte delle modifiche che mi troverò a fare.

In base alla complessità della tua applicazione puoi scegliere se usare librerie esistenti o formati di serializzazione standard (xml/json...). Nel mio caso la parte di salvataggio dei dati è una porzione molto piccola del software, trattandosi di un sistema di controllo di impianti, in sostanza mi serve solo per ricordare le impostazioni o preferenze.
Da quello che mi pare di capire invece la tua applicazione è più simile a quelle orientate ai dati che si appoggiano sui database "classici"; potresti valutare l'uso di un ORM, ma attenzione a valutare bene le controindicazioni. In ogni caso crea il classico layer di gestione della persistenza.

"spero" che la mia applicazione possa solo aggiungere campi.

Originariamente inviato da demetriol

Caro collega, perchè non provi ad usare l'ereditarietà? Hai la necessità di aggiungere campi, o anche modificarli/eliminarli? Certo che per quanto riguarda i dati salvati su disco un db è molto molto più flessibile rispetto alla serializzazione di oggetti java...

È proprio quello che è mia intenszione. solo che probabilmetne tra qualche settimana sposteremo tutto su un server con relativo database (probabilmente MySql oppure Derby) e quindi dovrò fare una nuova manipolazione dei dati da salvare. a questo punto mi butto direttametne su derby così posso lavorarci in locale senza installazioni e problemi di salvataggio....e vado di sql a manetta e nel caso creo tabelle con id di riferimento. visto che non posso permettermi una alta efficenza, almeno mi permetto una alta efficacia!!!