
Am 09. Oktober 2024 wurde im Rahmen einer feierlichen Veranstaltung im Messequartier Dornbirn der KMU-Preis des Landes Vorarlberg 2024 verliehen. FORTIX wurde als Gewinner in der Kategorie Dienstleistung/Tourismus ausgezeichnet!
Eine 7-köpfige Jury hat die Gewinner in den Kategorien Handel, Dienstleistung/Tourismus und Gewerbe/Handwerk ausgewählt. Die Fortix GmbH konnte sich gegen starke Mitbewerber durchsetzen und den begehrten Preis entgegennehmen.

## Ein großes Dankeschön

Wir freuen uns sehr über diese Auszeichnung und bedanken uns bei allen, die uns auf unserem Weg begleitet haben.
Ein besonderer Dank gilt unseren Kunden, die uns ihr Vertrauen schenken und uns immer wieder herausfordern, innovative Lösungen zu entwickeln.

![Alle KMU-Preis 2024 Preisträger](/images/blog/kmu-preis-2024/kmu2024_preistraeger.webp)

### Der KMU-Preis Vorarlberg

Der KMU-Preis Vorarlberg wird jährlich durch eine Initiative der Vorarlberger Nachrichten und der Wirtschaftskammer Vorarlberg verliehen.
Der 16. KMU-Preis wurde in den Kategorien Handel, Dienstleistung/Tourismus und Gewerbe/Handwerk vergeben. Die diesjährigen Partner des KMU-Preises
waren Land Vorarlberg, Hypo Vorarlberg, Vorarlberger Landes-Versicherung und Autohaus Lins.

#### Weitere Links:

