How to Have Code Reviews That Developers Actually Want
Download as PPTX, PDF0 likes513 views
The document discusses how to have effective code reviews that developers want. It outlines that the goal of code reviews is to find mistakes early to reduce costs. It recommends reviewing code for quality, readability, maintainability and style. The document suggests implementing a code review process that frames suggestions constructively and reinforces joint ownership over the code. It provides resources for learning more about best practices for peer code reviews.
How to Have Code Reviews That Developers Actually Want
- 1. Cameron Presley @pcameronpresley Cameron@TheSoftwareMentor.com How to Have Code Reviews Your Developers Actually Want
- 2. 2 Hello!
- 3. The Problem
- 4. “Looks Good To Me 4
- 5. 5
- 6. 6
- 7. What about …? Or …? Or … Thoughts on …? 7
- 8. 8
- 9. 9
- 10. 10
- 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. Not only for software development ￮ Architects – Red Line Reviews ￮ Engineers – Peer Reviews ￮ Doctors – Consultations ￮ Welders – Welding Review 13
- 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. Why the focus on finding bugs sooner? Bugs cost more the later they’re found 15
- 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. 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. 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
- 21. 21
- 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
- 24. 24
- 25. 25
- 26. 26
- 27. 27 Source
- 28. 28 No Faster than 500 LOCs an hour
- 29. 29 No More than an hour at a time
- 30. 30
- 32. “ That’s not how I would have done it… 32
- 33. 33 Is the goal to have everyone code the same? No, it’s to solve the problem
- 34. 34 Frame Suggestions Around Context using When, What, and Why
- 35. 35 Never return null when retrieving a list of records from the database
- 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 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 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 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
- 41. “ What should you do when the array is empty? 41 Reinforce Joint Ownership
- 42. “ What should you do when the array is empty? What should we do when the array is empty? 42 Reinforce Joint Ownership
- 43. “ This for loop is garbage, what in the world were you thinking?! 43 Code Is The Problem
- 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
- 46. 46
- 47. 47
- 48. 48
- 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
- 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. 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. 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
- 56. Next Steps Ask someone you respect to review your work ￮ Company == Coworker ￮ Side Project == Friend 56
- 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 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
Editor's Notes
- #6: Rubber Stamping Does anyone care? Apathy
- #7: Code Reviews are a waste of time
- #8: What about this? What about that? Question after question after question Critiqu after critique
- #9: Multiple hour beating
- #10: Feel exhausted So many changes Did you really accomplish anything?
- #11: Code Reviews Take Too Long…
- #20: Plenty of incentives for companies to have code reviews Responsible for doing what’s best for our employer But what about us?
- #22: 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
- #23: 5 years of experience, but each year introduces something new The same year 5 times?
- #24: 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)
- #26: Reviewing too much Can’t review ton of changes and expect to find issues How much code is too much?
- #27: 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
- #28: 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
- #31: Strive for smaller pieces of work Big changes will happen, need to have more frequent code reviews
- #32: Opinion Based Improvements
- #35: “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”
- #36: Never, really, there is no instance when this would make sense? Only a Sith deals with absolutes….
- #38: When is the keyword (i.e. when should we do this)
- #39: What: what do we do in this situation
- #40: Why should we do this? Lead into attacking the developer section
- #41: 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
- #42: Notice how we’re placing blame or onus on the developer?
- #43: By switching out you for we, it’s more collaborative
- #44: Tone implies that the code is bad Is it because of quality or is it because I don’t understand (Two different problems!!!)
- #45: Puts the problem on me and allows the developer to step through their code I may be learning a new trick here.
- #46: Lecturing Typically find this with a senior working with a junior One person doing all the talking
- #47: Tight Collaboration Everyone is talking and engaged Not a lecture
- #48: 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
- #49: Bus Factor How many people could be hit by a bus before the project suffered?
- #53: Concise for one team is unintelligible for another No surprises, the team can understand it
- #56: Don’t mention tools because they’re an afterthought Tools automate the process Tools don’t dictate the process, the process dictates the tools
- #64: 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…?
- #65: 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
- #67: 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
- #68: 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