Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ship Small Diffs

blog.skyliner.io

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Ship Small Diffs

#11

Post by toddsiegel »

Generally, I like the middle ground of reasonably small branch sizes and small, well-organized, well-written commits.

Walking through a half dozen or so commits in a PR is still manageable.

Too many small things deployed over time can be a pain to roll back too.

On the flip side, huge change-the-world deploys are bad too.

It's a balancing act of managing the initial feature size, getting it out, layering on more in subsequent releases.

Where tiny deploys work really well is when deploying refactorings, little housekeeping chores like upgrading libs. If, while working on a feature or bug, I need to add a missing test, refactor, or upgrade a lib, I extract those commits out and deploy them ahead of time when possible. That way the resulting feature branch is very focused on the feature at hand.

Re: Ship Small Diffs

#12

Post by xyzzy_plugh »

davidkellis wrote: post #10

This strikes a chord with me, but I'm coming at it from a different angle. Does anyone else encounter very large diffs as standard operating procedure in golang codebases? Here I'm considering "very large" to mean 500+ lines changed - however github computes lines changed. I mean, I'm looking at this from the perspective of someone who contributes primarily to Ruby codebases. It's understandable that there would be a…

Anecdotally, I agree it seems that Go codebases have considerable churn compared to other languages.

That being said, the churn is typically much easier to review and understand, and thus have confidence in, especially compared to Ruby or Python.

Re: Ship Small Diffs

#13

Post by tonyhb »

davidkellis wrote: post #10

This strikes a chord with me, but I'm coming at it from a different angle. Does anyone else encounter very large diffs as standard operating procedure in golang codebases? Here I'm considering "very large" to mean 500+ lines changed - however github computes lines changed. I mean, I'm looking at this from the perspective of someone who contributes primarily to Ruby codebases. It's understandable that there would be a…

The expressiveness of a language directly impacts the amount of code you need to write for a feature.

Go is a concise language but it's not expressive - you'll write 4 lines to call a func and check an error.

This means that PRs are inevitably going to be larger than a language like Ruby or other languages with metaprogramming.

Re: Ship Small Diffs

#14

Post by kornish »

davidkellis wrote: post #10

This strikes a chord with me, but I'm coming at it from a different angle. Does anyone else encounter very large diffs as standard operating procedure in golang codebases? Here I'm considering "very large" to mean 500+ lines changed - however github computes lines changed. I mean, I'm looking at this from the perspective of someone who contributes primarily to Ruby codebases. It's understandable that there would be a…

This definitely mirrors my experience on our Go codebase. Getting nontrivial features out the door generally requires hundreds of lines of code at a minimum, and sometimes thousands. We've taken to branching off of branches to keep code review moving quickly, but that creates new problems like cascading rebases all the way back down.

If there's some secret to architecture or tooling (e.g. feature flags) that people use to keep PR size down in Go codebases, would love to hear it.

Haven't worked in an enterprise Java setting before but would be curious to compare diff size there.

Re: Ship Small Diffs

#15

Post by aytekin »

Continuous Deployment is scary at first but once you have good test coverage it is safer than big releases.

If a developer is creating one bug per day. Is it better to release it every day or is it better to wait 1 month and release 30 bugs all at once?

Continuous improvements are also highly motivational. The difference is between saying "We can fix that at the next release" and losing the motivation to fix it later and saying "Just shipped the fix" and feeling great.

Re: Ship Small Diffs

#16

Post by mden »

This is something I've had a lot of problems with. I understand the benefit of small diffs, but I can't seem to find a way to really apply this for any actually meaningful changes. In my experience I would spend some time coming up with a system of multiple abstractions that are interdependent and then getting single logical commit for proof of concept would require hundreds of lines. Splitting the abstractions into separate commits would be confusing so I don't think that's good. Maybe I should stub functions a lot more aggressively and truly aim for minimal. The other problem is when you are replacing an abstraction in an already large code base, the raw number of changes required could easily be in the hundreds or even thousands of lines.

Re: Ship Small Diffs

#17

Post by Vendan »

tonyhb wrote: post #13
davidkellis wrote: post #10

This strikes a chord with me, but I'm coming at it from a different angle. Does anyone else encounter very large diffs as standard operating procedure in golang codebases? Here I'm considering "very large" to mean 500+ lines changed - however github computes lines changed. I mean, I'm looking at this from the perspective of someone who contributes primarily to Ruby codebases. It's understandable that there would be a…

The expressiveness of a language directly impacts the amount of code you need to write for a feature. Go is a concise language but it's not expressive - you'll write 4 lines to call a func and check an error. This means that PRs are inevitably going to be larger than a language like Ruby or other languages with metaprogramming.

I think you have those backwards. Concise is expressing an idea in less words, expressiveness is the breadth of ideas that can be communicated. Go is not concise and does not try to be.

Re: Ship Small Diffs

#18

Post by Animats »

Birth defects are forever. If the design has a problem, "small diffs" won't fix it. That's the trouble with the "continuous hacking and integration" approach.

Re: Ship Small Diffs

#19

Post by avenoir »

We're pushing fairly large changes once a week from multiple team members. What has really helped is having comprehensive unit, integration and end-to-end tests. We run first 2 on every check-in into main branch. Then run all 3 after moving from QA to Staging. And finally do smoke tests in Staging. The only problem with this approach is of course spending ungodly amount of time writing tests and infrastructure/tooling to support automated tests especially end-to-end. But this hasn't failed once yet.

Re: Ship Small Diffs

#20

Post by OJFord »

notacoward wrote: post #5

Um, no. Keeping diff sizes smaller is nice, but asking for "a few dozen lines" most of the time is too doctrinaire. In many codebases, especially those that are older and larger, even a fairly straightforward enhancement can require a few dozen lines of new code plus even more modifying callers or hooking things together in other ways. Oops, already over the limit. Breaking up patches can even make them less coherent…

Agreed - arbitrarily splitting into two commits just because otherwise you'd break the magic 'few dozen lines' limit is just making git management harder: rebasing? reverting? checking-out? Are you sure you included all the commits that make up the single logical 'commit' you're looking to rebase on/revert/checkout?
Post reply on HN