|
- **KISS: Keep it simple stupid**
|
|
**KISS: Keep it simple stupid**
|
|
|
|
|
|
Wir haben uns darauf geeinigt nach dem KISS Prinzip zu arbeiten und dadurch unnötig komplizierten Code zu vermeiden. Dadurch fällt es jedem Einzelnen leichter den Code nachzuvollziehen.
|
|
Wir haben uns während unseres Projekts darauf geeinigt, das KISS-Prinzip zu befolgen. Dies bedeutet, dass wir uns bemühten, den Code so einfach wie möglich zu halten und unnötige Komplexität zu vermeiden. Durch die Anwendung des KISS-Prinzips konnte jeder von uns den Code leichter nachvollziehen und verstehen, was zu einer verbesserten Zusammenarbeit führte. Das Ergebnis war ein klarer und effizienter Code, der leicht zu warten und weiterzuentwickeln war.
|
|
- **DRY: Dont repeat yourself**
|
|
|
|
|
|
|
|
Um den Code perfomanter zu machen und redundante Information zu vermeiden haben wir darauf geachtet keine Wiederholungen in unserem Code zu haben.
|
|
**DRY: Don't repeat yourself**
|
|
- **Seperation of concerns**
|
|
|
|
|
|
|
|
Das Frontend haben wir in einzelne in sich geschlossene Komponenten aufgeteilt, die jeweils eine bestimmte Aufgabe erfüllen. Diese Komponenten sind wiederverwendbar und können, wenn nötig überall eingesetzt werden.
|
|
Ein weiteres wichtiges Prinzip, das wir bei unserem Projekt berücksichtigt haben, war das DRY-Prinzip. Das DRY-Prinzip besagt, dass man vermeiden sollte, Code zu wiederholen, um die Lesbarkeit und Wartbarkeit des Codes zu verbessern und Redundanz zu vermeiden. Indem wir sicherstellten, dass wir keine Wiederholungen in unserem Code hatten, konnten wir die Code-Performance verbessern und die Arbeit an unserem Code effizienter gestalten.
|
|
Im Backend wurden die verschiedenen Aufgaben in verschiedenen Klassen realisiert. Semantisch zusammenhängende Klassen befinden sich in einem Package.
|
|
|
|
- **Linter für einheitliche Codestruktur (ESLint)**
|
|
|
|
|
|
|
|
Um einen roten Faden und eine einheitliche Struktur zu bekommen, benutzten wir ESLint. Damit kann man bestimmte Syntaktische Regeln definieren um klare Strukturen zu schaffen.
|
|
|
|
- **Code-Dokumentation**
|
|
|
|
|
|
|
|
Wir haben uns darauf geeinigt, dass die wichtigen Methoden beschrieben werden sollten. Diese Beschreibung sollte die Funktion der Methode, Übergabeparameter und Rückgabewert enthalten. |
|
**Seperation of concerns**
|
|
|
|
|
|
|
|
Um das Frontend unseres Projekts übersichtlicher und leichter zu warten zu gestalten, haben wir uns entschieden, es in einzelne, in sich geschlossene Komponenten aufzuteilen, die jeweils eine bestimmte Aufgabe erfüllen. Auf diese Weise können die Komponenten bei Bedarf wiederverwendet werden und an verschiedenen Stellen in unserer Anwendung eingesetzt werden. Im Backend haben wir verschiedene Aufgaben in verschiedenen Klassen realisiert und semantisch zusammenhängende Klassen in einem Package zusammengefasst. Dies führte zu einer besseren Organisation unseres Codes und erleichterte uns die Wartung und Entwicklung der Anwendung.
|
|
|
|
|
|
|
|
**Linter für einheitliche Codestruktur (ESLint)**
|
|
|
|
|
|
|
|
Um eine einheitliche Codestruktur und einen roten Faden in unserem Projekt zu gewährleisten, haben wir uns entschieden, den Linter ESLint zu verwenden. ESLint ist ein Tool, das es uns ermöglichte, syntaktische Regeln zu definieren und sicherzustellen, dass alle Teammitglieder dieselben Codierungsstandards einhalten. Durch die Anwendung von ESLint konnte unser Code lesbarer, fehlerfreier und leichter zu pflegen werden.
|
|
|
|
|
|
|
|
**Code-Dokumentation**
|
|
|
|
|
|
|
|
Eine weitere wichtige Maßnahme, die wir ergriffen haben, um die Lesbarkeit unseres Codes zu verbessern, war die Dokumentation unserer Methoden. Wir haben uns darauf geeinigt, wichtige Methoden im Code zu dokumentieren und eine Beschreibung hinzuzufügen, die die Funktion der Methode, Übergabeparameter und Rückgabewerte beschreibt. Dadurch konnten wir sicherstellen, dass alle Teammitglieder den Code leichter verstehen und bei Bedarf Anpassungen oder Erweiterungen vornehmen konnten. |