Denn in allen unseren Software-Projekten – ob in Kundenprojekten oder in internen Projekten – legen wir großen Wert auf die Software-Qualität. Das umfasst neben der möglichst fehlerfreien – weil mehrfach kontrollierten – Umsetzung auch Eigenschaften wie Erweiterbarkeit, Lesbarkeit und Benutzbarkeit. Hier möchten wir kurz unsere Vorgehensweisen beschreiben.

SOFTWARE-QUALITÄT – WÄHREND DER PLANUNGSPHASE

Als Software-Entwicklung bei DGM gehen wir nach einem agilen Modell vor. Das ist in einem Agenturumfeld gar nicht so einfach und es hat einige Jahre in Anspruch genommen, die Software-Entwicklung in Einklang mit den anderen Bereichen der Agentur zu bringen. (Ein Prozess, den wir übrigens auch bei Kund:innen zwischen IT und Marketing beobachten). Wir haben für unseren Entwicklungsprozess Teile aus Scrum genommen, etwas mit Kanban vermischt und noch einige eigene Ergänzungen gemacht. So setzen wir auf einen iterativen Prozess und die Sprints dauern meist zwei Wochen. Für jeden Sprint gibt es ein entsprechendes Planungsmeeting, in dem Tickets aus dem Backlog – das fortlaufend gepflegt wird – eingeplant und besprochen werden. Durch die regelmäßigen Besprechungen mit allen Beteiligten entsteht ein sehr gutes gemeinsames Verständnis der zu entwickelnden Software. Vorschläge zur Umsetzung von UI-Themen werden diskutiert und die bestmögliche Umsetzungsvariante festgehalten. Die Entwickler:innen schlauen sich dabei gegenseitig auf, welche bereits bestehenden Services für neue Features ggf. wiederverwendet werden können oder was gute Patterns für die konkreten Tickets sein könnten.

Durch dieses gemeinsame Verständnis und die Integration aller Beteiligten in die konkreten Entscheidungen bei der Umsetzung entsteht eine hohe Ticketqualität mit präzisen Anforderungsbeschreibungen, UI-Skizzen und im besten Fall noch Akzeptanzkriterien, welche die  Qualität der Software sicherstellen.

SOFTWARE-QUALITÄT – WÄHREND DER ENTWICKLUNG

Wie viele andere Entwicklerteams setzen wir zur Versionskontrolle git ein. In den Entwicklungsprozess haben wir dabei ein paar „Quality Gates“ integriert, die ein neues Feature oder eine Änderung erfüllen muss, bevor neuer Code in den Hauptbranch übernommen wird.

  1. Für Backend-Code (Java) müssen Unit-Tests oder Integrationstests geschrieben werden, soweit sinnvoll.
  2. Für neue UI-Elemente (Angular) muss ein end2end-Test geschrieben werden. Hier verwenden wir cypress.io.
  3. Bevor ein Pull-Request übernommen wird, muss ein Review durch mindestens einen anderen Entwickler stattfinden.

So vermeiden wir Fehler frühzeitig.
Sobald ein Pull-Request erstellt wird, werden alle bestehenden end2end-Tests mit cypress durchgeführt. Schlägt einer der Tests fehl, so muss nachgebessert werden. Dadurch stellen wir sicher, dass Seiteneffekte, die durch neue Features entstehen können, rechtzeitig entdeckt werden.

Erfolgreich ausgeführter e2e-Test mit cypress.io

Ein cypress-Test sieht im Code beispielsweise so aus. Einfach, aber effektiv:

[...]
it('test banner-edit detect unsupported chars', () => {
    cy.get('[data-cy="temp-text-placeholder"]').eq(0).clear();
    cy.get('[data-cy="temp-text-placeholder"]').eq(0).type('☺');
    cy.get('#enable-campaign-update').click();

    cy.get('.banner-save-button').click();
    assertAllMessageTextsMustContain('Zeichen gefunden', 50000);
});
[...]

Neben diesen Qualitäts-Maßnahmen, die von den Entwickler:innen selbst umgesetzt werden, setzen wir zusätzlich auf statische Code-Analyse zur Auffindung von etwaigen Fehlern. Je nach Setup des Projekts können dazu Tools von Github zum Einsatz kommen oder wir setzen Jenkins mit entsprechenden Plugins ein.

Durch diese Maßnahmen stellen wir sowohl die Code-Qualität als auch die Bedienbarkeit sicher. Aber wie verhält es sich mit der Erweiterbarkeit und Wartbarkeit? Diese erreichen wir durch den Einsatz von zeitgemäßen Frameworks und Architekturen. Für die Backend-Entwicklung setzen wir auf das Springframework, insbesondere Spring Boot. Im Frontend kommt meistens Angular zum Einsatz. Für die möglichst hohe Wiederverwendbarkeit von Code folgen wir dem API-First-Ansatz und strukturieren den Backend-Code gern entsprechend des hexagonalen Architekturansatzes. Wenn wir es für sinnvoll erachten, wird für bestimmte Funktionen oder Services zusätzlich ein eigener Micro-Service extrahiert. Hier wägen wir das jedoch im Einzelfall ab.

FAZIT

Durch unsere Erfahrung von über 10 Jahren in der Software-Entwicklung haben wir bei DGM die Expertise entwickelt, eigene Software mit einem hohen Qualitätsstandard zu schreiben und auch zu betreiben. Was wir entwickeln, entspricht dabei stets dem Stand der Technik und basiert auf sorgfältig ausgewählten Technologien. Ein auf uns zugeschnittener, agiler Prozess sichert die Flexibilität, steigert die Qualität und schafft ein gemeinsames Verständnis für die zu realisierende Software. Und was uns besonders freut: externe IT-Expert:innen bestätigen uns dies immer wieder.