Projekthandbuch - SE-TINF22B2/G3-ApeRepublic GitHub Wiki
Dieses Dokument enthält wichtige Informationen zur Organisation und Durchführung des Projekts.
Rollen
Person | Zuständigkeit |
---|---|
Anisa | Datenbank |
Elnaz | Frontend |
Marc | Backend |
Matej | API, Backend |
Simon | Frontend |
Weitere Rollen:
- Dokumentationsbeauftragter: Matej
- Zeitkoordinator: Anisa
- Scrum Master: Marc
Sprachen
Sprache | |
---|---|
Dokumentation | Deutsch |
Statusreport | Deutsch |
Code | Englisch |
Issues | Deutsch |
Statusreports
Wöchentliche Statusreports zu dem Projekt werden hier veröffentlicht.
Zeiterfassung
Die Zeiterfassung wird von jedem Teammitglied selbständig erfasst. Diese Zeiten werden in den wöchtenlichen Statusreports dokumentiert.
Aufwandsschätzung für Issues
Für die Aufwandsschätzung benutzen wir die (modifizierten) Fibonacci Zahlen für die Story Points.
0,5 - 1 - 2 - 3 - 5 - 8
Legende:
- 0,5 SP -> Leichte Aufgaben, hauptsächlich Dokumentation und ähnliches
- 1 SP -> Leichte Aufgaben, z.B. Performanceoptimierung oder Bugfix
- 2 SP -> Leichtere Aufgaben, Codeveränderungen, meist keine neuen Program-Funktionen
- 3 SP -> Mittelgroße Aufgaben, größere Codeänderungen
- 5 SP -> Umfangreiche Aufgaben, größere Codeänderungen, die Recherche benötigen
- 8 SP -> Sehr große Aufgaben, es soll überprüft werden, ob man die Aufgabe in kleinere zerbrechen könnte
Dabei entspricht 1 Storypoint ungefähr 45 Minuten.
Planung der Entwicklungsphase - Gantt Diagramm
Frontend Guide
-
Seiten-Komponente sollen immer mit “page-“ beginnen, Komponente innerhalb der Page nicht Beispielkomponente: page-logIn, page-main, table, graph, page-signIn
-
Alle Divs in der Anwendung sind per default mit “display: flex” definiert
-
Die Anwendung wird standardweise mit “Prozent” skaliert
-
Services sind im Ordner “services” zu erstellen
-
Icons und Bilder werden im Ordner “assets” gespeichert
-
es wird vorerst mit dem Material Design von Angular gearbeitet
-
Styles sollen so viel wie möglich in den scss-Dateien definiert werden (und nicht direkt im html, es sei denn es ist wirklich nicht wichtig)
-
komponentenübergreifende Änderungen sollen abgesprochen werden
-
Routing:
-
- Default-Page: DepotSeite,
-
- Falls kein SessionToken vorhanden bzw. nicht eingeloggt ist wird man auf die LoginSeite weitergeleitet,
-
- Auf der LoginSeite kann man sich entweder einloggen oder zur RegistrierenSeite wechseln,
-
- Bei erfolgreichem Einloggen/Registrieren bekommt man Zugang zur DepotSeite und die SessionToken,
-
- Mithilfe der SessionToken muss sich der User zukünftig nicht mehr einloggen,
-
- Im Header kann man sich ausloggen, die Token wird entfernt und man wird auf die LoginSeite zurückgeleitet,
-
- Der LogOut-Knopf wird nur angezeigt, wenn man eingeloggt ist
Backend Guide
Namenskonvention
Klassen des Servers werden immer kategorisiert in eine der folgenden Gruppen:
- Controller
- Services
- Models
- Repositories
- Config
Um den Zweck einer Klasse einfach erkenntlich zu machen, endet jede Klasse mit dem Namen seiner Gruppe.
Bspw.: "UserAuthService"
Struktur
Unterschiedliche Funktionalitäten werden strikt getrennt und nicht in einer Klasse gehandelt.
Das abgreifen von Anfragen und das Verarbeiten dieser ist Beispiel für diese Implementierung.
Um Webabfragen zu empfangen werden Controller verwendet. Sie sind die Schnittstelle nach außen und leiten die Anfrage an einen passenden Service weiter.
Bspw.: "StockPriceController" & "StockPriceService"
Anfrage- & Antwortmanagement
Anfragen werden entweder in sogenannten Requestklassen abgefangen oder über einzelne Emfangsparametern.
Bspw.: "UserRegisterRequest"
Antworten werden in einer Responseklasse modelliert, in ein JSON-Objekt umgewandelt und dann zurückgesendet.
Bspw.: "APIResponse" (generische Klasse, die verwendet werden kann um unterschiedliche Antwortformate zu modellieren)