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
akitotsukahara
.png){kind=avatar}
honmarkhunt
manfredsteyer
seike460
74th
yodakeisuke
chobishiba
tosuri13
kajitack
lnit
ryosukedtomita
uki00a
addyosmani
shpigford
morganepeng
danielanewman
dougneiner
rocio
destraynor
jcasabona
sonatard
reverentgeek
palkan
garrettdimon
