Pulisci il codice e cancella la cronologia git / jira

When we make git commits we are supposed to keep them as small as possible. This should make the commit easier understandable if somebody needs to read it and also, as far as possible keeps git blame pointing to the original author of some code

Questa politica include una cosa con cui sono d'accordo e una che non concordo con:

Vuoi mantenere i commit piccoli. Più precisamente, vuoi impegnare (e spingere e unire) spesso in modo che tutti possano rimanere aggiornati e unire i problemi siano ridotti al minimo e vuoi che i tuoi commit siano focalizzati in modo che i problemi riscontrati nella revisione del codice (o in altro modo) non ti impediscano di unire una parte desiderata a causa di qualcosa di non correlato.

Tu non vuoi commettere qualcosa che è troppo piccolo per funzionare - cioè non vuoi un commit "work in progress" che non viene compilato, o fallisce test esistenti - almeno non nella cronologia finale (vedi Come eseguire il refactoring in corso ).

• Quando crei una piccola correzione come get... - > is... , vuoi che la modifica si propaghino agli altri il prima possibile, in modo che nessuno finisca di scrivere il codice che usa la vecchia versione. Quel cambiamento non dovrebbe aspettare che tu aggiusti il resto di ciò su cui stai lavorando. Inoltre, probabilmente vorrai che il cambiamento si unisca anche se ciò su cui stavi lavorando non risulta essere indesiderabile.

• Allo stesso modo, quando il tuo altro lavoro è finito appena in tempo per una scadenza, non vuoi che venga rifiutato perché, a tua insaputa, il team ha una politica di usare sempre get per i getter, indipendentemente dal tipo.

Quindi, penso che sia una buona idea mantenere piccole correzioni come questa separate dal problema su cui stai "realmente" lavorando e farsele unire al più presto. Direi che questo tipo di pulizia dovrebbe essere spinto in modo preventivo anche se il tuo lavoro "reale" toccherà gli stessi file.

Mantenere git blame puntato sull'autore originale può sembrare attraente, ma ci sono diversi problemi:

• Tra discussioni di gruppo, programmazione di coppie e revisione del codice, non esiste sempre un singolo autore originale.

• Dato che le persone vanno in vacanza, si ammalano, lasciano l'azienda, assumono responsabilità diverse o dimenticano semplicemente le cose, sicuramente non vuoi incoraggiare situazioni in cui l'autore originale è l'unico che interagisce con un pezzo di codice.

• Per linee banali come questa, perché qualcuno dovrebbe essere interessato all'autore?

• Per le righe non banali, l'autore dell'ultima modifica ha compreso meglio il codice abbastanza bene, anche se non erano l'autore originale.

• Conoscere l'autore originale non ti aiuta veramente, se il codice è leggibile e testato. Conservare la conoscenza dell'autore non dovrebbe mai intralciare queste cose più importanti!

• Vuoi che le persone si concentrino sul fornire il miglior valore per il business. Il litigio sulla proprietà del codice non è un valore, quindi qualsiasi politica che eleva l'autore originale è negativa in questo senso.

L'autore originale può ancora essere trovato passando attraverso la cronologia. Per modifiche non funzionali su larga scala potresti voler ottenere un funky con git per preservare l'autore originale, magari qualcosa come Automatic formatting (original by XXX) , o forse solo XXX .

Quindi, in chiusura, potresti prima aver bisogno di parlare con la gente di questo, ma la mia soluzione preferita sarebbe:

• Apporta le tue correzioni in un commit separato e falla unire. Se hai bisogno di un ID Jira per questo, creane uno. Se non puoi, usa quello per il tuo compito corrente e chiamalo "pulizia per preparare X"
• (Re-) Basa il tuo altro lavoro sul commit "fisso"

Vedi Riconciliazione della regola Boy Scout e Refactoring opportunistico con le revisioni del codice per alcuni suggerimenti su come farlo in pratica.

La vera causa principale del tuo problema è che due regole

• "Richiedo sempre un numero di attività jira per un commit" e

• "dovremmo mantenere [commit] il più piccolo possibile"

sono in conflitto, dal momento che anche le attività Jira a grana fine sembrano essere un problema per la tua squadra. Questo non ha nulla a che fare con il refactoring e il codice pulito, quest'ultimo rende il conflitto più visibile.

Tuttavia, il problema verrebbe visualizzato anche se si definiscono attività Jira che richiedono diversi piccoli commit, anche se nessuno di essi contiene un refactoring.

IMHO sarebbe più sensato associare i numeri dei compiti degli inseguitori di problemi con unioni (dove ogni unione può contenere diversi piccoli commit). Non so se sia possibile nella tua organizzazione o con il tuo attuale set di strumenti, ma penso che tu abbia l'idea e possa trovare un modo per introdurla nel tuo flusso di lavoro.

Sebbene le regole siano in conflitto nella loro forma letterale, entrambe hanno lo stesso obiettivo. Rendi il codice più facile da capire.

Discutete semplicemente dei cambiamenti con i vostri colleghi prima di apportare la modifica e sono sicuro che non andrete molto male

Personalmente, penso che la situazione sia abbastanza semplice. Tutte le regole empiriche tendono ad essere buone fino a quando non rispettano la politica interna. In altre parole, si esegue "Pulisci codice" fino al punto in cui il codice pulito soddisfa la politica locale. A quel punto la politica locale dovrebbe sempre vincere.

Principalmente perché c'è un principio più ampio in gioco: mantenere il codice coerente. La coerenza è più importante della "pulizia". Quindi se qualcosa viene fatto in un certo modo, allora devi continuare a farlo in modo che le persone che si sviluppano in quel sistema non debbano ripetere l'apprendimento di nuovi processi più e più volte quando la funzionalità incapsulata esiste altrove, ma è stata cambiata a causa di la necessità di codificare in modo pulito.

Per quanto riguarda Jira. Jira è abituato a tenere traccia delle attività, se ci sono molti compiti allora ci sono molti Jiras. Evitare le attività di manutenzione perché potrebbe esserci un'altra Jira non dovrebbe essere una considerazione. Jira ci aiuta a tracciare il nostro lavoro, non dobbiamo mai limitare le nostre attività di manutenzione perché crea un sovraccarico amministrativo. L'obiettivo di uno sviluppatore è gestire e mantenere il codice.

Quindi per esempio

getConnectionActive instead of isConnectionActive

La mia domanda è questa: il prefisso "ottiene" una parte della politica? ci sono altre funzioni che usano questo stesso stile? C'è ad esempio una funzione getSomeOtherFunction? Perché se è così, quindi non cambiarlo, stai violando la coerenza sottostante del codice. In futuro qualcuno vedrà le due funzioni di ritorno booleane e dirà "Ok, perché questo è un" get "e perché questo è un" è "? C'è qualche differenza tra questi due pezzi di codice?

La mia preoccupazione generale è che, mentre sì, vogliamo costruire il codice nel modo più chiaro e corretto possibile, dobbiamo anche rispettare la coerenza del sistema stabilito. Perché le incoerenze creano dubbi e vaghezze, il che a sua volta significa che chiunque stia mantenendo il codice ora deve indagare se le funzioni "è" e "ottieni" stanno facendo la stessa cosa ... o no ... perché uno di loro è incoerente con il resto del codice.