III. Codequalität und Standards

A. C#-Code-Formatierung und -Stil

1. Code Style
2. Exceptions
3. Naming
4. Configuration

B TypeScript-Code-Formatierung und -Stil

1. Code Style

C. Code Reviews

Code Reviews sind ein entscheidender Aspekt jedes Entwicklungsprozesses und dienen als unverzichtbares Mittel, um Codequalität, Funktionalität und Wartbarkeit sicherzustellen. Ein sorgfältig durchgeführter Code-Review-Prozess ermöglicht es Teams, Fehler frühzeitig zu erkennen, Wissen im Team zu teilen und eine konsistente Codebasis aufrechtzuerhalten. Hier sind einige Richtlinien, die zu befolgen sind:

1. Fokus über Tippfehler und Formatierung hinaus

   Code Reviews sollten sich auf die Logik, das Design und die Performance des eingereichten Codes konzentrieren. Tippfehler, Formatierung und das Entfernen ungenutzten Codes sollten idealerweise vom Entwickler behoben werden, bevor der Code die Review-Phase erreicht. Der Einsatz automatisierter Werkzeuge für solche Aspekte wird empfohlen, um Einheitlichkeit zu gewährleisten und Code Reviews auf höherstufige Belange zu fokussieren.

2. Demonstration von Features

   Jedes Code Review sollte idealerweise eine Demonstration der implementierten Features beinhalten. Dies stellt sicher, dass der Reviewer die Funktionalität des Codes versteht und die Angemessenheit der Implementierung beurteilen kann. Demonstrationen bieten außerdem die Gelegenheit, das Feature gegen die Benutzeranforderungen und die erwarteten Ergebnisse zu verifizieren.

3. Umfang des Reviews

   Wenn ein Feature oder ein Bugfix zu viele Änderungen umfasst, um in einem einzigen Pull Request ordnungsgemäß überprüft zu werden, wird empfohlen, es in mehrere kleinere Pull Requests aufzuteilen. Dies hilft, Reviews handhabbar und gründlich zu halten. Ein Review sollte prägnant genug sein, um eine detaillierte Prüfung zu ermöglichen, aber umfassend genug, um alle mit einem bestimmten Feature oder Problem zusammenhängenden Änderungen einzuschließen.

4. Verständnis des Zwecks des Codes

   Der Reviewer sollte ein klares Verständnis des Zwecks des Codes haben. Dazu gehört zu wissen, was der Code tun soll, welches Problem er löst und wie er in die größere Codebasis passt. Der Autor des Codes sollte diese Informationen in der Beschreibung des Pull Requests bereitstellen, um den Reviewer zu unterstützen.

5. Feedback im Code Review

   Feedback in Code Reviews sollte konstruktiv und respektvoll sein. Das Ziel ist es, den Code zu verbessern, nicht den Programmierer zu kritisieren. Alle Diskussionen sollten auf die bestmögliche Lösung ausgerichtet sein und eine Lernumgebung fördern.

Denken Sie daran: Bei Code Reviews geht es ebenso sehr um menschliche Interaktion wie um Code. Sie sind eine Gelegenheit, zu kommunizieren, zu lernen und Wissen zu teilen, zusätzlich dazu, hochwertigen Code sicherzustellen.

D. Teststrategien

Die Einführung einer effizienten Teststrategie ist entscheidend, um eine robuste, zuverlässige und effiziente Codebasis aufrechtzuerhalten. Hier ist ein Überblick über die verschiedenen Arten von Tests, die Sie berücksichtigen sollten:

1. Unit-Testing

   Beim Unit-Testing werden einzelne Einheiten Ihres Codes — typischerweise Funktionen oder Methoden — getestet, um sicherzustellen, dass sie sich wie erwartet verhalten. Obwohl Unit-Tests mächtig sind, ist es wichtig, ein Gleichgewicht zu finden: Zu viel Mocking kann ihren Nutzen verwässern. Für kritische Algorithmen sind Unit-Tests jedoch von unschätzbarem Wert, um zu verifizieren, dass sie korrekt funktionieren. Ein Test-Driven-Development-(TDD-)Ansatz, bei dem die Tests vor dem Code geschrieben werden, produziert nicht nur Unit-Tests als Nebenprodukt, sondern führt auch zu saubererem, modularerem Code.

