12 Comments
Feb 15Liked by Ryan Peterman

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 :)

Expand full comment
Feb 11Liked by Ryan Peterman

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. 😃

Expand full comment
author

> I self-review my PRs before requesting reviews

This is great Akos, every engineer should be self-reviewing their PRs before sending them out

Expand full comment
Feb 10Liked by Ryan Peterman

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

Expand full comment
author

Hahah true, love seeing the count go up

Expand full comment
Feb 13·edited Feb 13

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?

Expand full comment
author

> Would you code the entire flow and then break it into 3 stacked diffs?

That’s correct. I’ll get it all working together on my local in a case like this. Then I’ll selectively add changes to each commit for the reviewers sake

Expand full comment

How to break changes, if it is features development having lot of change to merger master through CI/Cd

Expand full comment

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!

Expand full comment
author

Yep, love stacked diffs. Great for breaking down features into sets of separate diffs

Expand full comment

Any suggestions on how to manage it? For example - should diff contain complete feature/bug fix or can be partial?

Expand full comment
author

I'd recommend that each diff do just one thing. For 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

We could've done (2) and (3) in the same diff, but it's cleaner if we separate them out.

Expand full comment