Code Review at Yodas

Code review best practices and overview / Yodas

Transcript

1. CODE REVIEW YODAS
2. SETUP ▸ F2F ▸ vs Offline
3. WHO ▸ Peers
4. WHAT TO LOOK FOR IN CODE REVIEW ▸ You understand it ▸ Code is for ppl, not computers ▸ Each function does what you expect ▸ DRY ▸ Tests ▸ Names
5. CHECKLIST (?) ▸ Does the code execute as expected? ▸ Is all new code tested? Altered code tests up to date? ▸ Is the code readable? ▸ Do you understand the code you are reviewing? ▸ Has the developer tested the code? ▸ Coding conventions? ▸ Are all functions, methods and classes documented? ▸ Are complex algorithms and code optimizations adequately commented? ▸ Error Handling ▸ Resource Leaks ▸ Thread Safeness ▸ Is the code free of unintended infinite loops? ▸ Are function parameters explicitly verified in the code? ▸ Pending/TODO ▸ assertions ▸ abnormal terminations ▸ Database Transactions ▸ Correct synchronization ▸ no deadlocks/livelocks ▸ Bug Fix Side Effects ▸ All the occurrences of the bug are fixed
6. TOOLS FOR BETTER CODE REVIEW ▸ Github pull request ▸ Lint ▸ IDE support (lint, formatting) ▸ CI
7. CODE REVIEW - WHAT IS IT GOOD FOR? ▸ As the coder ▸ Better code, less bugs ▸ Learn
8. CODE REVIEW - WHAT IS IT GOOD FOR? ▸ As the reviewer ▸ Learn ▸ Know the code. You might be the next person working on it
9. CODE REVIEW - WHAT IS IT GOOD FOR? ▸ As a team ▸ Learn ▸ Common standards (coding conventions) ▸ No job security
10. GITHUB FLOW ▸ https://guides.github.com/introduction/flow/
11. EYE TRACKING
12. EYE TRACKING ▸ Now there's a physiological reason to write short method. ▸ People who spend more time on the first scan find more issues and find them faster
13. DEFECT DENSITY V/S LOC
14. DEFECT DENSITY V/S INSPECTION RATE ▸ Conclusion: Take your time (500 LOC/hour is max)
15. PSYCHOLOGY AND CODE REVIEW ▸ Let's face it, there's a lot of psychology in it, so play nice. ▸ Be professional, nothing is personal ▸ Understand, do not criticize.
16. GUIDELINES - TIPS FOR BETTER LIFE… ▸ Every LOC should be read by at least two ppl ▸ Every component should have: ▸ Owner ▸ Secondary maintainer ▸ Short and atomic PRs ▸ Know the coding conventions / styleguides ▸ Read related code (classes/method being used) ▸ Read Slow ▸ Short reviews (at most 60 minutes/200 LOC)
17. REFERENCES ▸ This presentation: https://speakerdeck.com/rantav/code- review-at-yodas ▸ A short book http://smartbear.com/SmartBear/media/ pdfs/best-kept-secrets-of-peer-code-review.pdf