TL;DR notes from articles I read today.
Why do so many developers get DRY wrong?
- Humans are good at pattern matching and developers do an even more excellent job of it. The more code you read/write, the more patterns you see coming up. And it is tempting to take those patterns, name them properly and keep referring back to them.
- It feels really good to DRY up the code. It is really like the lowest common form of refactoring. There were days you copy-pasted code because you did not have a hang of subroutines/functions and now that you have the experience and skill to condense this code, you go ahead and do it because it suddenly feels simpler & cleaner.
- ‘It was repetitive’ can be a trap. DRY is commonly misunderstood and leads to misguided refactoring.
- DRY has come to mean ‘don’t cut and paste’ but the original idea behind ‘don’t repeat yourself’ had to do with knowledge, and not code. The name is itself a leaky abstraction.
Full post here, 3 mins read
Great code reviews - the superpower your team needs
Lessons from Shopify
- Keep your pull requests small (200-300 lines, or one single concern) so the reviewer won’t procrastinate or be interrupted and can dive deeper, yet respond to you faster. This way, you will also get more independent review units and therefore better quality review, affect fewer people and need to call on fewer domains of expertise, make it easier to identify problems for rollbacks, and separate the easy stuff from the hard.
- Use work-in-progress (WIP) or draft pull requests (PR) to elicit early feedback that validates your choice of algorithm, design, API, etc., to ensure you are heading in the right direction before you start to build. This way you don’t waste time on documentation and details if you got it wrong.
- When you are the reviewer, follow the principle of strong opinions loosely held, and focus on the code rather than the person. As a reviewer, take co-ownership of the code, frame comments as suggestions rather than instructions, and also offer positive feedback. As an author, assume the best intention rather than taking comments personally.
- Pick the right person as reviewer: someone with context on the feature or component you are building, someone with strong skills in the language, framework or tool you use, someone with opinions on the subject, someone who cares about the outcome of your project, someone who needs to learn about this (in case of a junior reviewing a senior’s code).
- Use a PR template where the description includes why the PR is necessary, who benefits from this, what can go wrong, what other approaches you considered, why you settled on this solution, and what other systems it can affect.
Full post here, 10 mins read
Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().
Top comments (1)
that's sounds good