Thomas Baustert's Blog

Wenn ich ein Framework einsetze, habe ich folgende Erwartungen:

1. Es wurde aus einer laufenden Anwendung extrahiert
2. Es verfügt über eine hohe interne Qualität
3. Es ermöglicht einfache Testbarkeit meines Produktionscodes
4. Es lässt sich schnell und einfach installieren.
5. Es verfügt über gute Dokumentation und Beispiele.
6. Es bietet eine einfache und intiutive Schnittstelle

Es wurde aus einer laufenden Anwendung extrahiert.

Das Framework muss aus einer bestehenden laufenden Anwendung extrahiert worden sein. Nur dadurch hat es (zumindest für eine Applikation) seine Funktionsfähigkeit bewiesen. Im Handwerk werden nur Techniken, Konzepte usw. genutzt und weitergegeben, die sich in der Praxis bewährt haben. Erst die Erfahrung lehrt, was geht und was nicht. Gleiches gilt für ein Framework.

Gute Beispiele sind Ruby on Rails oder Spring (letzteres zumindest wegen diesem Punkt). Ein Anti-Beispiel ist EJB bis 3.0. Die Entwicklung auf der grünen Wiese hat wohl mehr Kosten beim Einsatz verursacht als Nutzen gebracht.

Es verfügt über eine Hohe interne Qualität.

Das Framework muss über eine hohe interne Qualität verfügen, d.h. gut lesbaren modularen Code und eine hohe Testabdeckung bieten. Nur so finde ich Vertrauen in das Framework und bin bereit mich darauf zu verlassen. Warum sollte ich einem Framework vertrauen, dass schluderig programmiert wurde und nicht ausreichend automatisiert getestet wird?

Es ermöglicht einfache Testbarkeit meines Produktionscodes.

Das Framework muss mir auf einfache Art und Weise ermöglichen, meinen darauf aufbauenden Produktionscode zu testen. Andernfalls habe ich den Eindruck, die Entwickler haben dem Thema wenig Beachtung geschenkt und das lässt mich skeptisch im Bezug auf den Rest des Frameworks werden.

Auch hier ist Ruby on Rails ein sehr gutes Beispiel, da ich Tests leicht erstellen und ohne laufenden Webserver ausführen kann. Ein Anti-Beispiel ist auch hier EJB bis 3.0, weil die Beans nur innerhalb des Containers getestet werden konnten und das Schreiben umständlich war. Eigentlich unglaublich, das soetwas jemals produktiv eingesetzt wurde (und wird). Bei 3.0 gibt es nun endlich POJOs und damit einfachere Testbarkeit.

Es lässt sich schnell und einfach installieren.

Wir alle sind immer unter Zeitdruck (zumindest gefühlt) und die Installation sollte daher einfach und zügig gehen. Wenn ich erst viele Abhängigkeiten auflösen muss, vergeht mir vermutlich die Lust und der Frust beginnt. Also bitte diese Arbeit nicht auf den Nutzer abwälzen.

Es verfügt über gute Dokumentation und Beispiele.

Eine gute Dokumentation, vor allem viele gute und einfache Beispiele helfen enorm bei der Einarbeitung. Wenn ich direkt ein Archiv herunterladen, auspacken und loslegen kann, bin ich eher angefixt. Auch Videos sind hier eine gute Unterstützung.

Vielleicht sollte ich noch anfügen, dass das Framework keine Eierlegendevollmichsau sein sollte, sondern sich auf eine Sache konzentrieren sollte, die es besonders gut macht.

Und Vorsicht mit sogenannten Standards! Ein Framework ist nicht Standard, weil ein Firma es als solches benennt. Standard soll nur werden, was sich über lange Zeit bewertet. Also ruhig hinterfragen.

Und was sind deine Kriterien?