Successfully reported this slideshow.
Your SlideShare is downloading. ×

How to Have Code Reviews That Developers Actually Want

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

How to Have Code Reviews That Developers Actually Want

  1. 1. Cameron Presley @pcameronpresley Cameron@TheSoftwareMentor.com How to Have Code Reviews Your Developers Actually Want
  2. 2. 2 Hello!
  3. 3. The Problem
  4. 4. “Looks Good To Me 4
  5. 5. 5
  6. 6. 6
  7. 7. What about …? Or …? Or … Thoughts on …? 7
  8. 8. 8
  9. 9. 9
  10. 10. 10
  11. 11. What’s The Goal Of A Code Review?
  12. 12. “ Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. - Wikipedia 12
  13. 13. Not only for software development ○ Architects – Red Line Reviews ○ Engineers – Peer Reviews ○ Doctors – Consultations ○ Welders – Welding Review 13
  14. 14. “ Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. - Wikipedia 14
  15. 15. Why the focus on finding bugs sooner? Bugs cost more the later they’re found 15
  16. 16. How Many Times More? 16 Time Introduced Requirements Architecture Construction System Test Post Release Requirements 1 3 5-10 10 10-100 Architecture - 1 10 15 25-100 Construction - - 1 10 10-25 from Code Complete 2nd Edition
  17. 17. How Much Savings? IBM found that each hour of inspection prevented about 100 hours of related work Assuming $25 an hour, that means for every $25 invested, $2500 was saved. 17
  18. 18. How Much Savings? Raytheon reduced its cost of rework from 40% of project cost to 20% of project cost The amount spent on bug fixes dropped by 50% 18
  19. 19. 19
  20. 20. Code Reviews For Me 20
  21. 21. 21
  22. 22. Which Developer Would You Prefer? 22 0 1 2 3 4 5 6 0 1 2 3 4 5 Experience Years Working Developer A Developer B
  23. 23. 23
  24. 24. 24
  25. 25. 25
  26. 26. 26
  27. 27. 27 Source
  28. 28. 28 No Faster than 500 LOCs an hour
  29. 29. 29 No More than an hour at a time
  30. 30. 30
  31. 31. Opinion Based Improvements 31
  32. 32. “ That’s not how I would have done it… 32
  33. 33. 33 Is the goal to have everyone code the same? No, it’s to solve the problem
  34. 34. 34 Frame Suggestions Around Context using When, What, and Why
  35. 35. 35 Never return null when retrieving a list of records from the database
  36. 36. 36 When returning records from the database and there aren’t any, we should return an empty list because all of the list methods work on an empty list and we don’t have to introduce error handling code
  37. 37. 37 When returning records from the database and there aren’t any, we should return an empty list because all of the list methods work on an empty list and we don’t have to introduce error handling code
  38. 38. 38 When returning records from the database and there aren’t any, we should return an empty list because all of the list methods work on an empty list and we don’t have to introduce error handling code
  39. 39. 39 When returning records from the database and there aren’t any, we should return an empty list because all of the list methods work on an empty list and we don’t have to introduce error handling code
  40. 40. 40
  41. 41. “ What should you do when the array is empty? 41 Reinforce Joint Ownership
  42. 42. “ What should you do when the array is empty? What should we do when the array is empty? 42 Reinforce Joint Ownership
  43. 43. “ This for loop is garbage, what in the world were you thinking?! 43 Code Is The Problem
  44. 44. “ This for loop is garbage, what in the world were you thinking?! I’m having issues understanding this for loop, can you step me through what it’s doing? 44 Code Is The Problem
  45. 45. 45
  46. 46. 46
  47. 47. 47
  48. 48. 48
  49. 49. What I Look For 49
  50. 50. Quality ○ Are inputs handled correctly? ○ Is the right answer computed? ○ How about nulls? Empty Arrays? Negative numbers, etc? ○ What about edge cases? ○ Are errors handled gracefully? ○ Does the app crash? ○ Is the user presented with a message? 50
  51. 51. 51
  52. 52. Readability ○ Determined by your team ○ Clear beats clever, but what makes code “clear”? ○ Write code simple enough for your team to understand, but strive to improve the lower bound 52
  53. 53. Maintainability ○ Code is in flux ○ The longer it takes to make changes… ○ The more expensive the work ○ More likely to make mistakes ○ Are certain design principles being followed? ○ SOLID, DRY, YAGNI, KISS 53
  54. 54. Style ○ Does this C# code look like it was written by a C# developer? Or more like a Ruby developer? ○ Focus on ○ Naming conventions ○ Proper coding constructs ○ Project structure 54
  55. 55. 55
  56. 56. Next Steps Ask someone you respect to review your work ○ Company == Coworker ○ Side Project == Friend 56
  57. 57. Next Steps Implement Code Review Process at work? ○ Convincing your boss? Code Complete by Steve McConnell ○ Trying to design the process? Brainstorming About Code Reviews by Geoff Mazeroff 57
  58. 58. 58 Resources ○ The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin ○ 11 Proven Practices For More Effective, Efficient Peer Code Review ○ Code Complete 2nd Edition by Steve McConnell ○ Brainstorming About Code Reviews by Geoff Mazeroff ○ http://blog.TheSoftwareMentor.com/presentations/#CodeReviews
  59. 59. Feedback! 59 http://blog.TheSoftwareMentor.com/F eedback

