Drupal und ökosoziale Software-Entwicklung

Eines der Kern-Probleme effizienter Software-Entwicklung ist Zeit.
Zeit kostet Geld und daher möchte man sie gerne einsparen.

Folgender kurzer Leitfaden zeigt einen einfachen Weg Zeit und somit Geld bei der Software-Entwicklung mit Drupal im Team zu sparen.
Der Leitfaden ist zunächst in 4 Punkte unterteilt dessen Namen wichtige Qualitätsmerkmale der allgemeinen Software-Metrik sind.
Anschließend gehe ich auf das "Weshalb" und das "Wie" ein.

• Wartbarkeit
• Wiederverwendbarkeit
• Verständlichkeit
• Erweiterbarkeit

Es sind jene 4 Qualitätsmerkmale an denen sich ausmachen lässt ob die Entwicklung noch oder schon ökonomisch ist.
Denn können alle 4 dieser Merkmale hoch gemessen werden, profitiert man...

• ... durch geringeren Aufwand bei späteren Wartungen (Fehlerfindung, Updates...).
• ... über das jeweilige Projekt hinaus von den bereits durchgeführten Arbeiten.
• ... geringeren Einarbeitungs-Aufwand von neuen Mitarbeitern oder Projekteinsteigern.
• ... einfachere und schnellere Erweiterbarkeit.

Wartbarkeit...

• ... durch selbsterklärenden Code.
• ... durch Vermeidung von Copy/Paste.
• ... durch vereinheitlichte Nomenklaturen.
• ... durch saubere Dokumentation.

Wiederverwendbarkeit...

• ... durch möglichst modulare, nicht monolithische Software-Anteile.
• ... durch Erstellung von Modulen die möglichst nur ein Problem abbilden.
• ... durch vereinheitlichte Nomenklaturen.
• ... durch saubere Dokumentation.

Verständlichkeit...

• ... durch selbsterklärenden Code.
• ... durch Kommentierung komplexer Routinen.
• ... durch prozedurale Abbildung möglichst kleiner Teilprobleme.
• ... durch vereinheitlichte Nomenklaturen.
• ... durch saubere Dokumentation.

Erweiterbarkeit...

• ... durch möglichst modulare, nicht monolithische Software-Anteile.
• ... durch Erstellung und Nutzung von API-Modulen welche Funktionen für sich wiederholende Aufgaben anbieten.
• ... durch prozedurale Abbildung möglichst kleiner Teilprobleme.
• ... durch saubere Dokumentation.

Viele dieser Unterpunkte wiederholten sich in den obigen Aufzählungen.
Damit sollte klar werden wie wichtig zum Beispiel gute Dokumentation und Standardisierung sind und womit man sie begründen kann.
Während viele Programmierer argumentieren ...
"Ich habe keine Zeit zum Dokumentieren und erstellen generischer Software-Anteile."
... erschaffen sie mit exakt dieser Haltung Zeit- und Kosten-Probleme.

Denn jeder Code der zur Gewinnung von Erkenntnissen durchwühlt oder zur Erweiterung erst umgebaut anstatt einfach nur erweitert werden muss kostet sehr viel mehr und potentiell öfter Zeit anstatt einmalige Dokumentation und generische Konzipierung.
Das betrifft vor allem jene Software-Anteile die potentiell wiederkehrende Probleme lösen.

Schon im Projekt, abgesehen von der Nutzung über ein Projekt hinaus, ist Wiederverwendbarkeit ein hoher Effizienz-Faktor.

Warum?

• Alles was ich bereits programmiert habe, muss ich, wenn ich es richtig gemacht habe, nicht noch einmal tun und auch kein Anderer.
• Alles was ich dokumentiert habe, verstehe ich wieder und jeder Andere nach mir.
• Alles was ich aus bereits gelösten Teilproblemen komponieren kann erspart mir beim Konzipieren das aufwendige "Wie?" zu erörtern denn ich muss nur wissen "mit was?". Zudem spart hier der Rückgriff auf bereits Erstelltes wiederum Zeit.
• Alles was ich aus zentraler Quelle schöpfe (API-Module) kann ich an einer Stelle bugfixen, erweitern oder optimieren ohne viele Teile des Projekt-Codes anfassen zu müssen.

