Tipps für nachhaltige PHP Entwicklung – Teil2

Erfahrenen Entwicklern stellt PHP ausreichend Mittel für elegante Software Entwicklung zur Verfügung. Schlüsselfertige Projekte wie Magento oder auch WordPress belegen dies. Selbst unerfahrene Entwickler können mit PHP in kurzer Zeit Erfolge erzielen. Eine berechtigte Frage jedoch: Fluch oder Segen?

Übersteigt die Komplexität einer Anwendung ein gewisses Maß, kann dies mittelfristig zu Problemen führen. Schnell sind die eigenen Programmierkünste überschätzt und grundlegende Eigenschaften guter Software werden in den Hintergrund gestellt:

  • unkomplizierte Erweiterbarkeit
  • Vermeidung von Redundanz
  • eine übersichtliche Strukturierung

Im privaten Umfeld kann man ein Projekt überarbeiten, austauschen oder einfach unter Lerneffekt verbuchen. Ist allerdings eine komplexere Software im beruflichen Umfeld erst einmal im produktiven Einsatz,  ist guter Rat vermutlich teuer! Schlecht strukturierte Software kann hier sogar wirtschaftlichen Schaden/Nachteil bedeuten. Das folgende Zitat von Martin Fowler aus seinem Buch Refactoring: Improving the Design of Existing Code bringt die Notwendigkeit von Software Design auf den Punkt:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Die beste Lösung für Fehler im Design: Von Anfang an vermeiden! Der erste Artikel aus dieser Serie: Tipps für nachhaltige PHP Entwicklung hat bereits ein paar Anregungen enthalten. Hier sind weitere Tipps die den Entwickler-Alltag sehr viel angenehmer gestalten und dafür sorgen können dass Software auch längerfristig erweiterbar und flexibel bleibt.

.

Inhalt

1. Coding Richtlinien

Wird im Team entwickelt, sind einheitliche Richtlinien zur Formatierung von Quellcode und Benennung von Variablen, Methoden, usw. sehr wichtig. Jeder hat hier jeder an gewissen Punkten andere Vorstellungen und dafür meist sogar gute Argumente. Wichtig ist jedoch die persönliche Präferenz hier der Software Qualität unterzuordnen und einen gemeinsamen Standard zu befolgen. Nichts ist schlimmer als sich in 4 von 5 Klassen, Dateien, o.ä. an unterschiedliche Stilrichtungen gewöhnen zu müssen.

2. Versionskontrolle

Mit einer Versionskontrolle kann man zum einen kurzfristig auf einen vorherigen Stand zurück springen und Änderungen zurückverfolgen. Auch für dass Deployment von PHP Code eignet sich eine Versionskontrolle im allgemeinen sehr gut. Es ist ein definierter Stand auf den Webservern vorhanden und bei Problemen kann schnell ein alter Stand auf allen Systemen wiederhergestellt werden.

Außerdem kann es passieren dass mehrere Entwickler parallel an einer Datei arbeiten. Die Versionskontrolle verhindert dass Änderungen überschrieben werden. Sollte es Konflikte geben, können parallele Änderungen an der gleichen Datei meist unkompliziert über die Versionskontrolle zusammengeführt werden.

3. Code Reviews

Ein Code Review kann man sich als gemeinsames Hinterfragen von Quellcode vorstellen. Bei einem Peer Review, eine spezielle Form eines Code Reviews, setzen sich zwei-drei Entwickler zusammen und analysieren gemeinsam Quellcode. Idealerweise ist einer der Entwickler komplett unbeteiligt an dem Quellcode der analysiert wird. So können Schwachstellen gefunden werden, der Code auf Richtlinien und Redundanz überprüft werden. Zudem lernt dass Team so mehr Quellcode kennen, was sich später als Vorteil herausstellen kann.

Leider habe ich die Erfahrung gemacht dass Code Reviews oft einfach als Kaffeepausen abgetan werden. Dabei ergeben sich dadurch mit ein wenig Disziplin und nur moderatem Zeitaufwand Vorteile die alle zu besserer Qualität und höherer Effizienz führen.

4. Testumgebung

Wo testet man eine Webapplikation unter nahezu realen Bedingungen? In einer Testumgebung! Speziell im professionellen Bereich sollte man dies tun bevor Änderungen auf produktive Systeme verteilt werden! Im besten Fall hat man ein eigenes (ggf. virtuelles System) dass die gleichen Parameter wie die Produktionsumgebungen bietet. Eine einfache Testumgebung (z.B. ein weiterer VHost auf einem Produktivsystem) ist für die meisten Zwecke vollkommen ausreichend. Sicher kann dies Probleme geben, z.B. wenn Endlosschleifen produziert werden, Sicherheitslücken im Quellcode sind usw. Allerdings ist dieses kalkulierbare Risiko weitaus besser als “am offenen Herzen” zu operieren. Jeder noch so kleine Fehler wird direkt an die Kunden weitergegeben. Bleibt ein Fehler unentdeckt, kann dies unheimlich schnell wirtschaftliche Verluste nach sich ziehen. Sind Fehler keine Ausnahme mehr, wirkt sich dies speziell bei Unternehmen die im Bereich eCommerce/Internet tätig sind auf das Image aus.

5. Projektmanagement

Werden größere Projekte in Angriff genommen, sollte ein Projektleiter definiert sein. Es ist nicht erforderlich dass dies ein Top Entwickler ist. Die Hauptaufgabe ist eher den Stand der Entwicklung im einzelnen im Auge zu behalten. Es ist zudem sehr effizient wenn dieser für die Kommunikation mit Ansprechpartnern außerhalb des Teams verantwortlich ist. Sicherlich haben Entwickler auch Kontakt mit Kunden, Grafikern und anderen Ansprechpartnern. Es ist unheimlich ineffizient als Entwickler sich nebenbei ständig darum zu kümmern dass benötigte Informationen beschafft werden.

Fazit

Alle angesprochenen Punkte sind selbstverständlich Empfehlungen. Sicher ist auch jedes Projekt und jedes Team anders aufgestellt. Deshalb gibt es nicht den idealen Weg für Software Entwicklung im allgemeinen. Aber gerade dass macht es spannend. Wäre jedes Projekt gleich, gäbe es keinen Raum mehr für Kreativität =). Nicht nur der Einzelne wächst und entwickelt sich weiter. Auch Teams, Abteilungen und Unternehmen können an sich arbeiten und interne Abläufe hinterfragen, effizienter werden und bessere Software produzieren! Siehe auch den ersten Teil aus dieser Serie: