Die 5 Must-Haves jeder Web-Applikation

Zunächst vorgneweg: In diesem Artikel geht es um die Basics. Erfahrene Entwickler werden hier nichts Neues lesen. Dennoch finde ich es wichtig, auf die folgenden 5 Punkte hinzuweisen. Die Praxis zeigt mir immer wieder, dass diese Dinge nicht bei jeder Entwicklung eine wichtige Rolle spielen.

Versionskontrolle

Die Diskussion über git vs. SVN hält schon eine Weile an. Ich persönlich arbeite gern mit bazaar. Letztlich ist es ziemlich unerheblich, welche Versionskontrolle man verwendet, hauptsache man nutzt überhaupt eine. Das erscheint trivial, ich habe aber genug Projekte erlebt, in denen das nicht der Fall war. Das läuft meist wie folgt ab: Man bekommt die Zugangsdaten zum FTP-Server und arbeitet mit dem, was gerade produktiv auf dem Server liegt. Na schön, schwierig wird es spätestens sobald auch jemand anders die Zugangsdaten hat, was meist immer der Fall ist. Die Änderungen durch mehrere Personen sind absolut nicht nachvollziehbar und man überschreibt sich ständig gegenseitig die Dateien.

Der Einsatz einer Versionskontrolle bringt aber nicht nur Vorteile in der Zusammenarbeit. Das Projekt Clean Code Developer [Link: http://www.clean-code-developer.de] stellt noch einen weiteren Vorteil der Versionskontrolle heraus:

„Angst vor Beschädigung eines „running system“ lähmt die Softwareentwicklung. Mit einer Versionsverwaltung ist solche Angst unbegründet. Die Entwicklung kann schnell und mutig voranschreiten.“

[Zitat, Quelle: http://www.clean-code-developer.de/Roter-Grad.ashx]

Somit hilft ein VCS vor allem die Scheu vor der Weiterentwicklung und Umgestaltung des Codes zu reduzieren. Darüber hinaus kann die Historie des Projektes Aufschluss darüber geben, warum jemand in der Vergangenheit Design-Entscheidungen getroffen hat. Dafür benötigt man aber sinnvolle Commit-Messages, z.B. „In order to reduce the load on the DB, we decided on caching the results for 15 min.“

Coding Standards

Ein weiterer wichtiger Bestandteil der Entwicklung ist die Auswahl und Einhaltung von Standards, in diesem Fall Coding Standards. Diese geben Auskunft über die Benennung und Schreibweise von Variablen, Funktionen und Klassen, über das Einrücken von Codeblöcken und die generelle Verwendung von Sprachelementen. Alle beteiligten Entwickler sollten sich auf diese Regeln einigen und diese konsequent anwenden. Das Resultat ist eine verbesserte Lesbarkeit des Codes, die vor allem in einer besseren Wartbarkeit resultiert.

Das Schöne ist: Die meisten Open Source Projekte bringen Coding Standards mit. Somit muss man sich auch für sein eigenes Projekt kein großes Kopfzerbrechen machen, sondern kann diese einfach übernehmen. Weit verbreitet sind PSR 1/2 [Link: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md]. Bei PHPStorm ist dieses Standard-Set sogar schon vordefiniert und kann für die Code Inspection genutzt werden. Besonders mächtig sind die Style-Vorlagen in Verbindung mit dem Tool Code Sniffer, der peinlichst genau auf deren Einhaltung achtet.

Staging Sicherheit

Die meisten Web-Projekte laufen in mindestens zwei Umgebungen: Dem eigenen lokalen Server (meist localhost) und der produktiven Umgebung. Generell ist es wünschenswert diese Umgebungen von der Konfiguration möglichst ähnlich zu halten. Dennoch gibt es immer wieder Unterschiede zwischen beiden. So müssen Pfade, DB Zugangsdaten, Logging Einstellungen usw. zwischen Development und Produktion angepasst werden. Viele Open Source-Projekte kommen mit Konfigurationsdateien, in denen solche Einstellungen getätigt werden können. Bei WordPress z.B. die wp-config.php. Leider sehen diese Dateien meist keine Unterstützung für mehrere Umgebungen vor. Sinnvoll ist hier der Einsatz unterschiedlicher Environment-Konfigurationen.

Die kann z.B. durch das Setzen umgebungsspezifischer Variablen erfolgen. In Apache kann folgende Konfiguration im vhost oder einer .htaccess-Datei gesetzt werden:

SetEnv STAGE DEVEL

#SetEnv STAGE PROD

In der Applikation wird im Config-File dann unterschieden:

switch($_SERVER['STAGE']) {

  case 'DEVEL':

    $db_user = 'root';

    $db_pass = 'pass';

    break;

  // other environments

  default:

  // production stage

    $db_user = 'QEUFecSf'

    $db_pass = 'zefpXDyECwAaQwY9';

    break;

}

Somit muss man sich über das Deployment der Anwendung weniger Gedanken machen, insbesondere erübrigen sich Gedanken wie: „Aufpassen, dass ich nicht die Konfiguration für Prod überschreibe!!!“.

Internationalisierung

Selbst wenn eine Software zunächst nur für einen Markt vorgesehen ist, profitiert man von der Internationalisierung. Damit meine ich vor allem die Separierung von Markup und Inhalten: Die Ausgliederung aller Sprachbausteine in separate Sprachdateien. Somit bleiben die Templates frei von Inhalten, die Pflege der Inhalte wird in dedizierte Dateien überführt. Das bringt vor allem Transparenz und Flexibilität. Sollte das Produkt irgendwann als Whitelabel-Lösung verkauft werden, oder plötzlich doch der Roll-Out in andere Märkte bevor stehen, spart man sich die Arbeit jeden Linknamen und jede Button-Beschriftung händisch aus dem Templates zu extrahieren.

Es gibt eine ganze Reihe von Tools, die bei der Internationalisierung unterstützen, z.B. gettext. Symfony2 kommt mit einem Translations-Bundle, welches das Format XLIFF unterstützt. Das sind XML-Dateien, in denen die Sprachbausteine abgelegt werden. Im Code verwendet man dann nur noch die sprachunabhängigen (meist Englischen) Keys.

Noch ein weiterer Tipp: Die Bennung von Variablen, Funktionen und Klassen (auch CSS), sollte immer Englisch sein. Das ist eine Konvention, die sich unter Entwicklern durchgesetzt hat. (Leider dennoch nicht immer befolgt wird…)

Error Logging

Wenn wirklich mal was im Argen liegt mit der Applikation, ist ein aussagekräftiges Error Logging unverzichtbar. Die Log-Level sollten entsprechend der Umgebung angepasst werden. Während der lokale Server talky-talky sein sollte im Bezug auf Notices und Warnings und deren Ausgabe im Frontend, sollte die Produktion alle Fehler nur in einen zentralen Logfile schreiben.

Es lohnt sich auch hier ein Blick in die PSR-Standards: PSR-3 schlägt ein Logger Interface vor, das verschiedene Log-Level vorsieht. Eine schöne Implementierung findet man bei Monolog [Link: https://github.com/Seldaek/monolog]. Dies sieht auch verschiedene Log-Formate wie Dateiausgabe, Webservice oder Datenbank vor.

Fazit

Mit diesen 5 Punkten lässt sich das Leben eines Entwicklers erleichtern. Die Liste lässt sich beliebig fortsetzen und ich freue mich, wenn Ihr weitere Punkte aufzählt. Täglich findet der Entwickler Code Smells oder Design-Fehler, welche die Weiterentwicklung eines Projektes erschweren. Es gibt einen ganzen Haufen von Fachliteratur, die sich diesen Themen widmen. Softwarequalität ist ein Prozess und man lernt jeden Tag neue Prinzipien und Mechanismen zur Verbesserung der Qualität kennen.