Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Code Review at Yodas

Code Review at Yodas

Code review best practices and overview / Yodas

Ran Tavory

May 05, 2016
Tweet

More Decks by Ran Tavory

Other Decks in Programming

Transcript

  1. 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
  2. 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
  3. TOOLS FOR BETTER CODE REVIEW ▸ Github pull request ▸

    Lint ▸ IDE support (lint, formatting) ▸ CI
  4. CODE REVIEW - WHAT IS IT GOOD FOR? ▸ As

    the coder ▸ Better code, less bugs ▸ Learn
  5. CODE REVIEW - WHAT IS IT GOOD FOR? ▸ As

    the reviewer ▸ Learn ▸ Know the code. You might be the next person working on it
  6. CODE REVIEW - WHAT IS IT GOOD FOR? ▸ As

    a team ▸ Learn ▸ Common standards (coding conventions) ▸ No job security
  7. 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
  8. 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.
  9. 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)
  10. 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