Quando, come e perché un framework di aggiornamento (Java)?

7

Breve sommario come introduzione:

Siamo un piccolo team di sviluppo web Java, che crea applicazioni utilizzando vari framework e librerie come JSF, Hibernate, Seam, tutte insieme implementate in JBoss AS.

Inizialmente, l'app è stata messa insieme e alcune funzionalità aggiunte per formare una vetrina da mostrare ai potenziali clienti. Si è verificata qualche lucidatura, l'app è stata rilasciata, è stata accettata e funzionante e con il passare del tempo sono state aggiunte funzionalità aggiuntive, i bug sono stati corretti, si sono verificati nuovi bug, come sempre.

A causa degli alti fattori di bus e delle gare di avvio, lo sviluppo è diventato un po 'fuori mano - sono state aggiunte sempre più funzionalità, non avendo compreso appieno l'architettura di base del sistema. Funziona ancora, ma ci sono sempre insidie perché il sistema si è evoluto da dove è nato a qualcos'altro e all'inizio sono state prese varie scorciatoie per accelerare lo sviluppo - ora tutto torna e lo sviluppo rallenta, perché i workaround sono usati ed è abbastanza difficile da introdurre nuovi sviluppatori nel progetto.

Ora sono in procinto di ripulire e organizzare le cose - installando un sistema di tracciamento dei bug, costruendo una cultura di test / qualità, pensando a come fare test automatici, revisioni di codice (tutte quelle cose professionali di fantasia che eravamo manca all'inizio) e fare un refactoring generale come organizzare gerarchie di classi e funzioni per rendere più facile l'uso di roba. Ciò rende tutto un po 'meglio, ma c'è ancora molto da fare. Dato che non sono la persona che inizialmente ha costruito il sistema (ex programmatore principale rimasto) e non quello esperto (che si sta sviluppando da 2 anni e mezzo, ma questa è la mia unica esperienza "aperta" finora), non sono sempre sicuro su cosa fare.

Ecco il mio problema:

Il refactoring è sempre qualcosa di buono e lo faccio costantemente per semplificare le cose, ma ciò che mi imbarazza è quando, come e perché dovrei aggiornare l'architettura di base (cioè, le librerie su cui si basa il sistema, il server delle applicazioni, il database ecc.)

Esempi:

  • Attualmente utilizziamo JBoss 4.2.2 - Ho già letto da qualche parte su JBoss 7.1, dovrei farlo? Come si può valutare questo?

  • Usiamo Seam 2.2 che sembra essere un grosso blocco (non funziona su versioni di JBoss più alte, non supporta JSF2). Inoltre, vedo fonti che mi dicono di usare le funzioni JEE al posto di Seam.

Fondamentalmente, sono interessato a qualsiasi approccio generico per questi problemi, non solo quelli che ho citato negli esempi sopra - perché potrei inciampare su questi problemi per un'altra libreria su un altro sistema in un altro momento (o qualcun altro potrebbe trovarsi di fronte problemi simili).

Quindi, qual è il punto? Devo essere aggiornato e utilizzare solo le librerie all'avanguardia o dovrei stare con quello che ho? Come riconosco, la tecnologia che sto usando è letteralmente un cavallo morto e salta fuori? Con quale frequenza dovrebbero apparire questi aggiornamenti tecnologici?

E un'altra domanda accanto al generale "come fare aggiornamenti". Come riconosco che il mio software potrebbe essere definito "creato da professionisti" ?. Esiste un test di Joel per software ben fatto oltre al senso comune dei programmatori?

    
posta Volker 06.08.2012 - 17:25
fonte

3 risposte

5

La risposta breve è che tu cambi quando lo sforzo di non cambiare supera lo sforzo di cambiare, o quando puoi prevedere che lo diventerà presto. Questa è una valutazione molto soggettiva che richiede esperienza, ma è relativamente facile vedere i casi estremi.

Ad esempio, supponi di stimare un mese per passare, ma non cambiare significa che non puoi usare un modulo che è disponibile solo nella versione aggiornata, quindi dovrai impiegare due mesi per implementarlo da zero. La scelta è semplice.

Per un altro esempio, se passi tutto il tempo a correggere le vulnerabilità della sicurezza nel software che non è più supportato dal venditore, è un buon momento per passare.

Se non hai mai riunioni in cui qualcuno dice "Sarebbe molto meglio / più semplice con la nuova versione", probabilmente non hai bisogno di cambiare.

I casi intermedi sono più difficili da riconoscere, ma di solito sembra una pressione costruttiva, dove attenersi alla vecchia versione sembra sempre più limitante.

Per quanto riguarda il tuo ben collaudato test del software, il tuo bug tracker fornisce una buona regola generale su questo. Quando hai zero difetti critici e il tuo elenco di difetti non critici è a un livello ragionevole e si riduce costantemente, puoi chiamarlo "fatto". Puoi avere un'idea della qualità dell'architettura del tuo software entro i tempi di risposta per aggiungere nuove funzionalità o correggere bug. Non c'è un punto di interruzione che dice "questo è professionale", ma più basso è, meglio è.

    
risposta data 06.08.2012 - 18:24
fonte
9

Ci sono diversi motivi per cui potresti voler aggiornare la tua infrastruttura sottostante, e dovresti valutare ciascuno di essi nel modo più empirico possibile. Ad esempio, potresti eseguire l'upgrade perché:

  1. Il venditore non supporta più la versione che stai utilizzando
  2. C'è un bug critico o una correzione per la sicurezza
  3. C'è una nuova funzione che vuoi sfruttare
  4. Aumenterà la tua velocità
  5. C'è una riduzione diretta dei costi di investimento in fase di aggiornamento (licenza di supporto più economica o simile)

Questi motivi devono essere rivalutati per il costo dell'aggiornamento, gran parte del quale viene speso in test. Questo è dove TDD / BDD viene davvero alla ribalta, specialmente se combinato con una buona configurazione di CI.

Significa che puoi "Refactator rapidamente senza paura"

Se non disponi di una suite di test completa e decente, significa che stai testando manualmente, che richiede molto tempo e molto soggetto a errori, aumentando i costi di aggiornamento.

    
risposta data 06.08.2012 - 18:27
fonte
3

Le tecnologie che hai elencato sono ampiamente utilizzate, è facile trovare la documentazione per loro e le persone che sono abili con loro, quindi penso che non ci sia un vero motivo per cambiarle. D'altra parte, consiglierei di aggiornare i tuoi framework alle ultime versioni rilasciate. Penso che dovrai farlo comunque, prima o poi (se non per nuove funzionalità e compatibilità con le nuove librerie, poi per i bug corretti nelle nuove versioni), e prima lo fai, meno noioso sarà questo compito.

    
risposta data 06.08.2012 - 18:36
fonte