
Nx ist für mich zum Grundstein jeder neuen Angular Anwendung geworden. Wir bei FORTIX haben schon viele Projekte mit Nx umgesetzt und
sind immer wieder begeistert, wie einfach es ist, Angular Apps in Monorepos zu entwickeln.
Sogar für einzelne Anwendungen, die nicht in einem Monorepo liegen, lohnt es sich, Nx zu verwenden.

## Was ist Nx?

Nx ist ein Open-Source Toolkit, das von [Nrwl](https://nx.app/company) entwickelt wurde. Es erweitert die Angular CLI um viele nützliche Features.
Es stellt Tools und Bibliotheken bereit, die uns Entwickler dabei unterstützen, effizienter zu arbeiten. Diese sind
besonders hilfreich für Projekte mit mehreren Anwendungen, Bibliotheken und geteiltem Code. Nx verbessert die Developer
Experience durch fortschrittliche Funktionen wie Codegenerierung, Dependency Graphs und konsistente Projektstrukturen.
Nx ist nicht nur für Angular Projekte geeignet, sondern auch für React, Node.js und viele weitere Technologien.

## Vorteile von Nx

- **Wiederverwendbarkeit von Code**: Mit Nx können wir Bibliotheken erstellen, die in mehreren Apps wiederverwendet
  werden können.
- **Effizenter Entwicklungsprozess**: Nx optimiert die Build- und Testprozesse und ermöglicht es uns, nur die geänderten
  Teile unserer Anwendung zu kompilieren und zu testen.
- **Dependency Graphs**: Nx erstellt einen Dependency Graphen, der uns hilft, die Abhängigkeiten zwischen unseren Projekten und
  Bibliotheken zu visualisieren.
- **Konsistente Projektstruktur**: Nx definiert eine konsistente Projektstruktur, die uns hilft, unsere Anwendungen und
  Bibliotheken besser zu organisieren. Dies erleichtert die Wartung und Weiterentwicklung unserer Anwendungen.
- **Moderne Tools**: Nx bietet moderne Tools wie [Cypress](https://www.cypress.io/), [Jest](https://jestjs.io/),
  [ESLint](https://eslint.org/), [Prettier](https://prettier.io/) und [Storybook](https://storybook.js.org/), die uns helfen,
  unsere Anwendungen zu entwickeln, testen und dokumentieren.

Wo Licht ist, ist auch Schatten. Nx ist nicht perfekt und hat auch einige Nachteile.

## Nachteile von Nx

- **Lernkurve**: Nx hat eine steile Lernkurve und es kann dauern bis alle Entwickler:innen sich mit den Konzepten und Tools
  vertraut gemacht haben.
- **Komplexität**: Ein Monorepo kann schnell sehr groß und komplex werden. Es ist wichtig, die Struktur und Organisation
  des Monorepos sorgfältig zu planen und zu pflegen.
- **Merge Konflikte**: In einem Monorepo kann es häufiger zu Merge Konflikten kommen, da mehrere Entwickler an verschiedenen
  Teilen des Codes arbeiten.
- **Zugriffskontrolle**: In einem Monorepo hat jeder Entwickler Zugang zum gesamten Code des Projekts. Es gibt keine einfache
  Möglichkeit Teile des Codes zu von unabsichtlichen Änderungen zu schützen. Deshalb sind Reviews und Tests umso wichtiger.

Nichtsdestotrotz überwiegen für mich die Vorteile von Nx und ich kann es nur empfehlen, es in jedem Angular Projekt zu verwenden.

## Nx in der Praxis

Ich möchte euch noch ein kleines Beispiel zeigen, wie wir bei FORTIX Nx in der Praxis verwenden.
Für unseren Kunden [Bundesverband Photovoltaic Austria](https://pvaustria.at/) durften wir schon 3 verschiedene Angular Projekte umsetzen.
Um dies möglichst effizient und somit auch kostengünstig zu gestalten, haben wir uns für die Verwendung von Nx entschieden. Dadurch konnten wir viele Vorteile
von Nx nutzen und die Projekte schneller und effizienter umsetzen.

Bei den Projekten handelt es sich um nützliche [Online PV-Tools](https://pvaustria.at/pv-tools/) für die Planung einer PV-Anlage.
Die Tools sind auf der Website des Bundesverband Photovoltaic Austria verfügbar:

- [SonnenKlar PV-Rechner](https://pvaustria.at/pv-rechner/)
- [SonnenKlar Föderkompass](https://pvaustria.at/foerderungen/)
- [PV-Profi-Suche](https://pvaustria.at/pv-profi/)

Alle Projekte leben in einem gemeinsamen Nx Monorepo. Mit dem Dependency Graph von Nx können wir die Abhängigkeiten zwischen
den Projekten und Bibliotheken visualisieren und so einen besseren Überblick über die Struktur des Monorepos erhalten.

```bash[class="line-numbers"]
nx graph
```

![](/images/blog/nx-monorepo-pva/pva-graph.png 'Nx Dependency Graph des PVA Monorepos')

Alle 3 Anwendungen sind im Corporate Design von PV Austria umgesetzt. Darum wurde eine UI-Bibliothek erstellt, die alle UI-Komponenten für die
verschiedenen Anwendungen enthält. Da es meistens ähnliche Komponenten in den verschiedenen Apps gibt,
konnten wir viel Code wiederverwenden und die Entwicklung beschleunigen.

Diese Anwendungen haben sonst keine weitere geteilte Businesslogik, deshalb haben wir keine weiteren Bibliotheken erstellt. In komplexeren
Anwendungen ist es aber möglich, mehrere Bibliotheken zu erstellen um so viel Code wie möglich wiederzuverwenden.

Wenn wir jetzt z.B. die PV-Profi-Suche App mit Cypress testen wollen, nimmt Nx uns viel Arbeit ab. Mit einem einzigen Befehl können wir
End-to-End Tests für unsere App konfigurieren:

```bash[class="line-numbers"]
nx generate @nx/cypress:cypress-project --name=pvexperts-e2e --project=pvexperts
```

Wenn wir jetzt den Dependency Graphen erneut anzeigen, sehen wir, dass ein neues Projekt für die Cypress Tests erstellt wurde:

![](/images/blog/nx-monorepo-pva/pva-graph-e2e.png 'Nx Dependency Graph des PVA Monorepos mit Cypress Tests')

## Fazit

Nx hat die Art und Weise, wie wir Angular Apps entwickeln, grundlegend verändert. Die Lernkurve ist steil, aber wenn man erstmal
die Konzepte und Tools verstanden hat, bietet Nx viele Vorteile, die die Entwicklung von Angular Apps oder Projekten mit anderen
Technologien deutlich effizienter machen.


Entwicklungs-Turbo: Nx Monorepos für Angular-Apps


Trotz guten Entwicklern und einem erfahrenen Projektteam ist der Erfolg eines Software Produktes nicht immer automatisch gewährleistet. Jahrelang eingespielte Entwicklerteams, ausreichend vorhandenes Know-How sowohl in Domäne als auch Tech-Stack gepaart mit genügend zeitlicher Flexibilität bleiben oft das Wunschszenario. Kurz gesagt, die Ressourcen sind knapp, die gesetzten Ziele hoch. Es gilt also mit diesen Rahmenbedingungen umzugehen, die Produktivität zu maximieren und die internen Voraussetzungen für einen effizienten Entwicklungsprozess zu schaffen.

Und dennoch ist in vielen Fällen genau hier noch Luft nach oben. Unklare Strukturen und Prozesse, mangelnder Fokus auf das Kernprodukt, unproduktive Meetings und teils ausbaufähige Architekturentscheidungen sind nur einige der Hürden, mit denen sich Produkt- und Entwicklerteams auseinandersetzen müssen. Gerade wenn Ressourcen nicht immer ausreichen und die Zeit drängt, können die richtigen internen Handgriffe dem Team die notwendige Struktur, Effizienz und Motivation verleihen.

#### Produktmanagement: Die Richtung festlegen und halten

Die Basis für einen optimalen Produktentwicklungsprozess entsteht bereits bei der Ausarbeitung der Produkt Strategie. Im Mittelpunkt, eine klar definierte Product Roadmap. Diese Roadmap sollte nicht nur kurzfristige Ziele festlegen, sondern auch eine klare Mission für das Produkt definieren. Ein gemeinsames Verständnis der Mission schafft Identifikation im Team, fördert die Zusammenarbeit und hilft dabei, die Entwicklung auf das Wesentliche zu konzentrieren. Dabei sollten ständige Richtungsänderungen und Insellösungen vermieden werden, da diese die Entwicklung verlangsamen und das Team demotivieren. Natürlich ist klar, dass auf gewisse Dynamiken im Markt reagiert werden muss und diese die Strategie beeinflussen können, allerdings haltet sich die Agilität an dieser Stelle idealerweise noch etwas in Grenzen.

#### Strukturierte Abläufe und klare Rollenverteilungen

Es hat gute Gründe, wieso Scrum der Grundstein für nahezu alle modernen Software Projekte ist. Es verteilt eindeutige Aufgabenbereiche, gibt einen transparenten und einheitlichen Arbeitsablauf vor und erlaubt somit für Flexibilität, Reaktionsschnelligkeit und Effizienz. Obwohl es nicht in allen Fällen notwendig ist einen Scrum-Prozess laut Lehrbuch einzuführen, sollte man sich den Vorteilen der Grundprinzipien von Scrum bewusst sein und bei Bedarf einen adaptierten Prozess implementieren. Das Ziel muss sein:

- Gut vorbereitete PI- und Sprintplanungen, welche durchdachte und ausführlich definierte Arbeitspakete verabschiedet und die Arbeitsbelastung ideal priorisiert
- Kompakte und regelmäßige Standup Meetings während des Sprints um den Informationsaustausch hochzuhalten und unnötige Meetings zu vermeiden
- Klare Rollenverteilung für direkte Kommunikation und kurze Entscheidungswege
- Gezieltes Dokumentieren von kritischen Informationen als Kriterium für Definition of Done
- Ständige Reflexion des Arbeitsprozesses und Team Dynamik durch regelmäßige Retrospective Meetings

Diese Grundprinzipien erlauben dem Entwicklungsteam vollen Fokus und Stabilität. Zusätzlich dazu wird es für neue Teammitglieder leichter sich schnell in das Projekt zu integrieren und Schritt für Schritt durch strukturierte Planung und direkte, regelmäßige Kommunikation den gewünschten Output zu produzieren.

#### Saubere Anforderungen und eine effektive Teststrategie

Viele haben es wahrscheinlich schon mitgemacht: Das Planungsmeeting geht wiedermal länger als geplant, Grundsatzdiskussionen nehmen die eigentlich wertvoll eingeplante Zeit für die Definition der Akzeptanzkriterien ein und jeder ist froh, wenn man das mühselige Meeting hinter sich lassen und mit der Umsetzung starten kann. Das Problem dabei, die geplanten Stories wurden nicht mehr im notwendigen Detail besprochen, Anforderungen wurden schlampig definiert und es herrscht zu viel Interpretationsspielraum. Dementsprechende Unsicherheit, Fehlinterpretationen und Missverständnisse während der Implementierung führen nun zu möglichen ungewünschten Outcomes und kostspieligen Verzögerungen.

Man sieht, die beiden oben angesprochenen Themen sind auch die Basis für ein sauberes Anforderungsmanagement. Aufbauend darauf ist es ausschlaggebend, die Lösungsspezifikation der Arbeitspakete nicht nur zu diskutieren, sondern auch vollständig und verständlich zu verschriftlichen. Somit wissen sowohl Entwickler und Product Owner genau was definiert wurde, das Risiko für Missverständnisse und zeitaufwendige Abstimmungsmeetings wird minimiert, und die Voraussetzungen für einen effizienten Review und Testing Prozess sind geschaffen.

Werden die Features nun on-time abgeschlossen und präsentiert, kann parallel direkt mit dem Testing angefangen werden während der nächste Sprint bereits in Entwicklung ist. Ergänzend zum bestehenden automatisierten Testing werden somit durch _Continuous Testing_ potenzielle Fehler frühzeitig erkannt und behoben. Dies ermöglicht nicht nur eine höhere Produktqualität, sondern reduziert auch das Risiko von teuren Nacharbeiten und langwierigen Testphasen vor dem Release.

#### Modularisierung von Architekturen für Flexibilität und Skalierbarkeit

Gerade in größeren Softwareprojekten mit einer Vielzahl an Entwicklern, oftmals sogar organisiert in mehreren Teams, kann eine suboptimale Architektur schnell mal zum Bottleneck werden. Je länger das Projekt andauert und die Applikation wächst, desto anspruchsvoller ist in der Regel die Entwicklung jedes einzelnen neuen Features und umso wichtiger ist der Fokus auf einen hoch-qualitativen und vor allem wartbaren Code.

Durch die Aufteilung eines komplexen Systems in unabhängige Module (z.B. bei Domain-Driven-Design) wird die Architektur klar strukturiert und getrennt, was die Flexibilität und Erweiterbarkeit erheblich verbessert. Modularisierung ermöglicht es, Änderungen in einem Teil des Systems vorzunehmen, ohne den gesamten Code zu berühren. Dies trägt zur Fehlerreduzierung bei und erleichtert es, neue Funktionen hinzuzufügen oder bestehende zu optimieren, ohne das gesamte System zu gefährden. Darüber hinaus fördert die Modularisierung die Zusammenarbeit in großen Entwicklerteams, da diese unabhängig voneinander an verschiedenen Teilen der Applikation arbeiten können.

#### Fazit

Um das volle Potenzial eines Entwicklungsteams auszuschöpfen benötigt es angefangen vom Produktmanagement bis hin zur Softwarearchitektur genügend Struktur, solide Planung, klare Rollenverteilung und gezielte Kommunikation. Auch wenn ein funktionierender Prozess gefunden wurde und die Produktivität stimmt, darf man sich nicht darauf ausruhen und muss sich laufend an die sich verändernden Situationen anpassen.

Ganz nach unserem Motto “Good people, good projects” kann natürlich der Entwicklungsprozess noch so feinjustiert sein, es braucht am Ende immer das richtige Team um den Projekterfolg sicherzustellen.


Erfolgsfaktoren für einen effizienten Entwicklungsprozess


#### Jakob’s Law

###### “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.”

Benutzer sind an bestimmte Designelemente und Interaktionen gewöhnt, die sie beim Verwenden verschiedener Websites und Anwendungen erleben. Durch die Verwendung vertrauter Design Patterns können Sie eine intuitivere und benutzerfreundlichere Erfahrung für Ihre Zielgruppe schaffen.

![Youtube Redesign 2017: Etablierte Navigation bleibt](/images/blog/laws-of-software-development/jakobs-law-youtube.jpg)

#### Hofstadter’s Law

###### “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

"Wie lange wird es dauern?“ ist eine der gefürchtetsten Fragen in der Softwareentwicklung. Hofstadters Gesetz beschreibt die Tendenz, dass Projekte und Aufgaben häufig mehr Zeit in Anspruch nehmen als ursprünglich angenommen. Sogar wenn bereits Verzögerungen und Puffer für Unvorhersehbarkeiten eingeplant wurden.

In Software-Projekte gibt es zahlreiche Gründe für Verzögerungen: Unseriöse Angebote und Aufwandschätzungen, falsche Annahmen, unklare Spezifikationen, Fokus auf unwesentliche Dinge, Legay Code, permanente Change-Requests, Angst Entscheidungen zu treffen, etc.

#### The 90-90 Rule

###### “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

Die 90-90-Regel spiegelt (etwas überspitzt) wider, dass Softwareprojekte oft länger dauern als erwartet. Die ursprünglich geplante Entwicklungsdauer wird aus diversen Gründen (siehe Hofstadter’s Law) überschritten. Auch wenn man zu Beginn große Schritte macht und die Entwicklung wie geplant voranschreitet, kann es – je näher der Go-Live Termin kommt – zu Verzögerungen kommen.

#### Brooks’s law

###### “Adding manpower to a late project makes it later.”

Das Gesetz stammt aus Fred Brooks' Buch "The Mythical Man Month" von 1975. Es befasst sich mit der Annahme, dass Teammitglieder und benötigte Monate austauschbar sind. Dies ist jedoch insbesondere in der Softwareentwicklung nicht zwingend der Fall. Warum? Aufgrund der Zeit, die benötigt wird, um Personen über den aktuellen Stand des Projekts auf dem Laufenden zu halten und sie in den Prozess zu integrieren. Zudem gibt es nicht immer die Aufgaben, die in kleinere Subtasks aufgeteilt werden können und gleichzeitig abgearbeitet werden.

![“You cannot have a baby in one month by getting nine women pregnant.”](/images/blog/laws-of-software-development/brooks-law.png)

#### Murphy's Law

###### “If there is a wrong way to do something, then someone will do it.”

Dies ist das bekannteste und universellste Gesetz auf dieser Liste. Murphys Gesetz ist in allen Bereichen des Projektmanagements, der Softwareentwicklung und des Lebens im Allgemeinen sichtbar.

#### Pareto Principle

###### "80% of the effects come from 20% of the causes."

Ein Klassiker! Das Paretoprinzip kann auf viele Bereiche der Arbeit und des Lebens angewandt werden. In der Softwareentwicklung können bedeutende Verbesserungen erzielt werden, indem man den Fokus auf die Funktionen legt, die dem User einen Mehrwert liefern. Zu früh und zu oft verliert man sich im Detail.

Sollte das Paretoprinzip immer berücksichtigt werden. Nein! Es gibt Fälle, in denen es von Vorteil ist, wenn man frühzeitig alle Eventualität berücksichtigt.

#### Dunning–Kruger Effect

###### "Low performers often struggle to recognize the skills and competence of others, leading them to consistently view themselves as better, more capable, and more knowledgeable than others."

Der Dunning-Kruger-Effekt besagt, dass Menschen mit geringen Fähigkeiten oft ihre eigenen Fähigkeiten überschätzen und die Tiefe des benötigten Fachwissens nicht erkennen. Weniger kompetente Personen halten sich oft für sehr kompetent, während kompetentere Personen ihre Fähigkeiten realistischer einschätzen können. In der Softwareentwicklung trifft man häufig auf dieses Phänomen.

![Zu Beginn ist die Lernkurve steil...](/images/blog/laws-of-software-development/dunning-kruger-effect.png)

#### Segal’s Law

###### “A man with a watch knows what time it is. A man with two watches is never sure.”

Hier geht es um die Daten und die Datenqualität – genauer gesagt das Konzept „Single source of truth“ (SSOT). Ein Unternehmen sammelt alle Daten an einem Ort. Dieser allgemeingültige Datenbestand liefert korrekte und verlässliche Daten.

Mehrere Datenquellen ohne SSOT können u.a. zu Verwirrung und Inkonsistenzen führen.

#### DRY (Don't Repeat Yourself)

###### "Every piece of knowledge must have a single, unambiguous representation within a system."

Das DRY-Prinzip besagt, dass in einem Softwareprojekt dieselbe Information oder Logik nicht an mehreren Stellen dupliziert werden sollte. Stattdessen sollte sie an einer einzigen Stelle verwaltet werden. Dies fördert die Wartbarkeit, reduziert das Risiko von Fehlern und vereinfacht Änderungen, da Aktualisierungen nur an einer Stelle vorgenommen werden müssen.

#### Gall’s law

###### “A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.”

Wenn man ein neues System entwickelt, sollte man schrittweise vorgehen. Galls Gesetz liefert einen guten Grund, die Entwicklung von Softwareprodukten in unterschiedliche Etappen zu unterteilen. In der Praxis setzt man dabei auf Werkzeuge wie Prototyping, PoCs und MVPs. Wenn alles funktioniert, kann man schrittweise weiterentwickeln und neue Funktionen hinzufügen.

![Step-by-Step zum Ziel mit Prototyping und MVPS](/images/blog/laws-of-software-development/galls-law.png)

#### KISS (Keep it Simple, Stupid)

###### "Simplicity is the ultimate sophistication."

Dieses Prinzip rät dazu, Software so einfach wie möglich zu halten, um unnötige Komplexität zu vermeiden. Einfache Lösungen sind oft leichter zu verstehen, zu warten und zu debuggen. Klingt simple oder?

#### Eagleson’s law

###### “Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

Mit sechs Monaten zählt Eagleson zu den Optimisten. Wie dem auch sei. Sein Gesetz unterstreicht die Notwendigkeit von Clean-Code, Standards und Kommentaren. Nach einer Weile kann selbst der ursprüngliche Programmierer seinen Code nicht mehr entwirren. Ich spreche da aus eigener Erfahrung…

#### Lubarsky’s law

###### “There’s always one more bug.”

Trotzt aller Bemühung und einhalten von Best-Practice-Ansätzen: Man wird immer noch einen Bug oder eine vermeintliche Optimierung finden. Die Arbeit ist nie abgeschlossen. Was lehrt uns das Gesetz: Nimm dich in Acht vor Perfektionismus! Es kann Zeit, Geld und Nerven kosten.

#### Knuth’s Optimization Principle

###### “Premature optimization is the root of all evil.”

Meiner Meinung nach trifft das nicht immer zu. Beispiel: Wenn wir wissen, dass ein bestimmter Teil eines Systems entscheidend für die Leistung ist und es einen besseren Ansatz als die aktuelle Implementierung gibt, sollte man zumindest über die Alternative diskutieren.

So oder so, in etwa 90 % der Fälle trifft dieses Prinzip zu: Wenn wir zu früh und zu stark optimieren, besteht die Gefahr, dass man das große Ganze aus den Augen verliert und wertvolle Zeit verschwendet.

#### YAGNI (You Aren't Gonna Need It)

###### "Always implement things when you actually need them, never when you just foresee that you need them."

“Nur für den Fall, dass wir sie brauchen” oder “irgendwann wird uns das Helfen”. Stop! YAGNI rät davon ab, Funktionalität oder Features vorzeitig hinzuzufügen. Stattdessen sollte man sich auf die aktuellen Prioritäten fokussieren.

#### Sayre’s Law

###### “In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake.”

Intensive Diskussionen sind wichtig. Manchmal wird zu viel Zeit für Nebenschauplätze verschwendet. Wenn man stundenlang über Dinge debattiert, die keinen Mehrwert bringen, ist das Zeitverschwendung. Daher gilt die Faustregel: Die Diskussionszeit sollte proportional zur Wichtigkeit des Problems sein.

![Fokus auf die wichtigen Themen](/images/blog/laws-of-software-development/sayres-law.png)

#### Parkinson’s Law of Triviality

###### "The time spent on any agenda item will be in inverse proportion to the sum involved."

Ähnlicher Ansatz wie Sayre’s Law. Das Gesetz besagt, dass Menschen tendenziell mehr Zeit und Energie für unwichtige Angelegenheiten verschwenden. In der Softwareentwicklung kann es zu ausgeschweiften Diskussionen über Details wie Formatierungen kommen, während bei tiefgreifende Architektur- oder Designentscheidungen wenig Input geliefert wird.

![Das berühmte Beispiel von Parkinson: Bikesheeding](/images/blog/laws-of-software-development/parkinsons-law.png)

#### Fazit

Wenn einem diese Gesetze und Prinzipien geläufig sind, wird man in der Praxis immer wieder auf sie stoßen. Sie bieten nicht nur Einsichten, sondern auch bewährte Leitfäden für erfolgreiche Projekte. Ob Reduktion der Komplexität, kluge Entscheidungen oder Fokussierung auf das Wesentliche – diese Regeln können als Anhaltspunkte dienen.

Trotz ihrer scheinbaren Strenge sollten wir im Hinterkopf behalten, dass ihre Anwendung oft flexibel ist. Ob und wie sehr man sich an diese Regeln hält, hängt von der jeweiligen Situation ab.

Fakt ist, diese Prinzipien sind ausgezeichnete Orientierungshilfen. Nutzen wir die Weisheiten, für unsere Softwareprojekte und heben diese auf das nächste Level – Code für Code.


Von Murphy bis Knuth: Die Gebote der Softwareentwicklung


Das Windows-Terminal bietet eine deutlich verbesserte Kommandozeile in Windows 10 und 11.
Es ist vollgepackt mit nützlichen Funktionen wie Tabs, Bereichen, Themes und Tastenkombinationen
sowie vollständiger Unterstützung für verschiedene Umgebungen wie PowerShell, Eingabeaufforderung
und Windows Subsystem für Linux.

In diesem Artikel beschreibe ich einige Möglichkeiten, wie das Terminal an deine Bedürfnisse angepasst
werden kann, und gebe ein paar Tipps und Tricks preis, damit deine Arbeit in der Kommandozeile reibungslos
und produktiv verläuft.

### Windows Terminal Features

Auf den ersten Blick sieht das Windows Terminal ziemlich einfach aus, aber es gibt einige Funktionen,
die es von der Standard Windows-Befehlszeile unterscheidet:

- Vollbildmodus
- Tab-Basierte Benutzeroberfläche
- Shortcut Tastenkombinationen
- Zoom mit der Maus (STRG + Mausrad)
- Unicode und UTF-8 Zeichenunterstützung erlaubt die Verwendung von Emojis 👩‍💻🔥👍
- Benutzerdefinierte Themes und Stile können erstellt werden
- Unterstützung für Windows Subsystem für Linux (WSL), SSH, PowerShell, Command Prompt, und Azure Cloud Shell

### Windows Terminal installieren

Leider liefert Microsoft das Windows Terminal nicht standardmäßig in Windows aus. Deshalb muss das Terminal entweder
über den [Microsoft App Store](https://aka.ms/terminal), [Github](https://github.com/microsoft/terminal/releases)
oder einen Package Manager (z.B.: winget, chocolatey, scoop) installiert werden.

### Windows Terminal konfigurieren

Nach der Installation kann das Terminal über mehrere Wege geöffnet werden:

- Über das Startmenü “Terminal” suchen
- WIN+R drücken und wt eingeben
- In Windows Explorer auf einem Ordner, oder in einem Leerbereich rechtsklicken und “In Terminal öffnen” auswählen
- In Windows Explorer in der Adressleiste wt eingeben
- Windows 11: WIN+X drücken und Terminal öffnen

Um die Einstellungen anzupassen wähle "Einstellungen" im Dropdown Menü oder drücke CTRL+,. Hier hast du die Möglichkeit
dein Terminal bis ins kleinste Detail zu konfigurieren. Es können verschiedene Profile für jede Shell angelegt werden
in denen Icons, Schriftart und Farben definiert werden. Das beste am Windows Terminal ist aber das die Konfiguration
im JSON Format gespeichert wird. Somit können Konfigurationen untereinander geteilt werden oder auf einen anderen PC übertragen werden.

Um das ganze noch visuell aufzupeppen empfehle ich die Installation von [Oh My Posh](https://ohmyposh.dev/).
Mit Oh My Posh liefert bessere Theme Funktionen mit denen beispielsweise der aktuellen Git status direkt im Terminal angezeigt werden kann.

Microsoft liefert hier ein Tutorial mit der die Installation ganz leicht klappt:

[Windows Terminal Custom Prompt Setup](https://learn.microsoft.com/en-us/windows/terminal/tutorials/custom-prompt-setup)

Ebenfalls zu empfehlen ist der Blog Post von Scott Hanselman:

[My Ultimate PowerShell prompt with Oh My Posh and the Windows Terminal](https://www.hanselman.com/blog/my-ultimate-powershell-prompt-with-oh-my-posh-and-the-windows-terminal)

![Windows Terminal konfiguriert mit Oh My Posh](/images/blog/windows-terminal/terminal-1.png)

### Bonus: Git Shortcuts

Um die tägliche Arbeit mit Git zu erleichtern habe ich mir noch einige PowerShell Alias erstellt.
Ein Alias unter PowerShell ist ein Synonym für einen PowerShell Befehl.
Um PowerShell Alias zu erstellen, öffne dein PowerShell Profil mit diesem Befehl:

```powershell[class="line-numbers"]
notepad $PROFILE
```

Um nicht immer die Befehle in der Konsole eintippen zu müssen und Typos entgegenzuwirken,
habe ich für jeden dieser Git Befehle PowerShell Alias erstellt:

```powershell[class="line-numbers"]
# Git Alias
# git status -> gco
function Get-GitStatus { & git status $args }
New-Alias -Name gst -Value Get-GitStatus

# git commit -> gco
function Set-GitCommit { & git commit -am $args }
New-Alias -Name gco -Value Set-GitCommit

# git checkout -> go
function Set-GitCheckout { & git checkout $args }
New-Alias -Name go -Value Set-GitCheckout

# git add -> ga
function Set-GitAdd { & git add $args }
New-Alias -Name ga -Value Set-GitAdd

# git pull -> pull
function Set-GitPull { & git pull }
New-Alias -Name pull -Value Set-GitPull

# git push -> push
function Set-GitPush { & git push }
New-Alias -Name push -Value Set-GitPush

# git add .
# git commit $args
# git push
# -> push-all commit message
function Set-GitSync { & ga . && gco $args && push}
New-Alias -Name push-all -Value Set-GitSync
```

Mit diesem Setup kann nun ganz leicht auf einen neuen Branch mit dem Befehl `go "branch-name"`
gewechselt werden. Zusätzlich gibt es einen `push-all` Alias mit dem es möglich ist alle aktuellen Änderungen
in das zentrale Repository zu pushen:

```powershell[class="line-numbers"]
push-all <commit-message>
```

### Fazit

Mit dem Windows-Terminal steht den Benutzern eine leistungsstarke und anpassbare Umgebung zur Verfügung,
um ihre Kommandozeilenarbeit zu verbessern. Egal, ob du ein Entwickler, Systemadministrator oder einfach
ein begeisterter Benutzer bist, das Terminal bietet die Werkzeuge, um effizienter zu arbeiten und Aufgaben
schneller zu erledigen. Wenn du noch nicht das volle Potenzial des Windows-Terminals ausgeschöpft hast,
solltest du definitiv die vorgestellten Tipps und Tricks ausprobieren, um das Beste herauszuholen.


Entwicklungs-Turbo: Nx Monorepos für Angular-Apps

Erfolgsfaktoren für einen effizienten Entwicklungsprozess

Von Murphy bis Knuth: Die Gebote der Softwareentwicklung

Windows Terminal für Entwickler