È necessario migliorare la qualità del codice mentre si lavora su un ramo di funzioni

Mi piace molto questo articolo su come lasciare il codice / campeggio in uno stato migliore di quello che hai trovato - sembra un approccio pratico nel mondo reale per mantenere la pulizia del codice.

Mi piacciono molto anche i rami delle funzionalità come un modo per sviluppare le funzioni in modo isolato, in modo che, se non ti piace, non puoi facilmente unirle ecc.

Tuttavia, se sto lavorando su un ramo di funzionalità e individuo del brutto codice, dovrei risolverlo?

Sembra che ci siano un certo numero di lati negativi per risolverlo:

• Quando unirò nuovamente il ramo, il diff sarà disordinato, ingombro di nomi variabili o estrazione di funzioni
• Se la funzione viene abbandonata, devi scegliere il commit di pulizia (che può o non può funzionare a seconda di come il codice vicino è cambiato facendo un'unione disordinata), rifallo o semplicemente abbandonalo.

D'altro canto, se non lo faccio mentre sono nel file, chiaramente mi dimenticherò di farlo tra un paio di giorni quando unirò il ramo.

Sono stato avvisato che questo era basato sull'opinione (penso solo al fatto che il titolo includa should), ma mi sento come se ci fosse una risposta (certamente le persone usano entrambi questi approcci quindi devono avere una risposta). Inoltre, le domande su development methodologiessono in tema e penso che necessitino di un certo grado di opinione.

Dovresti 'correggere' il codice in un ramo di funzionalità solo se stai modificando quel pezzo di codice come parte della funzione.

Per esempio. Sto lavorando sulla funzione "stampa conigli" e trovo il codice della stampante

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

Lo cambio in:

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

Perché:

• Sto lavorando al codice,
• Ho bisogno di cambiarlo per aggiungere funzionalità,
• la funzionalità aggiunta suggerisce un modo refactored di affrontare il problema.

Non colpisco in modo casuale un'altra parte della base di codice e "miglioriamo" come farebbe:

• Scontro con persone che lavorano su altre funzionalità.
• Utilizzare il tempo che dovrebbe essere assegnato allo sviluppo della funzione.
• Aggiungi un codice arbitrario a una filiale che, se la funzione non è terminata, potrebbe non essere unita al prodotto principale. Allo stesso modo, se ripristino la funzionalità, perderò il refactoring.

Se vuoi che i tuoi refactoring "vivano in modo indipendente" dal tuo ramo di funzionalità corrente, non apportare le modifiche lì. Invece, esegui il refactoring sul ramo di sviluppo principale (o un "ramo di refactoring", se è comune nel tuo team non applicare le modifiche direttamente al ramo di sviluppo). In questo modo chiunque nel tuo team (incluso te) può unire le modifiche nei rami delle funzioni attive su cui stanno lavorando. Tuttavia, fai attenzione a non applicare alcun refactoring globale in "metà della base di codice" senza prima chiedere l'autorizzazione ai tuoi colleghi: potrebbero non essere così felici se i tuoi refactoring interferiscono troppo con il loro lavoro attuale.

L'eccezione è qui quando i miglioramenti apportati sono locali alle parti della base di codice che tocchi esattamente in quel ramo di funzionalità e non ha senso dare loro un ciclo di vita diverso rispetto alla tua "nuova funzionalità".

Lo scopo dei branchtipi è fornire l' intenzione di gestirli. Se stai seguendo uno stile GitFlow di ramificazione, probabilmente hai tipi come feature, hotfix, release, ecc .. Nel caso di un ramo di caratteristica, la sua intenzione è quella di incapsulare una fusione in un altro ramo (cioè develop) che mostra lo sviluppatore responsabile fusione, che cos'è questa funzionalità. Se il codice che stai ripulendo non fa parte di quella funzione, non modificarlo.

Invece, trova il ramo più basso possibile in cui si trova il codice brutto (probabile develop) e ramo da lì. Modifica il codice e proponilo di unirlo come funzionalità. Se hai bisogno di quel codice in quello su cui stai lavorando e soprattutto vuoi evitare di unire i conflitti, unisci quel ramo nel TUO ramo.

Ecco una buona spiegazione delle diverse strategie: https://www.atlassian.com/git/tutorials/comparing-workflows/

se sto lavorando su un ramo di funzionalità e rilevo del brutto codice, dovrei ripararlo?

Probabilmente va bene correggere "brutto codice" a vista, a seconda del tempo del progetto, della "bruttezza" del codice, ecc., Ma cerca di non farlo sul ramo della funzione stesso.

• Se il tuo ramo di funzionalità è interamente locale, nascondi o esegui modifiche non salvate, controlla il ramo di sviluppo, apporta la modifica, quindi torna al ramo di funzionalità e disattiva lo sviluppo.
• Se non è possibile annullare lo sviluppo (ad es. Il ramo delle funzionalità si trova su un server pubblico), è comunque possibile selezionare lo svincolo di sviluppo se necessario o se si desidera evitare conflitti in seguito.
• Se stai modificando un file e devi davvero impegnare la correzione con il brutto codice in questo momento e davvero non puoi passare allo sviluppo, puoi effettuare la correzione, utilizzare git add -pper apportare la correzione, impegnare solo quella modifica e prima di unire / push (anzi, preferibilmente dopo il tuo prossimo commit), usa il rebase interattivo per spostare quel commit nel punto più presto possibile nel tuo ramo, o forse anche scegliere la ciliegia su sviluppo, a seconda della tua storia.

Lo farei anche con qualsiasi altra cosa che "risolve" il ramo di sviluppo (dove "correzioni" sono le modifiche che tu o qualsiasi altro sviluppatore potreste fare a vista per garantire che il codice aderisca agli standard). Questo aiuta...

• per mantenere le tue correzioni e la tua funzionalità si impegna in diversi gruppi in modo che il registro sia più leggibile,
• mantenere lo sviluppo il più vicino possibile alla liberazione in qualsiasi momento, e
• per evitare la duplicazione del lavoro (più persone risolvono lo stesso problema in modi leggermente diversi su rami diversi).