Devo solo sbatterlo fuori o discutere con il mio PM?

Sfortunatamente più che mai, non sei nel business della scrittura di codice elegante, sei nel business della spedizione di un prodotto.

Vorrei sicuramente sollevare i tuoi dubbi con il tuo PM. La mitigazione del rischio è una parte importante della gestione del progetto e i rischi dovrebbero essere sollevati nel momento in cui vengono rilevati. Se non li elevi, allora ti stai firmando per una marcia della morte, per la quale non avresti nessuno da incolpare se non te stesso.

Se esistono limitazioni chiare all'attuale base di codice, elencale tutte. Evidenzia i punti, ad esempio perché il refactoring di determinati blocchi di codice è necessario per implementare nuove funzionalità. Le probabilità sono, se non ci sono tali limitazioni, ti troverai a dover vivere con il codice così com'è. Potresti voler esaminare varie tecniche di lavoro con il codice legacy e il black boxing il più possibile (es. Attraverso un adattatore implementazione o qualcosa del genere).

Indipendentemente da ciò che succede, incontrerai questo tipo di progetto numerose volte durante la tua carriera (uno che ti fa tirare fuori i capelli). Alla fine della giornata, ti rende solo migliore in quello che fai. Avere la capacità di lavorare con orribile codice legacy e implementare nuove soluzioni (usando tecniche appropriate) è un'abilità inestimabile e uno che molti potenziali datori di lavoro cercano.

Per scopi illustrativi, supponiamo che tu abbia un programma di 1 mese e tu stimerai che ci vorranno 2 mesi senza alcun refactoring. Ci sono alcuni possibili risultati se si prima refactor:

• Ora del rifattore + nuovo tempo di lavorazione < = 1 mese. Non chiedere il permesso. Fallo e basta. Non sembrare troppo simile a Darth Vader, ma il refactoring è implicito nel tuo mandato. Naturalmente, segui le normali procedure di revisione tra pari per le modifiche al design.
• Ora del rifattore + nuova funzione ora > 1 mese, ma < Due mesi. Disporre le opzioni per il tuo PM. Se si fidano di te, andranno con il refactoring. Assicurati di non impiegare più di 2 mesi, altrimenti non si fideranno della tua prossima volta.
• Ora del rifattore + nuova funzione ora > Due mesi. Dì al tuo PM quanto tempo avresti potuto risparmiare se fosse già stato refactored, ma fallo stavolta. Premi per pianificare il refactoring dopo il rilascio quando c'è meno pressione di programma.

I just don't feel I have sufficient experience yet for a project of this complexity.

Questa è la tua unica affermazione che mi preoccupa. Mi porta a credere che tu stia probabilmente sottovalutando lo sforzo di pulizia. Ora puoi aggirare i problemi, ma se li rifatti, devi capire perché sono lì in primo luogo, e fare una valutazione se lo sviluppatore originale ha fatto un errore o se semplicemente non capisci il sottostante scopo del capriccio. Non andare con le opzioni 1 o 2 se non sei sicuro delle stime di refactoring.

Se hai intenzione di dare suggerimenti, e sono accettati, è molto probabile che tu sia l'unico ad implementarli, non qualcun altro, quindi assicurati di essere preparato mentalmente per l'attività. Seguendo i tuoi commenti non sembri pronto, quindi non andare avanti. Se vuoi farlo, il tuo prossimo problema è che ti stai arrendendo anche prima di aver provato:

I don't feel that the PM or my new colleagues are amenable to such changes.

Chiedi! Qual è la cosa peggiore che potrebbe accadere? Diranno no. Eccolo!

Quando lavori con un nuovo gruppo, la cosa peggiore che fai è entrare come straniero e dire loro che il loro codice è cattivo e ha bisogno di un importante refactoring. Chi pensi che abbia scritto quel codice?

Il modo migliore per avvicinarsi è acquisire una reputazione per sapere di cosa si sta parlando e di consegnare il prodotto. Poi quando fai emergere i problemi, hai credibilità.

Non c'è nulla in quello che hai detto che mi dice che sei fuori di testa (cioè incapace di capirlo effettivamente e fornire una correzione comunque imperfetta), solo che non ti piace lavorare in un codice poco elegante che non è impostato per il tuo preferenza personale.

Considera questo, questo è un progetto di manutenzione - forse quando è stato creato non avevano altra scelta per alcune delle decisioni che hanno preso con cui ora non sei d'accordo. Le persone che lavorano con il vecchio codice tendono a dimenticare che in quel momento erano state fatte delle scelte con ciò che era disponibile e nessuno ha avuto il tempo di rivisitare per usare le cose più recenti perché è molto lavoro che costa molto e inserisce nuovi bug per no guadagno per l'utente (cioè nessuna nuova funzionalità).

Nella tua carriera, dovrai spesso fare le cose nel modo in cui vogliono che tu le faccia e non come vorresti farle. È così e basta. Una volta che hai esperienza e hai sufficiente credibilità per suggerire modifiche (perché hai una buona reputazione all'interno dell'organizzazione), avrai più successo nel cambiare direzione e ottenere cambiamenti nel modo in cui approvano le attività. Ma non vincerai affatto nemmeno una volta che sarai un esperto locale, quindi devi essere consapevole che ci sono momenti in cui le condizioni non saranno ottimali.

Non sto dicendo che non provi a migliorare le cose, sto dicendo che potresti ancora dover lavorare con queste cose, anche dopo aver sollevato dubbi.

Sicuramente sollevare il problema con il tuo manager dicendogli che il codice è un disastro e ci vorrà più tempo di quello assegnato per completare l'attività. Il tuo manager / PM dovrebbe coinvolgere l'altro PM e trovare un piano per la funzionalità.

Diverse decisioni potrebbero essere:
1. Assegnare un altro sviluppatore per la funzione
2. Assegnare uno sviluppatore più anziano in grado di gestire l'attività più rapidamente 3. Spingendo la data ad una data successiva.
4. Un mix di quanto sopra 3.

Per quanto riguarda il refactoring, devi sempre presentare buoni argomenti per giustificare un ampio lavoro di refactoring, dovresti trovare un piano e suggerire alcune correzioni del codice della frutta per migliorare la qualità del codice, questo può essere fatto mentre si lavora sulla funzione. Una volta che hai finito, puoi probabilmente spingere per ulteriori correzioni di refactoring.

Chiedi perché usano VS2005 (potrebbe esserci una buona ragione) e puoi provare a vendere i tuoi nuovi colleghi su SVN.

Non hai familiarità con il codebase e dubiti della tua abilità. Questo è l'esatto momento sbagliato per provare i principali refactoring. Molte delle cose di cui ti lamenti sono lì per ragioni. Potrebbero essere cattivi motivi, ma dovrai capirli prima di poter apportare modifiche importanti.

Puoi provare a lasciare il codice meglio di come l'hai trovato. Quello che tocchi puoi legittimamente ripulire. Assicurati di non modificare il comportamento, dal momento che non sai quali sono le strane cose nel codice perché correggono un bug oscuro (probabilmente in modo negativo).

Se sei abbastanza sfortunato da continuare a lavorare su questo progetto, puoi guadagnare più credibilità ed essere in grado di apportare ulteriori modifiche.

Se hai delle riserve sulla possibilità di rispettare il programma, parla subito con il PM. Spiega le tue preoccupazioni. Il PM ha bisogno di sapere queste cose.