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
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
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
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”
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
Ü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
• 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:
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)
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
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
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
phoenixhawk
joergneumann
bkuhlmann
tomokusaba
josepaumard
o0h
syumai
okashoi
hinakko2
sakama
gotok365
ruzia
riofujimon
edds
jacobian
notwaldorf
akmur
searls
eileencodes
philnash
tenderlove
garrettdimon
chrisshort
destraynor
