Thoughtworks Brazil, Code Quality
0 likes554 views
The document discusses refactoring code to improve its structure and quality. It recommends measuring code smells and toxicity using various metrics tools to identify areas for refactoring. Key areas include complexity, duplication, feature envy, and dependency tangles. The steps involve quantifying issues, visualizing dependencies, agreeing on solutions, and then refactoring the code. Maintaining test coverage is important to ensure refactoring does not introduce bugs. The overall goal is to make the code easier to understand and modify without changing its functionality.
Thoughtworks Brazil, Code Quality
- 1. Ola.
- 2. You’re making me refactor. You won’t like me when I refactor
- 4. Refactoring?
- 5. a change made to the internal structure of so=ware to make it easier to understand and cheaper to modify without changing its observable behavior ThoughtWorks
- 7. Don't touch anything that doesn't have coverage. Otherwise, you're not refactoring; you're just changing shit
- 8. a change made to the internal structure of so=ware to make it easier to understand and cheaper to modify without changing its observable behavior ThoughtWorks
- 9. SomeHmes it just feels right.
- 13. Step 1: Measure the toxicity.
- 15. Smells in the code
- 16. CyclomaHc Complexity 5 to 7 is decent for most ruby code
- 17. Saikuro
- 18. Assignments, Branches, Calls with Flog Watch for scores greater than 40
- 19. Flog
- 20. DuplicaHon with Flay Watch for scores greater than 30
- 22. Control Couples and more with Reek Simulated Polymorphism Feature Envy UHlity Methods
- 23. LinHng with Dust/Nitpick JSLint for Ruby
- 24. Common smells in Ruby
- 26. Feature Envy
- 27. Meta-‐programming Keep it simple. Keep it declaraHve
- 29. Toxicity is more than code smells
- 30. “The real problem I have with the CK suite and similar metrics is that they only measure a single module (or class in this case). I claim that the quality of the design of a system is not something that can be determined by looking at individual classes. It is conceivable that every class in a system could be considered reasonable by whatever single-‐class metrics are being used, but the overall design is considered bad.” Ewan Tempero: A Research Agenda hDp://www.cs.auckland.ac.nz/~ewan/
- 31. DEPENDENCY
- 32. Tangles
- 33. Step 2: Make it visible
- 34. Treemaps (Max CC) hbp://mbostock.github.com/protovis/
- 35. Treemaps
- 37. Step 3: Agree on the fix
- 40. Step 4: Go fix it
- 41. Obrigado