Cosa fare quando si eredita una base di codice non mantenibile? [duplicare]

La somiglianza della tua situazione con ciò che ho vissuto circa 3 anni fa è spaventosa:

• stessa impostazione: non documentata, codifica cowboy
• il tizio "anziano" che ha reso la cosa scomparsa
• i restanti ragazzi sanno qualcosa sulla base di codice esistente ma non molto.
• pensava che la cosa fosse presentata come "funzionante" e il mio lavoro era stato introdotto come "aggiungi solo alcune funzionalità extra, nessuna ricodifica importante", era chiaro che nulla era fattibile senza un grande ri-trasporto.

Non so quale sia l'approccio migliore per questo, ma posso dirti come ho affrontato la cosa:

• prima di tutto, l'ambiente di codifica dei cowboy e la mancanza di documentazione (e test, nel mio caso) è stato considerato un aspetto positivo da tutti, proponendo quindi di cambiarlo nel senso in cui è stato dedicato del tempo alla documentazione, all'implementazione un'infrastruttura di test ecc. è stata negata sin dall'inizio. Quello che ho fatto è implementare tutto questo "in basso". Senza dichiararlo effettivamente come un compito, ho provato a passare 1-2 ore al giorno (per esempio, le prime 2-3 settimane) semplicemente organizzando il codice, mettendolo su svn, creando alcuni documenti e alcune unità di base e integrazione test. Test funzionali, CI e roba organizzativa di ordine superiore erano fuori questione in una tale configurazione, quindi è stato lasciato da parte, ma almeno qualche progresso è stato fatto.

• secondo, e ancora, senza dichiararlo veramente come tale, ho accettato il mio comando "aggiungi una nuova funzionalità, nient'altro" così com'è, ma reinterrogato l'intero modulo che è stato influenzato da quello compito (al fine di rendere l'attività implementabile). Ho semplicemente richiesto un po 'di tempo in più, ma senza dichiararlo, ho prima rifatto il codice di produzione esistente e poi aggiunto le funzionalità extra. Il lato positivo era che il codice originale, anche se era in produzione da un po 'di tempo, era così cattivo e poco performante, che un semplice refactoring del buon senso lo rendeva sostanzialmente più veloce e che mi ha guadagnato l'approvazione per il tempo extra. richiesto.

• infine, circa 2-3 mesi dopo, ho iniziato a cercare un lavoro diverso, perché era chiaro che non era qualcosa che volevo fare a lungo termine. Per farla breve, ho lasciato questo lavoro dopo circa 5 mesi, periodo in cui sono riuscito a implementare una parte decente delle funzionalità richieste da me, ma non tutte.

Ora, ecco quello che ho imparato da tutto: certo, se possibile evitare tali lavori, è meglio lavorare in un ambiente pulito e strutturato, in cui il processo di sviluppo del software è riconosciuto per quello che è e trattato con rispetto. D'altra parte, non posso negare che il mio breve periodo di lavoro in tali condizioni mi abbia insegnato molto su come affrontare i problemi in un ambiente così sotto pressione. Mi ha fatto anche apprezzare ancora di più tutti i protocolli e la metodologia necessari per un buon sviluppo del software.

Quindi, in breve, se puoi permettertene alcuni mesi, fallo, sarà un'esperienza interessante (basta che tu abbia una chiara via d'uscita nel prossimo futuro). Altrimenti, lascialo il prima possibile e facciamolo.

Non c'è una risposta facile alla domanda.

Da quello che hai scritto, il problema più grande sembra essere quello del project management. Troppe attività sono state eseguite troppo rapidamente. È possibile implementare i migliori standard di codifica del mondo, test automatizzati e così via, ma se questa pratica continua, sarà tutto inutile. Devi prima cambiare il pensiero da caratteristiche e scadenze e prima qualificare un terzo lontano da una qualità, scegliere caratteristiche o scadenze per la seconda o terza mentalità.

Devi parlare con la tua direzione per migliorare questo. Potrebbe non essere la colpa della tua gestione immediata. Forse le condizioni aziendali stanno cambiando o i clienti sono difficili, ma è qualcosa che devi affrontare. Se non puoi affrontare questo, vai via. Le aziende hanno bisogno di buoni sviluppatori più degli sviluppatori che hanno bisogno di cattive compagnie.

