search

wisydb / wisy

Open Source CMS for Training and Educational Purposes
Other
1 stars 3 forks source link

Code modularisieren #7

Open svenkaemper opened 6 years ago

svenkaemper commented 6 years ago

"Code-Überarbeitung im Sinne mehr Modularisierung beginnen – im Sinne einfacherer Veränderbarkeit in Zukunft. Zum Start: Fleißarbeit: Unterteilung sämtlicher Dateien, die das Frontend steuern in möglichst atomare (inhaltlich sinnvolle) Einheiten. Parallel: Konzept zum weiteren Umbau / Code Refactoring"

svenkaemper commented 6 years ago

@meyway @debagel In der Tat macht hier vorab ein Konzept zur technischen Umsetzung Sinn: Wo fängt man an, wie gliedert man was, welche Module haben Priorität etc. Auch die Dokumentation der Module bzw. eine Art "Coding Guidelines" für künftige Module/Entwickler ist sicher angebracht.

svenkaemper commented 5 years ago

@wisydb Wäre es nicht sinnvoll, Core51 (den bisher noch niemand produktiv einsetzt) als "sauberes" Whitelabel-Portal inkl. der neuen Suche aufzusetzen und dabei die von dir genannte "Code-Überarbeitung im Sinne mehr Modularisierung" anzugehen? Also Altlasten entsorgen (alte Suche rauswerfen, HTML5 als Standard, etc.), Frontend modularisieren usw. …?

wisydb commented 5 years ago

Ja, das macht alles Sinn. @debagel hat die Suche ja nun überführt und ich habe es auf den Server, dass die Betreiber es an Ihr Portal anpassen können. core20/50/51 wird in der Live-Version durchgehend genutzt bleiben. Aber mit der neuen Suche ist ein guter Zeitpunkt das ganze anzugehen. Die alte Suche ist ja dann schon aus dem aktuellsten Kern 51 geflogen (@debagel ?) oder ist das z.Z. noch parallel vorhanden? Wenn parallel, könnte es da i.d.T. rausfliegen, dass man einen "cleanen" aktuellen Stand hat.

Jedoch haben wir eine dev-Branch für wildere Entwicklungen angelegt. Vielleicht sollten wir die unangetastet lassen für laufendes.

Ich kann eine zweite dev-Branch anlegen (re-build, refactoring oder wie auch immer). Sinnvoll?

Ich denke es braucht einen groben Plan und dann eher kleine Schritte und die dann immer wieder in den Live-Kern integrieren, also z.B. Renderer für Renderer, weil man sonst sämtliche sonstigen, laufendem Änderungen immer mind. doppelt übernehmen muss (live + refactoring-branch)...

Die Unterteilung in kleinere Code-Einheiten sowie hie und da Trennung von Funktionen (vll. erst mal "View" <-> "der Rest") und weil Output dann besser getrennt: vll. mehr callback-Funktionen, hier (Frontend-Output) finden ja die meisten kleinen Eingriffe statt.

Dann müssen wir sehen, wie weit das aktuelle Budget damit reicht.

  1. Ziel also: Anpassungen in der Größe eindämmen, wo so "viele" Leute gleichzeitig daran arbeiten.

Eher als 2. Ziel danach sinnvoll: anderes (HTML5 wo noch nicht gegeben - wo noch gegeben, sind die alten Funktionen noch parallel enthalten?)...

svenkaemper commented 5 years ago

@wisydb @debagel Wie besprochen sehen wir hier im ersten Schritt zunächst eine Art "technisches Konzept" vor und überlegen, wie die Modularisierung im Detail erfolgen kann. Darin wird dann auch eine Priorisierung enthalten sein, die die nächsten Schritte vorgibt und die wir gemeinsam abstimmen.

debagel commented 3 years ago

@wisydb Ich schlage vor, dass wir für die Arbeiten an diesem Ticket einen neuen Branch nutzen aus dem wir dann als erstes alle "Altlasten" entfernen bevor wir die weitere Modularisierung planen. Bitte leg uns so einen Branch an, wenn du das auch so siehst :-)