jessitronWhen you refactor during a change, you make the change bigger.
When you refactor before the change, you make the change smaller.
- in a talk by Jason Swett
Jos Koelewijn@jessitron
How? I usually discover the need for refactor while working on the change.
Do people just add another task to their PBI, and create an extra PR with added review cycle?
I'd much rather do refactor and change together, while pair programming
How? I usually discover the need for refactor while working on the change.
Do people just add another task to their PBI, and create an extra PR with added review cycle?
I'd much rather do refactor and change together, while pair programming
@Jkw oh god no, not another task. just do them in separate commits.
Discover the need while making the change. Stop making the change (git reset), do the refactor, commit (maybe multiple times), then make the change. Tell people in the PR which commit to look at closely.
Sadly github doesn’t work well with stacked diffs, so this is the best we can do
@jessitron
Ooh that makes lots of sense yes, I usually do that. My clients mostly use azure devops, and there it's also not too clean to look at individual commit diffs. The commit just ends up being part of the whole PR, and usually will be reviewed as one change, even though a refactor could be in one or a few specific commits... Gets lost in there mostly. That's why I assumed separate PR's.
Ooh that makes lots of sense yes, I usually do that. My clients mostly use azure devops, and there it's also not too clean to look at individual commit diffs. The commit just ends up being part of the whole PR, and usually will be reviewed as one change, even though a refactor could be in one or a few specific commits... Gets lost in there mostly. That's why I assumed separate PR's.
@Jkw if it’s easy enough to make a PR on top of a PR, that’d be better, but we do what we can