How to improve the quality of your application
- 1. How to improve the quality 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 you do? How to improve software quality? Where do you start?
- 3. 2 @IoannisKolaxis Should you pay off your debt?
- 4. 3 @IoannisKolaxis Do not touch old 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 new debt âą 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 new debt âą Setup Quality Gates in SonarQube
- 7. 6 @IoannisKolaxis âą As a developer, 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 a developer, 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 of your code do you read most often? Just think âŠ
- 10. 9 @IoannisKolaxis âą Use git to 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 a total 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 refactoring will help you: âą Spend less time to read code & extend functionality. âą Become more productive! Refactor frequently-changing files
- 13. 12 @IoannisKolaxis âą âChurn measures based 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 not waste 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 the coverage of your new/changing code? Ask the right questions
- 16. 15 @IoannisKolaxis âą Files not changed 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 time from 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 more insight, 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 many times 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 calls for refactoring 227 commits
- 21. 20 @IoannisKolaxis Our #1 priority for refactoring 205 commits
- 22. 21 @IoannisKolaxis Our #1 priority for refactoring 6.767 â 8.396 lines 22.421â 29.310 tabs Sept 2014 205 commits
- 23. 22 @IoannisKolaxis âą Released on 8th November 2006. âą > 50 million lines of code. âą ~ 2.000 developers. Do you remember Windows Vista?
- 24. 23 @IoannisKolaxis âą Microsoft measured several 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 metrics are 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 another research, 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 researchers concluded 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 one of 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 another software 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 component will 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 minor contributors â 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 contributors must 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 customer asks 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 git to 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 creating new 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 where to start! How to improve software quality?
- 37. Atos, the Atos logo, 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 : ioannis.kolaxis@atos.net Twitter : @IoannisKolaxis