Technical Debt and Code Quality
•
0 likes•61 views
This document discusses technical debt and code quality. It explains that software engineers spend most of their time reading code rather than writing it, and identifies factors that slow this down such as bad code structure, duplication, lack of architecture and lack of tests. These problems can be addressed through techniques like automated testing, test-driven development, and tools to analyze code quality. Recognizing where technical debt exists is the first step to improving code and paying it down.
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Technical Debt and Code Quality
- 1. Technical Debt and Qode Cuality Vlad Korolev vlad@v-lad.org
- 3. 3 / 41
- 4. 4 / 41
- 5. 5 / 41
- 6. Quality : Further reading 6 / 41
- 7. 7 / 41
- 8. 8 / 41
- 9. Things to google and people to follow People Dr. Deming Eliyahu Goldratt Practices TQM Kaizen 9 / 41
- 10. Code Quality 10 / 41
- 11. 11 / 41
- 12. 12 / 41
- 13. 13 / 41
- 14. 14 / 41
- 15. Technical Debt 15 / 41
- 16. 0 10 20 30 40 50 60 0 10 20 30 40 Project Age (Months) Daystoimplementafeature 16 / 41
- 17. Why? 17 / 41
- 18. What does software engineer mostly do while at work? 18 / 41
- 19. Write code? 19 / 41
- 20. Not really 20 / 41
- 23. Quora question3 Typical answer 80-90 % reading 20-10 % writing 3 https://bit.ly/2ZIZUDt 23 / 41
- 24. Robert Martin (Uncle Bob)4 4 https://bit.ly/3c4BPtb 24 / 41
- 25. Amdahl’s Law S = 1 (1 − p) + p s Where: p - portion of whole to speed up s - speed up factor 25 / 41
- 26. Amdahl’s Law S = 1 (1 − p) + p s Where: p - portion of whole to speed up s - speed up factor Optimistic assumption 80% reading 20% writing Speed up factor of 2 Double the speed to write code → 10% overall improvement Double the speed to read code → 60% overall improvement 26 / 41
- 27. So, how do we speed it up? 27 / 41
- 28. What’s slows us down? Bad code structure Copy-pasta Lack of architecture Lack of common style Lack of unit tests (integration, end-to-end) 28 / 41
- 29. Bad structure : Spaghetti Code 29 / 41
- 30. Bad structure : Ravioli Code 100s or 1000s of classes No cohesion Each code change affects 30-40 classes Did we break anything by the change? 30 / 41
- 31. Bad structure : Lasagna Code A lot of layers Hard to comprehend what happens where Hard to understand impact of the change 31 / 41
- 32. Copy Pasta Need new method similar to existing one NO PROBLEMO! Copy paste existing method Rename and modify 32 / 41
- 33. Lack of architecture Let’s just write code Planning slows things down We need to get things out fast This prototype is good enough to ship 33 / 41
- 34. Lack of common style Even problem for projects of one Mental switch delay looking at different parts Huge restyling change sets for code reviews Hard to compare history (git bisect) 34 / 41
- 35. Lack of tests Unit, Integration, E2E No safety net Anxiety and resistance to change Not clear which parts affected by change 35 / 41
- 36. OK 36 / 41
- 37. We Got it 37 / 41
- 38. What can we do? 38 / 41
- 39. Recognize the problem Reckless Prudent Deliberate We don’t have time for design We must ship now and deal with consequences later Inadvertent What’s layering? Now we know how we should’ve done it From Robert Martin (Uncle Bob) technical debt quadrant5 5 https://bit.ly/2XDS2QZ 39 / 41
- 40. Techniques to use Automated Testing Unit Integration E2E TDD Pay down the debt Throw away your prototypes 40 / 41
- 41. Tools to help Py McCabe6 PyLint7 SonarQube8 6 https://bit.ly/3exl5g6 7 https://pypi.org/project/pylint/ 8 https://bit.ly/2M707Iq 41 / 41