Cosa fare come nuovo team guida su un progetto con problemi di manutenibilità?

Sono appena stato incaricato di un progetto di codice con problemi di manutenibilità. Cosa posso fare per ottenere un progetto stabile?

Mi trovo in un posto in cui stiamo lavorando con un sistema .NET multilivello molto grande a cui mancano molte cose importanti come unit test, IOC, MEF, troppe classi statiche, set di dati puri ecc. solo 24 ma sono qui da quasi tre anni (questa app è stata in sviluppo per 5) e principalmente a causa di vincoli di tempo abbiamo appena aggiunto più schifezze per adattarsi alle altre schifezze. Dopo aver fatto diversi progetti nel mio tempo libero, ho iniziato a capire quanto siano importanti tutti questi concetti. Anche a causa del trasferimento dei dipendenti, mi trovo ora a guidare il team in questo progetto e voglio davvero trovare alcuni modi intelligenti per migliorare questa app. Modi in cui il valore può essere spiegato alla direzione. Ho le idee su cosa mi piacerebbe fare, ma sembrano tutti così travolgenti senza molto guadagno iniziale. Qualsiasi storia su come le persone hanno o avrebbero affrontato questo sarebbe una lettura molto interessante. Grazie.

Tempo di budget per attaccare il debito tecnico. Devi solo farlo. Le parti che attacchi per prime dipendono da dove gli sviluppatori trascorrono più tempo attualmente, ma è più importante iniziare e iniziare con le cose ideali. Se stai usando Scrum, metti specifici pezzi di lavoro di debito tecnico sul tuo backlog e trattali come caratteristiche fino a quando non riesci a gestirli.

Lavorare in modo efficace con il codice legacy è altamente raccomandato e probabilmente sarebbe utile. Non l'ho letto, ma sembra avere molte informazioni su come ottenere unit test nel codice legacy in modo da poterlo modificare e aggiornarlo in modo sicuro.

Usa l'analogia della carta di credito con la gestione: stai "pagando gli interessi" su tutto ciò che fai perché è così difficile realizzare qualcosa. Se paghi il debito tecnico, libererai quelle risorse e sarai in grado di sviluppare nuove funzionalità più rapidamente in futuro. In caso contrario, i tuoi "pagamenti di interessi" (pagati in tempo di sviluppo) continueranno ad accumularsi e il tuo team produrrà nuove funzionalità più lentamente.

Forse iniziare a stimare la quantità di tempo che passi ogni ciclo lottando contro il debito tecnico per dare loro un'idea di quanto ha già accumulato. Descrivi come apparirebbe una correzione o una modifica di funzionalità in un sistema gestibile, come apparirà nel sistema reale e quali modifiche dovrebbero essere apportate o potrebbero essere dei primi passi per arrivarci.

Trasforma il debito tecnico in correzioni di bug e funzionalità aggiuntive.

Ho trovato che un approccio iterativo al miglioramento produce i migliori risultati. Il mantra del mio lavoro è migliorare la qualità del codice ogni volta che lo tocchi. Ogni lavoro, che si tratti di una correzione di bug o di una funzione, inizia con un'analisi di ciò che può essere risolto / refactored / ripulito. Proviamo a rendere il refactor alla pari (in scala) per il lavoro che dobbiamo completare.

Creare un elenco ordinato dei problemi nella base di codice. Assicurati che tutti siano a conoscenza dell'elenco e dell'ordine di priorità. Ogni volta che ottengono un lavoro, dovrebbero cercare un problema dall'elenco legato al codice su cui lavorerai.

Questo non risolverà tutto. Esistono alcuni refactor o correzioni che richiedono una grande quantità di tempo e risorse. In genere cerco di legarli ad altri grandi lavori che ne trarranno beneficio.

Potrei solo affermare l'ovvio, ma ehi.

