Voraussetzungen für einen erfolgreichen Workflow

Grundlage für den hier gezeigten Workflow sind PhpStorm als IDE mit installiertem git-flow-Plugin sowie ein funktionierendes Ticketsystem Redmine. Natürlich gibt es Alternativen zu dieser Kombination. PhpStorm arbeitet mit sehr vielen Systemen zusammen, und auch andere IDEs haben ähnliche Funktionen. Der Workflow im Versionskontrollsystem basiert auf unserer git-flow-Präsentation und ist aus meiner Sicht zwar im Feinen anpassbar, im Groben aber alternativlos.

Ticketsystem Redmine richtig einstellen

Das Ticketsystem sollte von außen erreichbar sein. Der zur Verknüpfung benutzte User sollte im Ticketsystem aktiv sein und Projekte und Tasks – im Weiteren auch Issues genannt – zugewiesen haben. Zusätzlich muss die REST-Api in der Konfiguration des Ticketsystems aktiviert sein.

In PhpStorm geht es weiter

In PhpStorm geht man zunächst über die Tastenkombi cmd+“,“ (Mac) in die Einstellungen und navigiert zu Tools -> Tasks -> Servers. Dort setzt man nach Auswahl des Ticketsystems die URL und Zugangsdaten zu seinem Ticketsystem.

Ein Klick auf den Test-Button liefert das Ergebnis:

Im zweiten Reiter stellt man die Commit-Einstellungen ein. Das Ticketsystem Redmine ist in der Lage, Commit-Nachrichten auszulesen und darauf zu reagieren. Eine sinnvolle Einstellung zur Automatisierung spart hier wertvolle Zeit.

Optimaler Workflow in PhpStorm mit dem Ticketsystem Redmine

Die Voraussetzungen sind hier ein Projekt im ausgecheckten develop-Branch, ein vorhandenes Ticket und eine eingerichtete Entwicklungsumgebung.

Die Steuerungsleiste für das Taskmanagement befindet sich im rechten oberen Bereich.

Über das Dropdown kommt man in den „Task öffnen“-Dialog.

Nach erfolgreichem Öffnen eines Tasks sollte man eine für den Task eingerichtete Changelist in PhpStorm und auf Ebene der Versionskontrolle einen Feature-Branch ausgecheckt haben.

Sollte man seine relevanten Entwicklungen lokal abgeschlossen haben, kommt der Zeitpunkt, an dem man seinen Code committet. Durch die Nutzung der taskrelevanten Changelisten ist dies selbst bei Bearbeitung mehrerer Issues in einem Projekt durchschaubar. Zudem verringern die voreingestellten Informationen aus dem Ticketsystem die manuell einzugebenden Informationen.

Vor dem anschließenden Push zeigt PhpStorm eine Zusammenfassung der Änderungen.

Als Abschluss muss man das Feature leider noch manuell über das git-flow-Plugin schließen, aber ich hoffe, dass das in naher Zukunft automatisiert wird.

Als Meldung sollte PhpStorm einblenden, dass der Feature-Branch erfolgreich zurückgemerged wurde.

Es kann zudem vorkommen, dass PhpStorm die Changelist nicht löscht. Um die Ordnung nicht zu verlieren, hilft das manuelle Löschen.

Außerdem kann es helfen, bei zu vielen Issues in der Liste auch diese manuell zu löschen.

Überprüfung in der Versionskontrolle und im Ticketsystem Redmine

Wer ähnlich wie wir Redmine mit gitolite und dem redmine git hosting nutzt, kann jetzt in seinem Projekt bei Redmine im Projektarchiv seinen neuen Workflow überprüfen.

Weiterführende Informationen zum Beispiel vom PhpStorm-Hersteller Jetbrains bekommt ihr hier.

Nutzt ihr in euren PHP-Projekten eine andere Kombination von Ticketsystem, Versionskontrolle und IDE? Wenn ja, dann schreibt uns hier doch bitte mal, welche das sind. Denn von einem solchen Know-how-Austausch profitieren ja letztlich alle. Die oben beschriebene Kombination schulen wir übrigens auch.

