Alternatives to Pull Requests?

Curious to know what possible alternatives might be out there instead of using Pull Requests for code review. I’ve read that pair/mob programming is one substitute but I’m not sure of the practicalities of this approach, especially since we’ve moved more towards remote teamwork now.

Is anyone NOT using Pull Requests as a way to review code ?

2 Likes

Corresponding tweet for this thread:

Share link for this tweet.

2 Likes

Great topic Finner, I’m interested too!

I haven’t used it yet, but people use #tmux for things like pair-programming:

1 Like

the JetBrains IDEs (IntelliJ for Java, Scala, Clojure: PyCharm for Python: & WebStorm for Javascript, Typescript, HTML, CSS) have an integrated feature called Code With Me to allow teams to pair program. I haven’t tried it yet but will do so very soon. Will let you know.

With tooling aside then, my understanding is that pair programming is considered sufficient as code reviewing and we can “skip” Pull Requests and push direct to master. It kind of feels risky but PRs are not silver bullets either.
I would love to hear from anyone who is doing this (bypassing PRs) or playing around with the idea.

3 Likes

We tried out the IntelliJ plugin, Code With Me, to see how it works. We didn’t use it to do any particular task though, we just wanted to see how to get a session going and how it performs in general.

  • the connection dropped constantly during one session but was good on a second session
  • both parties could edit the same file or different files during the session

Next step is to use it for a PR review or have a pair programming session. I’m thinking a kata would be a good way to give it a proper test drive.

1 Like

There is also VSCode LiveShare.

That said, I’ve found that the best pairing/mob session have been when following the driver (person typing)/navigator (person telling driver what to do) approach. To do this all you need is screen share capabilities over a video conference. It also have the benefits of everyone being able to use their preferred editor/IDE in case the team don’t all use the same already.

Many companies have a requirement of having a documented peer review process in place so sometimes you still have to go through the create pull request, approve, merge process but that step is simply as one person pushing and the other one approving if you have already paired.

1 Like

hi @Hallski - yep, we’ve also tried the VSCode LiveShare, again it was just to see it working so we haven’t gone through a proper session yet.
The driver/passenger model can work but you need to have both parties engaged obviously. In my opinion, the objective is to get all parties understanding the code, not just getting the code to work.
We don’t do much pair programming on our team, though. We probably do more “show and tell” and that doesn’t help spread knowledge. It’s too passive. Not enough “hands-on” or muscle memory. So maybe these tools will help us, especially when working remotely.

1 Like

Yeah, the reason driver/navigator works better is that both are engaged and focused.

Otherwise it’s very easy to get distracted (or doing something in parallel which is why I am not a fan of shared editing). Then it turns into something more similar to sitting next to each other rather than working together.

The most important aspect is that the person with the keyboard shouldn’t take any decisions/actions without first talking to the other(s) or you risk them disengaging.

1 Like

that the person with the keyboard shouldn’t take any decisions/actions without first talking to the other(s)

That’s a good rule of thumb

2 Likes