Traveling Coderman
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
Dhruva ⚙️@jessitron When you refactor without a real reason, you mostly add bugs.
Stories from the trench…
Matt Stine@hackworks @jessitron when you refactor and change the perceptible behavior of the system, you didn't really refactor. You just changed stuff.
Oops. Not you@jessitron re-factoring before change — helps to make it readable for yourself and might be more readable for newcomers.
Re-factoring after — helps to get review on change faster from those who are familiar with current codebase. And it also removes risk from change being blocked by re-factoring and/or need to fix/change re-factoring it is based on.
Re-factoring after — helps to get review on change faster from those who are familiar with current codebase. And it also removes risk from change being blocked by re-factoring and/or need to fix/change re-factoring it is based on.
@jessitron The difficult thing is to realize during the change, that a refactor would be beneficial and then to have the guts to throw the changes so far away and do the refactor beforehand.
Jon Lauridsen@jessitron love this. Matches the energy of “make the change easy, then make the easy change”
Ted M. Young@jessitron Some of my favorite refactorings are Prepare Refactorings. 😍
Julian Doherty@jessitron related Kent Beck:
“make the change easy, then make the easy change”
Dawn Ahukanna
Application refactor: business gets 6-figure check and progress updates and no visual changes but 100% system operation improvement
Business: I want my money back and burn the progress updates
https://giphy.com/gifs/foilarmsandhog-foil-arms-and-hog-fah-conor-mckenna-ej4fI1GF5M07nQbRLo
Conor Mckenna Fah GIF by Foil Arms and Hog - Find & Share on GIPHY
Discover & share this Foil Arms and Hog GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.
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
Javier Pérez@jessitron or, as somebody named Kent once said: "First make the change easy, then make the easy change" 😋