Der Beitrag PhpStorm mit dem Ticketsystem Redmine nutzen erschien zuerst auf Entwicklungshilfe NRW.

Legacy-Code-Probleme sind überall bekannt

„Nirgends werden tote Pferde so weit geritten wie in der Software-Entwicklung“ heißt es auf meiner Website. Nicht von ungefähr. Denn als Trainer und Dozent im Bereich der Software-Qualität kann ich infrage kommende Code-Stellen, die nach Robert C. Martin gerne als „Code smells“ bezeichnet werden, auch ohne die Unterstützung von Software sehr schnell ausfindig machen. Zudem sind sie unter Webdevelopern durchaus bekannt. Aber sie werden aus Zeitgründen umschifft.

Dabei ist Legacy Code längst kein Problem mehr, welches nur auf den Backend-PHP-Teil betrifft. Denn da heute Webapplikationen geschrieben werden, ist der Anteil von Javascript beträchtlich – und in den kommenden Jahren wird sich das noch weiter verschieben: API-Schnittstellen, Webservices und Microservices werden den Teil des Backends in der Applikation darstellen und unterschiedlichste Clients im Frontend die bereitgestellten Daten verarbeiten. Mit Technologien wie React und AngularJS zeichnet sich hier ein sehr klares Bild des zukünftigen Webdevelopments ab.

Legacy-Code-Nester in Webdevelopment-Projekten

Bei den Frontend-Teilen eines Webprojekts braucht man gar nicht lange zu suchen. Große Ansammlungen sind hier z. B. main.css, style.css und natürlich script.js und app.js. Das sind große und historisch gewachsene Files, die immer nur erweitert werden und selten ein Code-Refactoring gesehen haben. Auch im Bereich der Backend-Entwicklung wird trotz Software-Design und Patterns oft nicht sauber gearbeitet.

Eben dort ist PhpStorm eine große Hilfe: Code, der offensichtlich nicht verwendet wird, wird farbig ausgegraut und kann so recht zuverlässig entfernt werden. Aber auch hier ist große Vorsicht geboten: Ohne automatisierte Tests ist es nahezu unmöglich, effektiv zu arbeiten. Fakt aber ist, dass durch die gewachsene Komplexität und die schlechte Lesbarkeit viel Zeit und Motivation verloren gehen. Wenn man da überhaupt noch durchsteigt. Dann wird gerne kapituliert, was sogar bis zur Krankmeldung gehen kann. Hier Licht reinzubringen, ist, wenn man es nicht regelmäßig macht, ein immenser, unausweichlicher und stetig wachsender Kostenfaktor.

Legacy Code verursacht weitaus höhere Projektkosten

Webdevelopment-Projekte sind in einem schlechten Software-Zustand nicht mehr wartbar, zumal nach und nach immer mehr Bugs ans Tageslicht kommen. Das richtet großen Schaden in sämtlichen Bereichen einer Firma an und kann diese sogar in den Ruin treiben.

Auch Kunden ist das mittlerweile klar geworden: Rund 30 Prozent Mehrkosten sind als On-Top-Budget für Software-Qualität längst eine feste kalkulatorische Größe. Damit werden dann beispielsweise automatisierte Tests eingeführt, um den Entwicklungsprozess optimieren zu können.

Legacy Code verhindert die Weiterentwicklung der Berufssparte

Wenn die verfügbaren Ressourcen eines Webdevelopment-Teams völlig aufgebraucht werden, leiden darunter Weiterbildung und Motivation sowie die Bereitschaft, sich mit Herzblut in seine Arbeit einzubringen. Code wird dann sprichwörtlich hingerotzt. Dabei ist gerade bei der heutigen Programmierung ein enorm hohes und komplexes Wissen gefragt. Das kann nicht mal eben mit einer einzelnen PHP-Schulung abgebildet werden.

