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

Budget in tempo per attaccare il debito tecnico. Devi solo farlo. Le parti che attacchi per prime dipendono da dove i tuoi sviluppatori stanno spendendo più tempo al momento, ma è più importante iniziare, quindi iniziare dalle cose ideali. Se stai utilizzando Scrum, metti nel tuo backlog pezzi specifici del lavoro tecnico del debito e trattali come funzioni fino a quando non riesci a gestirli.

Lavorare efficacemente con il codice legacy è altamente raccomandato e probabilmente sarebbe utile. Non l'ho letto, ma sembra che ci siano molte informazioni su come ottenere i test unitari in codice legacy, così puoi modificarlo e aggiornarlo in sicurezza.

Usa l'analogia della carta di credito con il management - stai "pagando interessi" su tutto ciò che fai perché è così difficile realizzare qualsiasi cosa. Se paghi il debito tecnico, libererai quelle risorse e sarai in grado di sviluppare nuove funzionalità più rapidamente in futuro. Se non lo fai, i tuoi "pagamenti di interessi" (pagati in fase di sviluppo) continueranno ad accumularsi e il tuo team produrrà nuove funzionalità più lentamente.

Forse inizi a stimare la quantità di tempo che impieghi per ogni ciclo a lottare contro il debito tecnico per dare loro un'idea di quanto si è già accumulato. Descrivi come apparirà una correzione o una modifica di funzionalità in un sistema gestibile, come appare nel sistema attuale e quali modifiche dovranno essere apportate o potrebbero essere i primi passi per arrivarci.

Ripristina il debito tecnico nelle correzioni di bug e funzionalità aggiuntive.

Ho trovato un approccio iterativo al miglioramento che produce i migliori risultati. Il mantra nel mio lavoro è migliorare la qualità del codice ogni volta che lo tocchi. Ogni pezzo di lavoro, sia che si tratti di un bug fix o di una funzionalità, inizia con un'analisi di ciò che può essere corretto / refactored / ripulito. Cerchiamo di rendere il refactor par (in scala) al lavoro che dobbiamo completare.

Crea una lista ordinata dei problemi nella base di codice. Assicurati che tutti siano a conoscenza della lista e dell'ordine di priorità. Ogni volta che ottengono un lavoro, dovrebbero cercare un problema dalla lista legata al codice su cui si lavorerà.

Questo non risolverà tutto. Ci sono alcuni refactoring o correzioni che richiedono una grossa fetta di tempo e risorse. Generalmente cerco di legarli ad altri grandi lavori che ne trarranno beneficio.

Potrei semplicemente affermare l'ovvio, ma hey.

Scrivi un piccolo test di unità che esercita un blocco di codice che presenta problemi, quindi aggiusta detto blocco, assicurandoti che il test passi ancora. Passa a un'altra porzione di codice, quella che puoi raggiungere più facilmente da quella piccola porzione di solido terreno che hai appena costruito. Mescolare, sciacquare, ripetere.

Questo ti aiuterà anche a familiarizzare un po 'con il codebase.

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

Lascia sempre il codebase un po 'meglio di quanto non lo fosse prima di iniziare a penetrare in esso. Sono abbastanza sicuro che sia un piccolo investimento che pagherà, anche nel non lungo termine.

Potresti provare a spiegare il debito tecnico questo progetto ha una sola idea di dove cominciare. Potresti anche provare a contrattare che a causa dello spostamento dei dipendenti ci deve essere un po 'di tempo trascorso ad accelerare il codice e questo significa mettere alcuni test per contribuire a garantire un futuro sviluppo migliore dato che i test possono aiutare a prevenire bug e rendere le cose più facili nuove persone a lavorare sul progetto possibilmente.

In casi come questi, mi piace cercare di ottimizzare il progetto il più possibile. Scopri quali caratteristiche sono assolutamente necessarie per farlo andare avanti. Qualunque sistema in circolazione da molto tempo probabilmente ha un arretrato molto lungo. Molti di questi articoli saranno critici e molto saranno solo "campane e fischietti".

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

Buona fortuna.

Una delle opzioni è rispolverare il curriculum e iniziare la ricerca di un lavoro.

Una buona domanda da porsi è se questo progetto mal gestito sia indicativo di come viene gestita l'intera azienda. Se la risposta è sì, chiedi se sei pagato abbastanza per stare in una compagnia gestita male.

Molte volte puoi spingere il refactoring dal management superiore se puoi dire loro che sarà un aggiornamento delle prestazioni o corregge alcuni bug esistenti. Non ridimensionare solo per cambiare qualcosa in quello che faresti, specialmente se funziona. Il bug fix time può anche essere un buon modo per adattarsi a qualche refactoring, visto che ci sei già. Sii assertivo e non guardarlo come 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 indurre il management a darti cicli per altre cose.

Attualmente sto leggendo Sviluppo applicazioni Brownfield in .NET che, in pratica, tratta di come affrontare i problemi che attualmente hanno. Finora mi piace la maggior parte di ciò che dice (non proprio tutto - ma questo è il tipo di libro per aiutarti a pensare a modo tuo attraverso i problemi, non uno che è destinato a essere completamente prescrittivo). Può essere d'aiuto in un paio di modi: mostra che non sei solo; si spera che ti diano suggerimenti su come affrontare alcuni dei problemi.

Fondamentalmente sono d'accordo con la maggior parte degli approcci: non puoi sistemare l'intera cosa durante la notte, ma puoi migliorarla gradualmente in piccoli passi. E sì: il debito tecnico è la metafora che devi usare.

In definitiva dipende da quanto sono brave le persone nel progetto. Se è lo stesso equipaggio a creare il casino, allora hai poche possibilità di renderlo migliore con lo stesso gruppo. Analizza il tuo staff, scopri i membri più deboli e sostituiscili (se ne hai la possibilità)

"Non puoi fare un borsellino di seta dall'orecchio di una scrofa".