Scrivi un test di unità di piccole dimensioni che esercita un blocco di codice che presenta problemi, quindi refactoring detto blocco, assicurandoti che il test passi ancora. Passa a un altro pezzo di codice, quello che puoi raggiungere più facilmente da quella piccola porzione di terreno solido che hai appena costruito. Raccogliere, sciacquare, ripetere.

Questo ti aiuterà anche a familiarizzare un po 'con la base di codice.

Dopo averlo fatto per un po ', capirai che è tempo di fare un po' di refactoring più esteso. Capire codice duplicato, violazioni del principio DRY ... sai, le solite cose. A quel punto avrai una copertura del codice discutibilmente decente, che ti permetterà di mescolare metodi, estrarre interfacce e tutti quei servizi.

Lascia sempre il codebase un po 'meglio di prima che tu abbia iniziato a hackerarti. Sono abbastanza sicuro che sarà un piccolo investimento a ripagare, anche nel breve periodo.

Potresti provare a spiegare il debito tecnico che questo progetto ha per un'idea di dove iniziare. Potresti anche provare a contrattare che, a causa del trasferimento dei dipendenti, ci vuole un po 'di tempo impiegato per aggiornarsi sul codice e questo significa mettere in atto alcuni test per contribuire a garantire un migliore sviluppo futuro poiché i test possono aiutare a prevenire i bug e semplificare le cose nuove persone per lavorare al progetto possibilmente.

In casi del genere, mi piace provare a semplificare il progetto il più possibile. Scopri quali funzioni sono assolutamente necessarie per farlo andare avanti. Qualsiasi sistema che esiste da molto tempo probabilmente ha un backlog molto lungo. Molti di questi articoli saranno fondamentali e molti saranno solo "campane e fischietti".

Per quanto riguarda i test, i test unitari saranno sicuramente utili, ma potresti voler chiedere ad alcuni membri del personale non tecnico di partecipare ai test e inviare bug ai membri del tuo team.

In bocca al lupo.

Un'opzione è rispolverare il tuo curriculum e iniziare a cercare lavoro.

Una buona domanda da porsi è se questo progetto mal gestito è indicativo di come viene gestita l'intera azienda. Se la risposta è sì, allora chiedi se vieni pagato abbastanza per rimanere in un'azienda mal gestita.

Molte volte è possibile spingere il refactoring da parte del management superiore se si può dire loro che sarà un aggiornamento delle prestazioni o corregge alcuni bug esistenti. Non ripetere il fattore solo per cambiare qualcosa in quello che faresti, soprattutto se funziona. Il tempo di correzione dei bug può anche essere un buon modo per adattarsi ad alcuni refactoring poiché sei già lì comunque. Sii assertivo e non guardarlo perché sei più giovane dei tuoi colleghi programmatori. Inizia con qualcosa di piccolo come entrare in alcuni test unitari e lavorare da lì, potresti esporre alcuni bug che possono ottenere la gestione per darti cicli per altre cose.

Attualmente sto leggendo Brownfield Application Development in .NET che, fondamentalmente, tratta di come affrontare i problemi che hai attualmente. Finora mi piace la maggior parte di ciò che dice (non proprio tutto - ma questo è il tipo di libro che ti aiuta a pensare a modo tuo attraverso i problemi, non uno che vuole essere completamente prescrittivo). Può aiutare in un paio di modi - mostra che non sei solo; si spera che ti darà suggerimenti su come affrontare alcuni dei problemi.

Fondamentalmente sono d'accordo con la maggior parte degli approcci: non puoi sistemare tutto dall'oggi al domani, ma puoi migliorarlo in modo incrementale in passi molto piccoli. E sì: il debito tecnico è la metafora che devi usare.

Dipende in definitiva da quanto sono brave le persone nel progetto. Se è lo stesso equipaggio che ha creato il pasticcio, allora hai poche possibilità di migliorarlo con lo stesso gruppo. Analizza il tuo personale, scopri i membri più deboli e sostituiscili (se hai la possibilità di farlo).

"Non si può fare una borsa di seta dall'orecchio di una scrofa".