Zudem wird es Junior-Webdevelopern auf diese Weise nahezu unmöglich gemacht, sich in die vorhandenen Strukturen zu integrieren. Hinzu kommt die vertane Zeit. Denn sich mit Problemen aus einer „anderen technischen Epoche“ auseinandersetzen zu müssen, ist nicht zielführend. Innovationen und Sprünge in der Entwicklung sind so nicht machbar. Man steckt im Sumpf der Legacy-Projekte fest.

Refactoring ist der Anfang vom Ende des Legacy Codes

Software-Qualität entsteht durch Refactoring von Quellcode. Man spricht hier auch von „Aushärten“. In allen Arbeitsbereichen wird dabei noch einmal über die bestehende Arbeit geschaut, um diese zu korrigieren und zu verbessern. Sogar ein einfacher Blog-Artikel wie dieser hier bekommt dadurch mehr als zehn Revisionen.

Betrachtet man hingegen Code-Stellen, bleibt man im unteren einstelligen Bereich. Hier muss wesentlich mehr Zeit investiert und eingeplant werden. Dies ist dann zugleich eine Investition in das eigene Webdevelopment-Team. Denn warum sollte man sich schwieriger und langsamer in Projekten bewegen, bloß weil der Kunde an diesem Punkt keinen Bedarf sieht …? Schließlich geht es nicht zuletzt um die eigene Software-Qualität – und damit letztlich auch um Lebensqualität.

Wir können Software-Projekte nicht neu schreiben

Noch immer gibt es die Illusion, dass eine Website alle paar Jahre komplett neu gemacht werden muss. Selbst auf Internetseiten, die an Werbekampagnen gebunden sind, soll dies zutreffen. Doch in „Wegwerf-Seiten“ wurde in aller Regel keine aufwendige Business-Logik implementiert – wie etwa in Bereichen des E-Commerce. Insofern ist es purer Wahnsinn, zu denken, man könne mit den vorhandenen personellen Ressourcen parallel einfach mal eine neue Seite entwickeln. Das ist der falsche Weg.

„Same old thinking – same old result“ ist hier ein Problem an sich. Es verhindert, dass sich Entwickler mit neuem Wissen frisch ans Werk machen können, zumal dadurch alte Probleme am Ende nur neu verpackt werden. Zudem ergeben sich beträchtliche Spannungen, wenn ein Teil des Teams neue Software schreiben muss, während der andere Teil den bestehenden Teil weiterpflegt. So kommt nur unnötige Unruhe auf, die dem Teamgeist schadet und das Projekt behindert. Allerdings ist es ohne Weiteres möglich, bestimmte Routen eines Projekts neu zu erstellen und somit sukzessiv Teile zu erneuern. Zu diesem Thema beraten wir gerne.

Mit Pair Programming Probleme erkennen und lösen

Vor allem Refactoring im Team bietet eine hervorragende Möglichkeit, mit Pair-Programming anzufangen. Nutzt man diese Chance, so bildet man gleich auch das Webdevelopment-Team weiter und spart eine ganze Menge Zeit, die sonst für Absprachen und Konventionen nötig wäre. Gerade der „doppelte Blick“ ist ja der Schlüssel dafür, Probleme zu erkennen und aus einem anderen Blickwinkel betrachten zu können. Wir bieten Schulungen mit genau diesem Ziel an. Da der Start mit Pair Programming jedoch nicht immer ganz einfach ist, ist eine externe Meinung umso wichtiger, damit es hier nicht zum Kompetenzgerangel kommt.

Legacy Code und der innere Schweinehund

Sport ist gut für die Gesundheit, gesunde Ernährung ohnehin, und Bewegung tut ihr Übriges. Ein gesunder Körper kann am Ende immer auf einen gesunden Geist zählen. Und halten wir zur Genüge daran? Nein. Wir verfügen über einen regelrechten Ausreden-Katalog, der von täglichen Problemen bis hin zum Wetter immer eine passende Ausrede für uns parat hält. Und dabei ist es doch einfach nur eine Kopfsache.

