Mi è stato chiesto di lavorare in un'applicazione web Java che è progettata molto male. Nel nome di "rendere questo facile", hanno escogitato un proprio "framework" per rendere le cose estremamente difficili da capire. Sto lottando per capire il flusso di controllo. Hai una tale esperienza?
Che cosa fai in queste situazioni quando il ragazzo che lo ha "progettato" ha già lasciato la compagnia?
Mentre provi a capire come funziona, è probabilmente una buona idea scrivere unit test per questo. In questo modo sai cosa succede quando entra un parametro e in futuro sai ancora di non averlo infranto. Forse anche un po 'di refactoring, quindi puoi usare Dependency Injection in modo che i test unitari possano rimanere piccoli. Questo probabilmente non è facile, quindi prima prova a scrivere alcuni test di unità di scenario e riducili mentre procedi. In questo modo puoi assicurarti che l'applicazione rimanga stabile e ne impari un po '.
Se hai tempo, ti suggerisco di leggere questo libro un po ' Lavorando in modo efficace con il codice legacy . Ha dei buoni consigli su come comportarsi in una situazione del genere.
Nella mia breve carriera di 3 anni ho avuto 3 prodotti da mantenere in tali condizioni. E forma me ci sono 3 periodi nella mia mente:
All'inizio dovresti leggere linea per linea e cercare di capire come funziona il codice, personalmente disegno mappe su carta. Dopo un paio di settimane di questo si può quasi fare cambiamenti e non fare molto male per il resto di un codice. Latter refatter a poco a poco, e si potrebbe cambiare tutto sapendo di non danneggiare alcun codice personale e anteprime.
Ho la stessa identica sensazione ogni volta che devo usare Struts e molti altri "framework" ...
Ci si abitua, la maggior parte se non tutto il software è mal progettato. Più il design è andato in esso, più è probabile che il suo design sia scarso (come esemplificato dalla peggiore applicazione con cui abbia mai lavorato, che è stato enormemente sovraesposto da qualcuno che aveva scritto libri sulla progettazione del software e ne ha applicato ognuno di questi quel sistema allo stesso tempo).
Do you have any such experience ?
Ho quasi esclusivamente esperienze del genere :-) La maggior parte dei progetti su cui ho lavorato sono progetti legacy. È difficile capire il codice di qualcun altro, specialmente se ha una lunga storia di cambiamenti. In origine, poteva avere un'architettura bella e pulita, ma senza una cura e un refactoring costanti, qualsiasi design inevitabilmente marcirebbe nel tempo.
Ho ha risposto a una domanda simile su SO qualche tempo fa, prima che PSE venisse all'esistenza. Spero che ti aiuti anche.
Sebbene quella domanda (e la mia risposta) ora si adattasse meglio qui, ritengo sia meglio evitare la duplicazione, quindi mi limito a collegarmi ad essa piuttosto che copiare il testo.
Do you have any such experience ?
Sì. Ho quasi detto "ovviamente".
What do you do in such situations when the guy who has "designed" it has already left the company ?
Ci sei riuscito. Fa parte del tuo lavoro. Il modo in cui gestisci dipende dall'applicazione e dalla gravità del problema, ma varia da:
A seconda della natura / estensione del problema, potrebbe essere necessario portarlo all'attenzione della direzione. Ma potresti avere a che fare con il problema di convincere il management che il problema è nel codice ... non nelle tue capacità.
E ricorda che il mondo aziendale è pieno di vecchie basi di codice troppo rigide / troppo costose da sistemare o sostituire. Il tipico punto di vista gestionale è tipicamente che qualcosa che funziona (solo) abbastanza bene non ha bisogno di essere riparato.
È un posto difficile. Puoi provare a trovare qualcuno nell'organizzazione che abbia alcuna esperienza con l'applicazione. A parte questo, devi solo mordere il proiettile e iniziare a leggere il codice e passare attraverso il debugger mentre ti fai strada attraverso alcuni casi d'uso. Inizia con quelli semplici, quindi prosegui da lì.
Un modo semplice e buono per conoscere il flusso di controllo è collegare un profiler . Accedi all'app, avvia il profilo della CPU e quindi esegui l'azione che desideri conoscere. Al termine, interrompere il profilo della CPU e dare un'occhiata al grafico delle chiamate generato. Questo ti darà il percorso completo dalle pagine front-end (UI) e le azioni per la logica biz nel server fino alle istruzioni SQL andando al DB.
Sfortunatamente, soffrirai di più con questa posizione rispetto al codice, si spera non lo sia. Alcuni hanno avuto una grande idea inizialmente che avrebbero costruito questa grande struttura e il resto del codice sarebbe semplicemente entrato in posizione. Poi inizia la realtà. Proprio nel bel mezzo del progetto quadro, qualcuno vuole vedere più di un sito di lavoro in modo che possano dimostrarlo agli investitori, sr. gestione, partner commerciali o alcuni VIP. Quindi devono interrompere ciò che stanno facendo e mettere insieme qualcosa. Proprio quando pensavano di essere di nuovo in pista, qualcuno ha bisogno di una modifica alla vecchia applicazione a causa di alcuni regolamenti, leggi o un tipico capriccio aziendale.
Alla fine, qualcuno si aspetta che questo progetto sia in orario o dal momento che la demo è andata così bene, dovresti essere in anticipo sui tempi. Non importa che il reparto contabilità abbia dovuto ritardare i test per due settimane (qualcuno non ha parlato della fine del trimestre?).
Ora ti presenti. Si aspettano che tu riprenda da dove il tuo predecessore ha lasciato. Stai costantemente combattendo il desiderio di ricominciare tutto da capo invece di imparare il Quadro su Matrix. Scoprirai che non è così complicato finché i nomi delle tue classi sono palindromi.
Risolvi questo problema. Diventa l'eroe non celebrato e attendi il prossimo progetto per poter scrivere il tuo framework.
Penso che quasi tutti gli sviluppatori soddisfino tali situazioni.
Il punto è "progettato male" può essere eseguito , anche se funziona bene online.
La strategia conservativa è: refactoring di piccolo passo dopo passo , è sicuro per te e il tuo codice:)
Leggi altre domande sui tag maintenance legacy-code