Code quality as a built-in process
1 like602 views
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.
Code quality as a built-in process
- 1. Code Quality as a built-in process By Elad Maimon
- 2. When to start with code quality ?
- 3. When to start with code quality ?
- 4. Quality does not s t a r t after you submit
- 6. What is pair programming ?
- 7. What is pair programming ? 1 monitor
- 8. What is pair programming ? 1 monitor 1 keyboard
- 9. What is pair programming ? 1 monitor 1 keyboard 1 mouse
- 10. What is pair programming ? 1 monitor 1 keyboard 1 mouse
- 11. What is pair programming ? 1 monitor 1 keyboard 1 mouse 2 developers
- 12. Driver Navigator Tactician Strategist switch frequently...
- 13. Pros
- 15. Higher code quality Pros Encourage discussions
- 16. Higher code quality Pros Encourage discussions Knowledge sharing
- 17. Higher code quality Pros Encourage discussions Knowledge sharing Shared code ownership
- 18. Higher code quality Pros Encourage discussions Knowledge sharing Shared code ownership Teaching tool
- 19. Higher code quality Pros Encourage discussions Knowledge sharing Shared code ownership Focus Teaching tool
- 21. 1 + 1 > 2 ?
- 22. Might reduce creativity 1 + 1 > 2 ?
- 23. Reduce independency Might reduce creativity 1 + 1 > 2 ?
- 24. Reduce independency Might reduce creativity 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
- 28. It’s all about trust ...
- 29. our job is NOT to CODE our job is NOT to TEST we are software engineers we SHIP software that SOLVES problems. (Uri Nativ)
- 30. TDD & BDD
- 32. Who writes this ?
- 34. Code Reviews
- 36. WHEN ?
- 37. Every line of code! WHAT ?
- 38. Search for...
- 41. Search for... Bugs Design Requirements
- 43. Bugs Design Requirements UI Readability
- 44. Bugs Design Requirements UI Readability Styleguide
- 46. Code comments...
- 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 extensive commit 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