PHP mit Paul Bocuse

PHP mit Paul Bocuse PHP World Kongress 2010

Stephan Schmidt
• Head of Web Sales
Development bei der 1&1
Internet AG
• PHP seit 1999
• Autor von PHP Design
Patterns, Co-Autor weiterer
PHP Bücher
• Konferenzen seit 2001
• Open-Source-Aktivist

Holger
• Head of Sales Processes
Access bei der 1&1 Internet AG
• PHP seit 2000
• Gast-Dozent an der Berufs-
Akademie Mosbach
• Autor für die Zeitschrift T3N
• Clean Code Aktivist

Paul Bocuse
• Head of Nouvelle Cuisine
• Michelin Sterne seit 1965
• Autor von „Die neue Küche“,
„Französisch Kochen mit dem
Meister“ und weiterer Bücher
• Besitzer von fünf Restaurants
• „Koch des Jahrhunderts“
• Gewürz-Aktivist

Beispiele Für PHP im
Unternehmenseinsatz

Viele Entwickler
Montabaur
Karlsruhe
München
Bukarest
• Über 1.000 Entwickler sind
bei der 1&1 Internet AG
beschäftigt.
• Nicht nur PHP-Entwickler.
• Entwickler sind in
verschiedenen organi-
satorischen Teams.
• Entwickler sind über
verschiedene Standorte
verteilt.

Hohe Zugriffszahlen
500.000 Visits / Tag

Hohe Zugriffszahlen
2.000.000 Page Impressions / Tag

Viele Änderungen
3 - 5 Onlinegänge / Woche

Viele Änderungen
Neue Produkte und Preisänderungen

Viele Änderungen
Einbindung von neuen Services

Viele Änderungen
Änderungen des Seitenablaufs

Viele Änderungen
Kompletter Umbau des Portfolios

an unternehmenskritische
Software
Anforderungen

„Ein Unternehmen ist ein spezieller Betriebstyp in
marktwirtschaftlichen Systemen.
Konstitutive Merkmale des Unternehmens sind
nach Erich Gutenberg das erwerbswirtschaftliche
Prinzip (Streben nach Gewinnmaximierung), das
Prinzip des Privateigentums und das
Autonomieprinzip (Selbstbestimmung des
Wirtschaftsplans).“
Wikipedia
Unternehmen

Die Anforderungen im Überblick

1. Der Code
Wie ﬁnden Sie die richtigen Zutaten für
Ihre Applikation?
2. Das Team
Wie schaffen Sie es, dass viele Köche nicht
den Brei verderben?
3. Die Methoden und Tools
Wie rühren Sie die einzelnen Zutaten
zusammen und welche Küchengeräte
sollten Sie dazu einsetzen?
Empfehlung des Tages

Das Salz in einer PHP-
Applikation.
Code

Sauberer Code
„Sauberer Code kann von anderen Entwicklern
gelesen werden. Er verfügt über Unit- und
Akzeptanz-Tests. Er enthält bedeutungsvolle
Namen. Erst stellt zur Lösung einer Aufgabe nicht
mehrere, sondern eine Lösung zur Verfügung. Er
enthält minimale Abhängigkeiten, die
ausdrücklich definiert sind, und stellt ein klares
und minimales API zur Verfügung“
Dave Thomas

Verwende Namen die ihre Absicht aufdecken
• Namen von Variablen, Funktionen oder Klassen, sollten folgende Fragen
beantworten:
• Warum existiert die Variable (Funktion oder Klasse)?
• Was macht sie?
• Wie wird sie verwendet?
• $d = 1; // elapsed time in days
$elapsedTimeInDays = 1;

Benennung
• Verwende aussprechbare Namen
• GMDB und XGMDB (eXtended Generic Message Driven Bean)
• Verwende ein Wort pro Konzept (z.B. fetch, retrieve oder get)
• fetchMeals, retrieveIngredients, getChefs
• Vermeide "Nerd Names" in Klassennamen
• ...Helper, ...Manager oder ...Util

Kommentare
• Gute Kommentare
• @todo-Kommentare
• Informative Kommentare
• PHPDocs in öffentlichen APIs
• Schlechte Kommentare
• Redundante Kommentare
• Postionsmarkierungen
• Auskommentierter Code
Kommentare sind keine Ausrede für schlechten Code.

Coding Standards
• Legen fest, wie lang eine Zeile sein darf, wie eingerückt wird, wo geklammert
wird, wo Leerzeichen stehen, wann Großbuchstaben oder Kleinbuchstaben
verwendet werden, wie eine Funktionsdefinition aussehen soll, wie eine
Klassendefinition aussehen soll, wie eine Methodendefinition aussehen soll,
wie und wo Includes verwendet werden sollen, und, und, und, …
• Haben religiöse Sprengkraft
• Sorgen dafür, dass der Code für alle Entwickler lesbar bleibt
• Entwickler haben dadurch Zeit, sich auf das Wesentliche zu fokussieren

DRY - Don‘t Repeat Yourself
„Every piece of knowlege must have a single,
unambiguous, authoritative representation
within a system“
Andrew Hunt and Dave Thomas

DRY - Don‘t Repeat Yourself
• Nichts ist einfacher als Copy & Paste
• „Nummer Eins der Gestanksparade“ in Refactoring von Martin Fowler
• Jede Doppelung von Code leistet Inkonsistenzen und Fehlern Vorschub

Fehlerhandling
• Verwende Exceptions
• Reichere deine Exceptions mit sinnvollen Informationen an
• Exceptions sind für den Empfänger wichtig, nicht für den Sender
• Verwende Exceptions nicht als billige Alternative für goto
• Gib niemals null zurück

Die Pfadﬁnder-Regel
„Leave the campground cleaner than you found it“
Robert C. Martin

Die Pfadﬁnder-Regel
• „Don‘t live with Broken Windows“
• Fixe schlechte Designs, falsche Entscheidungen und schlechten Code
sobald du ihn siehst
• Es muss nichts großes sein
• Ändere den Namen einer Variable in einen besseren
Breche eine Funktion auf, die zu groß ist
Eliminiere ein kleine Duplizierung
• Software muss dauerhaft sauber gehalten werden

Schmutziger Code führt zu
unsauberem Design.
Lass auch bei Detail-Fragen die gleiche Sorgfalt
walten wie bei großen Design-Entscheidungen.

You Ain‘t Gonna Need It (YAGNI)

„Always implement things when you actually
need them, never when you just foresee that you
need them“
Ronald E Jeffries

• Anforderungen sind in der Software-Entwicklung notorisch ungenau oder
wechselnd
• Ungenaue Anforderungen werden oft durch möglichst ﬂexible und
funktionsfähige Software kompensiert
• Es werden Features entwickelt die keine Anwendung ﬁnden
• Dinge die niemand braucht, haben keinen Wert.

Do the simplest thing that could possibly work.
• YAGNI kann als Ergänzung des XP-Prinzips "Do the simplest thing that could
possibly work." verstanden werden
• Wann ist ein Design am einfachsten?
• Es verkörpert die Absicht des Entwicklers und besteht alle Tests.
• Es enthält kein Duplizierungen.
• Es enthält das Minimum an Klassen und Methoden

Emergenz
„Emergenz ist die spontane Herausbildung von
komplexen Systemen und Strukturen durch eine
Vielzahl von relativ einfachen Interaktionen.“
Wikipedia

Saubere Software durch emergentes Design
• Alle Tests bestehen
• Software muss in erster Linie den gewollten Zweck erfüllen.
• Software, die nicht testbar ist, kann nicht veriﬁziert werden.
• Klassen die dem Single Responsibility Prinzip folgen sind leichter zu
testen.
• Je mehr Tests wir schreiben, desto mehr bemühen wir uns Code zu
schreiben, der einfacher zu testen ist.

• Alle Tests bestehen
• Eine starke Kopplung erschwert das Schreiben von Tests
• Je mehr Tests wir schreiben, desto mehr bemühen wir uns, die Kopplung zu
minimieren

• Refactoring nach dem Bestehen eines Tests
• Duplizierten Code eliminieren
• Ausdrucksstärke des Codes verbessern
• Anzahl der Klassen und Methoden minimieren
• Tests sichern das bisherige Ergebnis ab

Vorsicht: Perfekt ist der Feind von "Gut genug"
• Entwickler tendieren dazu Lösungen danach zu analysieren wie elegant und
optimal sie für die Problemstellung sind.
• Software Entwicklung ist kein Schönheitswettbewerb
• Der Code ist klar, ausdrucksstark, gut dokumentiert und getestet. Geht es
noch besser?
• Klar. Aber es er ist gut genug.
• Verschwende keine Zeit auf der Suche nach dem perfekten Design

Mit kleinen Schritten zum
großen Ziel.
Mach es nicht perfekt, mach es gut genug. Je
länger Entscheidungen aufgeschoben werden,
desto mehr Wissen hat man darüber

Konkretes Problem
„Ich möchte Debug-Meldungen auf verschiedene
Arten verarbeiten und diese auswechseln können,
ohne den Code der MicroWave Klasse anpassen zu
müssen.“
Paul

Abstraktes Problem
„Ich möchte eine Aufgabe mit verschiedenen
Algorithmen lösen können. Jede der Lösungen soll
gekapselt sein und nichts von den anderen wissen.
Die einzelnen Lösungen sollen gegeneinander
austauschbar sein, ohne den nutzenden Client
anzupassen.“
Abstract Paul

Konkret vs Abstrakt
Abstrakt Konkret
Aufgabe
Verarbeiten von Debug-
Meldungen
Algorithmen
Ausgeben per print(), Schreiben
eines Logﬁles
Client Die Klasse MicroWave

Konkret vs Abstrakt
Abstrakt Konkret
Aufgabe
Persistieren von
Gästebucheinträgen
Algorithmen
Speichern in Datenbank,
Speichern in XML-Datei
Client Die Klasse Guestbook

Einsatz von Interfaces
class MicroWave {
... Eigenschaften der Klasse ...
public function __construct(Debugger $debugger) {
$this->debugger = $debugger;
}
... weitere Methoden der Klasse ...
}
interface Debugger {
public function debug($message);
}
class DebuggerEcho implements Debugger {
public function debug($message) {
echo $message . "n";
}
}

Einsatz von Interfaces
$debugger = new DebuggerEcho();
$microWave = new MicroWave($debugger);
class DebuggerLog implements Debugger {
error_log("{$message}n", 3, './MicroWave.log');
}
}
$debugger = new DebuggerLog();
• Debugger einsetzen
• Debugger austauschen

Pauls erstes Design Pattern
Strategy-Pattern

Design Patterns
• Lösungsmuster für häuﬁg auftretende Entwurfsaufgaben in der Software-
Entwicklung
• Keine Code-Bibliothek
• Organisiert in Pattern-Katalogen (z.B. Gang-of-Four Buch)
• Verschiedene Kategorien: Erzeugungsmuster, Strukturmuster,
Verhaltensmuster, Enterprise-Patterns
• Verhindern, dass Ihr Code so aussieht.

Erzeugungsmuster
• Erzeugungsmuster werden verwendet, um Objekte zu konstruieren.
• Zu den Erzeugungsmustern gehören unter anderem
• Singleton-Pattern
• Factory-Method-Pattern
• Prototype-Pattern
• Abstract-Factory-Pattern

Factory-Method-Pattern
• Deﬁniert eine Schnittstelle zur Erzeugung von Objekten
• Verlagert die eigentliche Instanziierung in Unterklassen
• Lässt Unterklassen entscheiden, welche konkrete Implementierung
verwendet wird

abstract class AbstractManufacturer {
protected $name;
public function __construct($name) {
$this->name = $name;
}
public function sellOven() {
$oven = $this->manufactureOven();
// weitere Operationen möglich
return $oven;
}
public abstract function manufactureOven();
}

class MicroWaveOvenManufacturer extends AbstractManufacturer {
public function manufactureOven() {
return new MicroWave($this->name);
}
}
$mwManufacturer = new MicroWaveOvenManufacturer('Bosch');
$microWave = $mwManufacturer->sellOven();

Das Factory-Method-Pattern definiert eine
Schnittstelle zur Erzeugung von Objekten. Es
verlagert aber die eigentliche Instanziierung in
Unterklassen; es lässt die Unterklassen
entscheiden, welche konkreten
Implementierungen verwendet werden.

Prototype-Pattern
• Das Prototype-Pattern erzeugt Objekte durch das Kopieren eines
prototypischen Exemplars
• Es ermöglicht das Hinzufügen neuer "Klassen" zur Laufzeit ohne
Programmierung
• Es hält die Anzahl der benötigten Klassen klein

Prototype-Pattern
class SandwichMaker {
protected $prototypes = array();
public function addRecipe($recipe, Sandwich $prototype) {
$this->prototypes[$recipe] = $prototype;
}
public function makeSandwich($recipe) {
if (!isset($this->prototypes[$recipe])) {
throw new UnknownRecipeException(
'No prototype for sandwich ' . $recipe . ' registered');
}
return clone $this->prototypes[$recipe];
}
}

Prototype-Pattern
interface Sandwich { ... }
class Melt implements Sandwich { ... }
class Reuben implements Sandwich { ... }
$swMaker = new SandwichMaker();
$blt = new Reuben();
$blt->addIngredient('Bacon');
$blt->addIngredient('Lettuce');
$blt->addIngredient('Tomato');
$swMaker->addRecipe('Tomato', $blt);
$cheese = new Melt();
$cheese->addIngredient('Blue Cheese');
$cheese->addIngredient('Swiss Cheese');
$swMaker->addRecipe('Cheese', $cheese);

Prototype-Pattern
Das Prototyp-Muster bestimmt die Arten der zu
erzeugenden Objekte durch die Verwendung eines
prototypischen Exemplars, das zur Erzeugung
neuer Instanzen kopiert wird.

Strukturmuster
• Strukturmuster befassen sich mit der Komposition von Objekten
• Zu den Strukturmustern gehören unter anderem
• Composite-Pattern
• Proxy-Pattern
• Adapter-Pattern
• Facade-Pattern

Composite-Pattern
• Lässt mehrere Instanzen eines Typs nach außen wie eine Instanz aussehen
• Implementieren einer neuen Klasse, die die einzelnen Instanzen aufnimmt
• Muss die selbe Schnittstelle implementieren wie die entsprechenden
Instanzen

Composite-Pattern
interface Debugger {
public function debug($message);
}
// Implementierungen
class DebuggerLog implements Debugger {
error_log($mssage, 3, 'debug.log');
}
}
class DebuggerMail implements Debugger {
mail('schst@php.net', 'Error happened', $message);
}
}