So ist es auch in der Software-Entwicklung. Hier verhalten wir uns aus mehreren Gründen unvernünftig. Wobei oft gar nicht erst nach Gründen gesucht, sondern ebenso wie beim Thema Sport & Gesundheit bei jeder Gelegenheit der „Keine-Zeit-Joker“ ausgespielt wird. Einfach mal mit einem festen Termin über zwei Stunden in der Woche freitags ab 16 Uhr starten! Das kommt auch erstmal gut an. Aber hier sind Ausdauer und Disziplin gefragt!

Wenn der Budget-Plan keine Software-Qualität zulässt

Investitionen in die Software-Qualität und in das Personal sind dringend notwendig. Aber oft lässt der Budget-Plan dies nicht zu. Doch wie weit kommt man mit einem Auto mit brennender Motorleuchte, ohne einen Motorschaden zu riskieren …? Schlimmstenfalls bis zum Totalschaden. Gleichermaßen riskant ist ein solch „blindes“ Vorgehen in der Software-Entwicklung. Und noch einmal: Darunter leidet immer auch die Stimmung in der gesamten Firma.

In puncto Software-Qualität muss also die richtige Entscheidung getroffen werden! Es gilt, konsequent Ziele zu beschließen und zu erreichen. Der Prozess muss kontrolliert und überwacht werden.

Mit zu viel Legacy Code werden Entwickler verheizt

Als Webentwickler mit Berufserfahrung findet man derzeit in jeder Stadt Arbeitgeber und kann sofort eine Stelle besetzen. Die Stellen selbst sind dabei, auch wenn die Gehälter einander entsprechen, höchst unterschiedlich. Wird der Entwickler gefordert und gefördert – oder doch nur verheizt? Etwa durch zu viel Legacy Code. Letzteres findet man überall. Ersteres vielleicht in den vier großen Städten. Vor allem Berlin zeigt, wie es geht. Und gerade deshalb gibt es dort auch so tolle Erfolgsstories.

Der Ruf der Entwicklungsabteilung und der Software-Qualität im Unternehmen ist ein zunehmend wichtiges Entscheidungskriterium für die Karriere. Daher gilt auch hier: Ist der Ruf erst ruiniert … Treffen Unternehmen indes die richtigen Entscheidungen, so festigt man die bestehenden Strukturen und macht sich attraktiv für neue Bewerber.

Mein Fazit zum Thema Legacy Code

Legacy Code ist nach wie vor ein großes Problem, das sich nur mit Arbeit lösen lässt. Doch ist man diesen Weg einmal gegangen, dann lohnt er sich. Denn klar ist:

• Die Software-Qualität steigt.
• Die Kunden sind zufriedener.
• Die Abteilungen können effektiv arbeiten.
• Der Spaß kehrt zurück an den Arbeitsplatz.

So betrachtet ist die gezielte und intensive Beschäftigung mit Legacy Code ein notwendiges Übel. Denn niemand mag es, ständig aufzuräumen und Ordnung zu halten. Für Profis gehört aber genau das nun einmal dazu.

Welche Erfahrungen hast du mit Legacy Code gemacht? Du kannst gerne das Kommentarfeld unter diesem Beitrag nutzen, um deine Erfahrungen mit anderen zu teilen.

Der Beitrag Legacy Code – Entstehung, Ursache und Auswirkung erschien zuerst auf Entwicklungshilfe NRW.

Continuous what?

Als Dozent für die PHP-Schulungen von Entwicklungshilfe NRW interessiere ich mich über die reine PHP-Entwicklung hinaus für das Thema Continuous Integration (CI). Neben der lokalen Entwicklung mit Tools wie Vagrant und PhpStorm zur schnellen und guten Programmierung an PHP-Applikationen ist eine stabile Pipeline zum Testen und Ausliefern (Deployment) des Codes Gold wert. Funktionierende Automatisierung spart immer Zeit und Geld. Wenn zusätzlich dabei noch getestet wird, schlafe ich als Entwickler direkt ruhiger. CI-Tools machen genau das: Sie testen in einer Entwicklungsumgebung euren Code. Jeder Durchlauf eines Prozesses wird dabei „Build“ genannt. Ziel ist es, durch automatisierte Tests und die vorherige saubere Entwicklung einen fehlerfreien Build auszuliefern.

