undefined | Better HN

0 pointsCthulhu_3y ago0 comments

And to extend the last point: before it is merged, to keep the mainline in a releasable state:

1. Continuous deployment means your mainline is sacred and always in a releasable state.

2. Unit tests and automated verifications only tell part of the story

3. Churn should be avoided (e.g. fixing code style issues); if fixes are made before it enters the mainline, it is avoided.

4. Code reviews should be asynchronous, because pulling someone out of their flow to switch to doing a code review is rude and unproductive.

0 comments

4 comments · 2 top-level

pyrale3y ago· 2 in thread

> Churn should be avoided

One of the big Taylorist mistakes of our industry IMO. It is OK to have churn, and it's certainly better to have a little too much than too few.

ilyt3y ago

Disagree. Mixing random style fixes in-between actual code just makes reading changelog more annoying. Sure, if you are refactoring some function put format changes with it but that's the most you should do.

If you want to make those:

* make it in separate bunch of commits * make sure team uses tooling that will not allow new style problems to happen, like mandating certain formatter with certain settings before each commit. Most editors have hooks to do it automatically, and if they don't, Git have them too

It also makes git blame less useful althought it now have options to ignore moved code or whitespace changes so it isn't as much of a deal now.

pyrale3y ago

It seems like your definition of "churn" is "all those petty and annoying things I shouldn't be concerned with or can be easily automated away". By that definition, of course, churn should be avoided when possible.

However, plenty of useful changes also qualify as churn, for instance:

* renaming stuff

* extracting a function to split a block that may have been fine for the author, but that you found hard to read. And yes, sometimes, reviews don't catch all those.

* Add a comment to provide context to an algorithm after you talked with business

All of these things (and others) are pretty valuable, and the cumulative effect of reducing friction against these changes add up to much better codebases, with less places where no one wants to work because of abandonment. This kind of light touches should take a couple minutes while reading your codebase, not half-a-day because you need to fill a PR and wait for someone to be available.

mrits3y ago

"Continuous deployment means your mainline is sacred and always in a releasable state."

Well if that is true why not just stop there?

j / k navigate · click thread line to collapse