[TYPO3-UG Berlin] Roadmap und Mitwirkung von Agenturen

[Elmar Hinz]

Thomas Murphy wrote:
> 
> Irgendwie wusste ich, daß das jetzt kommt ;)
> Sehe ich natürlich auch so, dennoch sollte die Verison 5.0 nicht von nun
> an für Ewigkeiten eine Kiste voller Featurewünsche bleiben, sondern
> wirklich Ergebnisse erzielt werden, sei es die Struktur auf dem Papier
> zu realisieren oder für erste Teile schonmal Prototypen zu erschaffen.
> 

Hallo Thomas,

die Features sind ja "vollständig". Es geht hierbei weniger um
Featurewünsche im traditionellen Sinne, sondern um
Architekturverbesserungen. So sagt auch die Roadmap. Da werden dann
vermutlich zwei, drei Worte ziemlich groß geschrieben "Refactoring",
"Unit-Testing", "Iteration". Prototypen passen dagegen nicht so recht in
diesen Ansatz, weil die eher für neue Features stehen.

> Und insgesamt kann man sicherlich in einem Zeitrahmen von 1 - 1,5 Jahren
> denken, da sich das Internet ja selbst ständig weiterentwickelt und jede
> Überlegung zu einem tollen CMS in 2-3 Jahren Schnee von gestern wäre.
> 

Dieser Zeitrahmen entspricht auch meinem Gefühl.

> Ich bin definitiv auch für gute API's, und zwar noch mehr als jetzt
> vorhanden sind, besonders z.B. eine Templating API für das Frontend, die
> es mir erlaubt z.B. auch Smarty zu verwenden.

Definitiv. Gut APIs sind auch mein zweiter Wunsch neben der
architektonischen Modularisierung. Vielleicht auch eine API TS 2. Wir
müssen bei den APIs auch weg kommen von dieser kryptischen Geheimsprache,
hin zu allgemeingebräuchlichen, klaren Begriffen.

> Wenn die Schnittstellen klar definiert sind, dann sollte auch ein
> Austausch von bestimmten Extensions/Komponenten kein Problem darstellen,
> man bei der Entwicklung also in mehreren Iterationen voranschreiten, was
> eben auch relativ schnell ein "seetüchtiges" Schiff zur Folge hat, das
> bei weitem noch nicht das Finale Produkt sein muss.
> 

Diese Sichweise geht Richtung der reinen Lehre des Refactoring. Das Schiff
wird bei laufender Fahrt in kleinen Schritten (iterativ) modernisiert, ohne
daß sein bisheriges Verhalten irgendwie beeinträchtigt wird. Es ginge dann
also ganz ohne Branching, wie wir es hier diskutiert hatten. Intern
umbauen, den Fortbestand der alten APIs mit Unit-Testing absichern, neue
APIs ergänzen.

Aber ist es wirklich so einfach wie die Theorie klingt? Wie sieht es in der
Praxis aus, wenn wir daran gehen wollen, die Tabellen pages,
pages_language_overlay etc. zu normalisieren. Da fliegt uns sicher ziemlich
viel um die Ohren.

* Können wir das alles mit Unit-Testing absichern?
* Wieviel zusätzlichen Code bräuchte es dann, um allein diese Änderungen
auf die alten APIs abzubilden?
* Zucken wir dann vor diesen grundlegenden Umbauten, in letzter Konsequenz
doch zurück und fahren weiter mit einem langsam veraltenden Rumpf?
* Ist ein Neubeginn in einem eigenen Branch doch der effizientere Weg,
gerade wenn er nicht in allen Teilen "from scratch" sein muß?


Ich glaube, daß wir solche grundlegenden Architektonischen Probleme
anfassen müssen, wenn TYPO3 sich gegen neuere Systeme langfristig behaupten
will. Ich frage mich nach dem besten Weg. Aber sicher ist es kein ganz
kurzer und schneller.

Warum hat MS Word seit Jahren Probleme mit der Stabilität bei größeren
Dokumenten? Trotz eines quasi unendlichen Finanzbudgets. Ich vermute, weil
sie aus Gründen des Marketings nie die Zeit bekommen, Fehler der
Vergangenheit grundlegend zu überwinden.



Grüße

Elmar