Download as PDF, PPTX
Uploaded byElad Maimon
Code quality as a built-in process
This document discusses various techniques for maintaining code quality, including pair programming, test-driven development, code reviews, and self-documenting code. It notes that pair programming involves two developers sharing one monitor, keyboard, and mouse to collaboratively write code. Benefits include higher quality code, knowledge sharing, and a teaching tool. Code reviews search for bugs, design flaws, nonconformance with requirements or style guides. Comments should explain why code is written a certain way rather than describing how.
More Related Content
Similar to Code quality as a built-in process
![[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...](https://cdn.slidesharecdn.com/ss_thumbnails/christophek-180419103038-thumbnail.jpg?width=640&height=640&fit=bounds)
Code quality as a built-in process
- 1. Code Quality as abuilt-in process By Elad Maimon
- 2. When to startwith code quality ?
- 3. When to startwith code quality ?
- 4. Quality does not s ta r t after you submit
- 5.
- 6. What is pairprogramming ?
- 7. What is pairprogramming ? 1 monitor
- 8. What is pairprogramming ? 1 monitor 1 keyboard
- 9. What is pairprogramming ? 1 monitor 1 keyboard 1 mouse
- 10. What is pairprogramming ? 1 monitor 1 keyboard 1 mouse
- 11. What is pairprogramming ? 1 monitor 1 keyboard 1 mouse 2 developers
- 12. Driver Navigator Tactician Strategist switchfrequently...
- 13.
- 14.
- 15. Higher code quality Pros Encouragediscussions
- 16. Higher code quality Pros Encouragediscussions Knowledge sharing
- 17. Higher code quality Pros Encouragediscussions Knowledge sharing Shared code ownership
- 18. Higher code quality Pros Encouragediscussions Knowledge sharing Shared code ownership Teaching tool
- 19. Higher code quality Pros Encouragediscussions Knowledge sharing Shared code ownership Focus Teaching tool
- 21. 1 + 1> 2 ?
- 22. Might reduce creativity 1+ 1 > 2 ?
- 23. Reduce independency Might reducecreativity 1 + 1 > 2 ?
- 24. Reduce independency Might reducecreativity 1 + 1 > 2 ? Soloist teammate
- 25. - Be stubborn -Get attached to your code - Dominate - Distract yourself - Late - Overuse DOs DONTs - Find proper environment - Talk a lot - Postpone hard decisions - Take shared breaks - Switch roles frequently - Switch pairs often
- 26.
- 27.
- 28. It’s all abouttrust ...
- 29. our job isNOT to CODE our job is NOT to TEST we are software engineers we SHIP software that SOLVES problems. (Uri Nativ)
- 30.
- 32.
- 34.
- 35.
- 36.
- 37. Every line ofcode! WHAT ?
- 38.
- 39.
- 40.
- 41. Search for... Bugs DesignRequirements
- 42.
- 43. Bugs Design Requirements UIReadability
- 44. Bugs Design Requirements UIReadability Styleguide
- 46.
- 47. Code comments... documentation ={ how: “code”, why: “comments” } # TODO documents ?
- 48. Self documenting code ➭Function and variable names ➭ Naming conventions
- 49. Self documenting code ➭Function and variable names ➭ Naming conventions This:
- 50. Self documenting code ➭Function and variable names ➭ Naming conventions vs. This: This:
- 51. - Write extensivecommit comment - Split to short commits - Don’t get attached to your code - Understand the reviewer is a better reference to readability than you Reviewer Reviewee - Don’t insist on perfect solution - Different approaches are OK - Ask for explanations - Separate faults that are not “NO GO” ( open ticket ) - Don’t argue back and forth more than twice - talk F2F