Composite-Pattern
class DebuggerComposite implements Debugger {
protected $debuggers = array();
public function addDebugger(Debugger $debugger) {
$this->debuggers[] = $debugger;
}
foreach ($this->debuggers as $debugger) {
$debugger->debug($message);
}
}
}
$debuggerComposite = new DebuggerComposite();
$debuggerComposite->addDebugger(new DebuggerLog());
$debuggerComposite->addDebugger(new DebuggerMail());

Composite-Pattern
Das Composite-Pattern fügt mehrere Objekte zu
einer Baumstruktur zusammen und ermöglicht es,
diese von außen wie ein einzelnes zu verwenden.

Adapter-Pattern
• Das Adapter-Pattern passt die Schnittstelle eines Objekts an die vom Client
erwartete Schnittstelle.
• Es erleichtert die Nutzung von Fremdcode in eigenen Systemen.
• Das Adapter-Pattern arbeitet ähnlich wie ein Adapter für Steckdosen.

Adapter-Pattern
class TwitterWarningSender {
protected $tweet;
public function prepareTweet($tweet) {
$this->tweet = $tweet;
}
public function sendTweet() {
// Code, der die Nachricht an Twitter verschickt.
}
}

Adapter-Pattern
class TwitterWarningSenderAdapter implements Debugger {
protected $warningSender;
public function __construct(TwitterWarningSender $warningSender) {
$this->warningSender = $warningSender;
}
...
$this->warningSender->prepareTweet($message);
$this->warningSender->sendTweet();
}
}
$warningSender = new TwitterWarningSender();
$debugger = new TwitterWarningSenderAdapter($warningSender);

Adapter-Pattern
Das Adapter-Muster passt die Schnittstelle einer
Klasse an die vom Client erwartete Schnittstelle
an. Es ermöglicht die Zusammenarbeit von
Klassen, die eigentlich aufgrund inkompatibler
Schnittstellen nicht zusammenarbeiten können.

Verhaltensmuster
• Verhaltensmuster beschreiben die Interaktion zwischen Objekten.
• Zu den Verhaltensmustern gehören unter anderem
• Subject/Observer-Pattern
• Template-Method-Pattern
• Command-Pattern
• Iterator-Pattern

Template-Method-Pattern
• Deﬁniert die Schritte eines Algorithmus in einer Methode
• Implementierung der einzelnen Schritte bleibt Unterklassen vorbehalten
• Gemeinsames Verhalten muss nur einmal implementiert werden: Änderungen
am Algorithmus nur an einer Stelle notwendig
• Neue Unterklassen müssen nur die konkreten Schritte implementieren

abstract class AbstractSandwichMaker {
...
final public function makeSandwich() {
print "Butter auf‘s Brotn";
$this->addButter();
$this->addCheese();
if ($this->isMeltedSandwich()) {
$this->melt();
}
}
abstract protected function addButter();
abstract protected function addCheese();
abstract protected function isMeltedSandwich();
protected function melt() {
print "Überbacke den Sandwich.n";
}
}

class SwissCheeseSandwichMaker extends SandwichMaker {
protected function addButter() {
print "Füge Butter hinzu.n";
}
protected function addCheese() {
print "Füge Swiss Cheese hinzu.n";
}
protected function isMelted() {
return true;
}
}

Das Template-Method-Pattern definiert die
Schritte eines Algorithmus in einer Methode und
überlässt die Implementierung der einzelnen
Schritte den Unterklassen. Diese können somit
Teile des Algorithmus modifizieren, ohne dessen
Struktur zu verändern.

Command-Pattern
• Kapselt einen Auftrag als Objekt.
• Aufträge (Objekte) sind parametrisierbar
• Aufträge können in einer Queue nacheinander abgearbeitet werden
• Aufträge können rückgängig gemacht werden.

Command-Pattern
interface DishWasherCommand {
public function execute(Dishes $dishes);
}
class DishWaherSimpleWashCommand implements DishWasherCommand {
public function execute(Dishes $dishes) {
echo "Das Geschirr wird gewaschen";
}
}
class DishWasherDryingCommand implements DishWasherCommand {
public function execute(Dishes $dishes) {
echo "Das Geschirr wird getrocknet";
}
}

Command-Pattern
class DishWasher {
protected $programmes = array();
public function addProgramme($name, array $commands) {
$this->programmes[$name] = $commands;
}
public function wash($prog, Dishes $dishes) {
foreach ($this->programmes[$prog] as $command) {
$command->execute($dishes);
}
}
}

Command-Pattern
$wash = new DishWasher();
$wash->addProgramme('standard', array(
new DishWasherSimpleWashCommand(),
new DishWasherDryingCommand()
));
$wash->wash('standard', $dishes);

Command-Pattern
Das Command-Pattern kapselt einen Auftrag als
Objekt. Dadurch wird ermöglicht, andere Objekte
mit Aufträgen zu parametrisieren, Aufträge in
eine Queue zu stellen oder diese rückgängig zu
machen.

• Kommen aus der Java Welt
• Stark geprägt durch Martin Fowler
• Meistens komplexer als die Gang-of-Four Patterns
• Deswegen ab hier keine Beispiele mehr
• Mehr zu Enterprise Patterns in PHP im
Buch "PHP Design Patterns"
http://www.phpdesignpatterns.de
Enterprise Patterns

Klassische PHP Architektur
Client
Alle Logik und alle Daten in einer Applikation
auf einem Server
HTTP

Client
Verteilte Architektur
Frontend
Service Layer
Business Logic
Storage
HTTP

Frontend FrontendFrontend
Storage Storage Storage Storage
Client
Verteilte Architektur
Service Layer
Business Logic
HTTP

Vor- und Nachteile verteilter Architekturen
+ -
•Skaliert besser als monolithische
Architekturen.
•Verschiedene Schichten können
leichter erweitert werden.
•Einzelne Schichten können
getrennt voneinander entwickelt
und gewartet werden.
•Komplexität steigt an
•Sie brauchen klare Deployment-
Prozesse und Versionierung der
einzelnen Schichten.
•Gesteigerter Testaufwand

Fallbeispiel: 1und1.de
Client
Frontend und
Business Logik
HTTP
Storage Storage Storage
Session
Frontend und
Business Logik
Session
Session
Session
Telnet

Fallbeispiel: 1und1.de
• Cluster mit vier Frontend-Rechnern
• Daten werden in MySQL-Cluster gehalten
• Sessions werden in einem Session-Cluster verwaltet
• IP des Rechners, der die Session hält ist in Session-Id verschlüsselt
• Beliebige zustandslose Frontend-Rechner greifen dadurch immer auf den
korrekten Session-Host zu
• Einfaches Telnet-Protokoll zum Abrufen der serialisierten Session-Daten

Fallbeispiel: United-Internet.de
Client
Frontend
HTTP
Services Services Services
CDS
Frontend
CDS
CDS
HTTP

Fallbeispiel: United-Internet.de
• Cluster mit zwei Frontend-Rechnern
• Größter Teil der Business-Logik und Daten werden über Services (RMI, REST
& SOAP) von verschiedensten Middleware-Systemen bereit gestellt.
• Statische Ressourcen werden beim Deployment auf Content-Delivery-
Server übertragen.
• Content-Delivery-Server verwenden Light HTTPD
• Statische Ressourcen werden performant ausgeliefert
• Requests auf Frontend-Rechner kann um bis zu 75% reduziert werden.

