suggerimenti e trucchi per il flusso di lavoro per la gestione di codice incompleto e non ancora funzionante? [chiuso]

Naviga le tue risposte
0

Realizzo web app e bash scripting e di solito lavoro su più progetti contemporaneamente in diversi contesti e lingue e spesso torno a un progetto dopo alcuni mesi di assenza.
Quando torno a un progetto ci sono sempre frammenti di codice incompleti e ho difficoltà a "ri-familiarizzare" me stesso con quello che stavo facendo e quello che stavo cercando di ottenere.
Io uso il controllo della versione e posso guardare la cronologia, ma questo dà solo un'occhiata indietro a quello che è successo in passato.

Riguardo al codice di rottura totale

Uso i rami di "argomento" di controllo della versione per isolare qualsiasi codice che interrompe completamente la funzionalità, Im più lottando con il tentativo di comprendere lo stato delle cose dei frammenti di lavoro incompleto, ma "non-breaking".

Qualcuno ha qualche suggerimento su come potrei gestire questi elementi in un modo "lungimirante"? , probabilmente sulla falsariga di

  • TODO 's
  • issues in github / bitbucket
  • commentando il codice
  • fa in modo che il codice esegua un avviso - nell'app - per dire ho bisogno di essere finito
  • scrivi test di unità definizioni che spiega cosa stai cercando di ottenere - anche se il test dell'unità non verrà scritto fino a più tardi
  • etc
posta the_velour_fog 11.07.2015 - 07:18
fonte

2 risposte

1

Ogni nuova funzione dovrebbe avere un problema nel tracker. Ogni volta che stai lavorando sulla funzione, tieni il problema aperto in una finestra del browser.

Prima di iniziare a lavorare sulla funzione, mappare ciò che pensi di dover fare per far funzionare la funzione. Controllali (ma non cancellali) mentre li completi. Continua ad aggiungere a questo elenco quando vedi cose nuove, prima di iniziare la codifica.

Alcuni tracker di problemi ti consentono di tenere traccia degli elementi da fare e persino dei problemi innestati. Utilizza ciò che è appropriato all'ambito, ma ricorda che devi essere in grado di entrare rapidamente e aggiungere il tuo todo al problema.

In questo modo, quando ritorni al problema, puoi vedere i progressi, i blocchi di lavoro in sospeso, ecc. in un colpo d'occhio prima di decidere di riavviarti, senza dover scavare il codice e analizzarlo.

Altre cose che potresti prendere in considerazione:

  • git hooks che cercheranno la stringa "todo" e si rifiuteranno di impegnarsi se sono presenti
  • Verifica se la tua suite di test supporta elementi utili come Test :: Altro di Perl.
  • scrivi commenti di codice esplicativi e linee di codice commentate in modo diverso in modo che tu possa grep per loro separatamente (ad esempio, fai in modo che tutte le righe di commento inizino //:: o #~ )
risposta data 11.07.2015 - 19:47
fonte
1

Il modo migliore per gestire tali modifiche / integrazioni incomplete è di evitare di averle in primo luogo. Cerca di rendere le tue funzionalità abbastanza piccole da poterle implementare completamente nel lasso di tempo in cui normalmente sei in grado di lavorare su un singolo progetto.
Se in genere puoi lavorare su un progetto per 4 o 5 ore, distribuire in pochi giorni, prima che la vita passi o devi passare a un altro progetto, allora dovresti provare a ridimensionare i tuoi pacchetti di lavoro in modo che non siano più di quei 4 5 ore.

Per i piani a lungo termine che hai con un progetto (tutto il lavoro che vuoi fare su di esso, ma non hai ancora capito), puoi usare diversi metodi che vanno da una semplice lista di spartiti su un sistema di tracciamento delle emissioni a tutti gli effetti. Dovresti semplicemente utilizzare ciò che funziona meglio per te personalmente.

    
risposta data 11.07.2015 - 07:59
fonte

Leggi altre domande sui tag

Come si gestisce un grafico a stati grandi quando si costruisce una macchina a stati finiti scalabile? Ci sono delle trappole da considerare quando ci si integra con terze parti? [chiuso]