What is the best way to code review a work-in-progress?

Question

I am working on a feature with a system that I am unfamiliar with. The feature is not ready, but I want to show the code to my team (who is familiar with the system) so they can give me early feedback. We are a fully remote team.

Making a pull request on GitHub so they can see the differences seems like the easiest way to do this. But then I will be creating a pull request that is not ready to be merged. This sounds dirty to me for various reasons, such as it muddies up the PRs, and someone may accidentally merge it.

I could just point them to a branch, but then they would have to find the diffs themselves, which not everyone knows how to do. They are also much less likely to review the code at all. I am hoping to let them review the code on their own time, instead of setting up yet another meeting.

Is there a standard for getting early feedback on work-in-progress features?

Answer 1

GitHub allows for PR to be in a "draft" state. Your team can see the differences, and even comment on it, but it's still obviously a work-in-progress, and cannot be merged until you click a "ready for review" button, which makes it mergeable.

I'd also say that if it's a work-in-progress, give them a clue as to what you want them to focus on, such as saying "I'm most concerned about the payment processing algorithm in SomeClass". That way they don't spend time reviewing other parts of the code that are subject to change even as they review.

See Draft Pull Requests and Convert Pull Request to Draft.

Answer 2

This comes down to the tools that you are using.

Since you mention GitHub, I'll point out that GitHub supports draft pull requests. Other tools may also have similar capabilities. The purpose of draft pull requests is exactly what you point out - to let people have a good view of the pull request yet prevent merging until it's ready.

Not all tools support this, though. Bitbucket, for example, doesn't. However, you can configure tools like Bitbucket to prevent merging if someone adds a task. For a draft pull request, a developer can open the pull request and add a task. Not assigning assignees to review can also indicate that it's a draft and make it less likely to merge.

For developers, though, I don't think that pointing them to a branch and asking them to use diff tools to compare would be a problem. This kind of functionality is built into a lot of mainstream IDEs already.