Editor's Notes

  • Rubber Stamping
    Does anyone care?
    Apathy
  • Code Reviews are a waste of time
  • What about this?
    What about that?
    Question after question after question
    Critiqu after critique
  • Multiple hour beating
  • Feel exhausted
    So many changes
    Did you really accomplish anything?
  • Code Reviews Take Too Long…
  • Plenty of incentives for companies to have code reviews
    Responsible for doing what’s best for our employer
    But what about us?
  • Developers start out knowing how to write code, but not much finesse
    Takes time to learn the nuances of development
    Not just time on the job, it’s constantly learning new techniques and perspectives
  • 5 years of experience, but each year introduces something new
    The same year 5 times?
  • Learn from those who came before you
    Always someone who knows more than you and code reviews can help share that knowledge
    Makes your more employable (i.e. easier to get a job)
    Makes you more valuable (i.e. get paid more and less likely to be let go)
  • Reviewing too much
    Can’t review ton of changes and expect to find issues
    How much code is too much?
  • IBM partnered with SmartBear and Cisco to determine some best practices for code reviews
    Published as 11 Best Practices for Code Review
    The study involved 2,500 code reviews, 50 programmers and 3.2 million lines of code at Cisco Systems
  • Defect density – review effectiveness, looking for high points on the Y axis
    Once we hit 200 LOC, we start dropping in effectiveness
    Once we hit 400 LOC, effectiveness goes to 0
  • Strive for smaller pieces of work
    Big changes will happen, need to have more frequent code reviews
  • Opinion Based Improvements
  • “If we’re retrieving an array of records from the database, we should return an empty array if the database is empty instead of returning a null because the return choices for an array should either be empty or a collection of those records”
  • Never, really, there is no instance when this would make sense?
    Only a Sith deals with absolutes….
  • When is the keyword (i.e. when should we do this)
  • What: what do we do in this situation
  • Why should we do this?
    Lead into attacking the developer section
  • It’s normal for developers to be anxious for another to review their work
    Especially when starting out, we can’t just call each other crap
  • Notice how we’re placing blame or onus on the developer?
  • By switching out you for we, it’s more collaborative
  • Tone implies that the code is bad
    Is it because of quality or is it because I don’t understand
    (Two different problems!!!)
  • Puts the problem on me and allows the developer to step through their code
    I may be learning a new trick here.
  • Lecturing
    Typically find this with a senior working with a junior
    One person doing all the talking
  • Tight Collaboration
    Everyone is talking and engaged
    Not a lecture
  • Knowledge Sharing
    One developer should not be solely responsible for a part of the application.
    Leads to problems like we can’t make changes without Cameron here
    By sharing business knowledge and the design of the code, other developers can pick up the context quickly
  • Bus Factor
    How many people could be hit by a bus before the project suffered?
  • Concise for one team is unintelligible for another
    No surprises, the team can understand it
  • Don’t mention tools because they’re an afterthought
    Tools automate the process
    Tools don’t dictate the process, the process dictates the tools
  • If application is service oriented, then it shouldn’t be following a layered approach
    It’s okay to have technical debt, but mortgage on home, not Ferrari on credit card
    You’re writing tests, right…?
  • View Report option is under the “About” menu
    Dumping an exception to the main window
    Telling the user the application lost connection to its database
  • If we can’t consistently reproduce the problem, how will we know when it’s fixed?
    Have we found the source of the problem, or are we patching a symptom?
    If we have a problem here, we can scrap the review and address the issue
  • You’ll have a feeling that there was a cleaner way to solve an issue, but you don’t know how to fix it. Perfect opportunity to get a second set of eyes

×