MSP-Projektwoche Ticketbearbeitung 87 und 214
Dokumentation | |
---|---|
Arbeitstitel | MSP-Projektwoche Ticketbearbeitung 87 und 214 |
Kurs | Methoden des Software-Entwicklungsprozesses |
Semester | WS 09/10 |
Teilnehmer | Patrick Schneider, Johannes Tietje |
Programmiersprache | PHP |
Die Bearbeitung zweier Tickets des eStudy-Projektes entsteht im Rahmen der MSP-Projektwoche Wintersemester 2009/10 an der Fachhochschule Gießen-Friedberg. Als Dokumentation der geleisteten Arbeit und der Erfahrungen mit der XP-Praktik Pair-Programming wird dieser Artikel genutzt. Verantwortlich für die Bearbeitung sind Patrick Schneider und Johannes Tietje.
Inhaltsverzeichnis
Aufgabe
Die Aufgabe bestand in der Bearbeitung je eines Bug- und eines Feature-Tickets aus dem eStudy-Projektmanagementtool trac. Bug und Feature befasst sich in unserem Fall mit der Buddy-Liste des Moduls "Messaging".
Bug
Zur Beschreibung: Ticket 87.
Der Fehler besteht darin, dass Links, die Aktionen auslösen (wie in diesem Fall die Aufnahme eines Kursmitglieds in die Buddy-Liste) auch versendet und von Fremden genutzt werden können -- und somit unbewusst Konsequenzen haben können, die der Benutzer nicht überblicken kann. Die allgemeine Lösung dieses Problems wird im Abschnitt "Feature" beschrieben.
Feature
Zur Beschreibung: Ticket 214.
Aktionen, die direkte Auswirkungen haben, sollten vom Entwickler gesichert werden können. Dazu wurde die Klasse "secureLink" entwickelt, um die Übergabeparameter einer URL zu sichern. Neben der Sicherung von Fremd-Links (die anhand der Benutzer-ID als solche identifiziert werden können), ist auch eine zeitliche Begrenzung denkbar -- und URL-Parameter sind nicht mehr manipulierbar.
Anwendung der Klasse "secureLink"
(Siehe trac: class.secureLink.inc.php)
Zur Beispielanwendung der Klasse in der Buddy-Verwaltung: tbd.
Die Klasse "secureLink" sollte als zukünftig verpflichtende Programmiervorgabe überall dort eingesetzt werden, wo der Entwickler eine benutzergebundene Aktion als Link einführt. Die Sicherung der Parameter erfolgt dabei etwa nach dem folgenden Beispiel:
$params = array(); $params['userId'] = $_SESSION['userid']; $link = new SecureLink($params); echo "<a href='index.php'" . $link . "> Link </a>";
Dabei erzeugt die Auswertung des secureLink-Objektes innerhalb einer Zeichenkette einen impliziten Aufruf, der die Zeichenkette ?encOpts=<Verschlüsselte Parameterliste>
erstellt, die wiederum beim Absetzen des Aufrufes ausgewertet und verarbeitet werden kann.
Lessons learnt
Es zeigt sich schnell, dass die in [1] beschriebenen Faktoren zutreffen -- jedoch lediglich in Bereichen, in denen Kreativität und neue Ideen gefordert sind. Hierbei wirken sich auch die vier beschriebenen Effekte Pair-Pressure, Pair-Think, Pair-Reviews und Pair-Learning positiv aus. Einzig bei Routine- und Reproduktionsarbeiten (Dokumentation) ist Pair-Programming schlichtweg fehl am Platze, da Kommunikation zwischen Entwicklern nicht nötig ist. Für diese Bereiche bieten sich Automatisierungstechniken an, da es sich um vermeidbaren Aufwand handelt.
Für neue Entwicklungen, Module und Komponenten (ergo in sich abgeschlossene Aufgaben) ist Pair-Programming also eine sinnvolle Erweiterung der Code-Reviews, soweit sich alle Beteiligten auf die Vorzüge aber auch "Einschränkungen" (zumindest auf den ersten Blick) einlassen.