Download to read offline
Javantura v6 - How can you improve the quality of your application - Ioannis Kolaxis
The document provides practical guidance for developers to improve software quality by minimizing new defects, focusing on frequently changing code, and enhancing testing strategies. It emphasizes the importance of organizational metrics and developer ownership, suggesting that higher ownership correlates with lower defect rates. Key recommendations include using tools like Sonarlint and Sonarqube, refactoring complex files, and being cautious with contributions from minor contributors.
More Related Content
Similar to Javantura v6 - How can you improve the quality of your application - Ioannis Kolaxis
More from HUJAK - Hrvatska udruga Java korisnika / Croatian Java User Association
![Devfest Harare 2025 Slides [GDG Harare] - Combined Slide Deck](https://cdn.slidesharecdn.com/ss_thumbnails/ilovepdfmerged12-251029161756-3b829161-thumbnail.jpg?width=640&height=640&fit=bounds)
Javantura v6 - How can you improve the quality of your application - Ioannis Kolaxis
- 1. How to improve thequality of your application A practical guide for developers Saturday 23rd February 2019, Javantura, Zagreb / Croatia Ioannis Kolaxis – Software Engineer / Senior Expert
- 2. 1 @IoannisKolaxis What can youdo? How to improve software quality? Where do you start?
- 3. 2 @IoannisKolaxis Should you payoff your debt?
- 4. 3 @IoannisKolaxis Do not touchold code! You will probably introduce new defects! Old code is more reliable “If a module is, on the average, a year older than an otherwise similar module, the older module will have roughly a third fewer faults.” T. L. Graves, A. F. Karr, J. S. Marron and H. Siy, "Predicting fault incidence using software change history" in IEEE Transactions on Software Engineering, vol. 26, no. 7, pp. 653-661, Jul 2000.
- 5. 4 @IoannisKolaxis Stop creating newdebt • Install SonarLint plugin in your IDE. • It helps you detect, and fix quality issues as you write code. • Download at: www.sonarlint.org
- 6. 5 @IoannisKolaxis Stop creating newdebt • Setup Quality Gates in SonarQube
- 7. 6 @IoannisKolaxis • As adeveloper, where do you spend most of your time? A. Reading existing code, B. Writing new code, C. Waiting for a full build to complete, D.Other Quiz
- 8. 7 @IoannisKolaxis • As adeveloper, where do you spend most of your time? A. Reading existing code, B. Writing new code, C. Waiting for a full build to complete, D.Other Quiz
- 9. 8 @IoannisKolaxis Which parts ofyour code do you read most often? Just think …
- 10. 9 @IoannisKolaxis • Use gitto find out where you spend most of your development efforts: git log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -r > files_change_frequency.txt 258 usermanagementportlet/…/UserManagement_de.properties 250 usermanagementportlet/…/UserManagement_en.properties 227 usermanagement/…/RetrieveUserTmpltForUsersDataControlImpl.java 205 usermanagement/…/UserManagementImpl.java 154 usermanagement/…/EditUserResourceTemplateRulesBean.java 135 usermanagementportlet/…/AddEditUserBean.java 109 usermanagementportlet/…/ConfigureNewUserResourceBean.java 103 usermanagementportlet/…/addEditUser.jsp Data never lies Commits per file
- 11. 10 @IoannisKolaxis The pattern From atotal of 10.007 files: • 11 files → more than 101 commits • 91 files → 31 < commits < 100 • 455 files → 10 < commits < 30 • 9.450 files → less than 10 commits • Only a few files change frequently! • This is where you spend most of your time!
- 12. 11 @IoannisKolaxis A well-aimed refactoringwill help you: • Spend less time to read code & extend functionality. • Become more productive! Refactor frequently-changing files
- 13. 12 @IoannisKolaxis • “Churn measuresbased on counts of lines added, deleted, and modified are very effective for fault prediction.” R. M. Bell, T. J. Ostrand, and E.J. Weyuker, “Does Measuring Code Change Improve Fault Prediction?“, ACM Press, 2011. • Files involved in a lot of bug fixing activities are most likely to be defective R. Moser, W. Pedrycz, and G. Succi, “A Comparative Analysis of the Efficiency of Change Metrics and Static Code Attributes for Defect Prediction“, Proceedings of the 30th International Conference on Software Engineering, 181-190, 2008. Changing files predict system failures
- 14. 13 @IoannisKolaxis • Do notwaste your time testing mature functionality (=components that do not change). • Focus all your testing efforts on the frequently-changing parts; those are most likely to fail! Focus your Quality Assurance efforts Unit Tests Integration Tests E2E Tests
- 15. 14 @IoannisKolaxis What is thecoverage of your new/changing code? Ask the right questions
- 16. 15 @IoannisKolaxis • Files notchanged in the past years → stable components → mature features • Is every mature feature still used by your customers? • If a feature is not used, then delete its code! • Else, extract stable features in separate libraries. Identify stable components
- 17. 16 @IoannisKolaxis • Save timefrom your builds. • Achieve faster onboarding of new developers, by: Go faster with deleted/extracted code • Focusing only on actively developed code. • Not having to familiarize with old/stable code.
- 18. 17 @IoannisKolaxis • Gain moreinsight, by measuring code complexity for each one of the frequently changing files. • Language-neutral metrics for code complexity: • Number of lines • Number of tabs Measure code complexity
- 19. 18 @IoannisKolaxis • How manytimes did you provide a bug fix, by adding a nested conditional in your code? if (…) { for (…) { if (customerSpecificSetup) { // Do some magic, so that the // application works for this customer! } } } Tabs increase complexity
- 20. 19 @IoannisKolaxis Rising complexity callsfor refactoring 227 commits
- 21. 20 @IoannisKolaxis Our #1 priorityfor refactoring 205 commits
- 22. 21 @IoannisKolaxis Our #1 priorityfor refactoring 6.767 → 8.396 lines 22.421→ 29.310 tabs Sept 2014 205 commits
- 23. 22 @IoannisKolaxis • Released on8th November 2006. • > 50 million lines of code. • ~ 2.000 developers. Do you remember Windows Vista?
- 24. 23 @IoannisKolaxis • Microsoft measuredseveral organizational metrics, and studied their correlation with the defects of Windows Vista. Organizational structure vs Quality Organizational metric Assertion Number of Engineers The more people who touch the code, the lower the quality. Number of Ex-Engineers A large loss of team members affects the knowledge retention, and thus quality. Organization Intersection Factor The more diffused the different organizations contributing code, the lower is the quality. N. Nagappan, B. Murphy, and V.R. Basili, “The Influence of Organizational Structure on Software Quality: An Empirical Case Study“, ACM, 2008. • Can the structure of your organization affect the quality of your software application?
- 25. 24 @IoannisKolaxis • Organizational metricsare better predictors of failure-proneness than the traditional metrics used so far, such as code coverage, code complexity, etc. Organizational structure impacts Quality Model Precision Organizational structure 86,2% Code coverage 83,8% Code complexity 79,3% Code churn 78,6% Dependencies 74,4% Pre-release bugs 73,8% N. Nagappan, B. Murphy, and V.R. Basili, “The Influence of Organizational Structure on Software Quality: An Empirical Case Study“, ACM, 2008.
- 26. 25 @IoannisKolaxis • In anotherresearch, focused on Windows 7, Microsoft distinguished between the following kinds of developers, depending on their commits for a given component: • Owner: has the most commits to that component. • Major contributor: has more than 5% of total commits. • Minor contributor: has less than 5% of total commits. More organizational metrics C.Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu, “Don’t Touch My Code! Examining the Effects of Code Ownership on Software Quality“, ACM, 2011.
- 27. 26 @IoannisKolaxis • The researchersconcluded that: • “The number of minor contributors has a strong positive relationship with both pre- and post-release failures …” • “Higher levels of ownership for the top contributor to a component results in fewer failures when controlling for the same metrics, but the effect is smaller than the number of minor contributors” Effects of minor contributors C.Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu, “Don’t Touch My Code! Examining the Effects of Code Ownership on Software Quality“, ACM, 2011.
- 28. 27 @IoannisKolaxis • In oneof our software components, we had a total of 427 commits: Gain insight into your components Commits per developer Metric Value Minor contributors 15 Major contributors 6 Total contributors 21 Ownership 20,37% • The top contributing developer made 87 commits: 87/427 = 20,37% ownership
- 29. 28 @IoannisKolaxis • In anothersoftware component, we had a total of 253 commits for the same period: Gain insight into your components Commits per developer Metric Value Minor contributors 3 Major contributors 6 Total contributors 9 Ownership 28,85% • The top contributing developer made 73 commits: 73/253 = 28,85% ownership
- 30. 29 @IoannisKolaxis • Which componentwill probably have more defects? • Where would you focus your testing efforts? Know where you are standing … Metric Component A Component B Minor contributors 15 3 Major contributors 6 6 Total contributors 21 9 Ownership 20,37% 28,85%
- 31. 30 @IoannisKolaxis • More minorcontributors → More defects • Bigger ownership → Less defects Beware of minor contributors! Metric Component A Component B Minor contributors 15 3 Major contributors 6 6 Total contributors 21 9 Ownership 20,37% 28,85%
- 32. 31 @IoannisKolaxis • Minor contributorsmust be consulting a major contributor of a component before making any changes to it. • Pay more attention when reviewing code submitted by minor contributors. • More extensive testing should be performed for components with low ownership. Use metrics to build better software
- 33. 32 @IoannisKolaxis • A customerasks for a new feature to be implemented, but the major contributors of that component are not available. What will you do? • Ask from minor contributors, to start implementing this new feature right away, or • Delay the implementation of the feature, until one or more major contributors are available? Planning new features
- 34. 33 @IoannisKolaxis • Use gitto find out all the contributors for a component: git shortlog -s – your_component > contributors.txt 78 Ioannis Kolaxis 27 … 48 … • Or, to limit the results to contributors after a given date (e.g. due to an organizational restructuring) git shortlog -s --after=2018-05-01 -- your_component > contributors.txt Learn your contributors Commits per developer Folder
- 35. 34 @IoannisKolaxis 1. Stop creatingnew quality issues. 2. Don’t touch old code. 3. Refactor your most complex, frequently changing files. 4. Focus your testing on frequently changing files. 5. Pay attention to minor contributors. Summary of proposed actions
- 36. 35 @IoannisKolaxis Now you know whereto start! How to improve software quality?
- 37. Atos, the Atoslogo, Atos Codex, Atos Consulting, Atos Worldgrid, Worldline, BlueKiwi, Bull, Canopy the Open Cloud Company, Unify, Yunano, Zero Email, Zero Email Certified and The Zero Email Company are registered trademarks of the Atos group. June 2016. © 2016 Atos. Confidential information owned by Atos, to be used by the recipient only. This document, or any part of it, may not be reproduced, copied, circulated and/or distributed nor quoted without prior written approval from Atos. Thank you! Email : [email protected] Twitter : @IoannisKolaxis