TDD con un'applicazione Java EE semi-cotta

0

Sono uno studente di Informatica del secondo anno attualmente in una posizione e attualmente sto sviluppando un'applicazione Java EE che raccoglie metadati da diverse fonti e quindi visualizza i dati. Questo è il primo grande progetto di programmazione che ho fatto. (Niente come università con 200 linee di codice per un incarico)

Sono circa la metà dello sviluppo di questa applicazione e ho imparato una quantità incredibile. Una di queste cose è TDD . Dall'apprendimento di questo ho acquisito una comprensione di quanto sia importante il test e di come possa contribuire ad accelerare lo sviluppo.

La ragione per la storia precedente è di coprire la mia ignoranza. La mia università non me l'ha insegnato ed è inesistente sul mio posto di lavoro. Sono incredibilmente desideroso di assicurarmi di seguire le migliori pratiche in tutto ciò che faccio e mi piacerebbe includerlo nella mia applicazione in quanto ritengo che apporterebbe molti benefici.

I problemi che ho però sono:

  • La mia applicazione (come molti ne sono sicuro) contatterà diverse fonti esterne. Prendiamo ad esempio il mio messaggio di consumatore. Contatterà fino a 3 interfacce restful remote e un database. Gli URL di queste apis sono dinamici e sono accessibili solo dopo che l'applicazione ha caricato il file delle proprietà (che deve essere modificato dall'utente dell'applicazione).
  • Ritengo che sarebbe difficile riconfigurare i test su un sistema che non è stato costruito in modo TDD.
  • Praticamente non ho tempo per riadattare / imparare come fare il TDD avanzato con le applicazioni Java EE.
  • Dato che non è affatto una pratica nel mio posto di lavoro, non sarei in grado di fare domande o essere corretto se ciò che stavo facendo era il migliore.

Devo accettare la sconfitta su questo progetto perché sono troppo avanti e andare avanti, dovrei solo applicare il TDD su tutto ciò che posso? (dove è pratico, naturalmente).

Sono solo preoccupato che eventuali futuri potenziali datori di lavoro potrebbero guardare il mio lavoro da questo posizionamento e pensare meno a me perché la mancanza di buone pratiche. (Non è preoccupato di quello che pensa la compagnia attuale in quanto non è una cosa e sono molto contento del mio progetto.)

    
posta Softey 23.01.2016 - 14:46
fonte

1 risposta

4

Ci sono molti articoli, libri, post di blog, discorsi di conferenze ... che trattano questo problema. Lavorare efficacemente con il codice legacy di Michael Feathers è da molti considerato uno dei, se non i migliori libri sul soggetto. C'è un PDF di 12 pagine disponibile gratuitamente online che ha costituito la base del libro e dovrebbe fungere da buon punto di partenza. Non lasciatevi ingannare dal termine "codice legacy": ieri ho visto il codice scritto solo la scorsa settimana che non era strutturato correttamente e difficile da testare e considero anche questo "legacy".

Ricorda che TDD, come ogni aspetto dello sviluppo, è anche un'esperienza di apprendimento. Ho fatto TDD per anni e il mio stile è cresciuto e si è evoluto come ho scritto e mantenuto il codice di test, leggere libri, ascoltato discorsi sull'argomento, ecc ... A tal proposito probabilmente non dovresti preoccuparti di futuri datori di lavoro. Finché puoi dimostrare che ti evolvi e impari (cosa che fai nell'adottare le pratiche TDD) probabilmente non lo manterranno contro di te.

    
risposta data 23.01.2016 - 15:30
fonte

Leggi altre domande sui tag