TODO: split by topic (code quality, process quality), order by stars
- ★★★ Act with prudence
- technical debt is like a loan: the longer you have it, the worse it gets
- Martin Fowler distinguishes
- deliberate technical debt
- inadvertent technical debt
- add a ticket and ensure it does not get forgotten
- Apply Functional Programming Principles
- referential transparency
- Ask "What Would the User Do?"
- false consensus bias
- assuming other people think like us
- "When you get stuck, you look around, when users get stuck they narrow their focus. It becomes harder to see solution somewhere on the screen."
- spending an hour watching user is more informative than spending a day guessing what they want.
- ★★★ Automate your coding standard
- make sure automatic code formatting is part of the build process
- linter warnings break the build
- break the build if test coverage is too low
- Beauty is in Simplicity
- Before you refactor
- avoid the temptation to rewrite everything
- many incremental changes are better than one massive change
- new technology is an insufficient reason to refactor
- preserve old tests
- ★★★★ Beware the Share
- sharing applied in wrong context increases cost rather than value
- two pieces of code could be accidentally similar, pulling them into shared library can be unwise
- introduces superfluous dependencies
- prohibits independent evolution of those pieces
- maintenance costs for library could be higher
- ★ The Boy Scout Rule
- Try and leave this world a little better than you found it
- a little bit is enough
- fix just one thing before leaving code aside
- care not only for your own code but for the team's code also
- Check your code before Blaming Others
- Choose your Tools with Care
- ★★★ Code in the Language of Domain
- make domain concepts explicit in your code
- Code is design
- software design isn't complete until it is validated with a battery of tests
- ★ Code Layout Matters
- good code layout
- Easy to scan: people are good at visual pattern matching
- Expressive: line breaks and groupings reflect the intention of the code
- Compact format: the more I can get on screen, the more I can see without breaking context by scrolling or swithing files
- ★★★★ Code Reviews
- they say: "you should do code reviews to increase code quality and reduce defect rate"
- common practice is "architect reviews everything" but this leads to overwhelming reviewers, so they can rapidly become the bottleneck in the process
- the real purpose of the code reviews should be to share knowledge
- collective code ownership
- common code guidelines
- instead of looking for errors, review the code by trying to learn and understand it
- introduce review roles to spread the burden across the team members
- one reviewer focus on docs
- another on exceptions
- third looks at the functionalty
- switch roles on next review
- ★ Coding with Reason