Der Fahrplan für das Treffen. Links:

• Konzeptdokument: DE: Konzept OpenSlides 4
• Separation of Concerns: Dijkstra: On the role of scientific thought.
• Notizen: Präsentationen, ...

Das hauptsätzliche Ziel ist es, alle "wichtigen" Services (s.u.) konzeptionell soweit fertigzustellen, dass parallel und unabhängig an einzelnen Services gearbeitet werden kann. Zum aktuellen Stand ist das Gesamtkonzept/Architektur noch nicht fertiggestellt. Die Übrigen TODOS müssen zuerst geklärt werden.

Service-spezifische/architektonische TODOS:

• Inter-Service-Kommunikation: Einige Services müssen HTTP unterstützen. Innerhalb des Servers können andere Technologien/Protokolle unterstützt werden. Beachte dabei: Jedes zusätzliche bereitgestellte Protokoll eines Services muss auch von allen abhängigen Services implementiert werden. Das Protokoll soll klare Vorteile bieten. Möglicherweise müssen Schnittstellen mit mehreren Protokollen erreichbar sein; dann ist eine gute Trennung im Code wichtig.
• Volltextsuche: Beachte die Gedankenansätze im Konzeptdokument
• Autoupdates: Performantere Technologien als Websockets.
• Persönliche Benachrichtigungen: Es fehlt eine konkrete Modellierung. Was wollen wir genau? Wie offen muss das Design für spätere Erweiterungen sein?
• IDs für Modelle: Immer Integers?
• Maximallänge von HTML-Strings?
• Logging in Docker
• Einheitliche Namensgebungen erweitern ("Ubiquitous Language" erschaffen, vlt. kleines Glossar)
• Migrationen klären
• Liste an Actions aus dem Client extrahieren
• Beispieldatenfluss erstellen
• Beschreibungsformat für Schnittstellen eines Services
• Liste wichtiger Dienste erstellen. Priorisieren von Entwicklungsschritten

Allgemeine TODOS:

• TDD Regeln aufstellen
• Codestyle:
  • Allgemeine Art und weise Code zu schreiben -> Smells und Heuristiken. Dabei möglicherweise zu relaxierende Regeln benennen.
  • Für jede genutzte Programmiersprache um sprachenspezifische Regeln erweitern
• Benennung der Services

Die Service-spezifischen/architektonischen TODOS können in Workshops von einer kleineren Gruppe getrennt und parallel bearbeitet werden. Die Lösung (oder Lösungen) sollte kurz der Gesamtheit vorgestellt werden und Pro/Contra/Alternativen genannt werden. Wie genau eine Lösung gesucht wird, evaluiert und vorgestellt wird, ist jeder Gruppe selbst überlassen. Für einige Themen (v.a. Inter-Service-Kommunikation) ist es auch sinnvoll, Technologien zu testen. Gibt es keine weiteren Anmerkungen bei der Vorstellung, kann die Lösung übernommen werden. Das Ziel ist es letztendlich, das Konzeptdokument mit der gefundenen Lösung zu füllen.

Die Lösungen der allgemeinen TODOS werden ebenfalls in das Konzeptdokument übernommen, bedürfen aber (voraussichtlich) die Abstimmung aller an OS4 Entwickelnden.

Danach sollte das Konzept der Architektur abgeschlossen seien, sodass sich um jeden Service einzeln gekümmert werden kann. Dazu werden die "wichtigen" Services aufgeteilt, um in Gruppen/Alleine die Schnittstellen eines Services zu spezifizieren. Dies beinhaltet die bereitgestellten Schnittstellen (Funktionen via HTTP/RPC/..., produzierte Events) im sinnvollen Kontext der Architektur (im Auge haben, was andere Services benötigen!) und benötigten Schnittstellen von anderen Services. Die benötigten Schnittstellen können schwammig angegeben werden (=Stichpunkte mit Text, keine Definitionen). Anschließend sollten die Schnittstellen gematched werden: Werden alle benötigten Schnittstellen implementiert? Sind alle benötigten Events vorhanden? Fals nicht, werden die Schnittstellen iterativ angepasst und erweitert.

Gleichzeitig sollte die Repositorystruktur des OpenSlides-Repositories angelegt werden und für jeden Service ein weiteres Repository mit einer einheitlichen Benennung und {Sprachen,Framework,Bibliotheks}-unabhängigen Aufbau.

Ziel der Schnittstellencharakterisierung ist es, die Services anschließend parallel und unabhängig entwerfen und entwickeln zu können. Die selben Personen, die die Schnittstellen geplant haben, sollten auch den Service entwerfen. Deshalb empfiehlt es sich, dass (falls in einer Gruppe gearbeitet wurde) diese Gruppe auf sehr wenige Personen zu beschränken. Dies ist ebenfalls durch die Vielzahl an Services, die entworfen werden müssen, sinnvoll.

Letztendlich sollte ein Entwurf erstellt werden, der generelle Fragen nach Sprache, Framework und/oder Bibliotheken, Testen in der Sprache, Technologien und die Einbettung in Docker klärt. Diese Rahmenbedingungen sind wichtig um darauf basierend sich Gedanken über das Softwarelayout zu machen. Durch die Schnittstellen werden möglicherweise Module abgeleitet, und mögliche Abstraktionsschichten werden klarer. Wichtig ist auch das Vorgehen zur Abkapslung von Drittanbietern, z.B. durch das Erstellen von passenden Adaptern und einer Isolation im eigenen Quelltext (siehe Dependency Inversion Principle). Nachdem ein Servicekonzept vorliegt, kann eine Erstimplementation beginnen.