SAP 1 - From Quality Attributes to
Code Quality
SA lessen focussen op het modelleren en designen.
- Hoe worden de requirements vervult en van requirements naar
architectuur.
SAP lessen focussen op de relatie tussen modellen en source
code
- Van model naar code en andersom
Leerdoelen:
Tactieken beschrijven en uitleggen om de onderhoudbaarheid te
verbeteren.
De ontwerpprincipes “low coupling” (lage koppeling) en “high
cohesion” beschrijven, herkennen en toepassen.
Uitleggen wat refactoring is, wat code smells en software metrics
zijn en wat de onderlinge relatie is.
De code smells uit de sheets uitleggen en herkennen in code.
Achieving Quality Attributes
Software wordt gemaakt om te kunnen voldoen aan de eisen van een business. Deze eisen
worden opgesteld binnen de requirements.
De bekende quality attributen zijn die van de ISO 25010
(performance, usability etc.). De focus van deze cursus
ligt bij het maintainability aspect.
Er zijn bepaald tactieken om maintainability te kunnen bereiken.
De meest belangrijke design
principles van Larman zijn ook
maintability tactieken:
•Low coupling
•High cohesion
•Protected variation
Deze principes kunnen worden
toegepast op architecturaal,
design en code niveau.
Jet Wardenier 27/12
, Code Smells
• Duplicated Code
Dezelfde code structuur op meerdere plekken. Je programma zal beter zijn als je een manier vind
om deze bij elkaar te voegen. Duplicated code kan bijvoorbeeld voorkomen wanneer je dezelfde
expression hebt in twee methodes van dezelfde klasse. Ook komt het veel voor dat er dezelfde
code staat in twee gerelateerde subklassen. Als code vergelijkbaar is maar niet precies hetzelfde,
moet je de verschillen en overeenkomsten van elkaar scheiden. Je moet uiteindelijk een keuze
maken waar de code het meest logisch past.
• Large class
Een klasse is vaak te groot wanneer het te veel variabelen van instanties heeft. Het makkelijkst is
om redundantie binnen de klasse zelf te verminderen. Wanneer je code uit 500 lines bestaat met
code die eigenlijk ongeveer hetzelfde zegt, kun je dit misschien verminderen naar 50 lines. Je kunt
de klasse ook uitbreiden naar meerdere subklassen, wanneer dit mogelijk is. Bij een grote GUI
klasse, kun je data en gedrag verplaatsen naar een apart domein object.
• Long method
Langere methodes zijn veel lastiger om te begrijpen en te lezen. Goede naamgeving is de beste
manier om kleine, makkelijk te begrijpen methodes te creëren. Door een goede naam te geven
aan een methode hoef je vaak de body niet te lezen om het te begrijpen.
Je kunt deze methodes vinden door op zoek te gaan naar comments binnen je code. Wanneer
een comment vertelt wat een methode moet doen is dit vaak een signaal dat het te uitgebreid is.
De naam van de methoden zou moeten vertellen wat een methode precies doet, niet de
comments.
- Cyclomatic complexity
Het meten van het aantal lineaire paden binnen een programma’s source code.
• Long parameter list
Je hoeft een methode niet alles mee te geven wat het nodig heeft. Je geeft de methode genoeg
informatie mee zodat de methode zelf op zoek kan gaan naar de verder nodige informatie. Lange
parameter lijsten zijn onhandig en lastig te begrijpen. Als de lijst te lang is of te vaak veranderd,
moet je opnieuw nadenken over de structuur van de dependencies.
• Data class
Dit zijn klassen die alleen datavelden en getters en setters voor deze velden hebben. Ze bewaren
alleen data en doen verder niks, ze worden alleen gebruikt door andere klassen. Deze klassen
kunnen bijvoorbeeld public datafields hebben, als dit het geval is wil je zo snel mogelijk deze data
inkapselen.
Kijk waar deze getting en setting methoden worden gebruikt in andere klassen. Probeer dan het
gedrag te verplaatsen naar de dataklasse. Eerst kunnen dataklassen handig zijn als beginpunt,
maar ze mogen daarna alleen blijven bestaan als ze ook daadwerkelijk een verantwoordelijkheid
hebben.
Jet Wardenier 27/12
Code Quality
SA lessen focussen op het modelleren en designen.
- Hoe worden de requirements vervult en van requirements naar
architectuur.
SAP lessen focussen op de relatie tussen modellen en source
code
- Van model naar code en andersom
Leerdoelen:
Tactieken beschrijven en uitleggen om de onderhoudbaarheid te
verbeteren.
De ontwerpprincipes “low coupling” (lage koppeling) en “high
cohesion” beschrijven, herkennen en toepassen.
Uitleggen wat refactoring is, wat code smells en software metrics
zijn en wat de onderlinge relatie is.
De code smells uit de sheets uitleggen en herkennen in code.
Achieving Quality Attributes
Software wordt gemaakt om te kunnen voldoen aan de eisen van een business. Deze eisen
worden opgesteld binnen de requirements.
De bekende quality attributen zijn die van de ISO 25010
(performance, usability etc.). De focus van deze cursus
ligt bij het maintainability aspect.
Er zijn bepaald tactieken om maintainability te kunnen bereiken.
De meest belangrijke design
principles van Larman zijn ook
maintability tactieken:
•Low coupling
•High cohesion
•Protected variation
Deze principes kunnen worden
toegepast op architecturaal,
design en code niveau.
Jet Wardenier 27/12
, Code Smells
• Duplicated Code
Dezelfde code structuur op meerdere plekken. Je programma zal beter zijn als je een manier vind
om deze bij elkaar te voegen. Duplicated code kan bijvoorbeeld voorkomen wanneer je dezelfde
expression hebt in twee methodes van dezelfde klasse. Ook komt het veel voor dat er dezelfde
code staat in twee gerelateerde subklassen. Als code vergelijkbaar is maar niet precies hetzelfde,
moet je de verschillen en overeenkomsten van elkaar scheiden. Je moet uiteindelijk een keuze
maken waar de code het meest logisch past.
• Large class
Een klasse is vaak te groot wanneer het te veel variabelen van instanties heeft. Het makkelijkst is
om redundantie binnen de klasse zelf te verminderen. Wanneer je code uit 500 lines bestaat met
code die eigenlijk ongeveer hetzelfde zegt, kun je dit misschien verminderen naar 50 lines. Je kunt
de klasse ook uitbreiden naar meerdere subklassen, wanneer dit mogelijk is. Bij een grote GUI
klasse, kun je data en gedrag verplaatsen naar een apart domein object.
• Long method
Langere methodes zijn veel lastiger om te begrijpen en te lezen. Goede naamgeving is de beste
manier om kleine, makkelijk te begrijpen methodes te creëren. Door een goede naam te geven
aan een methode hoef je vaak de body niet te lezen om het te begrijpen.
Je kunt deze methodes vinden door op zoek te gaan naar comments binnen je code. Wanneer
een comment vertelt wat een methode moet doen is dit vaak een signaal dat het te uitgebreid is.
De naam van de methoden zou moeten vertellen wat een methode precies doet, niet de
comments.
- Cyclomatic complexity
Het meten van het aantal lineaire paden binnen een programma’s source code.
• Long parameter list
Je hoeft een methode niet alles mee te geven wat het nodig heeft. Je geeft de methode genoeg
informatie mee zodat de methode zelf op zoek kan gaan naar de verder nodige informatie. Lange
parameter lijsten zijn onhandig en lastig te begrijpen. Als de lijst te lang is of te vaak veranderd,
moet je opnieuw nadenken over de structuur van de dependencies.
• Data class
Dit zijn klassen die alleen datavelden en getters en setters voor deze velden hebben. Ze bewaren
alleen data en doen verder niks, ze worden alleen gebruikt door andere klassen. Deze klassen
kunnen bijvoorbeeld public datafields hebben, als dit het geval is wil je zo snel mogelijk deze data
inkapselen.
Kijk waar deze getting en setting methoden worden gebruikt in andere klassen. Probeer dan het
gedrag te verplaatsen naar de dataklasse. Eerst kunnen dataklassen handig zijn als beginpunt,
maar ze mogen daarna alleen blijven bestaan als ze ook daadwerkelijk een verantwoordelijkheid
hebben.
Jet Wardenier 27/12