Premature Optimization
„Premature optimization is the root of all evil“
Donald Knuth

• Premature Optimization beschreibt die Situation in der Design
Entscheidungen aufgrund von Performance-Optimierungen getroffen werden
• Solche Optimierungen resultieren oft in unleserlicherem Code

Michael Jackson über Premature Optimization
„Don't do it!”

Michael A. Jackson über Premature Optimization
„Don't do it!
For experts:
Don't do it yet.”

• Was wenn Performance-Optimierung unumgänglich ist?
• Anwendung & Design entwickeln
• Proﬁler / Benchmarks einsetzen
• Flaschenhälse identiﬁzieren
• Ein einfaches und elegantes Design ist oft leichter zu optimieren

• Caching und Optimierungen können in
verschiedenen Schichten Ihrer Applikation Sinn
machen.
• Verwenden Sie einen Proﬁler oder Logging, um
zu analysieren, wo Ihre Performance Probleme
liegen.
Caching und Optimierungen
Client
Logik
Dateisystem

HTTP-Caching
• PHP ermöglicht Ihnen, HTTP-Header zu setzen, die das Caching des Clients
beeinﬂussen:
• Expires-Header
• ETag-Header
• Reduziert die Load auf dem Server und beschleunigt den Aufbau Ihrer
Website.

Caching der Logik
• Cachen Sie komplexe Operationen, die nicht für jeden Request neu
ausgeführt werden müssen.
• Parsen von XML-Dateien
• Datenbank-Abfragen
• Generierung von XSL-Stylesheets
• Legen Sie Daten im serialize-Format von PHP ab.

Caching des Dateisystems
• Abfragen auf das Dateisystem kosten Zeit.
• Können zum Bottleneck werden.
• APC ist eine Alternative, Caching ist jedoch lokal pro Server.
• memcached kann auch von mehreren Servern eingesetzt werden.

