Foren-Tage 2017: Software-Qualität

Die Folien für meinen Vortrag über Software-Qualität, gehalten am 23.09.2017 auf den Foren-Tagen in Hamburg.

Transcript

1. Das kleine 1x1 der Software-Qualität Foren-Tage 2017, Hamburg Sebastian P.R. Gingter @PhoenixHawk Delphi-PRAXiS: Phoenix
2. Oder: “Warum Qualität nicht einfach aus dem Compiler fällt” Das kleine 1x1 der Software-Qualität
3. Warum Software-Qualität?
4. Stichwort: Versicherung
5. Versicherung kostet immer Geld
6. Schäden kosten immer Geld
7. Qualitätsmaßnahmen sind ein Kompromiss zwischen Versicherungs- und Schadenskosten
8. Qualität kostet Geld
9. Zeit = Geld
10. Fokus: möglichst wenig Aufwand für möglichst viel Qualität
11. Mindestanforderungen
12. Quellcodeverwaltung & -versionierung
13. CVS / VSS
14. SVN / Git / Hg / TFS
15. Bugtracking
16. Bug- & Feature-tracking
17. Change- Bug- & Feature-tracking
18. Excel / Word
19. YouTrack, Mantis, Jira, Bugzilla, Roundup, Redmine, FogBugz, OnTime, TFS, …
20. Idealfall: mit Source-Verwaltung integriert
21. Idealfall: mit Zeiterfassung integriert
22. Disziplin
23. Bug: Beschreibung Reproduktionsschritte Begründung Lösung Aufgewendete Zeit
24. Feature: Präzise Beschreibung Dokumentation Herangehensweise Aufgewendete Zeit Beschreibung der Tests
25. Checkins / Commits NUR mit Tracker- #ID
26. Continuous Integration / Buildserver
27. Idealerweise: Integriert mit Quellenverwaltung Integriert mit Bug- / Featuretracking
28. Jeden Commit auf jedem Branch automatisch bauen lassen
29. Ermöglicht jeden einzelnen Commit auch zu testen
30. Warum?
31. Wir brauchen Kontrolle
32. Nachverfolgbarkeit
33. Disziplin
34. Produktivität und Gewissenhaftigkeit
35. Nachverfolgbarkeit Disziplin Produktivität und Gewissenhaftigkeit
36. Warum Quellcodeverwaltung und Bugtracking?
37. • Selbst kleinste Änderungen werden Seiteneffekte haben • Was geändert wurde zeigt die Quellcodeverwaltung • Warum das geändert wurde, zeigt nur die Begründung im Bug- / Feature-Tracker • Nur mit dem Wissen was warum geändert wurde, kann ein Fehler verläßlich behoben werden ohne • vorherige Bugfixes oder • andere Features wieder zu beschädigen
38. Warum Continuous Integration?
39. • Entdeckt Fehler sofort • Schnellstmögliches Feedback • Das etwas kaputt gegangen ist • Was kaputt gegangen ist und • Warum es kaputt gegangen ist • Warum schnellstmöglich? • Entwickler ist geistig noch im Thema • Kann Fehler sofort ohne erneutes Eindenken beheben • Andere Entwickler wissen um den Fehler und arbeiten nicht auf kaputten Code weiter • Ermöglicht automatisiertes Testen ohne großen Zusatzaufwand
40. Quellcodeverwaltung Bug- & Feature-Tracking Continuous Integration
41. Nachverfolgbarkeit Disziplin Produktivität und Gewissenhaftigkeit
42. Noch eine Grundvorraussetzung:
43. Clean Code
44. Nicht die Bewegung
45. Einfach nur ‘sauberer’ Code Clean Code, Robert C. Martin, Prentice Hall
46. Disziplin
47. Noch eine Grundvorraussetzung:
48. Wollen
49. Einfache & Billige Maßnahmen
50. Der Entwicklungsprozess muss Qualität als Ziel haben
51. Keine separate oder Nachgelagtere Qualitätssicherung kann so günstig sein
52. Mögliche Versicherungen einführen
53. Versicherung: Automatisierung
54. Automatisiere!
55. Automatisiere wiederkehrende Aufgaben
56. Automatisiere fehlerträchtige Aufgaben
57. Automatisiere nervende Aufgaben
58. Mögliche Fehlerquellen eliminieren
59. Versicherung: “Stabile Branches”
60. Branching-Modell muss an den eigenen Prozess angepasst werden
61. • “Stabile Branches” • Geben Sicherheit das • Eine stabile Version • zu jedem beliebigen Zeitpunkt • released werden kann
62. • Anforderungen an “stabile Branches” • Nur in branches Entwickeln, nie in trunk/master • Features • Bugfixes • Nur dann in release-branch integrieren wenn • Alle Tests positive abgeschlossen sind • Man in die Stabilität der Änderungen Vertrauen hat
63. Beispiel: develop /releases/1.0 /releases/2.0 /features/x /features/z /bugfixes/1 /bugfixes/1
64. Verhindert halbgare Features
65. Verhindert, das notwendige Releases blockiert werden
66. Verhindert, auszuliefern
67. Ermöglicht, jederzeit fertige Features ohne unfertige Features auszuliefern
68. Zu Beginn etwas mehr Aufwand bis man sich an das Branching-Modell gewöhnt
69. Kleine Änderung
70. “Aber”: Erfordert gutes Versionierungs-Tooling
71. Versicherung: Training
72. Gebt Entwicklern Zeit zum trainieren/lernen
73. Zielgerichtet / Unternehmensrelevant
74. Zeit = Geld
75. Investierte Zeit ist durch höhere Qualität, Effizienz & Motivation Geld Wert
76. Zugriff auf online-Ressourcen geben (Pluralsight, Egghead, etc…)
77. Am wichtigsten:
78. Gelegenheit und Raum zum Scheitern einräumen
79. Menschen lernen sehr gut durch Fehler
80. Hacking nights Couch coding Nebenprojekte
81. Viel Gelegenheit um Fehler zu machen & zu lernen ohne das Produkt zu belasten
82. • Vorteile von Training: • Bessere Entwickler • Weniger Fehler (im Produkt) • Höhere Motivation • Bessere Architektur
83. Versicherung: Review
84. Vorsicht: Problematisch
85. Intuitiv: Review vor dem Reintegrieren
86. Coding-Style richtig?
87. Dafür gibts eine App
88. • Tooling für Delphi: • http://www.codehealer.com/codehealer.php • http://www.peganza.com/products_pal.html • https://sourceforge.net/projects/dca • https://github.com/fabriciocolombo/sonar-delphi • Tooling für .NET: • FxCop • StyleCop • Resharper
92. • Code Review Vermutlich wird es falsch gemacht • Code reviews lenken ab • WTF WTF WTF • “Was hat der sich bloß dabei gedacht?!?!?!” • Reviewer benötigt zu viel Zeit zum eindenken • Unproduktiv und Zeitfressend • Review tendiert schnell zum Mobbing • “Halt Dich gefälligst an die Guidelines” • “Aber es weiß doch *jeder* das wir hier {ungeheuer spezielles Zeug} machen”
93. Nicht machen!
94. ?
95. Ja: Lieber keine reviews machen.
96. • Wenn Code Reviews: • “Over the shoulder reviews“ • Entwickler sucht sich Reviewer aus (Vertrauen!) • Entwickler geht zu ihm persönlich hin • Entwickler erklärt, was er gemacht hat • Reviewer stellt Fragen und weist auf mögliche Probleme hin • Entwickler macht sich Notizen • Entwickler macht Änderung nach eigener Auswahl • Entwickler commited
97. Was sonst, wenn keine Reviews?
98. Versicherung: Pair Programming
100. ABER!!! *schnappatmung* TEUER!!!
101. Nö! http://alistair.cockburn.us/costs+and+benefits+of+pair+programming
102. • Kosten von Pair Programming • Mehraufwand in Stunden • Übliche Schätzung: • 100% oder x 2 (sitzen ja dann zwei Leute dran) • Realer Mehraufwand: • 50% initial, während sich das Pair einspielt • 15% durchschnittlich nach der Einspiel-Phase
103. Moment mal…
104. … 15 % Mehraufwand …
105. … mit ZWEI Entwicklern …
106. … das bedeutet doch… ?!?!?!
107. Ja: Es macht die Entwicklung schneller!
108. Einzelner Entwickler • Aufgabe: 8h • Alleine: x1  8h • Alleine: 8h / 1 Person  8h • Ein voller Tag Paar • Aufgabe: 8h • Zusammen: x1.15  9,2h • Zusammen: 9,2h / 2 Person  4,6h • Halber Arbeitstag + bissl mehr als ne halbe Stunde Ein bissel Mathe:
109. • Vorteile von Pair Programming • Schneller Time-to-Market • ca. 15% weniger Fehler im Code • Da Fehler im Nachgang zu beheben teurer ist, als sie gleich beim Entwickeln zu bemerken, spart das allein schon mehr als das Pair overhead erzeugt • ca. 20% weniger Zeilen an Code • Bessere Architektur • Verteiltes Wissen im Team • Höhere Motivation (Zusammen macht’s mehr Spass) • Weniger Ablenkung (Zusammen surft man nicht auf Facebook)
110. Versicherung: Unit Tests
111. ABER!!! *schnappatmung* TEUER!!!
112. Nö! http://blog.jphpsf.com/2012/09/30/OMG-test-driven-development-actually-works https://www.typemock.com/blog/2009/03/the-cost-of-test-driven-development.html
113. Das wichtigste: Es funktioniert
114. Aber NUR:
115. Mit Disziplin und ‘Tests firsts’-Einstellung
116. ‘Tests after’ ist gleich ‘Tests never’
117. Versicherungen muss man auch im Voraus bezahlen
118. ‘’Unseren Erfahrungen und den ermittelten Ergebnissen nach weist alles auf den Fakt hin, dass TDD in den unterschiedlichsten Domänen eingesetzt werden kann und die Defekt-Rate signifikant reduzieren kann, während die Produktivität nicht signifikant reduziert wird.“ Quelle: Nachi Nagappan, Microsoft ESE Group https://www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf
120. Übrigens…
121. Falls ihr konkrete Zahlen haben wollt…
122. … die stecken in Eurem Tracking!
123. • Probleme mit TDD • Existierender Code ist extrem schwer bis gar nicht testbar • Code ist nur dann wirklich testbar, wenn er für Tests geschrieben wurde • Auch neue Features in existierendem Code sind schwer mit TDD zu testen • (Gute) Tests zu schreiben ist nicht einfach • Insbesondere, wenn es noch keine TDD-Kultur und Mentoren gibt
124. • Erste Schritte • Neuen Code mit TDD schreiben • Mit einfachen, isolierten Features starten • Sich langsam daran gewöhnen • Wenn nicht getestete Infrastruktur verwendet wird, diese mit etwas Mock-barem wegabstrahieren • Tests für existierenden Code nur • Wenn man größere Refactorings machen muss • Wenn man einen Bug fixen muss und der Code testbar ist • Oder mit wenig Zusatzaufwand testbar gemacht werden kann
125. Versicherung: Produktivität
126. Achtung: Teuer!
127. Gebt Entwicklern die besten Tools die man für Geld kaufen kann.
128. Sowohl Software, als auch Hardware
129. Keyboard, Mouse, höhenverstellbarer Tisch, zweiter, dritter oder gar vierter Monitor, CodeRush, ReSharper, Redgate SQL Toolbelt, LinqPad, GitKraken, …
130. Gebt Motivation: Hacknights, Meetups, Coachings, Kurse, Dokumentationen,…
131. Nachverfolgbarkeit Disziplin Produktivität und Gewissenhaftigkeit
132. Wollen
133. Vielen Dank!
134. Quellen: • Literatur: • “Clean Code “ by Robert C. Martin • Links: • https://www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality- Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams- nagappan_tdd.pdf • http://alistair.cockburn.us/costs+and+benefits+of+pair+programming • http://blog.jphpsf.com/2012/09/30/OMG-test-driven-development-actually-works • https://www.typemock.com/blog/2009/03/the-cost-of-test-driven-development.html