Code Review
Jun. 2, 2014•0 likes•1,871 views
Download to read offline
Report
Technology
Code review talk from the International PHP conference
Frank SonsFollow
More Related Content
Viewers also liked
molson coors brewing COORS_AR2000finance46
Make everything realtime & collaborative - JS Summit 2014Joseph Gentle
Breaking TechnologiesDavid Coallier
omnicare annual reports 1998finance46
Program book abfi2013Amril Taufik Gobel
Highlights of the Indian budget 2014Rajesh Goyal
More from Frank Sons
An Introduction to pair programming methodsFrank Sons
Introduction to architecture katasFrank Sons
Pair programmingFrank Sons
Effective Code Reviews (IPC 2018)Frank Sons
Architecture Katas - How can we learn to create better architectures?Frank Sons
Architektur Kata - Workshop SolutionsFrank Sons
Recently uploaded
9C Monthly Newsletter - SEPT 2023PublishingTeam
Accelerating Data Science through Feature Platform, Transformers and GenAIFeatureByte
UiPath Tips and Techniques for Debugging - Session 3DianaGray10
h2 meet pdf test.pdfJohnLee971654
"Building Asynchronous SOA for Modern Applications", Sai Pragna Etikyala Fwdays
Understanding Wireguard, TLS and Workload IdentityChristian Posta
Code Review
- 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