Wie?
Drupal bietet uns dafür nahezu perfekte Vorraussetzungen.
Einerseits ist da das Modul-System welche uns ermöglich API-Module zu schreiben die wir projektweit und darüber hinaus verwenden können.
Andererseits ist da die Theming-API welche es ermöglich für wiederkehrende Rendering-Aufgaben sogenannte Theme-Funktionen zu erstellen.
Letzteres ist quasi jedem Drupalaner schon einmal über den Weg gelaufen. Zum Beispiel in Form von theme ('table'....

Der Trick ist nun, für wiederkehrende Rendering-Aufgaben, beispielsweise eine standardisierte Darstellung von Blöcken derartige Theme-Funktionen zu vereinbaren, welche man dann in allen spezialisierten Modulen des Projekts verwenden kann.

Mit "Spezialisierten Modulen" sind hauptsächlich Module gemeint, welche ihre Aufgaben nur im jeweiligen Projekt erfüllen können.
Ferner ist es auch sinnvoll jene spezialisierte Module durch Komposition generischer Module und API zu erstellen.
Hierdurch schwinden der Copy/Paste-Faktor, damit auftretende Probleme und die Entwicklungszeit rapide.

Für die Theme-Funktionen gibt mehrere Möglichkeiten der Unterbringung.
Zum einen natürlich im Site-Theme. Dort passen sie ja schon rein vom Aspekt her hin.
Zum anderen könnte man sie auch in ein zentrales Modul packen.
Auf welche der beiden Möglichkeiten man hier nun zurückgreift ist eine Sache des Abwägens.
Die Variante mit dem zentralen Modul für die Theme-Funktionen ist z.B. dann sinnvoll wenn das Theme ansich für mehrere Seiten verwendet werden soll, nicht aber unbedingt alle Theme-Funktionen da sie sich von Seite zu Seite layouttechnisch unterscheiden können.
Am gängigsten und fast immer sinnvoll ist die Variante, die Theme-Funktionen im Theme unter zu bringen.
Auch nach einem halben Jahr noch, wenn Änderungen an Render-Elementen durchgeführt werden müssen, lassen sie sich da noch einfach finden. Denn da würde man doch zuerst suchen.
Hin und wieder kommt es auch vor, dass funktionale Module Theme-Funktionen bereitstellen müssen.

Es sollte hierbei jedoch darauf geachtet werden, dass die von Drupal gegebenen Guidelines hierzu eingehalten werden, damit z.B. das Überschreiben von, durch Theme-Funktionen genutzter Templates reibungslos funktioniert.

Beim Erstellen von API-Modulen ist es wichtig, vorweg zu konzipieren was, wann, wo gebraucht werden wird um hier auch gleich konkrete und einleuchtende Schnittstellen zu vereinbaren.

Es ist sinnvoll die API-Module so zu erstellen, dass sie aufgeteilt in funktionale Aspekte vorliegen.

Das erleichtert zum Einen die Wiederverwendbarkeit in weiteren Projekten und zum Andern die Wartung und Auffindungen von entsprechenden Funktionen.

All das sollte natürlich gut dokumentiert sein.
Am Einfachsten ist es, den Code a la Doxygen-Style zu kommentieren um direkt aus dem Code die endgültige Dokumentation automatisch erzeugen zu lassen.
Es ist hierbei sehr wichtig die Funktionen so zu kommentieren, dass Argumente- und Rückgabe-Typen stimmen und die Beschreibung der Funktion möglichst genau das hergibt was die Funktion tut.
Nur so kann zu einem späteren Zeitpunkt in der Dokumentation wirklich das gefunden werden was gesucht wird.
Wird dieses Prinzip nicht eingehalten, führt das nicht zuletzt dazu, dass Code neu geschrieben wird weil dessen Funktion nicht in der Dokumentation gefunden wurde.
Auch kann es dazu führen, dass Funktionen missverstanden werden und dadurch falsche Entwicklungs-Schritte unternommen werden.

Liebe Grüße
Marc Sven Kleinböhl