Supponendo che tu possa ottenere un certo impegno, inizia con una piccola parte del prodotto, come quella che devi modificare o estendere e renderla migliore. Ogni volta che hai un compito di codifica, calcola un po 'il preventivo e dedica un po' di tempo a sistemare o migliorare qualcosa.

Allo stesso tempo, inizia ad applicare le migliori pratiche come la revisione del codice, utilizzare i test unitari automatizzati e così via. Questo è obbligatorio per tutti gli sviluppatori, specialmente per quelli senior.

Michael Feathers ha un grande libro, Funzionante in modo efficace con il codice legacy , su codice di refactoring per renderlo più testabile. Non ho dimestichezza con gli strumenti PHP, ma c'è sicuramente un equivalente di .NET StyleCop per applicare gli standard di codifica. Identifica inoltre se i componenti del sistema possono essere sostituiti da librerie di terze parti. Ciò riduce il carico di manutenzione da te e probabilmente aumenta la qualità del codice.

Considerare anche la raccolta di alcune metriche. Potrebbe essere utile tenere traccia di quanto del codice base è stato ripulito, forse una percentuale del codice o del numero di componenti. Un modo per dimostrare il beneficio del lavoro per la gestione è confrontare il tasso di rilevamento dei difetti e il numero nel vecchio codice con il codice ripulito. Un altro è guardare il tempo impiegato per completare le modifiche al vecchio e al nuovo codice.

Una volta che questo ha avuto successo per alcuni componenti, collabora con gli altri sviluppatori sulla progettazione generale del sistema. Come dovrebbe funzionare effettivamente il sistema? Questo può essere difficile, soprattutto se il prodotto sta cambiando rapidamente, ma un progetto di alto livello per il sistema è qualcosa a cui aspirare con i cambiamenti incrementali. Senza di esso, la qualità dei singoli componenti potrebbe migliorare, ma il sistema sarà un disastro.

Dovresti trovarti in una situazione per rivalutare la tua posizione.

Un ultimo punto che voglio affrontare è il tuo indebitamento verso altri sviluppatori. Da quello che hai scritto, lo stato del prodotto non è colpa tua. Gli sviluppatori di software tendono a sentirsi strongmente legati l'un l'altro ed è uno dei motivi per cui molti di noi adorano il settore. Riparare un prodotto rotto avrà un bell'aspetto nel CV. Affogare nella negatività e nella futilità ti farà impazzire e bruciarti. Devi sapere dove tracciare la linea e fidarti degli altri per badare a se stessi.

Ci sono diversi approcci a questo, ma fondamentalmente molto dipenderà dal supporto del management - e se non hai una gestione che comprenda quali differenze significhi una base di codice testabile, solida e documentata, allora forse il tuo curriculum sarebbe il migliore itinerario.

Hai ambienti paralleli? La prima cosa che suggerirei sarebbe quella di mettere in piedi un framework per il test di regressione - prendere una normale fotografia dei dati di produzione e utilizzarla per un ambiente parallelo dev / UA. Quindi inizia a testare il codice refactored, nuovo o modificato lì prima del rilascio in produzione.

Se non riesci a testare l'unità / l'integrazione / il sistema da zero, allora dovresti almeno iniziare a testare correttamente qualsiasi codice nuovo / modificato - e per questo avrai bisogno dell'ambiente parallelo. Quindi almeno inizierai a guadagnare un po 'di fiducia nei cambiamenti che stai facendo.

Una volta che hai effettuato alcuni test, allora forse prova a procurarti alcuni strumenti di copertura in modo da poter iniziare a indovinare la portata dei tuoi problemi.

Esaminare anche la documentazione automatizzata - Sono attualmente in un mondo .net e in grado di abilitare la documentazione automatizzata e quindi mancare la documentazione contrassegnata come avvertenza, ma facoltativamente avere avvertenze trattate come errori, quindi le build falliranno quando la documentazione è assente , è un vero aiuto per trovare buchi. Non aiuta a creare commenti buoni , ma qualcosa è generalmente meglio di niente.

