About code reviews and BUGS

About code reviews and BUGS

Adopting code review into the software development practice is a good way to drive high quality code, improve team communication and knowledge sharing. We'll look at the best strategies to adopt it and continue to use it in the most proficient way.

Presentation held during an #apericoder of the montacchiello.dev group.

416c04c6f0793e236381c2f5df80c9ed?s=128

Giovanni Toraldo

June 27, 2019
Tweet

Transcript

  1. About code reviews and BUGS

  2. Famous software in history • 1962 - NASA Mariner 1

    mission, spacecraft destroyed ◦ 18 million USD • 1988 - Morris Worm experiment at MIT ◦ 50.000 USD • 1994 - Pentium FDIV ◦ 475 million USD • 2010 - Mt. Gox bitcoin exchange ◦ 850.000 bitcoins • 2012 - Knight Capital Group investments ◦ 440 million USD
  3. The cost of a

  4. Test failure while coding, immediate fix 1 €

  5. A colleague spots a bug during code review, few minutes

    fix 10 €
  6. During QA testing, receive a vague bug report, spend time

    reproducing it, write the fix and release after an hour 100 €
  7. In production, different users spot the a bug “it just

    don’t work”, 8 hours of work 1000 €
  8. Too many defects, release postponed by few weeks 10.000 €

  9. Too many defects and missing features, release postponed by months

    100.000 €
  10. Release to production even with many defects and missing features:

    bad user experience, loss of credibility project failure
  11. None
  12. Good to have practices to the rescue • Source code

    VC • Bug tracker • Dependency Management • Configuration Management • Automated deployment • Continuous Integration • Data management • Continuous delivery • Code reviews
  13. CODE REVIEWS

  14. 1. Write code 2. Ask for feedback 3. Repeat until

    OK
  15. WHY

  16. Find bugs before your customers do

  17. Meets specifications

  18. Shared ownership

  19. Keep the bar high

  20. Leave a written trail

  21. Mentorship by default

  22. Asynchronous feedback

  23. HOW (as a submitter)

  24. Avoid wall of diff

  25. Contain not interesting changes

  26. Solve one thing at a time

  27. Provide context

  28. Highlight most interesting points

  29. Respect for your colleagues time

  30. HOW (as a reviewer)

  31. Be polite

  32. Learn context before starting

  33. Give feedback that helps

  34. Look for missing tests and edge cases

  35. Pay attention to what tools can’t find

  36. our process

  37. None
  38. None
  39. None
  40. None
  41. None