Read on Twitter
When I was a jr engineer at AWS my PR’s went through 100+ comments and 7+ revisions due to poor code quality. The friendly, helpful feedback helped me improve.
Now as a mid-level I tend to ship code in <= 2 revisions with minimal comments.
Here’s how I’m doing it.
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">
Now as a mid-level I tend to ship code in <= 2 revisions with minimal comments.
Here’s how I’m doing it.
We read code 10x more than we write it. Our code must be understandable so our team can maintain and add features.
Poorly written code causes PR churn, which results in delayed delivery and can block other team members.
A good PR starts before any code is written. The task should be small, resulting in an easily reviewable PR.
Bad task: UpdateWidget API
Better: split into 4 separate tasks - UpdateWidget model; AuthN/AuthZ; input validation; implementation
- Pull down the latest code.
- Ensure local builds and tests are passing.
- Configure my IDE to working smoothly.
This saves time and headaches while coding.
Before implementing UpdateWidget, I look in the codebase to understand the current paradigm.
What design patterns are being used? Is there code from GetWidget or UpdateItem that should be reused? Will refactoring be necessary?
I write skeleton interfaces, classes and methods for my code structure.
I realize I won’t get this perfect, and may need refactoring later. But it gets me started.
I try to use decent names. This way I know where things are when I read, iterate and refactor later.
I write automated unit tests. Manual testing during this step is tedious, time consuming, and leaves the door open for bugs during refactor.
This is where I name intelligently. I segment the code into small functions and finalize my class structure. If anything looks weird or awkward, I search for an elegant solution.
This includes the implementation *and* the unit tests.
I make sure all the classes are working together properly. I cover basic functionality. I don’t rely on catching granular edge cases with this step - these should be covered by the unit tests.
I hold myself to a relentless standard. I often discard and recreate the PR with even a single nitpick.
In the summary I include relevant Jira or trouble tickets. I document manual testing steps.
I make sure I fully understand a teammate& #39;s perspective before addressing their comments in a new revision.
Even if their comment is wrong, I understand that it’s likely due to a lack of clarity in my code.
The above steps will improve your code quality and drive down churn on PR’s. This allows you and your team to deliver software faster.
What are some of your tips to improve your own code quality?
What are some of your tips to improve your own code quality?
