Kwaliteit van code

Transcript

1. Kwaliteit van code 1
2. Agenda  Waarom is codekwaliteit belangrijk?  Hoe wordt codekwaliteit bepaalt?  Hoe schrijf ik code van de juiste kwaliteit? 2
3. Functional vs technical quality  Kwaliteit is subjectief  Kwaliteit betekent veel verschillende dingen voor verschillende mensen  Waarom is kwaliteit belangrijk?  Functionele kwaliteit − Doet het wat het moet doen? (belangrijk voor nu)  Technische kwaliteit − Is het goed gebouwd? (belangrijk voor morgen)  “Software with high technical quality can evolve with low costs and risk to keep meeting functional and non-functional requirements” [SIG 2011] 3
4. De veranderende industrie  Software Engineering is een relatief jong werkveld (±1950)  Vergelijkbaar met andere jonge industrieën  Automotive industry  1896: 120 jaar later: 4
5. Werkverdeling van software engineers In 2020: 30% van de engineers werkt nog aan nieuwe projecten 70% van de engineers voert onderhoud uit op bestaande software Onderhoud en renovatie worden steeds belangrijker 5 Bron: Capers Jones, Software Productivity Research, 2011
6. Perspectieven op software kwaliteit 6 ISO/IEC 25010: Software Quality Lifecycle
7. Perspectieven op software kwaliteit 7 ISO/IEC 25010: Software Engineering – Product Quality
8. Onderhoudbaarheid Maintainability: gemak waarmee een systeem kan worden aangepast − Analyzability: mate van begrijpelijkheid waar en hoe software aangepast moet worden − Modifiability: gemak waarmee een aanpassing kan worden doorgevoerd − Testability: gemak waarmee bepaald kan worden of een aanpassing correct is doorgevoerd − Modularity: mate waarin een systeem is onderverdeeld zodat een verandering in een onderdeel geen impact heeft op de andere onderdelen − Reusability mate waarin een onderdeel kan worden hergebruikt 8
9. Maintainability Audits 9
10. TÜViT Trusted Product Maintainability 10 Van software product kwaliteitsatrributen naar source-code metrieken:
11. Terminologie in Static Code Analysis Java C# System Project Set Solution Component Project / Package Project / Assembly Module Class / File Class / File Unit Method / Constructor Method / Constructor / Property 11
12. Benchmarking  Grenswaarden worden jaarlijks bijgesteld op basis van benchmarkdata van 200 systemen  TUViT 4 = **** behoort tot 35% beste systemen in benchmark  TUViT 3 = *** marktgemiddelde  TUViT 2 = ** weggooien en opnieuw beginnen 12 * ** *** **** ***** 5% 30% 30% 30% 5%
13. Voorbeeld: Unit Complexity  System Property: Unit Complexity − Impacts Testability + Analyzability  Metric: Cyclomatic Complexity (per unit) 13 Academisch Gevoelsmatig Realiteit Aantal unieke paden door de code (McCabe 1976) Aantal beslispunten in de code Aantal keywords (+1) ! if, for, foreach, case, etc.. Cyclomatic Complexity = 2
14. Zelf metrieken berekenen en code analyseren  Vanaf Visual Studio 2012 Premium: Static Code Analysis tools − Code Metrics − Code Clones − Code Analysis 14
15. Zelf berekenen  Roslyn Compiler Platform (https://github.com/dotnet/roslyn) 15
16. Benchmarking 16 Bron: Alves, Tiago L., Christiaan Ypma, and Joost Visser. "Deriving metric thresholds from benchmark data." Software Maintenance (ICSM), 2010 IEEE International Conference on. IEEE, 2010.
17. Resultaat 17 Bron: http://sig.eu
18. Voorbeeld van onderhoudbaarheidsmeting 18
19. Maintainability vs Issue Handling  Bugs en wijzigingen kunnen sneller worden opgelost met een hogere technische kwaliteit van source-code! 19 Bron: Bijlsma et al. "Faster issue resolution with higher technical quality of software." Software quality journal 20.2 (2012): 265-285.
20. Hoe schrijf ik code die goed te onderhouden is?  Metrieken zijn een middel en geen doel  Cheating the metric  Maak gebruik van principes en best-practices uit het software engineering werkveld  Refactoring is nooit klaar! Het kan altijd beter. Metrics kunnen helpen om te bepalen wanneer te stoppen met refactoring. 20
21. Hoe schrijf ik code die goed te onderhouden is? Software Craftsmanship:  SOLID Principles − Single Responsibility Principle − Open/Closed Principle − Liskov Substitution Principle − Interface Segregation Principle − Dependency Inversion Principle Best-Practices:  Design Patterns  Encapsulation / Information Hiding  Coding standards  Unit Testing / Mocking frameworks / Dependency Injection  Domain Driven Design: Refactoring  kans om domeinkennis te vangen in code! 21
22. Hoeveel kwaliteit?  Kwaliteit inbouwen kost tijd en geld  Microsoft Research: TDD of Visual Studio 35% extra doorlooptijd vs 60% verbetering van defect density  Hoeveel % code coverage? 22 Bron: TIOBE Quality Indicator
23. Boodschap  Focus van het software engineering werkveld veranderd  Technische kwaliteit vergemakkelijkt het doorvoeren van aanpassingen  Metrics kunnen inzicht geven in technische kwaliteit  Principles en practices kunnen helpen om de technische kwaliteit te verbeteren  Kwaliteit kost tijd en geld en dient afgewogen te worden 23
24. Pepijn van de Kamp E-mail: pepijn.van.de.kamp@ordina.nl Twitter: @p3pijn
25. 25 www.ordina.nl