- [KMU-Magazin 2024](https://issuu.com/medienhaus.com/docs/kmu2024_journal/16)
- [Video KMU-Preis 2024](https://www.youtube.com/watch?v=GjK8EA-7qlM)

<small>Bilder © Vorarlberger Nachrichten</small>


Sieger KMU-Preis Vorarlberg 2024


In der Welt der Softwareentwicklung wird oft über technische Schulden gesprochen, häufig in einem negativen Kontext. Doch wie bei vielen Dingen im Leben gilt: Technische Schulden sind nicht per se schlecht. Tatsächlich können sie strategisch genutzt werden, um bestimmte Ziele zu erreichen. In diesem Blog möchte ich die Balance zwischen den Vorteilen und den Risiken technischer Schulden beleuchten und zeigen, wie ein bewusster Umgang mit ihnen die Produktentwicklung unterstützen kann.

#### Was sind Technische Schulden?

Der Begriff "Technical Debt" (Technische Schulden) wurde 1992 vom Softwareentwickler Ward Cunningham geprägt. Er verwendete diese Metapher, um zu beschreiben, wie kurzfristige Entscheidungen bei der Softwareentwicklung, die aus Zeitdruck oder Kompromissen resultieren, langfristige Nachbesserungen erforderlich machen können.

Technische Schulden entstehen, wenn bei der Entwicklung von Software bewusste Kompromisse eingegangen werden, um kurzfristig bestimmte Ziele zu erreichen. Diese Entscheidungen führen oft zu **zusätzlichen Nachbesserungen**, die nötig sind, weil die Entwicklung entweder schneller oder nachlässiger durchgeführt wurde. Dabei kann es sich um suboptimale Lösungen handeln, die es ermöglichen, eine Deadline zu erreichen oder eine schnelle Markteinführung zu realisieren.

#### Die Unterscheidung von Technischer Schuld nach Martin Fowler

Der bekannte Softwarearchitekt **Martin Fowler** hat das Konzept der technischen Schulden weiter differenziert, indem er sie in vier Kategorien unterteilt: **leichtsinnig** und **umsichtig** sowie **absichtlich** und **versehentlich**. Diese Unterscheidung hilft dabei, besser zu verstehen, wie technische Schulden entstehen und welche Herangehensweise dahinter steckt. Fowler teilt die technische Schuld in vier Quadranten auf, die je nach Bewusstsein und Absicht variieren.

**1. Leichtsinnig und versehentlich**

Diese Art von technischer Schuld entsteht, wenn Entscheidungen getroffen werden, ohne das notwendige Wissen oder Verständnis zu haben. Ein Beispiel hierfür wäre: "Was ist Layering?" – ein Zeichen dafür, dass die Entwickler grundlegende Prinzipien oder Best Practices nicht kennen. Hier resultieren die Schulden aus Unwissenheit und unüberlegtem Handeln.

**2. Leichtsinnig und absichtlich**

In diesem Fall weiß das Team, dass es eine schlechte Entscheidung trifft, wählt diesen Weg aber bewusst aus, oft aufgrund von Zeitdruck oder mangelnden Ressourcen. Ein klassisches Beispiel ist: "Wir haben keine Zeit für Design." Hier wird absichtlich auf Qualitätsstandards verzichtet, um schnell zu liefern, obwohl den Entwicklern die Konsequenzen klar sind.

**3. Umsichtig und absichtlich**

Diese Form der technischen Schuld entsteht, wenn man sich der Risiken und Konsequenzen bewusst ist, aber trotzdem eine informierte Entscheidung trifft, weil es unter den gegebenen Umständen notwendig ist. Ein typisches Szenario wäre: "Wir müssen jetzt das Produkt liefern und müssen mit den Problemen fürs Erste leben." Hier wird eine bewusste Risikoabwägung vorgenommen, um ein vorrangiges Ziel, wie eine rechtzeitige Markteinführung, zu erreichen.

**4. Umsichtig und versehentlich**

In dieser Kategorie entstehen technische Schulden aus Fehlern, die erst im Nachhinein als solche erkannt werden. Das Team hatte ursprünglich die besten Absichten und glaubte, eine gute Entscheidung getroffen zu haben, stellt aber später fest, dass es besser hätte gehen können. Ein Beispiel hierfür wäre: "Jetzt wissen wir, wie wir es hätten machen sollen." In diesem Fall wird aus den Fehlern gelernt, und künftige Projekte können davon profitieren.

![](/images/blog/technical-debt/technical-debt-dra-of-martin-fowler.png 'Darstellung der technischen Schulden nach Martin Fowler')

Diese Unterscheidung von Martin Fowler zeigt, dass nicht alle technischen Schulden gleich sind. Der Kontext und die Intention hinter den Entscheidungen spielen eine große Rolle, wenn es darum geht, wie kritisch diese Schulden bewertet werden sollten und wie man sie zukünftig vermeiden kann.

#### Technische Schulden sind nützlich, wenn...

- **Wichtige Deadlines erreicht werden müssen:** Es kann sinnvoll sein, bestimmte Qualitätsstandards zu senken, um ein Projekt termingerecht abzuschließen.

- **Die schnelle Markteinführung entscheidend ist:** In stark umkämpften Märkten zählt oft die Zeit. Ein Produkt kann schneller auf den Markt gebracht werden, auch wenn der Code nicht perfekt ist.

- **Ein MVP (Minimum Viable Product) gebaut wird:** Beim Start eines neuen Projekts ist es oft wichtiger, schnell Feedback vom Markt zu erhalten, als perfekten Code zu schreiben.

Doch auch wenn technische Schulden in diesen Fällen nützlich sein können, sollten sie so schnell wie möglich wieder abgebaut werden. Das bedeutet, dass nach der Erreichung kurzfristiger Ziele Zeit für Refactoring eingeplant werden sollte, um die entstandenen Schulden zu beseitigen.

#### Warum Technische Schulden nicht ignoriert werden sollten

Technische Schulden werden häufig als Synonym für schlechten Code verwendet. Es gibt jedoch einen wesentlichen Unterschied: Technische Schulden sind das bewusste Akzeptieren von Kompromissen in der Qualität zugunsten von kurzfristigen Zielen, während schlechter Code oft aus Nachlässigkeit oder fehlendem Know-how entsteht.

Technische Schulden können auf unterschiedliche Weise entstehen. Es ist wichtig, nicht nur die unmittelbaren Ursachen während der Entwicklungsphase zu betrachten, sondern auch die langfristigen Effekte, die durch das Nicht-Weiterentwickeln der Software auftreten können.

#### Technische Schulden während der Entwicklung

Technische Schulden entstehen oft direkt im Entwicklungsprozess, insbesondere wenn Teams unter starkem Zeitdruck stehen oder Anforderungen unklar formuliert sind. In solchen Situationen werden häufig Kompromisse bei der Codequalität eingegangen. Einige der häufigsten Ursachen sind:

- **Zeitdruck:** Wenn ein Projekt schnell fertiggestellt werden muss, wird häufig der saubere, durchdachte Code zugunsten von schneller umsetzbaren, aber weniger wartungsfreundlichen Lösungen vernachlässigt. Dies kann kurzfristig zu einem fertigen Produkt führen, erfordert aber in der Zukunft aufwendige Nachbesserungen.

- **Unklare Anforderungen:** Wenn die Anforderungen an ein Softwareprojekt nicht präzise definiert sind, besteht die Gefahr, dass Entwickler Lösungen umsetzen, die später überarbeitet werden müssen. Änderungen in den Anforderungen führen oft zu schnellen Anpassungen, die nicht optimal integriert sind und somit technische Schulden erzeugen.

- **Unzureichende Tests:** Wenn Tests nicht ausreichend oder gar nicht durchgeführt werden, steigt das Risiko von Bugs und Fehlfunktionen, die später behoben werden müssen. Dieser Mangel an Qualitätssicherung führt zu einem langfristigen Wartungsaufwand.

- **Schlechte Dokumentation:** Eine unvollständige oder unklare Dokumentation erschwert es den Entwicklern, den Code zu verstehen und zu pflegen. Dies führt zu Mehraufwand, wenn der Code später angepasst oder erweitert werden soll.

- **Unsauberer Code:** Suboptimale Code-Strukturen oder übermäßig komplexer Code, der schlecht lesbar oder wartbar ist, sind ein weiteres klassisches Beispiel für technische Schulden. Solche Codefragmente müssen in der Regel bei späteren Updates refactort oder gar neu geschrieben werden, um die Wartbarkeit und Erweiterbarkeit der Software zu gewährleisten.

#### Technische Schulden durch Nicht-Entwicklung

Technische Schulden entstehen nicht nur aktiv während der Entwicklung, sondern können sich auch durch das **Nicht-Weiterentwickeln** der Software anhäufen. Software, die nicht regelmäßig gepflegt wird, gerät oft technisch ins Hintertreffen. Diese „unsichtbaren“ technischen Schulden können genauso schwerwiegende Auswirkungen haben wie die Schulden, die durch aktive Entwicklung entstehen:

- **Technologischer Wandel:** Technologien und Best Practices in der Softwareentwicklung ändern sich stetig. Neue Programmiersprachen, Tools oder Frameworks bieten oft effizientere oder sicherere Möglichkeiten, Software zu entwickeln. Wird eine bestehende Software nicht regelmäßig modernisiert oder angepasst, entsteht eine Diskrepanz zwischen dem aktuellen Stand der Technik und der eingesetzten Technologie, was die zukünftige Wartung und Erweiterung erheblich erschweren kann.

- **Veraltete Bibliotheken und Frameworks:** Bibliotheken und Frameworks werden regelmäßig aktualisiert, um neue Funktionen zu integrieren, Sicherheitslücken zu schließen oder die Performance zu verbessern. Wenn eine Software auf veralteten Abhängigkeiten aufbaut und diese nicht regelmäßig aktualisiert werden, kann das zu Inkompatibilitäten, Sicherheitsrisiken oder eingeschränkter Funktionalität führen. Das Nachziehen dieser Updates kann dann aufwendiger und risikoreicher werden, je länger es hinausgezögert wird.

- **Neue Architekturkonzepte:** In der Softwarearchitektur entstehen immer wieder neue Paradigmen und Designmuster, die es erlauben, Systeme skalierbarer, robuster oder leichter wartbar zu gestalten. Unternehmen, die ihre Architektur nicht an diese neuen Konzepte anpassen, könnten langfristig darunter leiden, dass ihre Software schwerer erweiterbar oder weniger effizient ist. Auch das Ignorieren dieser Fortschritte kann technische Schulden akkumulieren, die später aufwändig beseitigt werden müssen.

Diese Art von technischen Schulden, die sich durch Nicht-Weiterentwicklung ansammeln, sind oft schwer zu erkennen, da sie nicht sofort sichtbar sind. Dennoch sind sie genauso kritisch, da sie die Flexibilität und Zukunftsfähigkeit der Software beeinträchtigen.

#### Wie technische Schulden abgebaut werden können

Technische Schulden müssen ernst genommen und strategisch angegangen werden, um langfristig eine stabile Codebasis zu gewährleisten. Hier sind einige Wege, um technische Schulden zu verringern:

- **Bewusster Umgang mit technischen Schulden** Technische Schulden sollten dokumentiert und überwacht werden. Es ist wichtig, stets im Auge zu behalten, wo und warum sie entstehen.

- **Feedback von Entwicklern einholen** Die Entwickler wissen am besten, wo sich technische Schulden verbergen. Regelmäßige Team-Meetings können helfen, diese Schulden zu identifizieren.

- **Automatisierte Tests und Tools verwenden** Tools wie [SonarQube](https://www.sonarsource.com/products/sonarqube/) können dabei helfen, technische Schulden zu visualisieren und die Codequalität zu verbessern.

- **Refactoring-Zeit einplanen** Es sollte in jedem Sprint Zeit für Aufräumarbeiten (Refactoring) eingeplant werden, um technische Schulden kontinuierlich abzubauen.

#### Das Projektmanagement von der Wichtigkeit überzeugen

Eine der größten Herausforderungen beim Umgang mit technischen Schulden ist, das Projektmanagement davon zu überzeugen, dass ihre Beseitigung wichtig ist. Hier ist es entscheidend, die **Ziele des Unternehmens** mit der Notwendigkeit des Abbaus technischer Schulden in Einklang zu bringen.

Drei Argumente können helfen, das Projektmanagement zu überzeugen:

- **Zahlen sprechen lassen:** Konkrete Metriken, die die negativen Auswirkungen technischer Schulden auf die Produktivität zeigen, sind oft das beste Argument.

- **Langfristige Probleme aufzeigen:** Technische Schulden, die nicht behoben werden, verschlimmern sich über die Zeit und können zukünftige Projekte erheblich verlangsamen.

- **Risikomanagement:** Der Aufbau technischer Schulden ist vergleichbar mit einem wachsenden Risiko. Je länger sie ignoriert werden, desto schwieriger und teurer wird ihre Beseitigung.

#### Fazit

Technische Schulden sind ein unvermeidlicher Teil der Softwareentwicklung. Sie können, wenn sie bewusst eingesetzt werden, sogar ein wertvolles Werkzeug sein, um schnelle Ergebnisse zu erzielen. Wichtig ist jedoch, dass sie stets im Auge behalten und so schnell wie möglich abgebaut werden, um langfristige Stabilität zu gewährleisten. Ein transparenter und geplanter Umgang mit technischen Schulden hilft dabei, die Balance zwischen Entwicklungsgeschwindigkeit und Codequalität zu wahren.

#### Links

- [Martin Fowler Technical Debt](https://martinfowler.com/bliki/TechnicalDebt.html)
- [Martin Fowler Technical Debt Quadrant](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)
- [LeadDev Technical Debt](https://leaddev.com/tech/tech-debt-engineering-leaders-how-shortcut-today-impacts-tomorrow?utm_source=tldrwebdev)
- [Engineering Leadership Technical Debt](https://newsletter.eng-leadership.com/p/engineers-guide-to-convincing-your?utm_source=tldrwebdev)
- [DevBoost Der richtige Umgang mit technischen Schulden](https://devboost.com/blog/tipps-fuer-den-richtigen-umgang-mit-technischen-schulden?utm_source=9-3)


Technische Schulden: Fluch oder Segen für die Softwareentwicklung?


In der digitalen Produktentwicklung ist ein gut strukturierter Design- und Entwicklungsprozess entscheidend für den Erfolg eines Projekts. Doch oft scheitern Teams an Herausforderungen wie mangelnder Kommunikation, unklaren Vorgaben und fehlender Abstimmung zwischen Designern und Entwicklern. Diese Schwachstellen führen nicht nur zu Missverständnissen und Verzögerungen, sondern auch zu inkonsistenten Ergebnissen, die die Qualität des Endprodukts beeinträchtigen können.

In diesem Blogpost werfen wir einen Blick auf die häufigsten Probleme in traditionellen Design- und Entwicklungsprozessen und stellen im Anschluss einen modernen Ansatz vor, der durch den Einsatz von Tools wie Figma und Storybook nicht nur die Zusammenarbeit verbessert, sondern auch eine konsistente und effiziente Umsetzung garantiert.

#### Der veraltete Design- & Entwicklungsprozess ❌

Der Design- und Entwicklungsprozess ist oft von Herausforderungen geprägt, die sich aus unklarer Kommunikation, unzureichenden Designvorlagen und mangelnder Abstimmung zwischen den Teams ergeben. Angefangen bei der Ideensammlung bis hin zur Entwicklung ohne klare Richtlinien können diese Probleme zu Missverständnissen, unrealistischen Erwartungen und ineffizientem Arbeiten führen.

**1. Brainstorming und Ideensammlung**

Der Prozess beginnt oft mit einer Idee vom Kunden, die dann an eine Designagentur ausgelagert wird. Hier liegt oft das erste Problem: Die Kommunikation zwischen Kunde und Agentur kann unklar sein, was zu Missverständnissen und unrealistischen Erwartungen führt.

**2. Erstellung von Wireframes**

Die Agentur erstellt Wireframes, oft noch in Form von statischen PDFs oder pixelbasierten Entwürfen zum Beispiel für Desktop. Diese können jedoch die dynamischen Aspekte einer Website oder App nicht angemessen erfassen und lassen oft wichtige Details unberücksichtigt und Entscheidungen und Feedback für den Start der Entwicklung fehlen.

**3. Entwicklung ohne klare Richtlinien**

Die Entwicklung beginnt auf Basis der Wireframes und eines möglichen Styleguides. Hier entstehen jedoch oft Probleme:

- **Unvollständige Informationen:** Der Styleguide ist oft unvollständig und lässt Fragen offen, wie die richtige und konsistente Verwendung von Farben und Schriften, optimierte Layouts für unterschiedliche Bildschirmgrößen oder die Darstellung unterschiedlicher Zustände und Interaktionen.
- **Mangelnde Konsistenz:** Da Designentscheidungen durch statische PDFs nicht eindeutig festgelegt sind, treffen Entwickler oft individuelle Entscheidungen. So kann es gut sein, dass ein Entwickler den Abstand zwischen Text und Button etwas größer interpretiert und umsetzt als sein Team-Mitglied. Dies führt zu inkonsistenten Ergebnissen und erhöhtem Zeitaufwand.
- **Fehlende Abstimmung:** Die fehlende Koordination zwischen Design und Entwicklung führt zu ineffizientem Arbeiten und kann zu unerwarteten Problemen im späteren Projektverlauf führen. Der Kunde hat die statischen Mockups in PDF-Form gesehen, hatte jedoch andere Erwartungen an die Interaktion des fertig entwickelten Produkt oder für spezifische Fälle, welche nicht abgebildet werden konnten.

![](/images/blog/optimierter-design-entwicklungsprozess/design-system-processes.png 'Vergleich Prozesse')

#### Ein moderner Prozess ✅

In einem modernen Design- und Entwicklungsprozess bildet ein **Design System** die Basis für effizientes Arbeiten und eine konsistente Umsetzung. Der Prozess wird durch den Einsatz von Tools wie [Figma](https://www.figma.com/de-de/design/) zum Erstellen von interaktiven Klick-Prototypen oder [Storybook](https://storybook.js.org/) zur Erstellung einer Komponenten-Bibliothek unterstützt.

**1. Erfassen der Anforderungen und Wireframing**

Die Anforderungen werden erfasst und erste Entwürfe/Wireframes werden erstellt. Dabei findet eine kontinuierliche Rücksprache mit dem Kunden statt, um Basiskonzepte und Grundlagen des Design-Systems wie Farben, Schriften, Layouts und Interaktionen zu definieren. In diesem Prozess ist es wichtig, auch die Abläufe und Funktionen aus Kunden- und Anwendersicht zu verstehen.

![© Figma](/images/blog/optimierter-design-entwicklungsprozess/figma-design-system.png 'Design System')

**2. Design System als Diskussionsplattform**

Basierend auf den umfangreich erfassten Anforderungen und Konzepten wird von der Agentur das Designsystem und die Applikation in einem modernen Tool wie Figma in mehreren Sprints umgesetzt und anhand von Klickprototypen interaktiv gemacht. Das Design System dient als zentrale Plattform für Diskussionen und liefert viele Informationen sowie Antworten auf Design- und Entwicklungsfragen. Durch den Einsatz interaktiver Prototypen in Figma können UX-Fragen frühzeitig geklärt und Feedback eingeholt werden.

- **Interaktive Prototypen:** Durch interaktive Prototypen werden Designentscheidungen besser verstanden und können erlebt werden. Der Kunde kann die Basis-Interaktionen schon vor der Entwicklung sehen und präzises Feedback geben.
- **Figma als Tool mit DEV Mode:** Entwickler erhalten frühzeitig relevante Informationen auch aus technischer Sicht und können spezifische Fragen stellen und ihre Erfahrung einbringen, was den Entwicklungsprozess optimiert.
- **Konsistenz und Effizienz:** Alle Entwickler arbeiten auf der gleichen, vollständigen Grundlage, was zu einer konsistenten und effizienten Umsetzung führt.

![© Figma](/images/blog/optimierter-design-entwicklungsprozess/dev-mode-copyright-figma.png 'DEV Mode ©Figma')

<Card className="p-4 sm:p-4 md:p-6 my-8">
**Figma Dev Mode**

Figma bietet mit seinem [Dev Mode](https://www.figma.com/de-de/blog/introducing-dev-mode/) einen Playground für Entwickler, der den gesamten Prozess der Entwicklung unterstützt.

<ul>
  <li>**Inspizieren von Komponenten:** Entwickler können Komponenten im Detail untersuchen, einschließlich Zuständen und Interaktionen.</li>
  <li>
    **Output für Entwickler:** Figma generiert automatisch CSS-Stile, Rem-Größen und verwendet Tokens, was Entwicklern die Entscheidungsfindung
    erleichtert.
  </li>
  <li>
    **Markieren von Komponenten/Screens als "Bereit für die Entwicklung":** Diese Funktion ermöglicht eine klare Kommunikation zwischen Design und
    Entwicklung. Durch direkte Notizen für Entwickler und die Einsicht in Änderungen am Design seit der Freigabe werden Produktbesitzer und Entwickler
    dabei unterstützt, nachträgliche Änderungen besser zu verstehen und zu verwalten. Diese Funktionen tragen dazu bei, die Zusammenarbeit zwischen
    Design und Entwicklung zu verbessern und die Effizienz des gesamten Prozesses zu steigern.
  </li>
</ul>

  </Card>

**3. Entwicklung von Komponenten**

Basierend auf dem grafischen und interaktiven Komponentenkatalog in Figma kann mit der Entwicklung gestartet werden. Oft wird hier bereits mit der Implementierung von Basis-Komponenten gestartet. Diese werden unabhängig von der Applikationslogik (Backend, Authentifizierung, ...) implementiert und können somit ohne Abhängigkeiten entwickelt und getestet werden. Die isoliert entwickelten Komponenten, wie beispielsweise Buttons, Popups oder die Toolbar, können dadurch auch in anderen Projekten des Unternehmens eingesetzt werden.

- **Eigene Style- und Component-Library:** Isolierte Frontend-Komponenten können in einer eigenen Component-Library entwickelt werden, die in verschiedenen Projekten wiederverwendet werden kann.
- **Unabhängige Konzeption und Implementierung:** Durch die Entwicklung und automatisierten Tests der isolierten Komponenten, ohne Abhängigkeiten zu spezifischen Applikationen, ist eine schnelle und unabhängige Entwicklung möglich.
- **Storybook als Tool:** Mit Tools wie zum Beispiel Storybook kann eine Art [Katalog für alle implementierten Basis-Komponenten](https://react.ui.audi/?path=/story/components-accordion--properties) erstellt werden. Dies ermöglicht es allen Teilnehmern die generische Komponenten-Bibliothek anzusehen, auszuprobieren und für weitere Projekte einzusetzen.

Durch diesen modernen Prozess wird eine effiziente und konsistente Umsetzung von Design und Entwicklung gewährleistet, was zu qualitativ hochwertigen Produkten führt.

![© Storybook](/images/blog/optimierter-design-entwicklungsprozess/storybook-example.png 'Storybook Example ©Storybook')

![© Atlassian](/images/blog/optimierter-design-entwicklungsprozess/style-library-copyright-atlassian.png 'Library / Tokens ©Atlassian')

#### Fazit

Ein moderner Design- und Entwicklungsprozess zeichnet sich im besten Fall durch die Nutzung eines Design Systems aus, das als Grundlage für alle Arbeitsschritte dient. Durch die klare Definition anhand des Design Systems wird eine konsistente Umsetzung gewährleistet.

Die verschiedenen Bereiche wie Design und Entwicklung rücken näher zusammen, da jeder Bereich nur seine spezifischen Fähigkeiten einbringt. Entwickler müssen keine Designentscheidungen treffen, sondern können sich auf ihre Expertise konzentrieren. Gleichzeitig ermöglicht dies eine bessere Verknüpfung von Know-how und Inputs aus verschiedenen Bereichen. Entwickler und Produktbesitzer können frühzeitig ihr Wissen und ihre Erfahrungen in den Designprozess einbringen und so wertvolles Feedback liefern.

Durch dieses nahtlose Zusammenarbeit wird eine effiziente und konsistente Umsetzung von Projekten erreicht. Die klare Kommunikation und das gemeinsame Verständnis für die Anforderungen führen zu qualitativ hochwertigen Endprodukten, die den Bedürfnissen der Nutzer gerecht werden.

![](/images/blog/optimierter-design-entwicklungsprozess/design-system-processes.png 'Vergleich Prozesse')

#### Links

- [Figma für Design Systeme](https://www.figma.com/de-de/design-systems/)
- [Figma Dev Mode](https://www.figma.com/de-de/blog/introducing-dev-mode/)
- [Figma Introduction to design systems ](https://help.figma.com/hc/en-us/articles/14552901442839-Overview-Introduction-to-design-systems)
- [Design Tokens](https://atlassian.design/tokens/design-tokens)
- [Storybook](https://storybook.js.org/)
- [Storybook Figma integration](https://storybook.js.org/docs/sharing/design-integrations)


Konsistenz und Effizienz: So verbesserst du den Design- und Entwicklungsprozess


Spätestens seit dem Release von Version 17 ist klar, dass das Angular Team eine neue Richtung einschlagen will. Im Mittelpunkt davon: Angular Signals. Diese sollen den Einstieg in die Angular Welt erleichtern, die Change Detection optimieren und das kontroverse RxJS zu einem optionalen, allerdings immer noch mächtigen, Werkzeug anstatt integralen Bestandteil des Frameworks machen.

Das NgRx Team hat zeitgleich mit dem Angular 17 Release die erste Version der @ngrx/signals Library veröffentlich und bietet damit direkt eine flexible und einfache Möglichkeit zum signal-based State Management an. Der darin enthaltene lightweight Signal State und etwas umfangreichere Signal Store sind dabei komplett abgekapselt zum bereits etablierten RxJS-based NgRx Store und Component Store zu betrachten.

Doch inwieweit unterscheidet sich der Signal Store von bisherigen State Management Lösungen, welche Features kommen out-of-the-box mit und ist eine zusätzliche externe Library überhaupt notwendig für das State Management von Signals? Wir haben den NgRx Signal Store bereits seit einem halben Jahr im Einsatz und ziehen Fazit.

#### Signal State

Wie bereits erwähnt gibt es zwei verschiedene Ausprägungen der NgRx Signals Library. Der Signal State ist eine lightweight und minimalistische Utility zum Verwalten von signal-based State. Dieser eignet sich beispielsweise besonders gut für abgekapselte States auf Komponenten Ebene. Dazu wird einfach die signalState Funktion aus dem Package eingebunden und mit dem initialen State initialisiert.

```jsx
import { signalState } from '@ngrx/signals';

const userState =
  signalState <
  UserState >
  {
    firstName: 'John',
    lastName: 'Doe',
    address: {
      street: 'Street 1',
      zip: 1234,
    },
  };
```

Sieht auf den ersten Blick nicht viel anders aus als ein gewöhnliches Angular Signal, unterscheidet sich aber folgendermaßen:

- **Deep Signal:** Der Signal State erzeugt im Hintergrund nicht nur für das userState Objekt ein readonly Signal, sondern zusätzlich auch für jedes verschachtelte Property. Somit kann beispielsweise die address Property mit userState().address und userState.address() ausgelesen werden und erlaubt für “fine-grained reactivity”. Konsumenten des Signals können den State also auf Property Ebene auslesen und werden bei anderen Änderungen des States nicht benachrichtigt und unnötige Change Detection Cycles bleiben erspart.
- **Immutable State Updates:** Um unerwartete Side Effects zu verhindern, bietet die patchState Funktion die Möglichkeit an den State auf eine kontrollierte Art und Weise zu aktualisieren.

```jsx
import { patchState } from '@ngrx/signals';

patchState(userState, { firstName: 'Jane' });
patchState(userState, (state) => ({ address: { ...state.address, zip: 5678 } }));
```

Zusätzlich dazu können auch wiederverwendbare State Updaters erstellt werden.

```jsx
import { PartialStateUpdater } from '@ngrx/signals';

function setZip(zip: number): PartialStateUpdater<{ address: Address }> {
  return (state) => ({ address: { ...state.address, zip } });
}

patchState(userState, setZip(5678));
```

Dieser funktionelle Ansatz zum State Management ermöglicht hohe Flexibilität und deckt wahrscheinlich die Anforderungen der meisten Use Cases ab.

#### Signal Store

Mit dem Signal Store hat NgRx die Basis Funktionalität des Signal States um einige Features erweitert und ist in der Lage komplexeren Anforderungen gerecht zu werden. Der Store wird mit der signalStore Funktion erstellt und liefert ein Injectable Service zurück. Der generierte Service kann entweder in root provided werden und als Singleton einen applikationsweiten State verwalten oder direkt in Komponenten provided werden und als Component Store eingesetzt werden. Der Signal Store umfasst folgende Konzepte:

- `withState`: Analog zum signalState kann mit der withState Funktion der initiale State des Stores gesetzt werden.
- `withComputed`: Basierend auf den initial erstellten Signals können direkt im Store berechnete Werte (Computed Values) definiert werden. Damit kann featurespezifische Logik von der Komponente in den Store ausgelagert werden und hilft dabei die Komponenten schlank zu halten.
- `withMethods`: Um zu vermeiden, dass der State von überall in der Applikation aktualisiert werden kann, werden mit der withMethods Funktion die State Update Logik bereit gestellt und führt mögliche asynchrone Side Effects entweder mit Promises aus oder wie bisher mit RxJS mithilfe der rxMethod Funktion.
- `rxMethod`: Wer nicht komplett auf die Stärken der RxJS Operators verzichten will, kann ganz einfach mit rxMethod Funktionalität ausgehend von einem Observable Stream ausführen. Entweder durch manuelle Trigger oder als Reaktion auf einen Signal Change emitted das Source Observable einen neuen Wert und macht es so möglich komplexere Side Effects zu handhaben.
- Lifecycle Hooks: Die mitgelieferten onInit und onDestroy Hooks machen den Store noch unabhängiger und in sich konsistent. Man sieht beispielsweise auf einen Blick, wie sich der initiale State zusammensetzt, ohne die gesamte Applikation für Methodenaufrufe durchsuchen zu müssen.
- Custom Features: Das auf den ersten Blick vielleicht unscheinbarste Feature ist womöglich das Mächtigste. Der Signal Store ermöglicht es wiederkehrende State Logik in eigene Features zu kapseln, die je nach Bedarf in den Store eingebunden werden. So kann man beispielsweise eine Loading/Error State Logik (inklusive State Properties, Computed Properties, Methods, etc.) auslagern und jeder Store der dieses Features aktiviert kann mit nur einer Code Zeile auf diese Logik aufbauen. Die perfekte Ausgangssituation für eine flexible Softwarearchitektur.

Ein Beispiel für einen simplen Signal Store könnte folgendermaßen aussehen.

```jsx
import { patchState, signalStore, withComputed, withMethods, withState} from '@ngrx/signals';
import { rxMethod } from '@ngrx/signals/rxjs-interop';
import { withLoadingState } from '../loading-state-feature';
[...]

const initialState: UsersState = {
  users: [],
  filter: ''
};

@Injectable({ providedIn: 'root' })
export class UserStore extends signalStore(
  withState(initialState),
  withLoadingState(), // <- Activate Custom Feature to access isLoading property
  withComputed(({ users, filter }) => ({
    usersCount: computed(() => users().length),
  })),
  withMethods((store, usersService = inject(UsersService)) => ({
    updateFilter(filter: string): void {
      patchState(store, { filter });
    },
    connectFilter: rxMethod<string>(
      pipe(
        debounceTime(300),
        distinctUntilChanged(),
        tap(() => patchState(store, { isLoading: true })),
        switchMap((query) => {
          return usersService.getByFilter(filter).pipe(
            tapResponse({
              next: (users) => patchState(store, { users }),
              finalize: () => patchState(store, { isLoading: false }),
            })
          );
        })
      )
    ),
  })),
  withHooks({
    onInit(store) {
      store.connectFilter(store.filter);
    },
  })
);
```

#### Fazit

Durch den funktionellen Ansatz und der flexiblen Anwendung bringt der Einsatz der Library viele Vorteile und wenige bis keine Nachteile mit. Das State Management verleiht der Applikation ausreichend Struktur und eine einheitliche Architektur bei geringem Overhead und gleichzeitig minimaler Vergrößerung der Bundle Size.

Unsere wichtigsten Erkenntnisse:

- **Flexibilität:** Je nach Feature oder Komponente kann der Store als Component Store oder globaler App Store eingesetzt werden. Sollte unklar sein, an welcher Stelle der App Struktur der Store erstellt und eingebunden wird, gilt als Faustregel den Store so spezifisch wie möglich zu integrieren. Sollte es notwendig sein, den Store globaler zu machen, ist das mit wenig Aufwand möglich. Somit können unnötige Abhängigkeiten einfach vermieden werden.
- **Schlanke Komponenten:** Mit der withComputed Methode lässt sich Komponentenlogik einfach und an einer Stelle im Store definieren und sorgt dafür, dass die Komponenten möglichst klein und wartbar bleiben. Der Einsatz von Computed State Properties versichert stabile und berechenbare Change Detection Cycles.
- **Custom Features:** Generische und wiederkehrende Logik lässt sich unkompliziert in eigene Files auslagern und fördert eine flexible Architektur.

Gerade in Projekten mit begrenztem vorhandenen RxJS Know How erleichtert der Signal Store die initiale Implementierung des State Managements und das Onboarding neuer Entwickler. Die Architektur des klassischen NgRx State Management mit strikter Trennung von Actions, Effects, Reducers und Selectors hat natürlich Vorteile in größeren Projekten, ist die etabliertere Lösung und ist von vielen Teams möglicherweise noch die präferierte Option. Dennoch sehe ich die den Signal State/Store als die flexiblere und einfachere State Management Lösung an, vor allem aufgrund des Shifts in Richtung Signals im Angular Framework.


Sieger KMU-Preis Vorarlberg 2024

Technische Schulden: Fluch oder Segen für die Softwareentwicklung?

Konsistenz und Effizienz: So verbesserst du den Design- und Entwicklungsprozess

NgRx Signal Store – worth the hype?