Building Maintainable Software

Transcription

1 Building Maintainable Software Joost Visser Software Improvement Group & Radboud University Nijmegen September 2016 GETTING SOFTWARE RIGHT

2 Today Code quality Functional suitability Performance efficiency Usability > What is code quality? > How can it be measured? Reliability > Why is code quality important? Software Product Quality ISO/IEC Security Building maintainable software Compatibility Portability Maintainability > 10 guidelines > Better Code Hub Page 2 of 31

3 SIG in a nutshell GETTING SOFTWARE RIGHT we help clients improve the software their business depends on some clients some numbers 170 supported technologies 1,800 systems monitored 7,400,000,000 lines of code in benchmark Page 3 of 31

4 Example services Assessments Support risk-based decision making with in-depth analysis of your software Inspections Profit from regular checks security, reliability, portability, performance, usability Monitoring Have a grip on quality, architecture, and productivity, at all times IT Due Diligence Secure your investment by upfront identification of technology risks Software Delivery Assurance Ensure a straight path from solution shaping to product delivery Training and Certification Facilitate developers to deliver top achievements Page 4 of 31

5 Maintainability is key Sustainable business requires maintainable software Quality product process people measurement management education Reliability Performance efficiency Security Functional suitability Software Product Quality ISO/IEC Usability Portability Compatibility Maintainability continuous change Page 5 of 31

6 A practical model for measuring maintainability Heitlager, Kuipers, Visser QUATIC 2007 Most Influential Paper Page 6 of 31

7 Taking the average is fundamentally flawed! Quantiles (% of LOC) Page 7 of 31

8 Result of consistently applying these guidelines Quality profiles for Unit Size Maintainable Unmaintainable Page 8 of 31

9 The more a software system complies with the guidelines, the better Unmaintainable Maintainable Page 9 of 31

10 Certification of maintainability of software products 2009 with TÜViT Certification > Third party gives written assurance that a product conforms to specific requirements Essential elements > Criteria: based on ISO/IEC 9126 > Evaluation body: institute that examines the product > Certification body: institute that confirms evaluation process and result Results > Evaluation report, including measurements > Certificate and quality mark: TÜViT Trusted Product Maintainability Page 10 of 31

11 Validation of the measurement model SQJ 2011 Page 11 of 31

12 Automatic Event Detection for Software Product Quality Monitoring QUATIC 2012 Quality alerts > Detection based on statistical process control > Sudden and sustained changes > Monitor control center Page 12 of 31

13 Monitor and Control Center Drill-down provides developers with detailed measurement results Control Center operators receive alerts, perform diagnostics, and initiate remediation actions Page 13 of 31

14 How can our developers learn to build maintainable software? Educational material and support Assessments Support risk-based decision making with in-depth analysis of your software Inspections Profit from regular checks security, reliability, portability, performance, usability Monitoring Have a grip on quality, architecture, and productivity, at all times IT Due Diligence Secure your investment by upfront identification of technology risks Software Delivery Assurance Ensure a straight path from solution shaping to product delivery Training and Certification Facilitate developers to deliver top achievements Page 14 of 31

15 Future-proof software starts today! Improving maintainability does not require magic or rocket science. A combination of relatively simple skills and knowledge, plus the discipline and environment to apply them, leads to the largest improvement in maintainability. [p. xi] Maintainability is not an afterthought, but should be addressed from the very beginning of a development project. Every individual contribution counts. [p. 4] Page 15 of 31

16 10 guidelines for future-proof code Code Write small units of code Write simple units of code Write code once Keep unit interfaces small Architecture Separate concerns in modules Couple architecture components loosely Keep architecture components balanced Keep your codebase small Way of working Automate tests Write clean code Page 16 of 31

17 10 guidelines for future-proof code Code Limit units to 15 lines of code Limit branch points per unit to 4 Do not copy code longer than 6 lines Limit parameters per unit to 4 Architecture Avoid modules larger than 400 lines of code Hide classes from other components, no cycles Aim for 6-12 top-level components Keep codebase below 200,000 lines of code Way of working Write automated tests that cover all code Stick to the seven boy scout rules Page 17 of 31

18 Identifying Tipping Points guideline Page 18 of 31

19 Examples of guideline compliant code Source code from This unit has 13 lines of code, 3 branch points and 1 parameter This unit has 15 lines of code, 4 branch points and 1 parameter Page 19 of 31

20 What we observe in practice, code that is beyond the tipping point Units with 15+ lines of code Units with 4+ branch points This unit has 38 lines of code and 5 branch points Page 20 of 31

21 Code that is far beyond the tipping point Units with 15+ lines of code Units with 4+ branch points This unit has 38 lines of code and 5 branch points Page 21 of 31

22 Small violations are quickly made but also quickly fixed Source code from our own repository Solution: Extract method This unit has 15 lines of code, 2 parameters, 1 branch point and 10 lines of code duplicated. Copy & Paste Duplicated code blocks 7 lines of code This unit has 15 lines of code, 1 parameter, 1 branch point and 10 lines of code duplicated. Page 22 of 31

23 Drawing the high-level architecture on a whiteboard should take 5 minutes Unbalanced components, aim for 6 to 12 components of approximate equal size Cyclic dependencies between architecture components Page 23 of 31

24 Aim for a balanced architecture and avoid cyclic dependencies Clear hierarchy, directed dependencies, between 6 12 components C1 C2 C1 C3 C2 Unbalanced components, aim for 6 to 12 components of approximate equal size C1 C2 C3 C4 C9 C5 C6 C7 C8 C3 C4 C5 C11 C12 C13 C14 C10 C1 C2 C6 C8 C7 C3 C4 C8 C5 Cyclic dependencies between architecture components C6 C7 Page 24 of 31

25 Tool support? Page 25 of 31

26 Page 26 of 31

27 Page 27 of 31

28 Page 28 of 31

29 Page 29 of 31

30 Better Code Hub Improve what matters online integration with GitHub > Learn > Train > Work Backlog & Documentation Team Communication Version Control Product Quality Continuous Integration Cloud Hosting Analytics Page 30 of 31

31 Take away Theory > Code quality can be measured > Appropriate selection and aggregation of metrics is key > Maintainability is fundamental to software quality in general > Sustainable business requires maintainable software Practice > Read the book > Use the Better Code Hub (bettercodehub.com) > Check, discuss, improve > Report back Page 31 of 31

32 Contact GETTING SOFTWARE RIGHT