Quale metodologia di sviluppo per un programmatore solista su un progetto di un mese?

Tipicamente, una metodologia di sviluppo è progettata per gestire un progetto software durante il suo ciclo di vita, dalla nascita alla fine del ciclo di vita. Quello a cui sei stato assegnato sembra più un compito piuttosto che un progetto di sviluppo software. È un compito importante che deve essere suddiviso, ma non è niente che necessiti di una metodologia di sviluppo formale. Invece, dovresti lavorare all'interno del processo definito per l'utilizzo nel progetto a cui è correlata questa attività.

Vorrei iniziare con una serie di passaggi molto semplice e metodica:

1. Scopri il sistema. Richiedi le specifiche dei requisiti, i documenti di progettazione e qualsiasi altro documento pertinente associato a questo codice. Esaminali insieme al codice. Se qualcosa non è aggiornato, vorrei informarsi sull'aggiornamento della documentazione, poiché sarebbe utile ai futuri sviluppatori.
2. Leggi il codice e i test associati. Una volta letti i documenti, leggi il codice. Annota le discrepanze tra i documenti e il codice. Se qualcosa non è corretto, i difetti dei file sono appropriati. Tratteniti qui - non saltare dentro e iniziare a sistemare le cose senza seguire il processo a livello di progetto. Se non ci sono test o casi di test mancanti, è un buon momento per crearli, specialmente se il tuo lavoro comporterà il refactoring.
3. Esegui i casi di test. Se qualche test fallisce, riporta i rapporti sui difetti come appropriato.
4. Strumento e profilo del codice. Non ho familiarità con gli strumenti di sviluppo di JavaScript, ma cerco di profilare il codice in esecuzione e scoprire dove sono le perdite di memoria e se determinate condizioni li innescano. Potrebbe anche essere utile creare un profilo di prestazione generale del codice di base per determinare dove si trova il codice meno efficiente. Anche se non hai il compito di risolverlo, hai gli strumenti necessari per trovarlo, quindi documentali per risparmiare tempo per i futuri sviluppatori.
5. Priorità ai difetti. Ciò include le perdite di memoria. Si spera che tu abbia più informazioni su di loro da "c'è una perdita di memoria" a questo punto, quindi ci dovrebbe essere una serie di difetti relativi a questi problemi. Se ci sono difetti nei moduli con perdite di memoria, risolverli prima. Vuoi migliorare le prestazioni del codice che altrimenti supera i test.
6. Inizia a correggere i difetti, iniziando da quelli con la priorità più alta. Assicurati di eseguire i test (automatici e manuali) per assicurarti che il sistema non sia diventato instabile.
7. Fai domande. Non dare mai nulla per scontato. Se hai accesso agli sviluppatori precedenti, approfittane quando hanno tempo. In caso contrario, consultare la documentazione e Stack Overflow secondo necessità. Assicurati di avere una buona comprensione di come si comporta il sistema, perché si comporta in questo modo e di trasmettere tali informazioni agli sviluppatori futuri attraverso varie forme di documentazione.

Durante questa attività, assicurati di utilizzare il controllo della versione per tenere traccia delle modifiche. Un buon controllo delle versioni e dei registri di commit ti aiuterà a tenere traccia di quali modifiche hai apportato e quando li hai creati. Il monitoraggio del tempo e delle attività completate ti aiuterà a migliorare le stime e a mantenere i manager oi supervisori in-the-loop sullo stato corrente del progetto.

La migliore idea su una base di codice legacy come quella è "Divide and Conquer", dividendo il problema in unità funzionali più piccole, specialmente se non è già strutturato bene. Questo può comportare alcuni refactoring in modo che il codice sia più gestibile, quindi cerca giunture in cui potresti suddividerlo in funzioni più piccole.

Alcuni di questi sono trattati nell'eccellente libro Funzionante in modo efficace con il codice legacy .

Un altro punto è che se non ci sono già test è necessario inserire alcuni test unitari per evitare di rompere le cose durante il refactoring, quindi assicurati di cercare modi per testare il codice. Esiste un framework per i test unitari chiamato QUnit che può aiutare a testare Javascript.

Immagino che tu non abbia davvero il tempo di leggere un libro su come lavorare con il codice legacy, quindi ecco i miei due centesimi (dopo aver letto Working Effectively con Legacy Code) e di essere stato in una posizione simile molte volte (lavoro per un'azienda Fortune 100 e aziende periodicamente di grandi dimensioni hanno questi enormi errori di progetto che li inducono a riconsiderare gli investimenti in vecchi sistemi legacy, quindi si finisce con enormi progetti di refactoring che non si era pianificato di fare).

1. Fai QUALCOSA. Non analizzare la schifezza di ciò che hai intenzione di fare. Il fatto stesso che tu abbia chiesto una metodologia potrebbe indicare che hai una tendenza psicologica a farlo. Non farlo. L'80% di averlo fatto correttamente lo sta facendo, specialmente in un piccolo concerto come un compito di un mese.
2. Dedicare una piccola quantità di tempo (meno del 5% del budget totale in termini di tempo come regola generale) per capire dove ti piacerebbe essere alla fine. Che aspetto ha il successo?
3. Sto lavorando al problema giusto? Stai letteralmente cercando di trovare una perdita di memoria? In tal caso, perché stiamo parlando di queste 8000 righe di codice? Ci sono un numero limitato di modi per creare perdite di memoria in JS (come riferimenti circolari), quindi mettiamo le cose per prime come dicono, e assicurati che il problema sia corretto.
4. Lavori da solo o con una squadra? Se lavori con una squadra, hai capito come ritagliarsi il lavoro tra di voi? In caso contrario, questo sarà un esercizio di frustrazione: fallo capire in anticipo, o almeno capire come deciderà quando scadrà il momento.
5. Analisi / Sviluppo. Una volta che hai capito i 4 elementi sopra, dovrai fare il duro lavoro di fare analisi approfondite - cercando di capire cosa sta facendo il codice. Una volta capito come funziona qualcosa, codifica questa comprensione usando un approccio divide et impera. Vale a dire, riscrivi alcuni sottoinsiemi del codice "nel modo giusto" e sostituisci tutti i riferimenti al vecchio codice con il nuovo codice nel modo meno intrusivo possibile (il che spesso significa che devi scegliere un punto arbitrario per "smettere di tirare" il filo fuori dal maglione "). Si finisce con una versione "pulita" del codice su un lato - codice buono, noto e completamente testato (Jasmine è buono per i test unitari JS tra l'altro), e il codice legacy sull'altro lato - non testato, codice di qualità sconosciuto che stai cercando di sostituire lentamente.