Code review tips from Jeff Atwood
•Download as PPTX, PDF•
0 likes•1,872 views
Code review is a process where another person reviews your code to check for errors, bugs, inefficiencies and adherence to coding standards and best practices. It allows another set of eyes to examine the code for potential problems or improvements that may not be caught by the original author. Code reviews are an important part of the software development process and help improve code quality and catch issues early.
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
More from Frank Sons
More from Frank Sons (20)
Recently uploaded
Recently uploaded (20)
Code review tips from Jeff Atwood
- 9. Jeff Atwood - @codinghorror
- 10. Jeff Atwood - @codinghorror
- 26. Jeff Atwood - @codinghorror
Editor's Notes
- Software Quality Engineer explained Ask who does code reviews
- Inspired by Jeff Atwood: „how to stop sucking and be awesome instead“ Not about: review tools Fokus: mindset!
- Authors can write, can‘t they? And coders can code…
- Improving developer skill is maybe even more important
- Trained inspectors Moderated reviews Today: Think of NASA, Airbus, etc. Agile does not work for everyone Not going to cover that
- Who heard that? Who said that? Next => What about the ego?
- Collective code ownership vs. Ego Next => Forget about your ego
- Embrace the suck and -> learn!
- Learn from others Share the knowledge
- Coding Standards: just have to be there
- TIME?? (~10-15min) Right tool for the right job
- Hallway testing
- Ask your colleague
- Storytime: Talk to the duck / Rubber duck debugging „The zone“ – interuptions costs time and performance
- Branch/commit/classes/etc.
- Author not present Can be used for mentoring/coaching e.g. Fisheye
- Often not seen as a review Agile approach Cultural change needed
- Can be used for bigger groups Present and test changes/new ideas Educate about Product/Framework/API/etc.
- Maintainable = understand the code in 6/12/24 months
- TIME?? (25-30min) Situation similiar to bug fixing 6 months in the future (try to understand the code) Think loud Eagle Eye: experienced dev Author explains / answers: comment! Gain: Is the code understandble more discussing
- Follow up: add TODOs and make sure they are done Don‘t abuse: 1on1, no lead devs in review (Use a mantra as reminder each review)
- 2h is critical, 1.5h is better, but can be hard. 250-300 lines of code Judith: 45min break?
- First review: Do they have coding standards? Do they document their code? After review: need to talk about standards/guidelines. Need to document more (Focus: style vs. Substance (nachdem Style geklärt ist)) Communication: - Need to talk to each others, find common ground
- Not about code reading