Tutti gli sviluppi, incluso il lavoro di refactoring, devono essere accompagnati da un problema di tracciamento?

Forse mi manca qualcosa qui, ma come fa la creazione di un ticket per il lavoro che stai facendo non rientra nello scopo dei tuoi altri ticket un "livello di resistenza"?

Hai recentemente implementato l'utilizzo di un sistema di tracciamento dei ticket? Se è così, allora siediti e prendi le tue regole per usarlo e fai sapere al team che sono tenuti a seguire queste regole. Se questo include la creazione di biglietti di refactoring per questo lavoro, così sia. Non puoi creare eccezioni in anticipo o potrebbe far deragliare l'intero processo che il tuo team sta tentando di configurare.

Se hai utilizzato un sistema di tracciamento dei biglietti per un po ', allora non capisco perché questo sarebbe un "livello di resistenza". La tua squadra dovrebbe già essere abituata ad avere Jira aperta e guardando i biglietti e dovrebbe essere a suo agio nel fare i biglietti.

Se si desidera mantenere tutti gli sforzi di refactoring in un unico posto, creare un ticket principale per questo, e fare in modo che il proprio team svolga compiti per il lavoro che sta svolgendo. Poi ci vogliono 5 secondi perché un dev faccia una nuova attività per questo e possono registrare il loro tempo per quella attività.

I project manager, i lead del team e gli sviluppatori devono sapere quanto tempo è dedicato allo sforzo di refactoing. Non vuoi che diventi un buco nero del tempo. Avere i biglietti mantiene gli sviluppatori responsabili per il loro lavoro, fornendo al contempo i manager e conduce un posto in cui tenere traccia di quante ore andranno allo sforzo.

Idealmente sì.

Qualsiasi modifica apportata al codice deve avere una motivazione. Può trattarsi di una richiesta del cliente, la più comune / probabile o di un oggetto interno, come nell'esempio di refactoring.

Questo significa che oltre al tracciamento quando è stata apportata una modifica, è possibile collegare nuovamente il changeset a qualcosa che spiega il motivo della modifica. Perché non possono essere solo i commenti dei changeset? Ci sono diversi motivi per cui questo potrebbe non essere adatto.

• Non esiste sempre una mappatura 1: 1 tra gli elementi di lavoro e i gruppi di modifiche: potresti aver bisogno di diverse serie di modifiche per completare un elemento.
• I commenti dei changeset in genere non sono visibili ai non sviluppatori o potresti dover allegare altra documentazione all'elemento di lavoro.

Il refactoring del codice, sebbene altamente desiderabile per migliorare la qualità, è anche un rischio intrinseco. Ciò è particolarmente vero quando si tratta di codice "di base" in cui un singolo bug farà cadere l'intero sistema e risolvere un singolo "problema" avrà effetti collaterali (forse imprevisti) nell'intera applicazione.

Indipendentemente dal tipo di codice coinvolto, quando un refactoring non è limitato al codice per un problema specifico (ticket), il controllo qualità deve essere coinvolto e reso consapevole delle parti del codice di base interessate. Dovranno fare un test completo di regressione su quelle parti per assicurarsi che non vi sia nulla di sfuggito. E lo dovranno fare anche, forse in particolare, se hai una serie completa di test unitari che ti fanno sentire sicuro di fare il refactoring. I test unitari testano molto, ma anche a loro manca molto.

Quindi, se la qualità del codice è importante, sì, ci dovrebbero essere meno barriere possibili per migliorare il codice. Ma non riesco a vedere come creare un biglietto per questo è una barriera. Semplicemente assicura che il QA abbia la possibilità di (im) dimostrare la qualità del codice e dovrebbe essere qualcosa di desiderabile, non qualcosa che viene visto come un ostacolo.

Penso che se non puoi descrivere il refactoring più specificamente di "refactoring", lo stai facendo male. Il refactoring dovrebbe avere uno scopo e una portata definiti. Tracciare separatamente le attività di refactoring in JIRA rende più semplice l'auditing, la revisione e il test, ma costringe i refactorer a focalizzare le loro menti su obiettivi concreti ("rimuovere una dipendenza circolare tra i moduli X e Y", ad esempio) e porterà semplicemente a miglior refactoring.

