Man stelle sich mal eine Firma mit zwei gro\u00dfen Entwickler-Teams vor.
Beide Teams arbeiten unter denselben knappen Ressourcen am gleichen Produkt.
Features m\u00fcssen entwickelt- und weite Landschaften im Code stark abge\u00e4ndert werden.
Aus organisatorischen Gr\u00fcnden, werden die forks nur sporadisch gemergt.<\/p>\n\n\n\n
Team A entwickelt verantwortungsbewusst und professionell jedoch ohne gro\u00dfartig auf Tests zu achten. Die Zeit ist knapp und der Product Owner will Resultate sehen, stabiler oder gar sch\u00f6ner Code ist zweitrangig. Kernfeatures sind durch Unit-Tests abgedeckt, alles andere h\u00e4ndisch von mindestens zwei Instanzen abgesegnet.<\/p>\n\n\n\n
Team B folgt dem Prinzip von TDD. Nicht nur eine Handvoll Unit-Tests, sondern das komplette Programm: Integration-, Smoke- und Snapshot-Tests, hohe Testabdeckung, you name it.<\/p>\n\n\n\n
Nach Monaten der Entwicklung kommt dann der Zeitpunkt, in dem beide Teams ihre Arbeit mergen m\u00fcssen. Team B hat nun einen entscheidenden Vorteil: noch bevor das Produkt das Licht des Monitors erblicken konnte, meldete der Build-Prozess, dass einiges im Argen liegt.
Die Fehler ausfindig zu machen, zu identifizieren und zu beheben sind da nur eine reine Flei\u00dfarbeiten die sich mit relativ wenig personellem Aufwand l\u00f6sen lassen. Bei Team A sieht das ganze anders aus.
Funktionieren die Features noch? Das erf\u00e4hrt man erst wenn sich jemand die Zeit nimmt und das Programm h\u00e4ndisch testet. Falls nicht, wo liegt der Fehler im Code? Das kann nur der Entwickler sagen, der das Feature implementiert hat. Im besten Fall hat besagter Entwickler eine Kleinigkeit \u00fcbersehen, im schlimmsten Fall handelt es sich um eine Regression durch den Merge.<\/p>\n\n\n\n