MVCLite: Mit Minimalismus zum Maximum
Manchmal frage ich mich selbst, weshalb ich MVCLite programmiert habe und immer komme ich zum selben Ergebnis: Weil es Lite ist.
Nun werde ich jedoch erläutern, wie ich auf das Ergebnis komme und was es letztendlich bedeutet.
Zuerst stellte sich mir die Frage, warum ich ein Mini-Framework
entwickle, wo es bereits so viele gute, ausgereifte und nützliche
Frameworks gibt? Besonders das Zend Framework
möchte ich hier hervorheben und werde es häufiger als Beispiel
heranziehen. Das ZF kann so ziemlich alles, was man brauchen könnte und
gerade das ist der punctum saliens. Dieses "könnte" impliziert, dass
man es nicht notwendigerweise benötigt. Ein prominentes Beispiel aus
dem ZF ist Zend_Translate, mit dessen Hilfe es kinderleicht ist, Texte
zu übersetzen. Klingt gut, mir gefällt das Interface und trotzdem ist
es ein Grund, weshalb ich MVCLite begonnen habe: Es
ist ein Feature, das ich meistens nicht benötige. Auf den ersten Blick
erscheint es dennoch nützlich: Was passiert, wenn ich eine bi- oder
multilinguale Webseite programmieren muss? Ja, dann sollte ich
natürlich von Anfang an Zend_Translate benutzen, damit ich das Problem
später nicht mehr habe. Alles schön und gut, aber das ist meines
Erachtens der falsche Weg. Denn bekanntlich ist Software erst dann
perfekt, wenn man nichts mehr weglassen kann (Warum? Nachzulesen in Getting Real.
Wieso um Probleme kümmern, die man noch gar nicht hat? Das ist einer
der häufigsten Fehler unter Programmierern, denn sie versuchen, alles
von Anfang an perfekt zu programmieren und vergessen dabei, sich auf
die wesentlichen Probleme zu konzentrieren. Das zieht den gesamten
Entwicklungsprozess in die Länge. Auch ich bin in dieser hinsichtlich
noch teilweise in der Denkweise, aber ich versuche mich in diesem Punkt
zu bessern - ein Recode meiner Homepage soll auf diesem Prinzip
basieren.
Mit einer kleinen Codebasis, die wirklich nur das grundlegendste bietet, hat man dieses Problem nicht. Man möge behaupten, dass MVCLite
für Projekte, die Komponenten á la Zend_Translate benötigen, nicht
geeignet ist, aber das ist ein klassischer Trugschluss. Man kann Code
aus fremden Bibliotheken wirklich wunderbar in MVCLite integrieren und somit auf Features zugreifen, die MVCLite
selbst nicht bietet. Das heißt nicht nur, dass man wirklich nur das in
seinem Code hat, was man wirklich braucht, sondern auch, dass man die
Freiheit hat, selbst zu wählen, was man benutzt. Auch wenn man der
Meinung sein kann, dass es auch mit dem ZF möglich ist, fremde
Bibliotheken zu benutzen, ist dies nur teilweise richtig.
Ich versuche es mit einem anschaulicheren Beispiel zu erklären:
Auch wenn definitiv kein Autonarr bin, versuche ich anhand von Autos meine Intention zu zeigen.
Autohersteller Z bietet ein Auto vom Typ F an. Dieses Auto besitzt
einen starken Motor, eine eher handelsübliche Ausstattung und ein gutes
Autoradio.
Autohersteller A bietet ein Auto vom Typ M an. Dieses Auto besitzt
einen äußerst leistungsfähigen Motor, aber fast keine Ausstattung.
Wir gehen in diesem Fall davon aus, dass Komponenten sehr leicht integrierbar sind.
Welches Auto sollte man nun nehmen? Wenn ich mir Auto F hole, dann habe
ich etliche Komponenten bereits integriert, wie z.B. das Autoradio. Und
mit großer Wahrscheinlichkeit werde ich das Autoradio auch benutzen,
warum denn auch nicht? Im Gegensatz dazu bietet mir das Auto M kein
Autoradio an, da müsste ich mir erstmal ein geeignetes Autoradio
aussuchen. Aber will ich überhaupt ein Autoradio? Wenn nicht, müsste
ich es aus Auto F erstmal ausbauen oder einfach nicht benutzen, aber
Letzteres wäre unnötiger Ballast. Ferner stellt sich die Frage, ob ich
mir in Auto F ein neues und vielleicht besseres Radio einbauen würde.
Aber das passiert meistens nur, wenn ein signifikanter
Qualitätsunterschied zwischen zwei Radios ersichtlich ist, denn
andernfalls meinen viele, der Aufwand sei zu groß. Dabei lässt sich
über die Bedeutung von Signifikanz streiten, denn das kommt auf die
Aspekte, auf die man Wert legt. Beim Auto M wird man logischerweise das
geeignetere Radio einbauen, da es keinen wesentlichen Unterschied
macht, welches man nun einbaut. Stringent bedeutet dies, dass man,
obwohl man bereits die Wahl hat, mit Auto M noch mehr Wahl hat, auch
wenn es paradox klingen mag.
Konntet ihr die Parallelen erkennen? Ja, das Autoradio entspricht
einfach einer Komponente zum Übersetzen von Strings. Autohersteller Z
entspricht Zend und das F steht einfach für Framework, ergo Zend
Framework. Auto M steht natürlich für MVCLite und Hersteller A für
meinen Vornamen.
Aus diesen Beispielen ergeben sich weitere interessante Zusammenhänge: Welcher Typ ist besser als Tourenwagen geeignet? Aus welchem kann man im Handumdrehen eine Luxuslimousine
machen? Der Punkt ist, dass beide Autos nicht auf diesen Einsatz
ausgelegt sind, aber im Endeffekt gibt es auch sehr wenige Fälle, in
denen man ein Auto wirklich so benutzen kann, als wäre das Auto nur für
diesen Zweck geschaffen. Daraus ergibt sich die Frage, welches Auto man
als Basis nehmen sollte. Die Antwort folgere ich aus der
Autoradio-Metapher: Den Typ mit der meisten Freiheit.
Ich will allerdings auch nicht die Konsequenzen dieses Ansatzes ausblenden.
Die erste Konsequenz ist die Objektivität: Man muss mehrere mögliche
Komponenten objektiv vergleichen, sodass man herausfinden kann, welche
Komponente am besten geeignet ist. Dies kostet Zeit, aber dadurch
steigt die Qualität des Codes merklich. Da man bei jedem Projekt
entscheiden sollte, welche Komponente man benutzt, werden Fehler á la
"mit Kanonen auf Spatzen schießen" höchstwahrscheinlich ausgemerzt.
Wenn man zu subjektiv arbeitet und dann immer wieder die Komponente
nutzt, die man bereits kennt, büßt man diesen Vorteil wieder ein, was
aber auch dazu führt, dass man schneller entwickeln kann, weil man sich
nicht mehr einarbeiten muss.
Eine zweite Konsequenz ist, dass man sich in neue Interfaces
einarbeiten muss, wenn man eine bis dato unbekannte Komponente nutzt.
Man gewinnt daran nicht nur an Erfahrung, sondern auch an Flexibilität,
da man flexibel sein muss, was als gutes Training angesehen werden
kann. Andererseits kostet es wiederum Zeit sich einzuarbeiten.
Aus diesen Gedankengängen folgere ich einige Konsequenzen für MVCLite:
- Vorteile:
- Man hat keinen unnötigen Ballast.
- Man wird dazu motiviert, geeignete Komponenten zu nutzen.
- Man kann sich schnell in MVCLite einarbeiten.
- Es wird weniger unnötige Features geben.
- Man bleibt flexibel.
- Nachteile:
- Man muss anfangs entscheiden, welche Komponenten man braucht.
- Man muss sich jene erst zusammensuchen.
- Man muss die Komponenten integrieren.
Ich kann jedem Leser nochmal das Buch Getting Real empfehlen... Es klärt wirklich unglaublich viele Aspekte während der Entwicklung von Software. Mich hat es dazu inspiriert, meinen Weg mit MVCLite weiterhin zu verfolgen.