MSP-Projektwoche Ticketbearbeitung 87 und 214

Aus THM-Wiki
Wechseln zu: Navigation, Suche
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.

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.