How to improve the quality of your application
- 1. How to improve the quality of your application A practical guide for developers Wednesday 20th February 2019, JHUG Meetup Athens / Greece Ioannis Kolaxis – Software Engineer / Senior Expert
- 2. 1 @IoannisKolaxis • Are you working for a software product, where …? • New features take too much time to be implemented • Customers keep complaining about bugs Software quality issues
- 3. 2 @IoannisKolaxis • Can you improve the quality of your software? • How? What can you do?
- 4. 3 @IoannisKolaxis Our application: CMP • Automates the configuration & provisioning of our switches, achieving significant time savings for our service.
- 5. 4 @IoannisKolaxis Customer tickets ✔ • We usually measure quality via customer tickets: CMP Customer tickets
- 6. 5 @IoannisKolaxis Code coverage ✔ • When we refer to quality, we usually think of code coverage! Increased coverage: • from 67% (Feb 2017) • to 72% (Jun 2018)
- 7. 6 @IoannisKolaxis Should you pay off your debt? Decreased debt: • from 1.359 days (Feb 2017) • to 392 days (Jun 2018)
- 8. 7 @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.
- 9. 8 @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
- 10. 9 @IoannisKolaxis Stop creating new debt • Setup Quality Gates in SonarQube
- 11. 10 @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
- 12. 11 @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
- 13. 12 @IoannisKolaxis Which parts of your code do you read most often? Just think …
- 14. 13 @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
- 15. 14 @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!
- 16. 15 @IoannisKolaxis A well-aimed refactoring will help you: • Spend less time to read code & extend functionality. • Become more productive! Refactor frequently-changing files
- 17. 16 @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
- 18. 17 @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
- 19. 18 @IoannisKolaxis What is the coverage of your new/changing code? Ask the right questions
- 20. 19 @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
- 21. 20 @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.
- 22. 21 @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
- 23. 22 @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
- 24. 23 @IoannisKolaxis Rising complexity calls for refactoring 227 commits
- 25. 24 @IoannisKolaxis Our #1 priority for refactoring 205 commits
- 26. 25 @IoannisKolaxis Our #1 priority for refactoring 6.767 → 8.396 lines 22.421→ 29.310 tabs Sept 2014 205 commits
- 27. 26 @IoannisKolaxis • The identified files are being changed by many developers in parallel. • Is it feasible to perform refactoring on a private branch? • Can we afford to stop development, while someone works for a long time on refactoring the identified files? Refactor frequently changing files
- 28. 27 @IoannisKolaxis Break large file by responsibilities findUser() addUser() editUser() deleteUser() findExtensionRange() addExtensionRange() editExtensionRange() deleteExtensionRange() getAssignedPhones() getUnassignedPhones() UserManagementImpl.java …. …. Originalfilehastoomanyresponsibilities UserManagementImpl.java Delegateoldmethodcallstonewclasses findUser() addUser() editUser() deleteUser()() UserMgmt.java Refactor findExtensionRange() addExtensionRange() editExtensionRange() deleteExtensionRange() ExtensionRangeMgmt.java getAssignedPhones() getUnassignedPhones() PhonesMgmt.java
- 29. 28 @IoannisKolaxis Divide and conquer Old/stable code New/changing code Stabilize code • When you refactor, always try to stabilize new/changing code!
- 30. 29 @IoannisKolaxis Stabilizing code by refactoring findUser() addUser() editUser() deleteUser() findExtensionRange() addExtensionRange() editExtensionRange() deleteExtensionRange() getAssignedPhones() getUnassignedPhones() UserManagementImpl.java …. …. Originalfile UserManagementImpl.java Refactoredfile findUser() addUser() editUser() deleteUser()() UserMgmt.java Refactor findExtensionRange() addExtensionRange() editExtensionRange() deleteExtensionRange() ExtensionRangeMgmt.java getAssignedPhones() getUnassignedPhones() PhonesMgmt.java
- 31. 30 @IoannisKolaxis • Released on 8th November 2006. • > 50 million lines of code. • ~ 2.000 developers. Do you remember Windows Vista?
- 32. 31 @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?
- 33. 32 @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.
- 34. 33 @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.
- 35. 34 @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.
- 36. 35 @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
- 37. 36 @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
- 38. 37 @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%
- 39. 38 @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%
- 40. 39 @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
- 41. 40 @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
- 42. 41 @IoannisKolaxis • Use git to find out all the contributors for a component: git shortlog -s – your_component > contributors.txt 17 Ioannis Kolaxis 18 … 34 … • 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
- 43. 42 @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
- 44. 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