Orchestrator/bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Europa-Naming-Conventions.md

Team Europa: Naming Conventions

Version: 11 | Last modified: 2026-02-02T11:46:28.363+01:00 Source: confluence page ID 402097097

---

Branch-ConventionstrueAQuA Branch rulesfalse600autotoptrue14024091 Dauerhafte Branchesdevelopment enthält zu jedem Zeitpunkt den letzten Stand der abgeschlossenen Issues, d.h. Arbeit an Features, Enablern und Bugs werden nach Abschluss per Merge Request auf diesen Branch gebracht. Im Fall von Hotfixes werden diese auch nach Abschluss über release zurück nach development gebracht. Von release (früher main) erstellen wir am Ende jeder Iteration ein Release durch Setzen eines Tags, nachdem wir den Stand von development dorthin gemergt haben.

Regeln für temporäre BranchesBranches für Hotfixes zweigen von release ab und tragen das Präfix hotfix/. Auf diese Weise sind sie nicht nur als Hotfixes leichter erkennbar, es lässt sich auch im GitLab konfigurieren, dass Merge Requests für Hotfixes per Default zurück nach release gehen. Von dort mergen wir dann weiter zurück nach development. Branches für die Arbeit an Jira-Issues (Features, Enablers oder Bugs, die keine Hotfixes sind) verwenden das Präfix ticket/ und werden von development abgezweigt. In GitLab konfigurieren wir, dass Merge Requests von diesen Branches per Default zurück nach development gehen. Die Information, um welche Art von Issue es sich handelt, ist nun nicht mehr redundant im Branchnamen enthalten, ist an der Stelle aber auch nicht nötig. Branches für Arbeiten ohne Issue verwenden als Präfix no-ticket/. Sie werden wie Issue-Branches von development abgezweigt und per Default dorthin gemergt. Durch Tools erstellte Branches, wie z.B. durch den Renovate Bot, erhalten einen Bezeichner des Tools als Präfix, wie z.B. renovate/, und werden per Merge Request nach development gemergt.

Auf das Präfix folgt bei Branches, die sich auf ein Issue beziehen, die ID des Issues sowie eine durch Bindestriche gekoppelte kurze Beschreibung des Inhalts, also z.B. IFPRPR-112-map-calendar-attributes. Bei Branches ohne Issue verwenden wir nach dem Präfix aussagekräftigen Kurzbezeichnung, z.B. add-ktlint Wichtig: Bei Commits auf den temporären Branches beachten wir die AQuA: Konventionen für Commit-Messages. Suffixe für API-KlassenDer AGS verwendet diverse Schemata für JSON-Daten, z.B. Produktions- und Vertriebsaufträge jeweils in den Domänen Vertrieb und Fahrplan, die wir umgangssprachlich APIs nennen und die in Form von OpenAPI-Spezifikationen vorliegen. Für die Verarbeitung der Daten nutzen wir Code, der mit einer ifpGenerateApiClient Gradle-Task generiert wird (siehe z.B. Submodul produktionsauftrag-api-fahrplan). Bei der Konfiguration der Task kann ein modelNameSuffix angegeben werden, der an alle Namen von generierten Klassen angehängt wird. Dieses Suffix sollten wir für alle APIs durchgängig einheitlich gestalten, so dass am Namen einer Klasse ihr Ursprung abgelesen werden kann, mit dem Ziel, den Code, der API-Klassen nutzt, leichter verständlich zu machen, und um Fehlern vorzubeugen. Ein Suffix sollte deshalb im Regelfall aus zwei Teilen bestehen: Einem Kürzel für die Gesamtmenge der enthaltenen Nachrichten. Aktuell verwenden wir Pa für Produktions- und Va für Vertriebsaufträge. Künftig wäre z.B. Bpe oder Pe für (Bau-)Planungsergebnisse im unterjährigen Bau denkbar. Einem Bezeichner für den Kontext - i.d.R. die Domäne - dem die API entstammt. Aktuell verwenden wir Vertrieb und Fahrplan für eben diese beiden Domänen. Als Kombination ergeben sich dann insgesamt z.B. ErstanmeldungMessagePaVertrieb und PathInformationVaFahrplan als Klassennamen. Dies sollte im Allgemeinen alles sein, ein weiteres Anhängsel wie Dto fügt nur unnötiges Rauschen hinzu, da das Vorhandensein eines Suffixes ohnehin schon signalisiert, dass es sich um eine API- und damit DTO-Klasse handelt. Commit Messages und Titel von Merge-Requestssiehe  Tests und TestvariablenVariablen innerhalb von Tests folgen diesen Konventionen: Test-Inputs bekommen den Präfix given Erzeugte Ergebnisse (typischerweise der Rückgabewert der getesteten Methode) bekommen den Präfix actual Erwartete Ergebnisse (typischerweise das, wogegen die actual-Werte verglichen werden) bekommen den Präfix expected Das zu testende System (typischerweise ein Service oder eine anderweitige Spring-Komponente, aber möglicherweise auch eine (Extension- oder statische) Funktion) bekommt den Präfix tested. Gemockte Komponenten bekommen den Präfix mock. Dies wird sinnvoll adaptiert für mock-ähnliche Komponenten (Spys, ...) Der Mehrwert, der hierdurch gewonnen werden soll, ist, dass innerhalb eines Tests eindeutig auf einen Blick identifiziert werden kann, welches das getestete System und welches nur Hilfestellungen für den Test sind. Codebeispiel(exemplarisch, nicht realer Code mit vielen Auslassungen) java @Spy var spyAngebotstrasseMessageService : MessageService

fun receiving Fertigmeldung should trigger sending Angebotrasse( val givenFertigmeldung: Fertigmeldung, // or string of JSON val givenZugtrasse: Zugtrasse, val expectedAngebotstrasse: Angebotstrasse ) { // Arrange when(mockAngebotstrassenRepository.getByFertigmeldung(givenFertigmeldung)).thenReturn(givenZugtrasse)

// Act spyFertigmeldungMessageService.send(givenFertigmeldung)

// Assert assertEquals(true, spyAngebotstrasseMessageService.hasNext()) val actualAngebotstrasse = spyAngebotstrasseMessageService.receive()        assertEquals(false, spyAngebotstrasseMessageService.hasNext()) assertEquals(expectedAngebotstrasse, actualAngebotstrasse)

val actualAllAngebotstrassen = testedAngebotstrassenService.getAllAngebotstrassen() assertEquals(1, actualAllAngebotstrassen.size) } }]]>