D'altra parte, se il refactoring è davvero semplice, locale e solo un sottoprodotto di svolgere un compito diverso, non mi preoccuperei di rintracciarlo sotto un biglietto separato e di documentarlo solo nel biglietto taks originale, se può avere un impatto sul lavoro di altre persone.

Sì, idealmente ogni modifica apportata al codice deve essere associata a un elemento JIRA e quindi tracciabile. Come altri hanno notato, dovresti essere in grado di identificare il motivo per cui è stata apportata una determinata modifica e quali altre modifiche sono correlate.

Va bene avere refactoring Epics a lungo termine in un progetto legacy, li abbiamo anche nel nostro. Tuttavia, dovresti sforzarti di concentrarti su alcune aree specifiche del codice, con uno scopo specifico, altrimenti è davvero difficile tenerlo sotto controllo. Per esempio. "moduli refactor Foo e Bar per eliminare le dipendenze cicliche", "gerarchia delle classi refactor A per rimuovere duplicazioni e ripulire la gerarchia di ereditarietà".

Quando si lavora su un codice legacy, con risorse limitate, si deve dare la priorità a possibili modi per ridurre il debito tecnico, per ottenere il miglior ritorno sull'investimento possibile. Quindi, prima di iniziare il lavoro, è necessario analizzare i possibili refactoring, la loro importanza, i rischi, i costi e i benefici. Inoltre, monitorare il progresso di un refactoring su larga scala e sapere quando è finito è importante. Rispetto a questi compiti richiesti, IMHO lo sforzo effettivo di gestione di un oggetto JIRA è minimo.

The argument has been made that PCI compliance (a near-future goal of the business) requires this level of tracking

Se intendi questo , posso in qualche modo capire perché i timori di gestione di modifiche incontrollate nella base di codice, tuttavia cambiano il tracciamento è solo una piccola parte della soluzione. Avete bisogno di test approfonditi del sistema e probabilmente di revisioni del codice per assicurarvi che nessun codice di carta di credito sia trapelato dal sistema tramite file di registro ecc. Il refactoring non dovrebbe modificare il comportamento del codice esistente e si suppone di avere test unitari per dimostrarlo comunque (non cercare di basarti sulla convinzione che strumenti di refactoring automatizzati non possano infrangere il codice - DEVI fare test unitari per evitare brutte sorprese).

In un mondo ideale, La risposta di Chris è giusta. Ogni volta che apporti una modifica al codice o a qualsiasi artefatto associato a un progetto software, dovrebbe esserci un registro di questo. Dovrebbe essere presentato, approvato, assegnato alla parte di destra, sforzo stimato, lavoro svolto, tempo totale registrato e una breve descrizione della modifica documentata.

Tuttavia, questo non è sempre fattibile. Ad esempio, il mio IDE è configurato per riformattare un file di codice in base alle linee guida del codice dell'organizzazione. Se apro un file e vedo che non combacia, è banale da correggere: CTRL + MAIUSC + F sul formato del file. Forse un CTRL + MAIUSC + O per correggere le importazioni. Lo faccio subito prima o subito dopo aver corretto il difetto che mi è stato assegnato.

In tal caso, si desidera sempre registrare il fatto che lo si è fatto e quanto tempo è trascorso, ma non apportare la modifica ora potrebbe essere peggio che passare attraverso il processo di assegnazione e implementazione formale del cambiamento. In alcuni casi, è più facile chiedere il perdono che chiedere il permesso. Dipende da te, come ingegnere, per giustificare dove esattamente quella linea deve essere disegnata.

In generale, il refactoring dovrebbe svolgersi come una normale parte del tuo flusso di lavoro. Per correggere bug A , devi testare quel bit del metodo, quindi devi estrarlo come metodo B . Mentre lo fai, noti che il campo C è molto mal chiamato e quindi lo rinomina.

Secondo il mio modo di pensare, questi refactoring normali vengono "addebitati" al bug originale A . Sono presentati con la correzione, esaminati con la correzione, con la correzione. Sono parte di la correzione.

Ma ci sono anche dei refattori più grandi e meno focalizzati. Un'osservazione generale che la classe D è troppo grande. Sarebbe più facile lavorare se hai eliminato la duplicazione in E . E quei refactoring sono tra quelli più rischiosi che dovrai affrontare (in particolare in una base di codice senza test). Con tutti i mezzi, creare biglietti per quelli; sottoponili almeno alla normale procedura di revisione.