Vielen Entwicklern wird Jenkins (bzw. Hudson) ein Begriff sein. Wer andere Erfahrungen mit ähnlichen Tools gemacht hat, kann das gerne als Kommentar hier mit einbringen.

PHPCI als Continuous Integration Tool

Heute gebe ich eine kleine Einführung in PHP Continuous Integration, kurz PHPCI. Als PHP-Entwickler habe ich zwar gute Erfahrungen mit Jenkins gemacht – ich finde aber den Ansatz von PHPCI besser, als CI-Tool für PHP-Projekte in PHP geschrieben zu sein. So verstehe ich als Entwickler das Tool besser. Obwohl PHPCI noch ein recht junges Projekt ist, finde ich die derzeitige Funktion schon brauchbar, und es macht Spaß, damit zu experimentieren. Das Github-Projekt findet ihr hier. Doch vor dem Vergnügen kommt erstmal kurz die Arbeit, sprich die Installation. Als Voraussetzung wird hier von einem Debian-basierten Webserver mit installiertem Apache und MySQL-Server ausgegangen. Paketinstallationen auf einem Server sowie das Tool composer sollten euch geläufig sein.

Installation von PHPCI

Zunächst wechseln wir in das Webverzeichnis des Servers (default /var/www):

cd /var/www

Nun erstellen wir per composer das PHPCI-Projekt. Bei dem letzten Befehl solltet ihr eure Datenbank-Zugangsdaten zur Hand haben.

composer create-project block8/phpci phpci --keep-vcs --no-dev
cd phpci && composer install
./console phpci:install

Das Ergebnis sollte so aussehen:

Eine einfache Vhost-Konfigurationsdatei, die dem Apache hinzugefügt und aktiviert wird, reicht zum Aufrufen unseres neuen Tools zur Continuous Integration:

    ServerAdmin __ADMIN__@__SERVER__
    ServerName phpci.__SERVER__
    DocumentRoot /var/www/phpci/public
    
        DirectoryIndex index.php
        Options Indexes FollowSymlinks MultiViews
        Require all granted
        AllowOverride All
        
    LogLevel warn

Solltet ihr nicht mit einer Seite wie dieser hier empfangen werden, schaut bitte in die Installationshilfe auf der PHPCI-Seite nach oder schreibt uns hier.

Wenn ihr jetzt die eingetragene URL aufruft, seht ihr die Startseite eures neuen CI-Tools, und ihr könnt euch einloggen.

Dieser komplette Installationsvorgang dauert keine 30 Minuten. PHPCI ist eine kostenlose, quelloffene Variante, die euch in die Lage versetzt, sehr schnell eine eigene Build-Pipeline als Grundlage für eine Continuous-Integration-, Continuous-Delivery- oder Continuous-Deployment-Strategie aufzubauen. Um die beiden letztgenannten Punkte geht es an dieser Stelle allerdings nicht.

Weitere Posts zum Thema Continuous Integration

Ich versuche, hier so schnell wie möglich weitere Anleitungen über PHPCI zu posten. Geplant sind derzeit auf jeden Fall:

• Aufsetzen eines versionskontrollebasierten PHP-Projektes in PHPCI
• Unit-Tests mit PHPCI
• Acceptance-Tests mit Codeception in PHPCI
• Weitere Tests wie Mess Detection und Code Coverage

Ich hoffe, meine kurze Anleitung war hilfreich für euch. Wenn ihr noch Fragen dazu habt, könnt ihr diese gerne unter Verwendung der Kommentarfunktion stellen. Ansonsten verlinke ich relevante Posts hier.

Einen detaillierten Überblick über unsere PHP-Schulungen für Webentwickler findet ihr übrigens auf der Website von Entwicklungshilfe NRW.

Der Beitrag Continuous Integration: Eine Einführung in PHPCI erschien zuerst auf Entwicklungshilfe NRW.