Cleanup und Refactoring

Paketstruktur überarbeiten

• de.thm.kim.tc.app

  • account (Homescreen und Profile)
    • data
      • entity
        • enums
      • repository
    • service
    • web
  • timeline (Timeline zeugs)
    • data
      • entity
        • emus
      • repository
    • service
    • web

• (siehe !24 (merged)), zur Zeit hängt alles im app-Modul rum

Unnötige Methoden entfernen

In Timeline-Sources unnötige und nicht benutzte Routen wie /timeline/sources/campus/{campusId} usw., entweder komplett entfernen, oder mittels Builder-Pattern ändern.

[Lynda] Der gute alte Frank. :3

Abhängigkeiten loswerden! :)

Die Entites sollten im Controller aufgelöst werden und nicht im Service. Dadurch fallen die Abhängigkeiten auf der Service-Ebene weg und im Controller werden die Objekte serialisiert. Sollte eine ID nicht vorhanden sein, wirft der Controller ein 404 RessourceNotFound. Zum serialisieren des Objektes, am besten eine Methode schreiben (getUser(id: Long)), um Boilerplate-Code zu vermeiden. Auf Service Ebene, immer nur Optional zurückgeben, anstelle von Web-Exceptions.

Swagger-Dokumentation überarbeiten

Sind alle Dokumentation erstellt? Sind manche Stellen unglücklich formuliert oder werfen Fragen auf? Eigene Kategorien wie "Account", "Timeline", "Thinkbig" erstellen. :)

Neues Schema an Flyway anpassen

Auslagern der Pakete in eigene SQL-Dateien. Beispielsweise könnte man die SQL-Dateien dem Schema so anpassen:

• V_1_0_0_Initial_database.sql
• V_1_0_1_Create_account_schema.sql
• V_1_0_2_Create_timeline_schema.sql
• V_1_0_3_Create_thinkbig_schema.sql

Das gleiche natürlich auch mit dem Hinzufügen der Testdaten.
Daten sollten unterschieden werden zwischen dem Dev- und dem Produktiv-System.

Boilerplate-Code in Interfaces auslagern.

Die ganzen UserTimeline*Service, machen oft dasselbe, eventuell kann man diese in ein Interface oder einer abstrakten Klasse auslagern. Vielleicht hilft ein Design Pattern (Factory).

[Lynda] Ach Franky, Factory Design-Pattern

@Transactional an Controller-Methoden

Die Controller die Daten in der Datenbank manipulieren, sollten die Annotation @Transactional bekommen. Da sonst bei einer fehlerhaften Ausführung die Hälfte der Daten bearbeitet ist und die andere Hälfte nicht.

[Lynda] Siehe mehr dazu hier. :3

DTOs mittels ResourceAssembler erstellen

Sollten DTOs in mehreren Controllern erstellt werden, kann man diese auch mit einem ResourceAssembler erstellen.

[Lynda] ResourceAssembler zum erstellen von DTOs.

Tests umschreiben

Durch das Refactoren müssen wahrscheinlich ein paar Mockito-Tests neu/um-geschrieben werden. :( Da die Abhängigkeiten aus der Service-Ebene in die Controller-Ebene ausgelagert wird.

Module ausmisten

• reward-Modul entfernen
• jobboard und schedule erstmal nicht mitbauen

Konsistenz

• Schreibweisen von Fehlermeldungen einheitlich
• Reihenfolge von Parametern konsistent über (möglichst) alle Ebenen
• Manchmal ist ein User "Author", ein anderes Mal nur "User" etc. Mal überlegen, was da am Besten ist. In DTOs lohnt es sich, sprechende Namen zu verwenden, finde ich.