Come indirizzare il codice rifattorico tangenziale in un ramo di funzione

2

[Risposte riassunte inserite] Quando lavoro in un ramo di funzionalità e trovo il codice che dovrebbe essere refactored che non è correlato al ramo a parte il fatto che si trova nello stesso file in cui sto lavorando.

Devo creare una nuova user story?

  • Il consenso è che in effetti dovrebbe esserci una sorta di nuova PBI che copre il refactoring. [User Story, Bug, Issue]

Inoltre come scrivi una user story per il codice di refactoring?

  • Riferimento al commento @DocBrown, Come lavorare su attività correlate a User Story .
    • Dovresti in effetti strutturare il refactoring come User Story e sforzarti di inserirlo in questi termini per concentrarti sul suo potenziale valore per l'azienda.
    • Citare ragioni come: Debito tecnico e In che modo la responsabilità del refactoring è ereditata dalla funzione passata che non soddisfaceva la qualità standard, quindi non avrebbe mai dovuto incontrare la Definizione di fatto

Nel caso di piccole correzioni, giustifica la creazione di un PBI e un ramo da correggere?

  • Come risposta @DanCornilescu, ci sono dei motivi per separare la correzione dal lavoro corrente in corso, come la creazione di conflitti inutili nel ramo o la creazione di una distrazione da ciò che si supponeva stessero facendo.
  • Anche aggiunto da @DanCornilescu è il valore aggiunto quando si lavora sui team. Se le correzioni sono indirizzate in un ramo personale e non vengono aggiunte alla gestione del progetto, altri sviluppatori possono eseguire le stesse correzioni.

Sarebbe una cattiva pratica provare e trovare la storia utente relativa più vicina e avviare un compito in?

posta Devin Gleason Lambert 18.02.2017 - 15:50
fonte

2 risposte

4

Personalmente mi limito a presentare un problema per rintracciarlo, da sistemare nel ramo di sviluppo principale (o ovunque tali elementi siano indirizzati nel tuo progetto / org più grande), per diversi motivi, il tutto alla fine traducendo in ulteriori ostacoli per superare per la tua caratteristica molto personale:

  • qualsiasi modifica non necessaria in un ramo di funzionalità potrebbe creare conflitti non necessari nelle future fusioni di ramo, incluso il proprio ramo di funzionalità
  • è una distrazione dal punto di vista della metodologia agile, ti perderebbe tempo a fare qualcos'altro rispetto a quello che dovresti fare per la tua funzione

È probabile che altri sviluppatori che tocchino lo stesso file notino anche la necessità di refactoring, nelle proprie sezioni di funzionalità. Con una politica di open season per questo tipo di lavoro è probabile che alcuni saltino su di esso, causando più problemi che benefici a causa di conflitti. Quindi avere un problema di monitoraggio è molto importante:

  • il refactoring è visibile e non dimenticato
  • il refactoring sarà fatto con una corretta pianificazione, stabilendo la storia a cui appartiene, chi lo farà, quando, in quale branch / release, ecc.
  • tutti sono sulla stessa pagina
risposta data 18.02.2017 - 16:22
fonte
1

Cross ha pubblicato la mia risposta ...

La risposta dipende da come il team sta usando User Stories and Tasks e dal loro approccio al refactoring.

Associazione degli elementi di lavoro ai commit

Se hanno una politica arbitraria che ti obbliga ad associare commit a Articoli di lavoro, dovrai o sovrascrivere la politica o associarla. Spesso questa associazione è necessaria per un qualche tipo di rapporto di rilascio in modo da poter vedere tutte le modifiche in una versione. Forse il team sta usando associazioni per tracciare il tempo sul compito? In tal caso, creare un'attività per associare il commit a. Quindi, la risposta dipende da come la squadra sta usando l'associazione. In passato, ho utilizzato una User Story "Improve Component X" per associare i refactoring a. Questa User Story rimane aperta come luogo per tenere traccia dei miglioramenti. Il mio consiglio generale è di evitare sforzi inutili (ad esempio, creare attività quando non vengono effettivamente utilizzati per qualcosa di valore) e fare la cosa più semplice possibile. Vuoi rendere il refactoring il più semplice possibile.

Branching

Il refactoring deve entrare nella linea principale in un momento diverso rispetto alla funzione? Se è così, avrai bisogno di un ramo separato. Se il refactoring può entrare nello stesso momento della feature, mantieni le cose semplici e refactoring nel feature branch. Vorrei almeno usare un commit separato per il refactoring.

    
risposta data 20.02.2017 - 18:53
fonte

Leggi altre domande sui tag