Vorgehen

• Alle nötigen naming conventions und custom Klassennamen in einem codi erfassen, sowie offizielle styleguides suchen und auch im codi verlinken.
• Im Backend beginnen und Ordner für Ordner durchgehen. Nachdem ein file angepasst wurde direkt alle references, imports usw. fixen soweit nicht schon von der IDE automatisch gemacht, dann commiten. Wenn ein file angepasst wurde eventuelle zusätzliche namings im Codi erfassen.
• Jeden abgeschlossenen Ordner im Codi erfassen um den Fortschritt zu tracken. Wenn mitten in einem Ordner aufgehört wird diesen vermerken, sowie das letzte File an dem gearbeitet wurde.
• Am Ende jeden Tages kurz mit jemand anderem den Fortschritt und die erarbeiteten naming conventions besprechen.
• Das gleiche im frontend wiederholen.
• Am Schluss den erstellten styleguide (das codi) im readme verlinken.

Codi mit naming conventions:
https://codimd.puzzle.ch/DWVLjwB8SkaCw0-0LbREWg?edit

Stand 25.11.2024
Für den momentanen Stand des refactorings siehe codi.

Todo Frontend Naming Config

• Dokumentation zu den verschiedenen Tools lesen
• Bestes Tool für uns auswählen (Codi link & mit begründung)
• Config für TS schreiben
• Config für HTML schreiben
• Config für CSS schreiben
• Config für custom conventions schreiben
• Testen, ob jede convention richtig checkt
• Peer-Review

Stand 9.12.24

Ich habe mich nun für eine reine ESLint Lösung entschieden, da es einfach weniger dependency
sind und wenn auch komplizierter als mit anderen Tools wie Stylelint ist es trotzdem noch im akzeptablen Bereich
Ich habe nun begonnen, die ESLint config für TS Files zu schreiben. Habe aber noch keine gute Möglichkeit gefunden, die Custom Wörter wie KeyResult auf richtige Trennung oder Schreibweise zu testen.

Stand 10.12.2024

Ich habe nun weiter an der Config gearbeitet. Ich habe bei HTML und TS die grundlegenden Regeln, die geprüft werden, eingebaut.
Aus irgendeinem Grund dauert der formatter extrem lange.

Still Todo

• Bei TS muss noch ein weg gefunden werden, wie readonly variablen nicht beachtet werden, da beim check nach camelCase readonly variablen in UPPER_CASE als falsch angesehen werden
• SCSS Config
• Bei allen muss noch die Ausnahmen (Keyresult/TeamManagement... https://codimd.puzzle.ch/DWVLjwB8SkaCw0-0LbREWg?edit ) richtig konfiguriert werden
• Anschauen, wieso der Formatter so lange hat, bis er durchläuft.

Stand 11.12.2024
Das Backend habe ich jetzt fertig bearbeitet und gehe nun zum frontend über.

Stand 12.12.2024

Ich habe weiter an der config gearbeitet. Ich habe die Parcing Errors rausgenommen, damit nur noch die Naming conventions angezeit werden. Ebenfalls habe ich es geschafft, dass die readonly variablen nicht mehr als Fehler angezeigt werden, wenn sie in UPPER_CASE sind. Ich habe dann noch an dem id-matcher gearbeitet, damit wir garantieren können, dass die custom Wörter richtig sind. Der regex geht leider nicht mit der i flag da es eine Version der regexe ist, wo es noch kein caseinsensitive supportet (nicht so wie ich es geschrieben habe)

Stand 17.12.2024

Ich habe für den regex eine methode geschrieben die es und serlaubt custom wörter zu einem regex umzuwandeln der kebab-case PascalCase camelCase und UPPER_CASE nach der richtigkeit der schreibweise überprüft. Dies habe ich somit im Html und im Ts eingebaut.

Still Todo

• Fertigstellen der genauen regeln im TS
• Nochmaliges nachschauen ob es wirklich keine option für css gibt
• Eventuell nuch mehr tests zum Helper
• Peer review

Tests mit @ DisplayName versehen

Hierbei ist das Ziel das alle Tests die annotation @ DisplayName erhalten. Diese kann dan mit einer genauen beschreibung der Tests abgefüllt werden. Nebenbei soll noch das naming der Tests allgemein überprüft werden, so das es möglich Konsistent ist.

Hier sind alle Ordner der Tests aufgelistet welche diese Annotation erhalten sollen:

• architecture
• controller
• deserializer
• mapper
  • checkin
  • keyresult
• models
  • authorization
  • keyresult
• multitenancy
  • customization
• security
  • helper
• service
  • authorization
  • business
  • clientconfig
  • persistence
  • validation
• util.quarter
  • check
  • generate
    • h2

Alleinstehende files:

• ForwardFilterTest
• SpringCachingConfigTest
• UserKeyGeneratorTest

Stand 18.12.2024
Ich habe das Ticket gestern noch gerebased und heute am frontend weitergearbeitet. Neben den ganzen Cypress sachen, habe ich einen grossteil der components in /components abgeschlossen (siehe codi für genauen Fortschritt).