414N ha scritto:...il fatto di usarlo tramite reverse engineering su codice già esistente è segnale di un processo di sviluppo del software non ottimale.
Parto da questo passo della tua costatazione abbastanza condivisibile per cercare di spiegare meglio il mio punto di vista ed estendere il concetto di progettazione del software dicendo che: l'ottimizzazione dello sviluppo del codice presuppone sicuramente una progettazione formale di cio che si vuole realizzare, in termini di requisiti>scenari>funzionalità, ma come si sa il ciclo di vita del software è sempre pieno di evoluzioni che vanno debitamente gestite una per una. Non è possibile pensare che la progettazione accurata generi il codice ottimo, tuttavia è sicuramente un buon punto di partenza. Ma ora passiamo alla pratica, quando si decide di implementare un software, è fuori dubbio che non si parte scrivendo codice, una prima fase di analisi è obbligatoria(si parla di progetti medio-grandi), ma il punto cruciale è: quanto dedicare nel dettagliare la progettazione e quanto dedicare alla realizzazione reale. Questo passaggio è come sappiamo, sicuramente dipendente dalla tempistica di cui si dispone, non voglio dire che la progettazione è una perdità di tempo, ma si deve comunque fare una scelta di compromesso in molti casi.
414N ha scritto:In soldoni, si prendono i modelli prodotti durante l'analisi e si trasformano per adeguarli alle esigenze di implementazione, spesso rendendoli molto più dettagliati e dipendenti dalle scelte implementative. ...è poi possibile arrivare in un certo numero di passi alla generazione automatica della quasi interezza del codice necessario (non solo stub)
Questo approccio è sicuramente costruttivo, ma non tiene conto di alcune difficoltà tipiche, la modellazione può sicuramente descrivere le componenti in gioco e le relazioni tra esse, ma il comportamento di un componente è molto, almeno x me, difficile da astrarre, quello lo dettagli appunto in fase di implementazione(debitamente commentata). La generazione del codice nella sua quasi interezza è una situazione abbastanza rara in contesti medio-grandi e molto customizzati, ma sicuramente una buona parte del lavoro si risparmia, e soprattutto si standardizza... Io a dire la verità ho quasi
sempre lavorato alla parte di progettazione in maniera abastanza scrupolosa, rigorosamente prima della stesura del codice, ma ho anche spesso affrontato la fase di riallineamento tra modelli e codice a cui facevi riferimento, e ti assicuro che se vuoi lavorare bene quella sarà la fase più frequente e impegnativa che si affronta.
Per quanto riguarda il reverse engineering io ho fatto questo esperimento per pura curiosità, ma con gli strumenti che ci sono in giro ti assicuro che si generano component diagram e class diagram molto descrittivi del codice, e assolvono comunque al ruolo di vista generale del funzionamento del software, quindi non penso sia
inutile come è stato detto. Ovviamente c'è bisogno che alla base ci sia una struttura chiara ben definita. Io sostanzialmente dico che: facendo una progettazione ad alto livello, magari anche in maniera informale, si ha una prima bozza della propria architettura, poi la si mette in piedi a livello di codice stub+, e si passa al raffinamento, seguendo comunque dei dettami soggettivi che si ci è prefissato. In fase di sviluppo può anche capitare di voler intrudurre un design pattern per ottimizzare alcune procedure, o anche modificare una struttura precedentemente creata, questo va sicuramente ponderato, tenendo conto delle ripercussioni che tale decisione ha sul resto del progetto(impact analisys), e ad essere sincero a me è capitato di attuare tali cambiamenti direttamente sul codice, purtroppo è così, ma riallineando i modelli, anche a posteriori, non faccio altro che ripetere la procedura di reverse, sfruttando i feedback che mi restituisce per individuare falle nell'approccio di cui non mi ero accorto. Sostanzialmente ssto valutando la possibilità di sfruttare la modellazione, più formale, per effettuare controlli incrociati, e come istantanea del lavoro svolto, che può comunque tornare utile in contesti in cui la comunicazione con il cliente è parallela al processo di sviluppo, sicuramene non è il modo migliore, ma è un buon compromesso.
Su questo argomento sono un pò prolisso, me ne scuso, ma mi interessa molto, non nascondo che credo in questa strada, anche se mi sembra sempre il solito dilemma: piano e bene o svelto e approssimativo(ma sibuto fruibile)?!?, che spesso si risolve con la produzione di lavori mediocri a cui ci siamo assuefatti...
ma non ho ancora capito molto bene come utilizzarlo.
