- Review diffs
- Why code review?
- At least two people know about
- Ensure readability
- Catch bugs
- Encourage a healthy engineering culture
- Get feedback all the time
- Grund rules for effective code review:
- Don't make people do a machine's work
- Everybody gets code reviewed
- Do code review before code get merged
- Every change. Every time.
- Even if it's one line
- The process become natural
- Easy to *(get better)
- Get a tool:
- Phabricator
- Github
- Gerrit
- Whatever
- How to be a good path author:
- Describe clearly what the path does
- Keep it small
- PESQUISAR, rebase antes do merge
- Code review is collaborative
- How to be a good reviewer:
- What are you looking for?
- Intent: what this is trying to do?
- Design: architecture design
- Implementation, there is:
- Tests?
- Documentation?
- Grammar:
- Good names?
- Suggest different sintax
- Look for small details
- Types of review elements:
- TODO's
- Questions
- Suggestions for follow ups (go back and look at that later)
- What are you looking for?
- Anti-patterns:
- Very manual processes
- Irregular code review (once a week, etc.)
- Positive patterns:
- Share early, share often:
- push code
- ask for feedback
- talk
- Document the steps
- Lend a helping hand (always be helpfull)
- Keep checklist of what are you working on
- Share early, share often:
- Code review is an important part of engineering culture:
- It also makes it easier to ship good code
- Code review helps people get better
- Code reivew makes the core-developers less special
-
Code review must be part of every team's workflow
-
Use tooling to make the job easier
-
Use code review to promote collaboration and learnig on your team
-
Pesquisar:
- Profiling
- Know how long the program should take