DEV Community

Shalanah Dawson
Shalanah Dawson

Posted on • Updated on

The Self-PR - And How Your Team Can Benefit from Them

Before I ask for a review on a PR, I make sure that my code is production-ready and fully reviewed by me. I developed this mindset by having to review my own PRs and having no code review safety net.

If you adopt this mindset, your code will be less buggy, and future-you will be thankful because of how clear your code is.

If you have reviewers, their PR comments will have more substance, if they have reason to write anything at all.

The key takeaways

Re-read your code changes in a PR as if you were reviewing it for the first time. This is not unlike cleaning up for a house guest. Is there a confusing corner of code? Fix it! Future-you will be thankful you did.

If you have a reviewer, only have them look at your PR once you have given your full stamp of approval on the code legibility and functionality.

You're still not an island!

This isn't to encourage coders working in silos. This is to encourage taking responsibility for the code you have chosen to write.

Ask questions as you write code on how it should be written if you're not sure. Confirm the code does what you and everyone expects it to do as you're solving problems.

Here's my full process for Self-PRs

(and PRs in general)

  • Write code quickly that does everything you want it to do (locally)
  • Do a clean up pass (locally)
  • Be happy with the functionality of the code (locally)
  • Push your branch
  • Create a PR (but don't yet ask for a reviewer)
  • Read your code changes as if you were reviewing it for the first time
    • If anything is unclear as you read... change it!
    • Rename vars/funcs
    • Create functions to separate out logic, if necessary
    • Check spelling and remove not needed code
    • If you pause too long when reading your code after doing the above changes, write a comment
  • Document your PR + testing instructions as you validate both
    • Test browsers
    • Run and modify tests
    • Other click through cases
  • When you feel that your code is production-ready...
    • Ask for someone to review your PR -OR- accept your own PR

When should I do this?

I do this on all my PRs except my for fun side projects.

Closing

I hope this method makes code reviews smoother and faster for you and your coworkers.

Do you practice this mentality when making PRs?

Have you ever been completely responsible for your code (and only you)?

Top comments (4)

Collapse
 
13roy profile image
13ROY

This is a really interesting and I think important point. I always try to review my own work, but normally within my IDE.
Conducting a review as if it was someone else's code, within your favourite code review tool should give you an outsider's perspective on your work. I am going to adopt this approach going forward.

Thanks Shalanah :)

Collapse
 
tamouse profile image
Tamara Temple

Great post, Shalanah!

Most of this is my personal practice, even on my side / learning projects. I've chatted with other team-mates about it as well; our current project tries to self-review before requesting a code review.

Collapse
 
tamouse profile image
Tamara Temple

p.s. - do I see a future lightning talk at JS MN? 😁

Collapse
 
jessekphillips profile image
Jesse Phillips

I think this is important and also why I recommend cleaning up history to