2. Integrationstesting

   Integrationstesting ist der Prozess, mehrere Einheiten gemeinsam zu testen, um zu prüfen, ob sie als Gruppe korrekt zusammenarbeiten. Diese Tests können oft mehr Informationen über die Funktionalität einer Komponente liefern als Unit-Tests, und das mit weniger Aufwand. Auch wenn sie die genaue Fehlerquelle möglicherweise nicht ausfindig machen, eignen sie sich hervorragend, um anzuzeigen, ob eine Komponente insgesamt korrekt funktioniert. Schwierigkeiten beim Einrichten von Integrationstests können ein Zeichen für schlechtes Komponentendesign sein und auf zu viel Kopplung oder zu wenig Kohäsion hindeuten.

3. Systemtesting

   Beim Systemtesting wird das gesamte System als Ganzes getestet. Diese Teststufe kann komplexer einzurichten sein — sie erfordert eine korrekt konfigurierte Infrastruktur —, aber sie liefert wertvolle Einblicke in die Qualitätsattribute des Systems, wie Performance, Resilienz und Zuverlässigkeit.

Denken Sie daran: Alle Arten von Tests sind wichtig, um Qualität sicherzustellen, aber sie sollten die Produktivität nicht behindern. Jede Testart bietet ihre eigenen Vorteile und sollte je nach Bedarf und Kontext des Projekts angemessen eingesetzt werden. Testen ist ein Werkzeug, kein Hindernis — es sollte die Entwicklung unterstützen, nicht behindern.

E. Überlegungen zur Performance

F. Sicherheitsüberlegungen

G. Dokumentation und Kommentare

Ihren Code effektiv zu dokumentieren, ist essenziell für Wartbarkeit und Lesbarkeit. Auch wenn Kommentare helfen können, komplexe Logik zu verdeutlichen, sollte das Ziel sein, selbstdokumentierenden Code zu schreiben. Hier sind die wichtigsten Richtlinien, die zu befolgen sind:

1. Selbstdokumentierender Code

   Der Code sollte so geschrieben sein, dass er für sich selbst leicht verständlich ist. Wenn umfangreiche Kommentare erforderlich sind, kann das ein Hinweis darauf sein, dass der Code refaktoriert werden muss. Die Verwendung aussagekräftiger Namen, kleiner Funktionen und gut strukturierter Klassen kann den Code lesbarer und selbsterklärender machen.

2. Übergeordnete Dokumentation

   README.md-Dateien dienen als Ausgangspunkt für andere Entwickler, um die Software zu verstehen. Diese Dateien sollten einen übergeordneten Überblick über den Dienst oder die Bibliothek geben, einschließlich seines Zwecks, wie man ihn einrichtet und wie man ihn verwendet. Es ist entscheidend, diese Dokumentation so zu schreiben, dass sie nicht mit jeder kleinen Änderung veraltet.

3. API-Dokumentation

   Wenn Sie Werkzeuge wie xmldoc für die API-Dokumentation verwenden, konzentrieren Sie sich darauf, nützliche Informationen bereitzustellen, statt das Offensichtliche zu benennen. Anstatt beispielsweise nur anzugeben, dass ein Parameter 'fileName' ein Dateiname ist, dokumentieren Sie spezifische Erwartungen oder Einschränkungen — zum Beispiel, ob der Dateiname ein absoluter Pfad sein soll oder ein Parameter eine positive Zahl sein muss.

4. Dokumentation von Erweiterungspunkten

   Teile Ihres Codes, die als Erweiterungspunkte für andere Komponenten dienen, sind erstklassige Kandidaten für detaillierte Dokumentation. Hier ist es wichtig, die erwarteten Eingaben, Ausgaben, Seiteneffekte und alle architektonischen Entscheidungen klar zu erläutern, die der Erweiternde kennen muss. Dies hilft sicherzustellen, dass Erweiterungen korrekt funktionieren und den Rest des Systems möglichst wenig stören.

Das Ziel sowohl der Dokumentation als auch der Kommentare ist es, die Codebasis für andere Entwickler, die sie möglicherweise verwenden, warten oder erweitern müssen, so klar wie möglich zu machen. Denken Sie daran: Das Publikum Ihrer Dokumentation und Kommentare ist nicht nur Ihr aktuelles Team, sondern auch zukünftige Entwickler, die mit der Codebasis arbeiten werden.