Come gestisco il seguente problema tecnico? [chiuso]

1) Dove il tuo manager ha ragione

Il tuo manager desidera un'architettura flessibile . Per fare ciò, devi progettare il nostro codice, che è facilmente composto da componenti pluggable .

What according to him is pluggable is obtaining object instances through Java Reflection

Questo è un modo per organizzare la creazione di oggetti ed è come DI -frameworks fanno il loro lavoro. In genere contrassegni dependencies di un oggetto utilizzando @Inject annotazione. Non vedo alcun senso nel farlo a mano, quando hai delle strutture per fare il lavoro in modo affidabile.

he insists us to write a class that reads an xml file where it is written which class has to be instantiated and do actual reading from that object instantiated using reflection.

Mi sembra che voglia sviluppare la sua versione di Spring con tutti i dolori dell'uso dell'XML per la configrazione (container)

2) Dove il tuo manager è (terribilmente) sbagliato

And he thinks that whenever an xml file structure is changed, its parsing code or writing code need not be changed.

Sembra una versione strana del principio aperto / chiuso , dove una classe dovrebbe essere aperta per l'estensione , ma chiuso per la modifica.

Un design migliore sarebbe quello di refactare il comportamento di analisi verso un'interfaccia . Quindi puoi mantenere la logica generale che si occupa del risultato e gestire diversi tipi di Parser con oggetti diversi.

Se vuoi gestire diverse versioni del tuo XML allo stesso tempo, puoi progettare diversi parser per ogni versione. Ma se vuoi solo avere a che fare con una versione attuale del tuo XML, avrebbe senso, per aggiornare solo il codice di un parser, lo hai.

Se non rifatti mai il tuo codice e solo le classi di pile finisci con un casino.

We, the programmers, prefer using JAXB for marshalling and unmarshalling the xmls as it is intuitive.

Che è - in breve - perfettamente a posto.

Very frequently he complains that the code is slow, or the programmers are incapable of providing an architecture

Per quello che vedo, l'unico che fornisce un'architettura disordinata è il tuo capo. Scusa, fratello! @ddyer ti ha dato un suggerimento su come convincere il tuo capo: Benchmarks - numeri / fatti difficili. Riscrivi una parte del codice e mostra le differenze.

But after some period he finds something else is fascinating and asks us to change the whole structure of the xml.

Ecco come la gestione (spesso) è .

tl; dr

Che cosa fare?

Se vuoi conviciare il tuo capo:

Se il tuo tempo lo consente, riscrivi l'applicazione (parzialmente) o almeno esegui un prototipo veloce con gli elementi principali dell'applicazione, confrontalo, mostra i numeri al tuo capo. Forse potresti fare una revisione comparativa del codice di come appare il vecchio codebase e quello nuovo. E parla con lui delle differenze.

Ma onestamente: se hai la possibilità - lascia la compagnia ti stai facendo un grosso favore.

Sembra un ambiente molto brutto per un lavoro produttivo. Sei il programmatore (i) e tu sei responsabile per codebase non il tuo manager; o se si sente così - ed è quello che mi è venuto in mente leggendo la tua storia, dovrebbe fare il tuo lavoro (da solo). Come sviluppatore di software professionale dovresti metterti di testa contro il tuo capo. Ma dipende dalle possibilità di ottenere un nuovo lavoro. Forse sei in un dilemma di smettere, ma non avere alternative.

Alcune esecuzioni di benchmark potrebbero aiutare a stabilire perché le tue applicazioni sono lente. Quindi potrebbe essere suggerita una dimostrazione di un notevole miglioramento con un cambiamento nella metodologia.