Refactoring Atrocious Java Code [duplicate]

Se la base di codice fosse in perfetta forma, non avresti un lavoro lì. Ho visto abbastanza sviluppatori girare per notare che la solita tendenza è riscrivere tutto perché è un disastro e riscrivere il risultato sarebbe un codice supportabile ed estensibile da manuale .... Solo per finire con un pasticcio leggermente più recente. Detto questo, inizierei semplicemente fermando l'emorragia. Tutto ciò che viene toccato per correggere qualunque bug o estendere qualsiasi funzionalità viene ripulito e messo sotto copertura. Farlo riconoscendo il rischio è che i tentativi di ripulire potrebbero causare interruzioni. Gestisci bene quel rischio e sei d'oro. Se non lo fai, non puoi nemmeno pensare di incolpare l'ultimo sviluppatore.

Sarei più paziente di Thomas. Mentre stai facendo le correzioni iniziali dei bug e le funzionalità aggiunte, prendi nota dei problemi (come hai iniziato) e anche, mentre impari come funzionano le cose e cosa è "più importante", prendi in considerazione approcci per risolverli.

Quindi vai dal tuo capo e presenta le idee e chiedi "cosa devo affrontare per primo?" Per quanto ne sai, dirà qualcosa come "Ho sempre voluto provare quella libreria JSP" o "Non ho mai avuto la possibilità di aggiungere una migliore gestione delle eccezioni" e puoi procedere a correggere parti del codice. O "stiamo andando a scaricare XML per JSON, non preoccuparti di aggiustare quel codice". Quindi non aggiusti cose che non contano.

Supponendo che abbia successo, avrai guadagnato credito come buon programmatore e potrai proporre ulteriori miglioramenti del design.

Ho svalutato due buone risposte, ma ecco un piccolo consiglio in più.

1) Hai detto le parole magiche "Small Software Company". Questa è un'arma a doppio taglio. Ci sono molte opportunità per cambiare le cose e imparare tutti i tipi di abilità utili se le fai nel modo giusto ma ci sarà anche molta pressione per ottenere risultati rapidi per mantenere il flusso di cassa. Ricordalo.

2) Devi costruire credibilità prima di poter cambiare il mondo. Ciò significa ottenere cose che direttamente e ovviamente fanno guadagnare denaro alla tua azienda. Immergersi in un refactoring di 6 mesi che lascia il codice funzionante praticamente come hai trovato non ti farà guadagnare molto credito. In effetti, essere troppo critici nei confronti della programmazione del tuo capo potrebbe essere una mossa davvero limitante per la tua carriera.

3) Inizia in piccolo come suggerisce Thomas e rendi il mondo migliore per un test unitario alla volta.

4) Se non lo hai già fatto, leggi "Clean Code" e "Clean Coder" di Bob Martin. Lasciali sulla tua scrivania e vedi se riesci a coinvolgere il tuo capo. Le probabilità sono che sono stati troppo occupati a fare in modo che l'azienda non venisse ad auto-educarsi. Se riesci a interessare il tuo capo ai benefici del fare le cose nel modo giusto, otterrai più libertà, se il tuo capo è più "Completa rapidamente - e passa al prossimo lavoro", impara cosa puoi, migliora ciò che puoi e se il Boss rimane irriconoscibile dovresti considerare di spostarti da qualche parte più ricettivo prima che la tua anima venga consumata dal Buco Nero di Codefail.