E torna alla gestione: ogni sviluppatore ti dirà che non ha tempo sufficiente per fare le cose, ma se puoi iniziare a cucinare in tempo per le tue stime per includere test e documentazione, anche se si gira "più tardi oggi "in" domani all'ora di pranzo "o simili, poi raccoglierai i dividendi abbastanza presto.

Insegnerai ai giovani anche alcune buone pratiche e se sarai ancora in giro in pochi anni, anche quella sarà una grande vittoria.

Se esci e il dipartimento si spegne non ti ritengo responsabile, ammesso che tu sia una recente aggiunta alla compagnia. Ma d'altra parte, se sei stato lì più che dire 6 mesi e c'è chiunque (almeno, chiunque importante ) che non sa cosa pensi le norme attuali quindi ti terrei parzialmente responsabile.

Non basta dire semplicemente "dovremmo commentare il nostro codice" ai tuoi colleghi sviluppatori. Se il codice non è mantenibile, è responsabilità dell'utente - ad esempio parte del tuo lavoro - assicurarti che tutti lo conoscano dai colleghi e dai compagni di squadra alla gestione e all'assistenza. Se non gli interessa, allora lo accetti o parti.

Non te ne sei andato, quindi lo hai implicitamente accettato. Non dici che hai testato o commentato il tuo codice, quindi posso solo supporre che tu non abbia. Ora tutto quel "debito tecnico" sta tornando a casa. Hai tre opzioni:

1. cut-and-run, trova un nuovo lavoro. Presumibilmente lo farai di nascosto mentre lavori ancora al lavoro attuale fino a quando qualcosa non si presenterà. Questo è quello che faresti se pensassi che il problema sia insormontabile, troppo rischioso o troppo duro lavoro. Inizia a cercare immediatamente, perché se il codice è come dici tu le cose potrebbero diventare brutte molto rapidamente.
2. intensificare, posizionarsi come nuovo sviluppatore senior e risolvere il problema. Hai l'opportunità di metterti alla prova, se sei all'altezza. Ma collegherei alcune dipendenze che devono accadere prima di investirti nel compito
   • la tua gestione deve capire che sei in una correzione, che le cose non sono state eseguite correttamente e che i processi devono cambiare. Potresti avere un momento difficile qui se hai fatto parte del problema - se sei stato lì per un po 'di tempo, allora il tuo capo dirà' così perché non mi hai fatto sapere che stava succedendo? '
   • ottieni una promozione per senior dev, il che significa che ottieni l'autorità per far accadere le cose nel modo desiderato. Se non si fidano che puoi fare il lavoro, questo non accadrà.
3. non fare nulla. Basta presentarsi e farsi pagare come hai fatto fino ad ora, assumeranno qualcun altro per essere lo sviluppatore senior che sarà responsabile della risoluzione del problema, non sottolineo.

Il codice può sempre essere manipolato in uno stato testabile ... Dipende solo se hai il tempo!

Raccomando una lettura di Funzionante in modo efficace con il codice legacy che ti aiuterà a identificare le strategie per l'esecuzione dei test.

La tentazione è di buttare via tutto e ricominciare da capo ... Questo è quasi sempre il cosa sbagliata da fare (quindi dice Joel Spolsky , quindi deve essere vero!).

Since I've joined this company I've tried to push for better coding standards, project documentation, etc

Se sarai il solo sviluppatore esperto lasciato nel progetto, questa sembra un'occasione d'oro per introdurre una migliore pratica di codifica.

Siate aperti con il team di gestione e spiegate la situazione in cui vi trovate, spiegate loro che avete bisogno di tempo per lavorare sulla base di codice esistente prima di continuare a trascinarvi sopra.

Può sembrare scoraggiante affrontare il codice riga per riga senza commenti, ma in seguito la tua comprensione di come funziona il software aumenterà considerevolmente, e troverai che le aggiunte future saranno un gioco da ragazzi!

E infine ... a volte un nuovo lavoro può essere solo il ticket, ma in 3 mesi potresti trovarti esattamente nella stessa posizione ma con meno influenza sui problemi che contano (ad esempio gli standard di codifica!).