Tine 2.0 [1] ist eine Plattform zur internen Koordination eines Unternehmens und vereint die Aspekte Groupware, CRM und ERP. Die Zahl 2.0 bezieht sich dabei in Anlehnung an Web 2.0 auf die genutzten Technologien. Ursprünglich sollte das Projekt „eGroupWare 2.0“ heißen und somit auch gleichzeitig die zweite große Version der bekannten Online-Kollaborations-Software werden. Doch das Projekt hat sich geteilt und daraus ist Tine 2.0 entstanden. Eine Erkenntnis zu Beginn: Die anstehenden Probleme waren nur noch durch einen kompletten Rewrite sinnvoll lösbar.

Eine weitere wichtige Grundannahme: Software-Ergonomie ist ein entscheidender Faktor für die Akzeptanz einer Unternehmens-Software. Technisch ausgezeichnete Projekte scheiterten in der Vergangenheit immer wieder an Mitarbeitern, die die Software nicht benutzen wollten – für eine Groupware der Todesstoß.

Deshalb kamen bei der Erstellung der Funktionen und des Benutzer-Interfaces externe Experten der Open-Source-Usability-Labs hinzu. Jede Benutzergruppe wird dabei durch eine idealisierte virtuelle Person repräsentiert. Diese „Personas“ sind sehr hilfreich bei allen Diskussionen und Entscheidungen über die Benutzbarkeit und Relevanz der geplanten Features und Dialoge.

Die Mitarbeiter der Open-Source-Usability-Labs sind selbst keine Techniker und verstehen sich als „Anwälte der Benutzer“. In einem fortlaufenden Prozess begleiten sie die Entwicklung und sorgen mit ihren Hinweisen dafür, dass die Software die Benutzer optimal unterstützt.

Nächster Ausgangspunkt: Wenn eine Software unternehmenskritische Daten verwaltet, muss man ihr uneingeschränkt vertrauen können. Dafür setzt das Tine-2.0-Team auf intensive automatisierte Tests. Als Testframework ist der PHP-Clone von JUnit, PHPUnit, im Einsatz. Die Tests sind in drei Stufen organisiert: In der ersten Stufe werden die Backends getestet. Hier wird sichergestellt, dass alle SQL-Queries, LDAP-Abfragen und File-Zugriffe genau so wie geplant funktionieren. In einem zweiten Schritt werden die Domain-Logik und die Zugriffskontrolle getestet. Diese Tests stellen die Referenz für die interne API dar. Als Letztes werden dann die externen APIs getestet, auf die später der Client zugreift.

Zentraler Ansatz der Entwicklung ist „Test First“. So werden zuerst die Tests geschrieben und darüber die Funktionsweisen der Klasse festgelegt. Erst im zweiten Schritt wird dann die eigentliche Funktion programmiert. Oftmals ist dieser Weg in viele kleine Wiederholungen (Iterationen) unterteilt und übernimmt Aspekte des „Extreme Programming“ in den Entwicklungsprozess.

Durch die Tests ist außerdem die Funktionsweise einer Klasse genau dokumentiert. Merkt man beim Programmieren, dass es eine logische Lücke in einer Klasse gibt oder ihre Funktionsweise nicht klar ist, so wird diese Lücke durch weitere Tests umgehend geschlossen und festgehalten.

Tests geben dabei nicht nur dem Kunden Sicherheit, sondern vor allem auch den Programmierern. Wenn man erstmal eine Weile konsequent mit Tests gearbeitet hat, mag man nicht mehr auf sie verzichten.

Da die Entwickler diese Tests meistens lokal laufen lassen, läuft diese Version nicht automatisch auch im Repository so wie gedacht. Deshalb gibt es für Tine 2.0 einen „Continues Integration“-Server. Dieser Server updatet sich nach jeder Änderung selbstständig und lässt alle Tests in einer der Produktion gleichenden Umgebung ablaufen. Schlägt ein Test fehl, werden die Entwickler informiert. Zusätzlich werden mit jedem Durchgang auch verschiedene Qualitätsmetriken errechnet, sodass es ständig einen Überblick zum Qualitätsstand des Projekts gibt.

