Codekwaliteit - Hoe bereik ik dat?

Presentatie van de Code & Comedy Software Engineering conferentie bij Ordina.

Transcript

1. Codekwaliteit Hoe bereik ik dat? Pepijn van de Kamp @p3pijn #codecomedyordina
2. Introductie • Pepijn van de Kamp • Architect / Consultant Software Engineering Ordina Software Development – Gespecialiseerd in analyseren van technische kwaliteit van softwaresystemen • Interessegebieden: – Software Construction – Meta-programmeren • Compilerbouw • Parsing • Statische Code Analyse • Software Visualisatie
3. Source Code “A collection of computer instructions written using some human-readable computer language” “source code is often transformed by a compiler program into low-level machine code understood by the computer”
6. • Hoeveel regels code schrijft een developer gemiddeld per dag?
7. • Hoeveel regels code schrijft een developer gemiddeld per dag? • 18 tot 40 regels (afhankelijk van taal en stijl) uitkomst van onderzoek naar 5.000 software projecten Bron: Function Points as a Universal Software Metric, Capers Jones, 2013
8. Niet alleen code schrijven • Het werk van de developer bestaat vooral ook uit: – Leren over het probleemdomein – Begrijpen van de huidige technische oplossing – Communicatie met peers. – Etc…
9. Time for some code
10. Tokens 208 tokens
11. Class with members 1 class with 2 members
12. Control Flow / Error Handling 2 decision points 1 catch
13. Data Flow: Definitions / Uses 8 variables 16 definition / use pairs
14. Bron: Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
15. Bron: Sach, 2008 Budget besteding: Initiele ontwikkeling vs Beheer
16. Technische kwaliteit → Oplostijden Bron: Bijlsma et al. "Faster issue resolution with higher technical quality of software." Software quality journal 20.2 (2012): 265-285.
17. Change… • … is de belangrijkste driver van Software Projecten: – Het kunnen begrijpen van code is een cruciaal onderdeel – Code is een communicatiemiddel – Code wordt veel meer gelezen dan geschreven
18. Goede code is… • Gemakkelijk te begrijpen • Gemakkelijk aan te passen
19. • Symptomen – Veel duplicatie • Code clones / Copy-Paste – Aanzienlijke omvang en complexiteit • Grote classes / methodes (veel regels code) • Complexe methodes (veel beslispunten) – Afhankelijkheid • Verwijzingen naar andere modules/classes Symptomen Hoe herken je “slechte” code?
21. Systeem: smallsqldb Textuele duplicatie: 16% Duplicatie Source codestructuur die op meerdere plaatsen in een programma herhaald wordt. • Kan ontstaan wanneer developers bestaande code niet durven aan te passen. (COPY PASTE) • Onderhoud dient plaats te vinden op elke code clone (Foutgevoelig!)
22. Omvang • Aantal regels code in een class/methode/functie • Aantal beslispunten in een class/methode/functie • Lastig te begrijpen • Lastig te hergebruiken (dus bron voor code cloning)
23. Afhankelijkheid
24. Afhankelijkheid De mate waarin source codestructuren afhankelijk zijn van andere source codestructuren. (bijvoorbeeld: classes, functions, modules, etc) • Veel inkomende verwijzingen: Een kleine aanpassing kan leiden tot veel aanpassingen in afhankelijke source codestructuren. (Ripple Effect) • Veel uitgaande verwijzingen: Lastig in isolatie te (unit)testen
25. • Symptomen – Veel duplicatie • Code clones / Copy-Paste – Aanzienlijke omvang en complexiteit • Grote classes / methodes (veel regels code) • Complexe methodes (veel beslispunten) – Afhankelijkheid • Verwijzingen naar andere modules/classes Oorzaken van verslechtering van codekwaliteit
26. Hoe heeft dit kunnen gebeuren?
27. Oorzaken van verslechtering van codekwaliteit • Technische kwaliteit is onzichtbaar  code-base is een black box • Verantwoordelijkheden van classes nemen toe over tijd • Functionele druk (geen tijd voor technische verbeteringen) • Developers komen en gaan, kennis over de codebase gaat verloren • Geen unit tests die werking demonstreren en controleren • Onzekerheid over het doen van aanpassingen in complexe code • Sub-optimaal gebruik van geldende principes binnen technologieparadigma (OOP / functioneel)
28. Mogelijke oplossingen tegen verslechtering van codekwaliteit
29. Maak technische kwaliteit zichtbaar • Gebruik een kwaliteitsdashboard (SonarQube, FitNesse, etc). • Source Code Metrics • Coding Standards • Quality Gates • Static Code Analysis (vindt potentiele defecten) • Stel realistische doelen voor het verbeteren van kwaliteit. • Stel eisen op waar nieuwe code aan moet voldoen (DoD) • Nieuwe code moet voldoen aan de gestelde regels. Zorg voor snelle feedback d.m.v. integratie in delivery pipeline.
30. Keep it simple (and small)!
31. • Richtlijnen volgens SIG: • Limiteer de lengte van units tot 15 regels • Limiteer het aantal beslispunten binnen een unit tot 4 • Limiteer het aantal parameters van een unit tot 4 • Limiteer de lengte van modules tot 400 regels Bron: Joost Visser, “Building Maintainable Software”, 2015 Keep it simple (and small)!
32. Don’t Repeat Yourself (DRY) 1/2
33. Don’t Repeat Yourself (DRY) 2/2 Abstractie • Welke code is gelijk voor alle varianten?  (abstract) Super-class • Waar zit variabiliteit?  Sub-classes Bron: Ochimizu, Higashida, "Object Modeling"
34. Pas principes en technieken toe uit paradigma Een aantal suggesties: • Abstraction / Problem Decomposition • SOLID principles • Polymorphism over control structures • Encapsulation / Information Hiding • Law of Demeter • Design Patterns • Domain-Driven Design Verwacht: voorjaar 2016: Cursus Codekwaliteit
35. Schrijft nooit nieuwe code zonder tests • Unit-tests documenteren en demonstreren de verwachte werking van code • Unit-tests helpen bij snelle verificatie van aanpassingen (op het code level) • Side-effect: Onderhoudbaar design • Klein • Simpel • Onafhankelijk
36. Take-aways • Codekwaliteit beinvloedt gemak waarmee code kan worden aangepast. • Symptomen: – duplicatie, omvang, coupling, code smells, etc • Oplossingen: – Zichtbaarheid, simpel, klein, herbruikbaar, onafhankelijk, unit testing, etc
37. Codekwaliteit • Aanbevolen literatuur:
38. Codekwaliteit Hoe bereik ik dat? Pepijn van de Kamp @p3pijn #codecomedyordina