diff --git a/05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md b/05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md index 4829411..ccdfa03 100644 --- a/05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md +++ b/05-Diplomarbeitsbuch-individueller-teil-Konstantin-Hintermayer.md @@ -774,7 +774,7 @@ Das Modul "Schwarzes Brett" dient als digitale Anschlagtafel für den Absolvente Die Anzeige der Einträge erfolgt in einer responsiven Grid-Ansicht (Index-Komponente), wobei jeder Eintrag als Karte (Card) dargestellt wird. Dieses Design sorgt für eine übersichtliche Präsentation auch bei einer größeren Anzahl von Mitteilungen. - +![Übersicht der Einträge auf dem Schwarzen Brett](./images/05-Konstantin/BlackBoard-Overview.png){ width=70% fig-pos=H } Bilderunterstützung: Das Modul nutzt die Oqtane-interne Dateiverwaltung. Wenn ein Bild für einen Eintrag hochgeladen wurde, wird dieses über einen Image-Proxy skaliert und als Vorschaubild angezeigt. Fehlt ein Bild, wird ein konsistenter Platzhalter verwendet, um das visuelle Gleichgewicht der Grid-Ansicht zu wahren. @@ -808,7 +808,7 @@ Ein wichtiges Merkmal des Schwarzen Bretts zur Sicherstellung der Inhaltsqualit Auf der Serverseite folgt das Modul dem etablierten Muster mit einem `BlackBoardRepository` für den effizienten Datenbankzugriff und einem `BlackBoardController` für die API-Bereitstellung. Die Implementierung des Scheduled Jobs als HostedServiceBase ermöglicht eine tiefe Integration in die Oqtane-Infrastruktur bei gleichzeitig geringem Ressourcenverbrauch. -## Learnings +## Learnings {#sec:kh-learnings} ### Produktion != Staging @@ -855,6 +855,19 @@ Lösungsansatz: Meetings und Besprechungen asynchron zueinander setzen. - Asynchrone Daily-Updates: Statusberichte erfolgen schriftlich (z. B. in Gitea Issues oder YouTrack), nicht mehr in stundenlangen Call-Marathons. Das nimmt den zeitlichen Druck vom einzelnen Entwickler. Oder zumindest in kurzen Commitnachrichten, welche am Ende des Tages automatisch an alle Teammitglieder zum Überblick gesendet werden (eventuell mit \@username tagging, um eine Person nochmal genau anzusprechen) - Review-First-Policy: Ein Feature gilt erst dann als „fertig“, wenn es einen asynchronen Code-Review-Prozess durchlaufen hat. Das Meeting dient nur noch der Klärung von Blockern, nicht der Präsentation von Code. Das war eigentlich schon von Anfang an in unserer `Definition of Done` festgelegt worden. -- Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#continuous-integration) Pipeline) am Tag der Besprechung zu vermeiden. +- Entkoppelung von Meeting und Deadline: Meetings sollten der Synchronisation dienen, während die Abgabe von Arbeitspaketen kontinuierlich (Continuous Integration) erfolgen muss, um Lastspitzen (in der [Gitea Actions](#sec:continuous-integration) Pipeline) am Tag der Besprechung zu vermeiden. -\pagebreak +# Fazit + +Die Entwicklung des Alumnihubs auf Basis von Blazor und Oqtane war eine Reise geprägt von technischer Tiefe, organisatorischen Herausforderungen und wertvollen Erkenntnissen über moderne Software-Architektur. Rückblickend lässt sich festhalten, dass die Wahl des .NET-Stacks sowohl die erwarteten Stärken als auch unerwartete Hürden mit sich brachte. + +Technisch gesehen haben sich die statische Typisierung von C# und das integrierte Dependency Injection Framework als äußerst wertvolle Werkzeuge erwiesen. Sie haben die Entwicklung komplexer, modularer Strukturen – wie des generischen *Reporting Systems* – erheblich vereinfacht und für eine hohe Konsistenz gesorgt. Dennoch zeigt der Vergleich zu anderen Stacks wie React und Go, dass Architektur-Vorteile nicht exklusiv an ein einzelnes Ökosystem gebunden sein müssen. Die Erfahrung mit Protobufs in anderen Kontexten verdeutlicht, dass eine sprachenagnostische Typisierung oft flexibler ist, ohne die Bindung an ein spezifisches Framework-Ökosystem zu erzwingen. .NET bleibt jedoch eine absolut valide und stabile Wahl für Projekte dieser Größenordnung. + +Ein zentraler Aspekt der Reflexion betrifft den Entwicklungsprozess. Die Erkenntnis, dass eine strikte Review-Kultur und eine frühzeitige CI/CD-Automatisierung essenziell sind, kam erst im Verlauf des Projekts voll zum Tragen. Initial fehlende Strukturen führten dazu, dass Module oft unreflektiert hochgeladen wurden, was die Qualitätssicherung erschwerte. Für zukünftige Projekte wäre ein „Automation-First“-Ansatz die oberste Priorität. + +In organisatorischer Hinsicht war die Verkleinerung des Teams ein Wendepunkt. Trotz der gestiegenen individuellen Arbeitslast führte das „Downsizing“ zu einer signifikant höheren Identifikation mit dem Projekt und einer gesteigerten Effizienz. Die klarere Verantwortung jedes einzelnen Mitglieds sorgte für eine Dynamik, die im größeren, weniger fokussierten Team nicht erreicht werden konnte. + +Persönlich bleibt vor allem die fünfmonatige Auseinandersetzung mit der Deployment-Problematik im Gedächtnis. Dass die Lösung für eine komplexe Infrastruktur-Hürde schließlich in einem unerwarteten Moment außerhalb der Arbeitsumgebung – fast schon ironisch – auftauchte, unterstreicht eine wichtige Lektion für jeden Entwickler: Beharrlichkeit ist notwendig, aber oft braucht es auch den nötigen Abstand, um den entscheidenden Blickwinkel zu finden. + +Abschließend lässt sich sagen, dass der Alumnihub nicht nur eine funktionsfähige Plattform für den Absolventenverein darstellt, sondern für mich persönlich als Beweis für die Bedeutung von technischer Neugier, architektonischer Weitsicht und der Fähigkeit zur kritischen Selbstreflexion dient. +(Mehr dazu unter [Learnings](#sec:kh-learnings)) \ No newline at end of file