Live data from Hacker News

A study of Google's code review tooling (Critique)

engineercodex.substack.com

151–160 of 302 posts

Re: A study of Google's code review tooling (Critique)

#151

Wait... this looks like Gerrit with extra plugins The experience can be nice sure, but Gerrit is not something I'm too enthusiastic about (and yes, Github is better in some aspects, Gerrit is more configurable though and it seems it is smarting tracking "non official" merges)

Gerrit is a released version of Google's code review tool called Mondrian--the predecessor to Critique. Critique is basically Gerrit 2.0, although Gerrit has evolved somewhat independently.

There was also Ritveld (ugh) before Gerrit

And yes, I won't say much about Ritveld besides: ugh

Re: A study of Google's code review tooling (Critique)

#152
I don't see it mentioned, but there's a recent addition that greatly improved my turnaround time to review incoming CLs: A prompt will show up in the corner about the next pending CL that you can approve, when you give LGTM to the CL that you are reviewing.

It's kind of like those "Customers who bought this also bought" prompts on e-commerce websites. Only here it slightly nudges you to have a "CL review streak" and clean up your review queue.

Re: A study of Google's code review tooling (Critique)

#153

Earlier quoted context omitted.

> I have Github connected to Slack; if someone needs my review I get a message and can have it done within 5 minutes. Do you not do anything else? If I'm working on something else, I'm not getting to any new task within 5m (at least, not without a net loss of productivity to reload context)

If you're writing code and you get a review request and ignore it, you are literally preventing value from being shipped while you work on making some abstract idea a reality. Usually, the code review is the very last step before value becomes available to the business. There is absolutely no reason to delay a code review in this case, none, whatsoever. Even if it isn't the last step, you're delaying the chance for a…

>There is absolutely no reason to delay a code review in this case, none, whatsoever.

"I'm in a meeting with business owners". There, now either value is delayed or egos from the ones gaining value is bruised. Guess which one usually prevails?

We don't have to be this dramatic here.

Re: A study of Google's code review tooling (Critique)

#154

Earlier quoted context omitted.

This kind of greedy optimization approach is fine if all you’re just trying to maximize velocity, but it starts showing cracks on a long enough timeline in sufficiently large or complex projects. Speed without alignment on direction leads to ugly, tangled messes. As with most quality issues, the key is to try and surface quality problems as early as possible. Finding a bug in prod is worse than finding it in PR is wo…

> In my team we prefix nitpicky comments explicitly with “nit:” and it’s up to the author to decide what to do with it This is different from what the OP is talking about. I've worked at places where staff engineers seem to have been rated on number of comments left on PRs... they were typically somewhere between nit picky and useless, with the occasional person directly contradicting feedback they'd given in a previ…

> rated on the number of comments

It sounds idiotic.

It is unrelated to the question whether short-term (one PR) only reviews are preferable over reviews that recognize the reality that it is not the last PR ever and therefore more long-term view may be useful.

Re: A study of Google's code review tooling (Critique)

#155

Earlier quoted context omitted.

I've received plenty of negative feedback on the internet for this (and up to now, discarded all), but I really don't think acceptance review is the correct time for guidance. Yes, juniors need guidance. That means you must read their code, and talk to them about it. They also need real-world feedback. They do really need you not managing all of the interaction they have with the real world. Now, what you can not man…

So, when is the right time?

At some time you plan for it. Preferably a calm time, not one they are waiting a decision from you.

E.g. before they start implementing a feature is better than after they finish it.

Re: A study of Google's code review tooling (Critique)

#156

Earlier quoted context omitted.

The alternative is a big design upfront?

Generally, it goes something like this imaginary Slack convo: Me: I think we are getting events from SQS out of order and that’s why we are seeing some weird synchronization issues. What do you think about sending events to the regular queue and a FIFO queue at the same time and comparing them? Team: How would that work? Me: Since we are using a single threaded consumer here, I think we can simply override the transp…

> There won’t be any surprises in the review.

There can always be surprises. Sometimes when you see something implemented you can get a « click » as to why another solution would be better. It happens to me regularly both on the receiving and giving end of this and it’s rarely a big deal. Most of the time it happened to me, I could reuse the functional tests I had written and parts of the code anyway.

Reworking on something so that it’s better is never a waste of time, and it’s always better to do it before it reaches Prod.

Re: A study of Google's code review tooling (Critique)

#157

I’m always surprised to see the totality of support for this workflow. My biggest gripes were: - Owners - Readability review (or really the 18month queue to get Java/python readability) Although seemingly innocuous, this made maintaining internal libraries very challenging. There was no way to update every call site of your library in an efficient way. Tools like Rosie were added on top so that you could shard your P…

The owner system is kind of a necessary evil to enforce reviews from the domain experts. I've seen lots of junior engineers who just want to submit their code and move on and I appreciate their productivity, but there have been so many cases where a seemingly innocuous change eventually led to a million dollars incident and only those domain experts could've detected it. And I've still gotten lots of pagers exactly due to this reason even with this enforcement thanks to someone able to find a relatively lenient reviewer on the codebase with broad ownership.

> There was no way to update every call site of your library in an efficient way.

There are global approvers. It's not super easy to get their approval (you need to go through the large scale change process), but getting each owner's approval will be exempted if you can get the one.

Re: A study of Google's code review tooling (Critique)

#158

