Bei der Paarprogrammierung kann die Erfahrung jedes Teammitglieds auf neue Mitglieder übertragen werden. Diese Erfahrung ist immer synchron mit dem Code, weil der "Senior" des Paares weiß, wie der Code funktioniert und was das Design ist.
Was ist der Nutzen der Entwurfsdokumentation in diesem Fall?
AKTUALISIEREN
Ich unterstelle kein Design, ich unterstelle keine Dokumentation. Mit einem Team, das Paar-Programmierung praktiziert, denke ich, dass jeder wegwerfbar ist, weil jeder den Code kennt. Wenn der leitende Entwickler abreist, denke ich, dass es immer mindestens eine Person gibt, die den Code kennt, weil die Erfahrung vorher geteilt wurde.
Was ist, wenn Ihr Team größer als 2 Personen ist?
Nur weil zwei Leute einen Teil eines Systems kennen, heißt das nicht, dass es nicht dokumentiert werden sollte.
Und ich wäre froh zu wissen, dass ich mich nicht an jedes kleinste Detail eines Systems erinnern muss, nur weil es nirgends anders als in meinem Kopf gespeichert ist.
Für ein kleines System mag das funktionieren, aber wenn das System größer wird, beschränkt sich das auf Sie und Ihre Kollegen. Ich würde lieber die Speicherkapazität für ein neues System verwenden, als sich an alles vom alten System zu erinnern.
Der Satz von zu erbringenden Leistungen sollte unabhängig davon entschieden werden, ob Sie die Paarprogrammierung verwenden oder nicht.
Sechs Monate oder zwei Jahre später könnten alle beteiligten Personen in einem anderen Projekt (oder einer anderen Firma) sein. Möchten Sie zurückkommen und die Konstruktionsdokumentation verwenden können? Dann produziere es. Wenn Sie nicht zurückkommen wollen oder das Design einfach genug ist, dass Sie es mit den Spezifikationen und dem Code ohne die Hilfe eines expliziten Designdokuments verstehen können, dann können Sie es überspringen.
Aber verlassen Sie sich nicht darauf, dass die beiden Ihnen das Design ein Jahr später erklären.
Wartung. Sie können nicht erwarten, dass das Team statisch bleibt, weil es keine neuen Mitglieder gibt oder alte Mitglieder verloren gehen. Die Design-Dokumentation stellt sicher, dass diejenigen, die neu in dem Projekt sind, die Jahre darauf warten müssen, Informationen darüber haben, welche Entscheidungen getroffen wurden, warum der Ansatz gewählt wurde und wie er umgesetzt werden sollte. Für den langfristigen Erfolg eines Projekts ist es sehr wichtig, diese Dokumentation zu haben, die über eine Kombination aus traditionellen Dokumenten, Quellenkommentaren, Komponententests und verschiedenen anderen Methoden bereitgestellt werden kann.
Ich sehe nicht, dass diese Paarprogrammierung die Designdokumentation überflüssig macht. Ich muss sofort an den Truck-Faktor denken. Klar, der Senior weiß vielleicht, was das Design ist. Aber was passiert, wenn er krank ist? Was passiert, wenn er > von einem Lastwagen angefahren wird? Was ist, wenn er gefeuert wird?
Paar-Programmierung verbreitet zwar Wissen, aber es tut nie weh, dieses Wissen zu dokumentieren.
Wer kennt den zuerst geschriebenen Code? Die Antwort ist niemand weiß, weil es nicht geschrieben wurde. Der Grund, warum es nicht geschrieben wurde, ist, weil niemand weiß, was zu tun ist, daher die Notwendigkeit für ein Design-Dokument.
Bei der Paarprogrammierung teilen sich nur zwei Personen einen Computer. An sich sagt es nichts darüber aus, welche Art von Entwurfsmethodik das Paar / die Paare verwenden.
Paar-Programmierung, wenn Sie als Teil von Extrem Programmierung " bedeutet, die Extreme Programming Richtlinien für Design zu befolgen. Dies beinhaltet typischerweise das Sammeln und Codieren von "User Stories". Diese Geschichten würden dann anstelle anderer Design-Dokumentation stehen.
Die Erfahrung von Menschen kann mit dem Code übereinstimmen, wie Sie sagen. Aber die Designentscheidungen werden nicht alle im Code erfasst - nur die getroffenen Entscheidungen sind vorhanden.
Um wirklich zu verstehen, warum Code so konzipiert ist, wie er ist, müssen Sie nach meiner Erfahrung wissen, welche Designentscheidungen nicht getroffen wurden, welche Ansätze versucht und gescheitert haben usw. Sie können hoffen, dass das "chinesische Flüstern" chain überträgt das korrekt, da dies im Code nicht aufgezeichnet wird, um Speicher zu aktualisieren oder Fehler zu korrigieren ...
... oder Sie können eine Dokumentation über das Design und wie es dazu gekommen ist schreiben. Auf diese Weise vermeiden Sie, in Zukunft von den Wartungsprogrammen in eine dunkle Gasse gezogen zu werden.
Hängt davon ab, was Sie unter "Design-Dokumentation" verstehen.
Wenn Sie Funktionstests haben - insbesondere BDD-Tests (Behavior-Driven Development) oder Fitnesse- oder FIT-Tests - dann sind sie sicherlich eine "aktive Dokumentation" ... und das haben sie sicherlich Wert sowie als Regressionstests.
Wenn Sie User Storys schreiben und sie in Aufgaben aufteilen und diese Aufgaben auf Karten schreiben, damit Paare tun, dann machen Sie eine Art Dokumentation ...
Das sind die zwei Hauptformen der Dokumentation, die ich in XP-Teams verwendet habe, die den gesamten Produktionscode koppeln.
Das einzige andere Dokument, das ich als ziemlich nützlich empfinde, ist eine halbe Seite oder so viele Aufzählungszeichen, die zeigen, wie man die Build-Umgebung für einen Entwicklungscomputer einrichtet. Sie sollten die Liste beibehalten, während Sie sie verwenden.
Wenn Sie ein Tabellenkalkulationsprogramm anstelle eines Textverarbeitungsprogramms verwenden möchten, ist ein Designdokument nützlich: -)
XP, paarweise Programmierung, agil, etc ... bedeutet nicht, dass Sie keinen Plan haben, es ist nur ein viel weniger detaillierter Plan (auf der Mikroebene) von dem, was vor sich geht. Die Anwendungsfälle, die der Benutzer wählt, sind mehr von dem Design, und es ist mehr ein lebendiges Dokument als mit anderen Arten von Design / Programmierung.
Fallen Sie nicht in die Falle, weil Sie etwas "Cooles" tun, dass Sie keine guten Praktiken mehr brauchen - tatsächlich erfordert diese Art der Programmierung mehr Disziplin als weniger, um erfolgreich zu sein.
Die Paarprogrammierung ist eine Gelegenheit für das Team, zu vermeiden, dass ein großer Teil der Projektzeit für die Dokumentation von allem aufgewendet werden muss. Aber der Bedarf an Dokumentation hängt davon ab, wie gut Sie sich daran erinnern, was wichtig ist und wie gut Ihr Code ist. Sie können immer noch eine Menge Dokumentation wünschen, wenn mit dem Code schwer zu arbeiten ist.
Sie könnten einige Experimente ausprobieren: -
Nein Auch mangelnde Paarprogrammierung bedeutet, dass Sie Dokumentation benötigen. Dokumentation ist erforderlich! Wie es aussieht, kann Sie überraschen!
Ein agiles Team entscheidet, wann und welche Dokumentation benötigt wird. Eine gute Faustregel, wenn niemand es lesen wird, schreibe es nicht. Lassen Sie sich nicht vom Artefakt des Wasserfall-Artefakts ablenken, indem Sie Artefakte bereitstellen, weil der Projektmanager dies sagt.
Die meisten denken an Dokumentation als etwas, das Sie mit Word machen. Wenn ein agiles Team ordnungsgemäß arbeitet, wird der Code selbst mit TDD (testgetriebene Entwicklung) eine Reihe von automatisierten Tests enthalten, die die Anforderungen dokumentieren und durchsetzen. Bild, Dokumentation, die mit dem Code übereinstimmt ... und das bleibt so.
Nachdem das gesagt wurde, hilft die Paarung, das Wissen über die Bereiche Domäne, Anwendung, Praxis und Fähigkeiten sehr schnell durch das Team zu verbreiten. Durch die Paarung wird außerdem sichergestellt, dass das Team die technischen Verfahren wie TDD und andere automatisierte Tests einhält. Die Ergebnisse sind, dass die Anwendung gesund bleibt und zukünftige Änderungen leicht herbeigeführt werden können.
Unter dem Strich ergibt die Paarprogrammierung eine bessere Dokumentation. Es beseitigt keine Dokumentation (obwohl Sie möglicherweise kein Word-Dokument finden können).
Ich bin ein Befürworter und ein Fan von Dokumentation. Bei der Paarprogrammierung ist kein "Ein älterer Entwickler" erforderlich. Nach meiner Erfahrung mit der Paarprogrammierung werden Entwickler aller Ebenen für eine schnelle Entwicklung paarweise zusammengeführt. Ich habe oft mit Junior-Entwicklern gearbeitet und würde auf der Tastatur handeln. Es gab viele Male, die ich mit älteren Architekten arbeitete und auf der Tastatur handeln würde. Dokumentation ist immer noch notwendig, insbesondere mit Ihren Kernkomponenten und der Datenbank.
Paar-Programmierung aktiviert nur Ihre Kodierung und logischen Aspekt.
Aber Dokumentation ist eine gute Übung. Immer Dokumentation machen ...
Tags und Links extreme-programming pair-programming