AntonioGanci

# re: L'architettura è sufficientemente malleabile?

Argomento interessante, e altrettanto lo sono gli "esempi", piuttosto variegati....

Come prima risposta "a pelle", mi verrebbe da dire che dipende molto dalle dimensioni del software di cui si sta parlando: se si tratta effettivamente di un gestionale "enterprise" allora la predisposizione per affrontare alcune di queste modifiche potrebbe essere ammortizzato, mentre per programmi "piccoli" potrebbe non essere facile permettersi a priori di realizzare un'archiettura tale che consenta di andarli poi effettivamente a gestire in futuro.

Provo a fare degli esempi: la modalità offline può essere implementata in tanti modi, più o meno invasivi, la sincronizzazione tra i dati creati nel client e quelli lato server non è in genere banale (ovvio che dipende dal contesto in cui ci si trova), perciò a seconda delle situazioni potrebbe essere abbastanza costoso andarlo a gestire in seguito o anche a prevederlo all'inizio, se non ce se lo può permettere (oppure si possono utilizziare dei framework di sincronizzazione che un po' aiutano nello sviluppo, ma probabilmente hanno dei costi in licenze).

Uun'altra situazione che dipende un po' da come la si vuole implementare può essere quella del testo tutto in maiuscolo: se mentre l'utente sta scrivendo deve già vedere il testo in maiuscolo, si possono sfruttare le proprietà sul casing, come quelle che hanno le caselle di testo, e per abilitarle si può intervenire in diversi modi.
Il discorso può essere invece diverso se occorre trasformare il testo in maiuscolo in fase di salvataggio...

Il discorso poi di utilizzare WPF al posto di Windows Forms non è ugualmente banale, nel senso che, anche se con Windows Forms già si possono prevedere le solite separazioni tra UI / Business, riprogettare la UI per un'altra tecnologia non è detto che non sia costoso, poi WPF in particolare ha una curva di apprendimento piuttosto ripida, e non è detto che tutti si possano permettere di aggiornarsi su tutte le tecnologie che negli ultimi anni vengono sfornate molto velocemente.

Riassumendo in pochissime parole, secondo me oltre al discorso architetturale c'è anche dell'altro da considerare.
Poi si, sicuramente realizzare il software secondo principi e tecniche che ci possono portare ad un'architettura più "malleabile", rende più economico (se non addirittura semplicemente possibile) andare a fare modifiche in corso... e fortunatamente di queste tecniche se ne inizia a parlare sempre di più!

Diciamo che in generale sarei curioso di capirne di più su come hai affrontato e valutato gli scenari che hai descritto!

# re: L'architettura è sufficientemente malleabile?

Il cliente ha ragione a lamentarsi del fatto che a suo tempo disse: "basta che funzioni" (e che costi poco).
Di solito il problema è (anche) quello.

# re: L'architettura è sufficientemente malleabile?

Antonio, stai diventando sempre più figo. Vengo a lavorare per te :-)

# re: L'architettura è sufficientemente malleabile?

Leggo ora "per *alcune* la modifica ha richiesto meno di mezz'ora". E le altre? :-) Sono curioso...

# re: L'architettura è sufficientemente malleabile?

@Antonio

ho incontrato richieste tipo quella della modalita off-lina, quella degli arrotondamenti all'epoca del passaggio dalla lira all'euro. quella del log, e una simile al passaggio a wpf (nel mio caso era da winform a webform).

tutte hanno richiesto un costo esagerato e in molti team dove ho lavorato lo stato della code base porterebbe a risposte simili. quindi i miei complimenti per il risultato!!!

per il piu delle richieste che elenchi intuisco come la separezione di reaponsabilita, l'evitare la duplicazione e il pattern MVC possano fare la differenza.
per quanto riguarda il log centralizzato e la modalitá off-line invece non riesco a immaginare un disegno che abiliti queste modifiche senza "predisporre" il codice pagando un costo in anticipo. sarei curioso di sapere come hai fatto.


@Stefano

> oltre al discorso architetturale c'è anche dell'altro da considerare.

credo che invece di vedere in questo report sia che il puntp centrale é scrivere del buon codice che sia facile da modificare ed evolvere.
l'aspetto tecnologico é spesso sopravvalutato, per importanza e difficolta. in realta sono skill facilii da acquisire comparati a quelli di coding di qualitá.


> la predisposizione per affrontare alcune di queste modifiche

in punto non é predisporre in anticipo, cioé pagare in anticipo un costo per una richiesta specifica che forse il cliente non fara mai, invece é scrivere codice che é in generale facile modificare ed evolvere per la maggior parte di richieste che il cliente potra fare e che ora non possiamo ne vogliamo prevedere.

# re: L'architettura è sufficientemente malleabile?

Visto l'interesse farò un post con qualche dettaglio in più e qualche esempio di codice su come ho affrontato il problema. Comunque in linea di massima l'approccio che per me è stato vincente è quello di creare un DSL interno cioè tramite gli oggetti realizzare una descrizione di più alto livello del sistema.

# re: L'architettura è sufficientemente malleabile?

Sono curiosissimo ed aspetto con ansia la soluzione al problema.

# re: L'architettura è sufficientemente malleabile?

Non si puo' fare non esiste, e' troppo costoso lo dice il cliente, il cliente ha sempre ragione, in teoria e in pratica.

-LV

# re: L'architettura è sufficientemente malleabile?

Quella della funzionalità Offline sulla carta è la più onerosa, ma molte volte dipende dal tipo di sistema/architettura. Un po' di tempo abbiamo avuto la stessa richiesta e sfruttando il fatto che il sistema fosse di tipo client-server (Windows Forms) è stato sufficiente implementare un proxy diverso da quello standard (.Net 2.0 e Remoting) per fare in modo che il client non si accorgesse di nulla.

# re: L'architettura è sufficientemente malleabile?

Ho postato alcuni commenti e una parziale traduzione in inglese sul mio blog:

http://matteo.vaccari.name/blog/archives/364

# re: L'architettura è sufficientemente malleabile?

> Comunque in linea di massima l'approccio che per me
> è stato vincente è quello di creare un DSL interno cioè
> tramite gli oggetti realizzare una descrizione di più alto
> livello del sistema

E' una tecnica che non viene spesso considerata. Chissà, forse perché la maggior parte degli sviluppatori a un certo punto della loro carriera perde la voglia di sognare? :-)

# re: L'architettura è sufficientemente malleabile?

x Matteo:
> E' una tecnica che non viene spesso considerata. Chissà, forse perché la maggior parte degli sviluppatori a un certo punto della loro carriera perde la voglia di sognare? :-)

Più che altro è molto faticoso e difficile, riuscire ad arrivare ad una sintesi apparentemente banale è estremamente faticoso.

x Tommaso Caldarola:
Nel tempo ho visto diverse soluzioni a questo problema se riesco ci faccio un post perchè è difficile fare un esempio.

x Massimiliano Cecili
> Sono curiosissimo ed aspetto con ansia la soluzione al problema.
Non è la soluzione in se la cosa importante e di soluzioni ce ne possono essere più di una è il processo che porta alla soluzione. Detto così è un pò criptico spero di chiarire un pò meglio nel prossimo post.

# re: L'architettura è sufficientemente malleabile?

> Più che altro è molto faticoso e difficile, riuscire ad arrivare
> ad una sintesi apparentemente banale è estremamente faticoso.

Beh se fosse facile lo farebbero tutti :-) Però quello che io vedo mancare spesso è l'ispirazione, il desiderio, l'idea che si possa fare molto meglio... Diamo per scontato che il fango del nostro codice verboso sia inevitabile!