Spot on, Ryan! Long diffs have a higher chance of a random LGTM occurring than smaller diffs! Because I self-review my PRs before requesting reviews, I'm encouraged to make those smaller diffs anyway. 😃
What do you do when you have dependent changes? I'll reuse your example:
> imagine I have a simple server <> client setup and I want to log info from the client in the backend. Here's how this might look:
> Diff #1 - pass field from client in request to the server
> Diff #2 - add the new field to the logging event schema from the backend
> Diff #3 - read the field from the client request and log it using the new event schema
In this example, suppose you don't know the exact format you need in the server until after writing diff 3. Would you code the entire flow and then break it into 3 stacked diffs?
I agree, small diffs are better than larger ones, but with smaller diffs you could lose context of the much larger change. How does a dev know the full picture.
Stacked diffs offer the opportunity for larger changes to be reviewed as well as smaller ones, so consider utilising this for a more well rounded approach to staying small, but keeping context 😄🙌
Might be exaggerating, but I’ve always said that the best diff/PR size is the one that fits the smartphone screen or possible to review on the go :)
Spot on, Ryan! Long diffs have a higher chance of a random LGTM occurring than smaller diffs! Because I self-review my PRs before requesting reviews, I'm encouraged to make those smaller diffs anyway. 😃
Great article Ryan! This exact topic is on my list to cover as well. An added bonus is small CLs can be used to pad your ~coding stats~ :P
What do you do when you have dependent changes? I'll reuse your example:
> imagine I have a simple server <> client setup and I want to log info from the client in the backend. Here's how this might look:
> Diff #1 - pass field from client in request to the server
> Diff #2 - add the new field to the logging event schema from the backend
> Diff #3 - read the field from the client request and log it using the new event schema
In this example, suppose you don't know the exact format you need in the server until after writing diff 3. Would you code the entire flow and then break it into 3 stacked diffs?
How to break changes, if it is features development having lot of change to merger master through CI/Cd
I agree, small diffs are better than larger ones, but with smaller diffs you could lose context of the much larger change. How does a dev know the full picture.
Stacked diffs offer the opportunity for larger changes to be reviewed as well as smaller ones, so consider utilising this for a more well rounded approach to staying small, but keeping context 😄🙌
Good luck with branch management and rebasing!
Any suggestions on how to manage it? For example - should diff contain complete feature/bug fix or can be partial?