Earlier quoted context omitted.

No, it's not and there is a ton of literature (even entire books) written on why it isn't the time to bring this up during a review. For starters, it results in a waste of time for literally everyone involved: 1. The person writing has to rewrite it (probably). 2. The reviewer could have sat down with the person before a single line of code was written. 3. Anyone else reviewing just wasted their time because it will…

1. That's the point. It's not up to standard 2. They could but they usually don't. It's fine to sit down and make sure they understand some esoteric structure within a system I owj I'm not going to sit down with someone else to make sure they use for each loops unless it's a very new junior (i wouldn't block that in most code reviews anyway unless the code was legitimately painful to read, but every company is differ…

Anyone who has ever come along in a code review and told me my code “isn’t up to standard” will inevitably start a very long game of attrition with me. Here’s the thing: there’s no such thing as “standard” software architecture (until someone writes a new kind of software architecture called “standard”).

I’ve seen and used everything from MVC to DDD to TDD to MVVC to whatever React is to reactive to event-oriented to actors to whatever you can imagine. There simply isn’t a “standard” way to do anything in this industry. If you hired me, you hired me for these different perspectives on problem solving, and that goes for all of us.

A code review simply isn’t the place to enforce your unique perspectives on someone else.

Sometimes, there is simply a better way to do things. These might even be new ideas in the code base. If it looks like it is, hopefully the author will bring it up with the team beforehand. If the reviewer changes their mind in the code review… well, that’s not the authors problem. The reviewer should rewrite it and the author review it.

Actually, that’s exactly what I suggest if someone ever tries that with me (usually when I’m the new guy). Please submit your own PR showing me how it’s done. I’ll move on to another ticket.

Usually, about half way through their implementation, they’ll see why I did it the way I did it and approve my PR. It only takes one time before they start asking “why” instead of assuming they know everything; every line of code exists for a reason, after all.

In one case, one specific dude (bless his heart) kept blocking PRs after we discussed everything before hand. I had to get HR involved, and other engineers. Dude just didn’t like being wrong and would throw tantrums when he was. He eventually got fired after people realized they could do what I was doing to stop the nits he said was a blocker. Nobody cared if a variable should be renamed from “SameFactory” to “EqualFactory”.

Ah, but code quality! It’s so subjective. High code quality, to me, is easy to maintain code. Is the intention clear, do the comments reflect reality, is it easy to read, but more importantly, easy to change? Will changing a line in the module break 15 other sibling modules? God I hope not. Dependencies should be obvious. And, no, I’m not writing an interface if there is exactly one implementation. That’s ridiculous.

For some people, they want layers. More layers of abstraction than a layered cake on a wedding day. To them, that’s good code quality! Some people think high code quality is beautiful code. The kind you frame and put over your fire place to admire with a glass of wine.

There’s no objectively “high quality” code in existence.

Re: A study of Google's code review tooling (Critique)

#159
post #131

Earlier quoted context omitted.

> Things like "I find this code very hard to follow, and I think it could be made easier" is also objective The "I" in that sentence suggests this should be considered subjective. And that's I think the cleave-point between gating and non-gating: "Other people have already agreed on this" vs. "In the moment, I, a single code-reviewer, think this name could be improved."

It's not an exact science and there's a grey area of course, but what I have in mind is mostly code that's just needlessly confusing in ways I think very few would disagree with. I can't really think of a specific non-trivial example at the moment, but just like natural language I do think some code can objectively "hard to follow", even if that's somewhat vague and not strictly defined. Other factors are if I'm the…

I can't speak to everyone's experience, but I can say how teams I've been on have handled that sort of thing.

When it's not explicitly documented in the style guide and it doesn't violate some agreed-upon convention (which needs to be gleanable from within the file itself or it's not an agreed-upon convention... No "We know it was always done like that but now we're doing this," if you want to change it, you do the heavy lifting of putting together the consistency refactor to bloody well change it...), it's a suggestion. Non-blocking.

But taste does matter, so if an engineer is observed by their peers to be ignoring too many refactor suggestions with no explanation, it becomes an issue with the project lead and that engineer might get put on a shorter leash (in the form of "These are normally non-blocking... Except for Steve, he wouldn't know consistent and terse naming if it bit him on the FaceManagerFactoryService). It required enough human touch to understand what each others' strengths and weaknesses were, so more expensive in terms of mind-space, but I think it generated better results overall.

(And as the one whose code is reviewed: if you have a good reason not to change something and can express it, fine! You're a team member too and your opinion on how things should be also matters).

Re: A study of Google's code review tooling (Critique)

#160

Earlier quoted context omitted.

1. That's the point. It's not up to standard 2. They could but they usually don't. It's fine to sit down and make sure they understand some esoteric structure within a system I owj I'm not going to sit down with someone else to make sure they use for each loops unless it's a very new junior (i wouldn't block that in most code reviews anyway unless the code was legitimately painful to read, but every company is differ…

Anyone who has ever come along in a code review and told me my code “isn’t up to standard” will inevitably start a very long game of attrition with me. Here’s the thing: there’s no such thing as “standard” software architecture (until someone writes a new kind of software architecture called “standard”). I’ve seen and used everything from MVC to DDD to TDD to MVVC to whatever React is to reactive to event-oriented to…

I'd like to agree. But there is one part of that distinction that is real: there is such a thing as low quality code.
Post reply on HN