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.

Transcript

1. About code reviews
   and BUGS
   
   

   View Slide

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
   

   View Slide

3. The cost of a
   

   View Slide

4. Test failure while
   coding, immediate fix
   1 €
   

   View Slide

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

   View Slide

6. During QA testing, receive a
   vague bug report, spend time
   reproducing it, write the fix
   and release after an hour
   100 €
   

   View Slide

7. In production, different users
   spot the a bug “it just don’t
   work”, 8 hours of work
   1000 €
   

   View Slide

8. Too many defects, release
   postponed by few weeks
   10.000 €
   

   View Slide

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

   View Slide

10. Release to production even
    with many defects and
    missing features: bad user
    experience, loss of credibility
    project failure
    

    View Slide

11. View Slide

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
    

    View Slide

13. CODE
    REVIEWS
    

    View Slide

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

    View Slide

15. WHY
    

    View Slide

16. Find bugs before
    your customers do
    

    View Slide

17. Meets specifications
    

    View Slide

18. Shared ownership
    

    View Slide

19. Keep the bar high
    

    View Slide

20. Leave a written trail
    

    View Slide

21. Mentorship by default
    

    View Slide

22. Asynchronous feedback
    

    View Slide

23. HOW
    (as a submitter)
    

    View Slide

24. Avoid wall of diff
    

    View Slide

25. Contain not
    interesting changes
    

    View Slide

26. Solve one thing at a
    time
    

    View Slide

27. Provide context
    

    View Slide

28. Highlight most
    interesting points
    

    View Slide

29. Respect for your
    colleagues time
    

    View Slide

30. HOW
    (as a reviewer)
    

    View Slide

31. Be polite
    

    View Slide

32. Learn context
    before starting
    

    View Slide

33. Give feedback that helps
    

    View Slide

34. Look for missing tests
    and edge cases
    

    View Slide

35. Pay attention to
    what tools can’t find
    

    View Slide

36. our process
    

    View Slide

37. View Slide

38. View Slide

39. View Slide

40. View Slide

41. View Slide