Q U A L I TÄT, K Ä S E U N D S P I E L E
D E V S U M M I T 2 0 2 2 | 2 2 . 0 6 . 2 0 2 2 | O L I V E R K L E E | @ O L I K L E E | O L I K L E E @ C H A O S . S O C I A L
Slide 2
Slide 2 text
Ü B E R M I C H
Oliver „Oli“ Klee
#bonn
#extension-dev
#workshop-teacher
#unit-testing-guy
#typo3-ombudsperson
#typo3-quality-assurance-initiative
#gamification-working-group
#game-cooking
#powermetal
Slide 3
Slide 3 text
Q U A L I TÄT
Slide 4
Slide 4 text
WA R U M M E H R Q U A L I TÄT F Ü R S O F T WA R E ?
weil wir es den Kund:innen versprechen
weil wir stolz auf unsere Arbeit sein wollen
weil wir zu alt für den schlechten Code sind
Slide 5
Slide 5 text
WA S I S T Q U A L I TÄT ?
es gibt wenige Bugs
wir spielen kein Jenga
der Code ist leicht änderbar
Upgrades und Refactorings sind risikoarm
Slide 6
Slide 6 text
K Ä S E
Slide 7
Slide 7 text
D A S S C H W E I Z E R - K Ä S E - M O D E L L
https://commons.wikimedia.org/wiki/File:SwissCheese_Respiratory_Virus_Interventions_GERMAN.jpg
Slide 8
Slide 8 text
K Ä S E S O R T E N F Ü R S O F T WA R E Q U A L I TÄT
statische Codeanalyse (Syntax, Stil, Typen …)
automatisierte Tests (Unit, Functional, …)
Code-Reviews
Slide 9
Slide 9 text
S P I E L E
Slide 10
Slide 10 text
L E V E L S U N D K L A R E Z I E L E
Slide 11
Slide 11 text
L E V E L S U N D K L A R E Z I E L E
Rule-Levels bei PHPStan und Psalm
Baseline-Datei mit Blockliste
Regeln nach und nach einschalten
Tests nur bei Codeänderungen schreiben
eine Klasse pro Woche mit Tests abdecken
Slide 12
Slide 12 text
M I T H E R A U S F O R D E R U N G E N S P I E L E N
Welches Rule-Level können wir erreichen?
Welche Code-Coverage kriegen wir hin?
Wie wenige Mutations entkommen uns?
Wie weit können wir testgetrieben entwickeln?
Was können wir alles automatisieren?
Slide 13
Slide 13 text
V I E L S PA ß B E I M D E V S U M M I T 2 0 2 2 !
D E V S U M M I T 2 0 2 2 | 2 2 . 0 6 . 2 0 2 2 | O L I V E R K L E E | @ O L I K L E E | O L I K L E E @ C H A O S . S O C I A L