Read on Twitter
I’ve reviewed over 750 PR’s at AWS. As my team’s tech lead I provide insightful feedback and enforce a high code quality bar.
But as a jr engineer I couldn’t review code. I didn’t know where to start, what to look for or how to comment.
Here’s how I review PR’s.
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧵" title="Thread" aria-label="Emoji: Thread"> https://abs.twimg.com/emoji/v2/... draggable="false" alt="👇" title="Rückhand Zeigefinger nach unten" aria-label="Emoji: Rückhand Zeigefinger nach unten">
But as a jr engineer I couldn’t review code. I didn’t know where to start, what to look for or how to comment.
Here’s how I review PR’s.
They& #39;re an excellent coaching opportunity. Insightful feedback accelerates learning and growth.
Quality code strengthens readability and system understanding. This is a force multiplier for the team’s long term feature velocity.
I understand principles like SOLID, DRY and KISS.
I’ve read the Clean Code book. I understand the importance of naming, small functions and logical control flow.
Insightful feedback requires a deep understanding of the change. I prevent my eyes from glazing over a line of code I don’t 100% understand.
I pretend there& #39;s a flaw hidden in the code; I& #39;m the detective.
I scan through the PR to find the critical piece of implementation. This could be the API entry point or the refactored data access layer.
I start reading. I write comments as I go, knowing I& #39;ll need to fix them later.
I follow function calls. I jump around. I read existing code for context. Every line of code is a puzzle piece.
I often end up reading the same code 3, 4, even 5 times. I read until the entire puzzle forms in my brain.
This comes only after I achieve deep understanding.
I ideate unit tests as I read the implementation. I ensure the edge cases are covered when I read the test code.
I comment on the code, not the person. I avoid using “you” or “your.” I prefix nitpicks with “nit.” I phrase most comments as questions or suggestions.
I leave at least one positive comment. (I sometimes forget to do this; I shouldn’t.)
I write comments while reading. But I rewrite many of these comments after deep understanding.
Each comment explains the problem with the code, the reason why it’s a problem, and how the author can resolve it.
I hold my teammates to a relentless high standard. I give a [kind, accurate] comment even with minor confusion.
But I understand perfection is a pie in the sky. I approve if it works, and/or it only has a few nitpicks.
The above steps https://abs.twimg.com/emoji/v2/... draggable="false" alt="👆" title="Rückhand Zeigefinger nach oben" aria-label="Emoji: Rückhand Zeigefinger nach oben"> will help you become a better PR reviewer. They’ll deepen your understanding of the code and help develop other team members.
What& #39;s your thought process during code reviews? I’d like to hear it!
What& #39;s your thought process during code reviews? I’d like to hear it!