Da Tine 2.0 für den Einsatz im Unternehmen gemacht ist, warten also im Gegensatz zu einer öffentlichen Website nach der Authentifizierung Informationen, die im Regelfall nur für die Augen der Mitarbeiter bestimmt sind. Allerdings gibt es auch Schnittmengen mit der Website: zum Beispiel das Kontaktformular, dessen Eingaben im CRM-System landen sollen.

Anstatt auch noch ein Content Management System zu programmieren, fiel die Wahl auf TYPO3 – hier gab es bereits Erfahrungen bei der Firma Metaways, die die Entwicklung von Tine 2.0 unterstützt. Die Brücke zwischen Tine 2.0 und TYPO3 zu schlagen, war einfacher als erwartet: Da Tine 2.0 selbst eine Server-Client-Architektur nutzt, mussten die TYPO3-Plugins nur mit einem HTTP-Client ausgestattet werden, der auf die externe API zugreift.

Derzeit sind zwei Plugins im Einsatz: ein Kontaktformular und ein „Ansprechpartner“-Plugin, das einen Kontakt aus dem Adressbuch anzeigt. Die Plugins verbinden sich zu einer externen Tine-2.0-Installation und authentifizieren sich dort als Nutzer mit eingeschränkten Rechten.

Spätestens seit der Version 5 sind Objektorientierung und Design-Patterns sehr populär in der PHP-Szene. Und das mit gutem Grund, denn sie helfen oftmals, den Code schlanker und performanter zu gestalten. Der damit einhergehende Standardisierungseffekt hilft überdies enorm, sich im Code zurechtzufinden – besonders, wenn dessen Erstellung schon eine Weile zurückliegt oder er von Kollegen geschrieben wurde.

Allerdings gibt es auch Situationen, in denen Patterns überhaupt nicht weiterhelfen oder den Code eher verschlechtern. Manche der in den Lehrbüchern vorgestellten Patterns sind für PHP schlicht ungeeignet. Als Credo sollte deshalb gelten: Patterns verwenden, wenn sie sinnvoll erscheinen, aber an anderen Stellen auch bewusst darauf verzichten und stattdessen die Funktionsweisen und den Prozessablauf gut dokumentieren.

Eine weitere Grundregel sollte außerdem lauten: Das Rad nicht immer wieder neu erfinden. Als vor sieben Jahren die Entwicklung des „eGroupWare“-Vorgängers „phpgroupware“ unter PHP 3 begann, gab es noch keine Frameworks im heutigen Sinne. Für alle zu bewältigenden Aufgaben wurden daher eigene Skripte geschrieben oder man passte kleine externe Programme an die eigenen Bedürfnisse an. Mit der Zeit kamen so über 60 MB PHP-Code zusammen, für deren Wartung und Sicherheitssupport allein das jeweilige Projekt zuständig war.

Tine 2.0 setzt auf das Zend Framework im PHP-Backend und auf ExtJS im JavaScript-Client. Für die Wahl des einen oder anderen Frameworks gibt es immer viele gute Gründe, und jedes Lager hat Anhänger, die gerne Mailinglisten und Foren mit Argumenten für den exklusiven Anspruch des eigenen Frameworks füllen. Letztendlich ist es aber fast egal, für welches Framework man sich entscheidet – Hauptsache, man nutzt die Vorteile des externen Codes und hört auf, für jedes Standardproblem eine selbstgestrickte Lösung zu erstellen.

Das Ziel bei Tine 2.0 ist, GroupWare, CRM und ERP unter einen Hut zu bringen. Im ersten Release, das für September dieses Jahres geplant ist, sind ein Adressbuch, ein Aufgabenmanager und CRM-Funktionalitäten vorgesehen. Im nächsten Schritt sollen die klassischen Groupware-Funktionen Kalender und E-Mail sowie ein Stundenzettel mit Abrechnungs-Export beigesteuert werden. Ist dieser Punkt erreicht, ist das Entwicklerteam seinem Ziel schon sehr nahe.

Technisch stehen als nächstes die Integrationen von JavaScript-Unit-Tests und automatisierten Browsertests an. Zwar existieren Tools wie Selenium und JSUnit, trotzdem gibt es noch einigen Entwicklungsbedarf an geeigneten Tools für das zuverlässige Testen von JavaScript-Programmen.