PHP Caching
• Opcode-Caches verhindern, dass Ihre Skripte bei jedem Request neu
interpretiert werden müssen.
• Alternative PHP Cache (http://pecl.php.net/package/APC)
• eAccelerator (http://eaccelerator.net/)
• XCache (http://xcache.lighttpd.net/)
• Zend Server (http://www.zend.com/de/products/server/)

... unless you plan learning more about wheels
• "Reinventing the wheel" ist eines der bekanntesten Anti-Patterns in der
Software Entwicklung
• Stetige Neuerstellung von Software ohne bestehende Lösungen oder
Frameworks zu nutzen
• Verhindert Wiederverwendung und führt zu instabiler, unreifer, teurer Software
• Sie sind nicht alleine
• Irgendwo auf der Welt kämpft immer jemand an den gleichen Software
Design Problemen wie Sie

Vorteile von Frameworks
• Bringen fertige Komponenten und Lösungen für typische Probleme mit:
• Cross-Cutting-Concerns werden vom Framework gelöst.
• Fokussieren Sie Ihren Entwicklungsaufwand auf die Business-Logik anstatt
auf das Schreiben von Glue-Code.
• Standardisieren Ihre Architektur und Ihren Entwicklungsprozess:
• Durch Inversion-of-Control wird die Steuerung des Ablaufs an das
Framework übergeben.
• Ihr Team implementiert Standard-Interfaces des Frameworks.

• Komponenten-orientiertes
Framework für PHP 5
• Fokusiert auf Web 2.0
Anwendungen
• Viele Komponenten wie z.B. MVC-
System, Lokalisierung, PDF-
Erstellung oder Suchfunktionen
• http://framework.zend.com
• Einige der Merkmale
• Flex Integration
• LDAP Interface
• REST Interface
• Caching
• Google Apps Integration
Zend Framework

• MVC Framework für PHP 5
• Wird seit 2005 entwickelt
• Basiert auf den Prinzipien von Ruby
on Rails
• Fokusiert für die Entwicklung von
Enterprise-Level Anwendungen (wie
z.B. Askeet und Yahoo)
• http://www.symfony-project.org
• Template Engine
mit PHP Syntax
• Scaffolding von
CRUD-Interfaces
• Request Dispatcher
für "saubere" URLs
• Mehrsprachigkeit
Symfony

CakePHP
• MVC Framework für PHP 4 und 5,
dass seit 2005 entwickelt wird
• Basiert auf den Prinzipien von Ruby
on Rails
• Fokussiert auf Einfachheit und
schneller Entwicklung
• Geeignet für Websites und
Kommandozeilen-Tool
• http://cakephp.org
• Application
Scaffolding
• Code Generation
• Authentiﬁzierung
• Helper für AJAX,
XML, RSS, JavaScript
und mehr

CodeIgniter
• Leichtgewichtiges auf Einfachheit
und Schnelligkeit fokussiertes
Framework für PHP 4
• Erste öffentliche Version seit 2006
• Gut geeignet für Shared Hosting
Accounts
• Gute Dokumentation mit vielen
Video Tutorials, einem User Guide
und einem Wiki
http://codeigniter.com
• Bild-Manipulation
• FTP-Support
• Verschlüsselung
• Filtern von Eingaben und
Ausgaben

Apache Zeta Components
• Besser bekannt als eZ Components
• Seit Juli 2010 bei Apache
• Modulare Komponentenbibliothek
für PHP 5
• http://incubator.apache.org/
zetacomponents
• Template Engine
• Unterstützung für RSS-Feeds
• Generierung von Graphen
• WebDAV Server
• Validierung von
Benutzereingaben

Der Code
Clean Code
Verteilte Architekturen Don‘t Reinvent
Design PatternsYAGNI
Caching

Viele Köche verderben nicht
immer den Brei.
Das Team

Communication is King!
• Verstehen die Entwickler, was der Kunde möchte?
• Versteht der Kunde, was der Entwickler liefern kann?
• Verstehen die Entwickler gegenseitig wirklich, wie die Schnittstellen
aussehen?
• Verstehen die Entwickler, was die Qualitätssicherung braucht?
• Verstehen Sie, was ich damit sagen will?

Kommunikationswege
• Treffen von Angesicht zu Angesicht.
• Videokonferenzen.
• Telefonkonferenzen.
• E-Mails und Instant Messenger.
• Projekt-Blogs und Microblogging.

Vertrauen
Forming
Storming
Norming
Performing
„Das Vertrauen gibt dem Gespräch mehr
Stoff als Geist.“
François Duc de La Rochefoucauld

Teambildung
• Gemeinsame private Erlebnisse stärken das Teamgefühl und fördern die
Zusammenarbeit.
• Das gilt nicht nur für gemeinsame Essen, jedoch ist der Effekt dabei
besonders groß.
• Schaffen Sie Rituale.

Tod durch Meeting
• Team-Meetings sind oft unstruktiert und werden von vielen als verschenkte
Zeit empfunden.
• Machen Sie sich Gedanken über die Struktur und das Ziel der Meetings.
• Richten Sie verschiedene Meetings mit verschiedenen Zielen ein, statt alles in
einem Meeting zu besprechen.
• Strategie-Meeting, Status-Meeting, ...
• Es gibt kein Rezept für die richtigen Meetings.
Richten Sie die richtigen Meetings für Ihr Team ein.

Beat the Meeting
Be...scheiden
Erfolgreich
Abgehakt
Todo
60s pro
Thema
Jedes Team-
Mitglied erzählt
60 Sekunden zu
jedem Thema.
Ein Thema geht
reihum, bevor
das nächste
Thema
drankommt.

Vorteile von BEAT
• Die Meetings erhalten eine klare Struktur.
• Jeder weiß, was von ihm erwartet wird und kann sich vorbereiten.
• Die vorangegangene Woche wird reﬂektiert und sowohl über positive als auch
negative Erlebnisse nachgedacht.

Die richtige Team-Zusammensetzung
Senior vs. Junior
Entwickler
Kreative Köpfe vs.
Analytiker
Kommunikative Mitarbeiter
vs. Zuhörer
Führungspersönlichkeiten

Verantwortung
• Teilen Sie die Verantwortung im Team auf und vermeiden Sie, dass diese sich
an wenigen Stellen konzentriert.
• Etablieren Sie Collective Code Ownership.
• Ermöglichen Sie einen konstruktiven Umgang mit Fehlern im Team, ansonsten
wird niemand Verantwortung übernehmen.
• Zu Verantwortung gehört auch die Möglichkeit, Entscheidungen treffen zu
dürfen.

Kultur der Angst
„Was wären wir sündigen Kreaturen dann ohne
die Angst, diese vielleicht wohltätigste und
gnädigste Gabe Gottes?“
Umberto Eco, „Der Name der Rose“

Sie leben in einer Kultur der Angst, wenn...
• …es gefährlich ist, bestimmte Dinge auszusprechen.
• …Zielvorgaben so aggressiv sind, dass diese unmöglich erreicht werden
können.
• …Macht über gesunden Menschenverstand triumphieren darf.
• …die Leute, die gehen müssen, sind im Durchschnitt kompetenter als die, die
bleiben.
Aus "Spielräume" von Tom DeMarco

Matrixorganisation
PHP Entwickler 1
PHP Entwickler 2
PHP Entwickler 3
PHP Entwickler 4
PHP Entwickler 5
Frontend
Entwickler 1
Frontend
Entwickler 2
Frontend
Entwickler 3
Frontend
Entwickler 4
Frontend
Entwickler 5
Tester 1
Tester 2
Tester 3
Tester 4
Projektleiter A
Projektleiter B
Projektleiter C
Teamleiter PHP
Teamleiter
Frontend
Teamleiter QA
Organisatorische EinheitProjekteinheit

Vor- und Nachteile der Matrixorganisation
+ -
•Kürzere Kommunikationswege
•Spezialisierung der Teamleiter, sie
müssen nicht parallel noch
Projektmanager sein
•permanenter Ansprechpartner für
den Mitarbeiter, der sich um
dessen Weiterentwicklung
kümmern kann.
•Kompetenzkonﬂikte können
auftreten
•Langsame Entscheidungsﬁndung
•Hoher Kommunikationsaufwand
•Unsicherheit bei den Mitarbeitern
(„Zwei Herren“)

Das Team
Kommunikation
Organisation & Struktur

Schneiden, mixen, rühren und
der richtige Ofen.
Methoden und Tools

Versionsverwaltung
• Ermöglicht parallele Änderungen an einem Projekt
• Es gibt viele Variationen von Versionsverwaltungssystemen - alle teilen die
gleichen Konzepte: Checkouts, Commits, Merges und Nebenläuﬁgkeit
• Es ist egal, welches System Sie einsetzen, aber tun Sie's!

Richtlinien für die Versionsverwaltung
• Einigen Sie sich auf gemeinsame Richtlinien
• Checkins von Zwischenschritten (nicht funktionierenden)?
• Wo sollte der Code eingechecked werden?
• Gibt es Orte die weniger kontrolliert werden?
• Wie gelangen die Änderungen in Releases?
• Wie werden Tags, Branches und der Trunk verwendet?

Branching Patterns
• Gängige Patterns
• Release Branches
• Feature Branches

Release Branch
• Ist die Entwicklung einer neuen Version der Anwendung abgeschlossen, wird
ein Release Branch erzeugt
• Dieser Branch wird anschließend getestet, getagged und deployed
/trunk
/branches/v1.0 /branches/v2.0
/tags/v1.0.0 /tags/v2.0.0

Aktualisierung des Release Branch
• Entwicklung im Branch direkt sollte generell vermieden werden
• Bugs werden im Trunk geﬁxt und anschließend in den Branch gemerged
• Ansonsten besteht die Gefahr, dass Änderungen nicht in den Trunk
übernommen werden und beim nächsten Release-Branch fehlen
• Ausnahmen sind Änderungen, die für den Trunk nicht mehr nötig oder nicht
möglich sind

Feature Branch
• Umfasst eine Neuentwicklung mehrere Commits die den Trunk in einen
instabilen Zustand versetzen, wird ein Feature Branch angelegt
• Nach abgeschlossener Test-Phase wird der Branch zurück in den Trunk
gemerged und von dort deployed
/trunk
/branches/feature-1
/branches/feature-2

Aktualisierung des Feature Branch
• Ein Feature Branch sollte stets aktuell gehalten werden
• Im Idealfall wird der Trunk ein bis zwei mal pro Woche in den Branch
gemerged
• Je älter ein Branch ist, desto schwieriger wird der Merge zurück in den
Trunk
• Sobald der Branch zurück in den Trunk gemerged wurde ist die Entwicklung
darin abgeschlossen

Tools zur Versionsverwaltung
GIT

Subversion

CVS

Mercurial

Bazaar

LibreSource

Es ist egal welches Tool Sie
einsetzen, aber tun Sie's

Entwicklungsumgebung
• Eclipse PDT
http://www.eclipse.org/pdt/
• Komodo IDE
http://www.activestate.com/komodo-ide
• PHPEdit
http://www.phpedit.com
• Netbeans
http://netbeans.org
• phpDesigner
http://www.mpsoftware.dk
• Zend Studio
http://www.zend.com/de/products/studio/
• Aptana Studio
http://www.aptana.com/products/studio3
• Codelobster
http://www.codelobster.com
• NuSphere PhpED
http://www.nusphere.com
• Dreamweaver
http://www.adobe.com/de/products/dreamweaver/
• E-Texteditor
http://www.e-texteditor.com
• Coda
http://www.panic.com/coda/
• Textmate
http://macromates.com
• ...

Integrierte Versionsverwaltung

Refactoring und Code Generierung

Unterstützung für HTML, CSS & JavaScript

Die Qual der Wahl
• Schnell einsatzbereit oder möglichst "feature complete"?
• Kostenlos oder kostenpflichtig?
• Tipps zur Entscheidungsfindung
• Testen Sie die kostenlosen IDEs zuerst
• Wenn Sie eine IDE gefunden haben, die Ihre gewünschten Funktionen
bietet, prüfen Sie ob diese korrekt in der IDE funktionieren
• Wenn nur wenige Funktionen fehlen, testen Sie dafür spezifische Tools

Statische Code Analyse
• White-Box-Test Verfahren - man benötigt den Quelltext
• Der Quelltext wird dabei einer Reihe formaler Prüfungen unterzogen
• Statische Code Analyse ermöglicht unter anderem
• das werkzeuggestützte oder automatisierte Erkennen von Fehlern
• die Abdeckung von zusätzlichen Qualitätsaspekten wie Wartbarkeit und
Analysierbarkeit
• eine einfache Vergleichbarkeit der Messergebnisse mit anderen Systemen

• Misst mithilfe
unterschiedlicher
Ausprägungen den Umfang
eines PHP Projekts anhand
der Lines of Code (LOC)
• Darüber hinaus wird die
Anzahl der Namensräume,
Klassen, Methoden und
Funktionen gezählt
• https://github.com/
sebastianbergmann/phploc
phploc

Copy/Paste Detector (CPD)
• Durchsucht PHP Projekte
nach dupliziertem Code
(Code Clones)
sebastianbergmann/
phpcpd

Dead Code Detector (DCD)
• Durchsucht PHP Projekte
nach Code der nicht mehr
aufgerufen wird
sebastianbergmann/
phpdcd

PHP Depend
• Ein an JDepend
angelehntes Tool das eine
Vielzahl an Software-
Metriken für PHP Projekte
berechnet und visualisiert
• Zyklomatische
Komplexität
• NPath-Komplexität
• http://pdepend.org

PHP Mess Detector
• An das Java Tool PMD
angelehntes Tool, dass auf
PHP_Depend aufsetzt und
Warnungen bzw. Fehler
auslöst wenn vorgegebene
Schwellenwerte für
einzelne Software-Metriken
überschritten werden
• http://phpmd.org

PHP_CodeSniffer
• Durchsucht PHP Projekte nach
"übel riechenden Codes" (Code
Smells) wie beispielsweise
• Formatierungsregeln
• Software-Metriken
• Erkennung von potentiellen
Fehlern
• Performance Problemen
• http://pear.php.net/package/
PHP_CodeSniffer/

Test
• Es gibt viele Arten von Tests
• Unit Tests
Ein Test auf der tiefsten Ebene bei dem einzelne Komponenten auf korrekte
Funktionalität getestet werden
• Integrationstests
Testen die Zusammenarbeit voneinander abhängigen Komponenten
• Akzeptanztests
Ein Test der gelieferten Software durch den Kunden
• Systemtests
Das gesamte System wird gegen die gesamten Anforderungen (funktionale und
nicht funktionale Anforderungen) getestet

Unit Tests
„Im Unit Test werden kleinere Programmteile in
Isolation von anderen Programmteilen getestet.“
Frank Westphal

Unit Tests
• Testen eine einzelne Codeeinheit isoliert.
• Die Granularität der Codeeinheit kann von Methoden über Klassen bis hin
zu Komponenten reichen.
• Unit Test-Frameworks für PHP
• PHPUnit - JUnit Portierung für PHP von Sebastian Bergmann
• SimpleTest - von Marcus Baker

Unit Tests
require_once 'OvenCompany.php';
class OvenCompanyTest extends PHPUnit_Framework_TestCase {
protected $ovenCompany;
protected function setUp() {
$this->ovenCompany = new OvenCompany();
}
public function testAddToInventory() {
$this->ovenCompany->addToInventory(new MicroWave('Bosch', 'silber'));
$ovenCount = $this->ovenCompany->countOvensInInventory();
$this->assertEquals(1, $ovenCount);
}
}

Unit Tests
$ phpunit OvenCompanyTest
PHPUnit 3.4.2 by Sebastian Bergmann.
.
Time: 0 seconds
OK (1 test, 1 assertion)

Integrations- und Akzeptanztests
„There is a vast gulf between the process mappers
who model business systems pictorially, and the
programmers who grind out the C++ or Java
or .Net services that support those business
systems. Between the two camps lies a fertile land
of opportunity. It's time to jointly explore it.“
Ward Cunningham

FIT - Framework for Integrated Tests
• Framework für Integrations- und Akzeptanz-Tests
• Der Kunde schreibt die Testfälle in HTML, Word oder Excel
• Bezieht den Kunden in den Entwicklungsprozess ein und fördert agiles
Vorgehen
• Mittlerweile für sehr viele Sprachen verfügbar, für PHP innerhalb von PEAR

Funktionsweise
• Kunde erstellt eine Tabelle mit Eingabe-Parametern und erwarteten
Rückgabe-Werten
• FIT parst die HTML-Tabelle und interpretiert diese als Testfälle
• FIT reicht die Eingabeparameter an den Testcode (Fixture) weiter
• Der Testcode führt den zu testenden Code aus
• FIT holt die das Ergebnis aus dem Testcode
• FIT markiert Abweichungen in der HTML-Tabelle

Webtests mit Selenium
• Dem Kunden sind Unit-Tests egal, wenn die Website nicht funktioniert
• Selenium prüft die Anwendung auf der Ebene, die der Kunde sieht
• Steuert den Browser fern und prüft gegen das erwartete Verhalten
• Funktioniert in allen großen Browsern, auch im IE6
• Tests können über Firefox-Extension aufgezeichnet werden
• Selenium RC ermöglicht Fernsteuerung aus PHPUnit Tests

Continuous Integration
• Beschreibt den Prozess des regelmäßigen, vollständigen Builds und Testens
einer Anwendung
• Vorteile durch den Einsatz von CI
• Integrations-Probleme werden frühzeitig entdeckt
• Fehler werden nicht verschleppt
• Code Qualität ist über den gesamten Entwicklungsprozess sichtbar

Continuous Integration
SVN Repository CI Server

Better safe than sorry.
Schaffe dir Sicherheitsnetze durch
automatisierte Tests auf verschiedenen
Ebenen deiner Applikation.
Integriere regelmäßig und stelle Fehler
frühzeitig fest.

Build-System
• Erleichtern Setup eines Projekts in neuen Umgebungen.
• Führen wiederkehrende Aufgaben aus, die nötig sind, um eine Applikation zu
starten.
• Kopieren, Löschen, Verschieben
• Dependencies ermitteln
• Source-Code transformieren
• In PHP noch nicht so weit verbreitet, da meistens kein Code kompiliert
werden muss.

Apache Ant
• Java basiert, aber universell einsetzbar.
• Plattform unabhängig.
• Build-Skripte werden in XML geschrieben und dann ausgeführt.
• Bereits seit Jahren in vielen Java-Projekten im Einsatz.
• Bereits für viele Aufgaben schon „Tasks“ vorhanden, die diese ausführen.
• Eigene Tasks werden in Java implementiert.

Typisches Ant Build-Skript
<project name="MyProject" default="build" basedir=".">
<description>simple example build file</description>

<property name="src" location="src"/>
<property name="build" location="build"/>
<target name="init">

<mkdir dir="${build}"/>
<echo message="Directory ${build}"/>
</target>
<target name="build" depends="init">
<copy todir="${build}">
<fileset dir="${src}"/>
</copy>
</target>
</project>
• Default-Dateiname ist „build.xml“
• Ausführen durch Aufruf von „ant“, optional abweichender Dateiname

</target>
</copy>
</target>
</project>
• <project> gibt Projektname, Default-Target und Build-Verzeichnis an
• Optional Projektbeschreibung über <description>

</target>
</copy>
</target>
</project>
• Häuﬁg verwendete Werte, wie Ordner-Namen, Versionen in Properties
• Können auch einfach aus einer „.properties“ Datei gelesen werden

</target>
</copy>
</target>
</project>
• „build“-Target hängt vom „init“-Target ab
• Kopiert alle Dateien von „src“ nach „build“

</target>
</copy>
</target>
</project>
• „init“-Stellt sicher, dass der „build“-Ordner existiert.
• Gibt mit <echo> eine Meldung nach STDOUT

Ausführen des Build-Files
$ ant
Buildfile: build.xml
init:
[mkdir] Created dir: /Users/schst/tests/ant/build
[echo] Directory /Users/schst/tests/ant/build
build:
[copy] Copying 1 file to /Users/schst/tests/ant/build
BUILD SUCCESSFUL
Total time: 0 seconds
• Aufruf von „ant“ genügt

Informationen zum Build-File
$ ant -p
Buildfile: build.xml
simple example build file
Main targets:
Other targets:
build
init
Default target: build
• Aufruf von „ant -p“

Features von ant
• Alle File-Tasks, die man sich vorstellen kann.
• Archive-Tasks, Pre-Processing Tasks (ANTLR, XSLT, etc.)
• Java kompilieren, JARs erstellen, etc.
• SCM-Tasks, Testautomatisierung, Code-Coverage
• Mails, Logging, SQL, FTP, SSH,...
• Als letzter Fallback einfach <exec/>

Phing
• PHP Port von Apache Ant.
• Konzept und Großteil der XML-Struktur übernommen.
• Leider nicht zu 100% kompatibel.
• Weniger vordeﬁnierte Tasks als Ant, dafür mehr PHP-verwandte Tasks
• Neue Tasks werden in PHP geschrieben

Typisches Phing Build-Skript
<project name="MyProject" description="simple example build file"
default="build" basedir=".">
<property name="src" value="src"/>
<property name="build" value="build"/>
</target>
</copy>
</target>
</project>
• Default-Dateiname ist „build.xml“
• Ausführen durch Aufruf von „phing“, optional abweichender Dateiname

Unterschiede zum ant Build-Skript
<project name="MyProject" description="simple example build file"
default="build" basedir=".">
<property name="src" value="src"/>
<property name="build" value="build"/>
</target>
</copy>
</target>
</project>
• Beschreibung ist ein Attribut, kein Element.
• <property/> kennt nur „value“, keine „location“

Ausführen des Build-Files
$ phing
Buildfile: /Users/schst/tests/phing/build.xml
MyProject > init:
[echo] Directory build
MyProject > build:
[copy] Copying 1 file to /Users/schst/tests/phing/build
BUILD FINISHED
Total time: 0.0642 seconds
• Aufruf von „phing“ genügt

Informationen zum Build-File
$ phing -p
Buildfile: /Users/schst/tests/phing/build.xml
simple example build file
Default target:
-------------------------------------------------------------------------------
build
Subtargets:
-------------------------------------------------------------------------------
build
init
• Aufruf von „phing -p“

phing oder ant?
Verfügbare Tasks
Sehr viele Tasks vorhanden,
da jahrelang im Einsatz
Weniger Tasks als ant, die
Wichtigsten sind vorhanden
Arten der Tasks
Breit gefächtert, allerdings
keine PHP-speziﬁschen
Tasks
Sehr PHP-speziﬁsche
Tasks, wie PHPUnit,
phpDocumentor,
phpCodeSniffer
Erweitern
Kann einfach erweitert
werden, Java-Wissen nötig
Kann einfach erweitert
werden, PHP-Wissen reicht
aus

Apache Maven
• Java-basiertes Build-System.
• Setzt auf „Convention over Conﬁguration“.
• Verwendet einen deklarativen Ansatz.
• Alle Informationen zu einem Projekt werden in einem „Project Object
Model“ (pom.xml) deﬁniert.
• Build-Prozess wird nicht mehr programmatisch beschrieben, sondern
standardisiert.
• Sehr mächtiges Dependency-Management.

Typisches Maven POM
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://
www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://
maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>de.paul-bocuse</groupId>
<artifactId>mvn-app</artifactId>
<name>PHP mit Paul Bocuse</name>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
• Beschreibt das Projekt und dessen Dependencies
• Beschreibt nicht, wie der Build aussieht

Typisches Maven POM
<dependencies>
<dependency>
<scope>test</scope>
</dependency>
</dependencies>
</project>
• Maven verwendet XML-Namespaces
• Jedes Projekt hat eine Group- und Artefakt-Id, optional einen Namen

Typisches Maven POM
<dependencies>
<dependency>
<scope>test</scope>
</dependency>
</dependencies>
</project>
• Packaging Mechanismus ist JAR, kann auch WAR, EAR, etc. sein.
• Plugins können neue Packaging Mechanismen hinzufügen.

Typisches Maven POM
<dependencies>
<dependency>
<scope>test</scope>
</dependency>
</dependencies>
</project>
• Dependencies werden über Maven-Koordination deﬁniert
• Group-Id, Artefact-Id und Version (bzw. Range)

Ausführen des Builds
• „mvn package“ startet den Build
$ mvn package
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building PHP mit Paul Bocus
[INFO] task-segment: [package]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (MacRoman actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /Users/schst/tests/mvn/src/main/
resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] No sources to compile
...
[INFO] [jar:jar {execution: default-jar}]
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Final Memory: 15M/81M
[INFO] ------------------------------------------------------------------------

Maven Repositories
Developer 2
Local Repository
Developer 3
Local Repository
Developer 1
Local Repository
Company
Repository
Public
Repository

Der Maven Build-Lifecycle
generate-sources
compile
test-compile
test
package
integration-test
install
deploy
POM
archetype
compile
sureﬁre
jar
install
mvn compile
mvn install
mvn test

Sind wir noch beim
PHP World
Kongress?

Maven mit PHP
• Maven Plugin
• PHPUnit Integration
• Generiert Dokumentation über DoxyGen (statt JavaDoc)
• Installation über Hinzufügen von neuen Repositories in der settings.xml
• http://www.php-maven.org/

Erstellen eines neuen Projekts
• maven-php liefert einen eigenen „Archetype“
$ mvn archetype:generate
-DarchetypeGroupId=org.phpmaven
-DarchetypeArtifactId=php5-lib-archetype
-DarchetypeVersion=1.1
-DgroupId=de.paul-bocuse -DartifactId=mvn-app
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO] task-segment: [archetype:generate] (aggregator-style)
[INFO] ------------------------------------------------------------------------
....
[INFO] Using property: package = de.paul-bocuse
Confirm properties configuration:
groupId: de.paul-bocuse
artifactId: mvn-app
version: 1.0-SNAPSHOT
package: de.paul-bocuse
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5 seconds

Typisches PHP Maven POM
<project>
<artifactId>mvn-app-2</artifactId>
<packaging>php</packaging>
<name>Sample PHP 5 library project</name>
<build>
<plugins>
<plugin>
<groupId>org.phpmaven</groupId>
<artifactId>maven-php-plugin</artifactId>
<extensions>true</extensions>
</plugin>
</plugins>
</build>
...
</project>
• Basisdaten wie bei Java-Projekten, aber <packaging> ist „php“
• maven-php-plugin wird für den Build benötigt

<project>
...
<dependencies>
<dependency>
<groupId>org.phpunit</groupId>
<artifactId>phpunit5</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
...
</project>
• PHPunit wird als Dependency benötigt
• Wird automatisch aus dem Maven PHP Repository geladen

<project>
...
<reporting>
<plugins>
<plugin>
<groupId>org.phpmaven</groupId>
<artifactId>maven-php-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
<version>2.4</version>
<reportSets>
<reportSet>
<reports>
<report>report-only</report>
</reports>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
</project>
• Im Reporting wird das maven-php-plugin eingebunden

Ausführen des PHP Builds
• „mvn package“ startet den Build auch mit PHP
$ $ mvn package
[INFO] ------------------------------------------------------------------------
[INFO] Building Sample PHP 5 library project
[INFO] task-segment: [package]
[INFO] ------------------------------------------------------------------------
...
[INFO] [php:php-validate {execution: default-php-validate}]
...
[INFO] [php:phpunit {execution: default-phpunit}]
[INFO] Surefire report directory: /Users/schst/tests/mvn-php/mvn-app-2/target/surefire-
reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running AppTest
Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.001016
Results :
Tests run: 1, Failures: 0, Errors: 0
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: /Users/schst/tests/mvn-php/mvn-app-2/target/mvn-app-2-1.0-
SNAPSHOT.jar
[INFO] [plugin:addPluginArtifactMetadata {execution: default-addPluginArtifactMetadata}]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------

Der Maven Build-Lifecycle mit PHP
generate-sources
compile
test-compile
test
package
integration-test
install
deploy
POM
archetype
php-compile
PHPUnit
jar
install
mvn compile
mvn install
mvn test

Maven vs. Ant/phing
• Maven hat einen großen Vorteil beim Dependeny-Management und
Deployment.
• Maven generiert automatisch eine Website mit Dokumentation,
Testergebnissen, Übersicht über die Abhängigkeiten, etc.
• Maven gibt einen Standard für den Build-Prozess vor.
• In PHP bislang nicht verbreitet, für das Dependency-Management wird PEAR
verwendet.
• In den meisten Projekten ist es (noch) sinnvoller, Ant oder Phing einzusetzen.

Weitere Build-Systeme
• make
• install.php oder setup.php
• pake (http://github.com/indeyets/pake)

Henry Gantt
Der Paul Bocuse des Projektmanagements.

Wasserfall-Modell
Initialisierung
Analyse
Entwurf
Realisierung
Einführung
Nutzung
„Jetzt wo ich das
sehe, würde ich
gerne nochmal was
ändern...“
„Das hätten wir
hier wissen
müssen!“

Software-Entwicklung
ähnelt eher dem Kochen
als dem Hausbau.
Wenn man die Software abgeschmeckt
hat, möchte man gerne auch mal
nachwürzen.

Agiles Projektmanagement und agile Entwicklung
Initialisierung Analyse
Entwurf
Realisierung
Test
Nutzung
„Jetzt wo ich das sehe,
würde ich gerne nochmal
was ändern...“
„Kein Problem,
machen wir in der
nächsten Iteration.“

Vorteile des agilen Projektmanagements
• Kosten für Änderungen steigen mit dem Projektfortschritt nicht so stark an,
wie bei klassischen Vorgehensmodellen.
• Ergebnisse werden früher sichtbar und die Geschwindigkeit ist höher. Es wird
eine bessere Transparenz über die Teamperformance geschaffen.
• Durch regelmäßige Priorisierung wird sichergestellt, dass die wichtigsten
Anforderungen umgesetzt werden.
• Fehlentwicklungen werden früher erkannt und das Team kann gegensteuern.
• Das Team ist bei der Planung involviert und trägt somit die Verantwortung mit.

Verschiedene Methoden
• SCRUM
• Crystal
• Adaptive Software Development (ASD)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Kanban

SCRUM
Daily Scrum
24 Stunden
Iterationen
1-4 Wochen
Product
Backlog
Sprint
Backlog lauffähiges
Produkt
inkrementell verbessert
priorisiertAlle Anforderungen

Scrum Charakteristika
• Scrum ist eine teambasierte, iterative und inkrementelle
Entwicklungsmethode.
• Die Entwicklung wird in Zyklen, sog. Sprints organisiert.
• Der Kunde priorisiert seine Anforderungen im sog. Product Backlog vor jedem
Sprint.
• Nach jedem Sprint ﬁndet ein Review statt und die Entwicklung wird
angepasst.

Kanban
• Kombiniert Erkenntnisse aus der Lean Production mit Ergebnissen der
Engpasstehorie und der Fluss-basierten Produktentwicklung.
• Setzt den Fokus auf die gesamte Wertschöpfungskette, nicht nur auf die
Entwicklung.
• Beschränkt die Menge der parallelen Arbeit (Work-in-progress) durch Limits
und verkürzt damit die Durchlaufzeit der wertschöpfenden Anforderungen.
• Für jede erledigte Anforderungen wird eine neue Anforderung in das System
gegeben.

Kanban-Board
Anforderungs-
Deﬁnition
Anforderungs-
Deﬁnition fertig
Entwicklung
Entwicklung
fertig
Test Test fertig Betrieb
2 2 4 2 3 1

Kommerziell Frei
Desktop
Webbasiert
Projektmanagent-Tools

MS Project
• Die Mutter aller Gantt-Diagramme.
• Geeignet für Projekte, die nach dem Wasserfall-Modell geplant werden.
• Anbindung an Project Server erfüllt die meisten Anforderungen an Enterprise
Project Management.

Task Juggler
• Projektmanagement Software für Linux.
• Aufgaben werden in einer Beschreibungssprache deﬁniert.
• Taskjuggler „errechnet“ dann den Projektplan.
• Achtet darauf, dass keine Überlastung stattﬁndet.
• Eher für Wasserfall-Projekte geeignet.

Basecamp
• Produkt der 37signals.
• Online Kollaborationslösung mit allen benötigten Features.
• Verwaltet Dokumente, Aufgaben, Meilensteine, etc.
• Jede Menge Add-Ons und Integration anderer Systeme.
• Für agile Projekte geeignet.

JIRA & GreenHopper
• Eigentlich „nur“ eine Aufgabenverwaltung.
• Sehr mächtiges Workﬂow-Management, somit auch zum
Prozessmanagement gut geeignet.
• Greenhopper-Plugin bringt alles mit, was für agile Projekte benötigt wird.
• Aktuell 225 JIRA-Plugins verfügbar

Burndown Charts in Greenhopper

Kanban Tool
• Kostenloses und simples online Kanban-Board.
• Sehr ﬂexibel konﬁgurierbar.
• Liefert Auswertungen zu den einzelnen Aufgaben und Stationen mit.
• Kann Aufgaben in Projekte organisieren.

Kanban Workﬂow Editor
Kanban Tool

•Der Klassiker
•Reines Bug- und
Aufgabentracking
•Sicher und stabil, wenig
fancy Effekte
•Issue Tracker mit
Standard-Funktionalität
•Wiki, CI-Server, Source-
Browser, Code-Metriken
•Gute Unterstützung für
PHP, da aus PHP
Community entwickelt
•Issue Tracker mit
Standard-Funktionalität
•Wiki, Source-Browser,
Roadmap, Timeline
•Sehr viele Plugins
verfügbar (Python)
Tasktracker - Projektmanagement im Kleinen

Methoden und Tools
Versionsverwaltung
ProjektmanagementBuild & MonitoringTesting & Integration
Code AnalyseEntwicklungsumgebung

Fragen?
Vielen Dank für Ihre
Aufmerksamkeit.
Bildquellen © iStockphoto.com
Kontakt
holger.rueprich@1und1.de
stephan.schmidt@1und1.de

PHP mit Paul Bocuse

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie PHP mit Paul Bocuse

Ähnlich wie PHP mit Paul Bocuse (20)

Mehr von Stephan Schmidt

Mehr von Stephan Schmidt (20)

PHP mit Paul Bocuse