Auto-translate this article in English using Google Translate.
Ich werde regelmäßig von Kunden engagiert, um Reviews für Softwareentwicklungsprojekte speziell in Verbindung mit Microsoft-Technologie durchzuführen. Im Lauf der Jahre habe ich meine persönliche Checkliste erarbeitet. In diesem Blogartikel möchte ich eine Zusammenfassung der Checkliste zeigen. Die Detailfragestellungen in der Checkliste sind nur einige Beispiele. Jedes Kundenprojekt ist anders - man muss sie auf jeden Fall je nach Situation anpassen und erweitern. Fehlt etwas? Kommentare? Ich freue mich über Feedback im Kommentarbereich unten.
Hinweis: Kundenspezifisch angepasste Versionen dieser Review-Checkliste verwende ich für reine Code Reviews. Für Architektur-Reviews habe ich andere Checklisten.
-
Sourcecode-Review
- Automatische Qualitätsprüfung
- Kompiliert der Sourcecode fehlerfrei?
- Kompiliert der Sourcecode ohne Compiler-Warnungen?
- Gibt es auffällige Warnungen von Visual Studio Code Analysis (Analyse IL-Code)?
- Gibt es auffällige Warnungen von Quellcodeanalysetools (z.B. StyleCop, JSLint, JSHint, etc.)?
- Manuelle Qualitätsprüfung
- Werden die von Microsoft ausgegebenen Richtlinien für Framework Design eingehalten (siehe z.B.
Framework Design Guidelines)? Beispielkriterien:
- Sinnvolle Namensvergabe
- Exception Handling
- Memory Management (z.B. IDisposable)
- Einhaltung von best Practices in Sachen Klassendesign
- Etc.
- Ist der Code sinnvoll dokumentiert (C# Codedokumentation, Dokumentation in längeren Methode, etc.)?
- Wird API Dokumentation aus der Codedokumentation generiert (z.B. Sandcastle)?
- Auf welchem Stand ist der geschriebene C# Code? Beispiele:
- Werden C# 3 Strukturen wie Lambdas und Linq verwendet wo sinnvoll?
- Werden C# 4 bzw. 5 Funktionen wie TPL, async/await verwendet wo sinnvoll?
- Welche Version von ASP.NET MVC wird eingesetzt?
- Welche Version von .NET wird verwendet?
- Werden aktuelle Versionen der eingesetzten Drittanbieterkomponenten verwendet?
- Werden aktuelle Kommunikationsstandards genutzt (z.B. REST vs. SOAP, Tokenformate, etc.)?
- Ist die Gliederung der Projekte und Solutions in Ordnung?
- Ist das Projekt nachvollziehbar in Projekte gegliedert?
- Gibt es offensichtliche Schwächen in Sachen Abhängigkeitsmanagement (z.B. klare Trennung der Anwendungsschichten in Projekte mit entsprechenden Projektreferenzen)?
- Wird NuGet für gemeinsame Bibliotheken verwendet?
- Folgt die Anwendung den von Microsoft definierten Best Practices für Cluster-Systeme (u.A. auch in
Windows Azure)? Beispiele:
- Umgang mit Web Sessions
- Retry-Logik bei Zugriff auf DB-Cluster
- Prüfung der Vollständigkeit
- Gibt es Unit Tests?
- Verteilung Unit Tests vs. Integrationstests?
- Laufen die Unit Tests erfolgreich durch?
- Welche Code Coverage wird erreicht?
- Enthalten die Unit Tests sinnvolle Prüfungen (Asserts)?
- Ist die Laufzeit der automatisierten Tests akzeptabel?
- Ist der geschriebene Code testbar (z.B. Möglichkeiten für Mocking, klare Trennung von UI und Logik durch MV* Patterns, etc.)?
- Sind die Unit Tests dokumentiert?
- Sind die Projekte zur Erstellung der Azure-Pakete enthalten?
- Gibt es einen automatisierten Build?
- Funktioniert der automatisierte Build?
- Sind die Unit Tests integriert?
- Ist die Erstellung der API-Dokumentation integriert?
- Werden die Azure-Pakete automatisch erstellt?
- Ist ein automatisiertes Azure-Deployment im Build bzw. mit Scripts (z.B. PowerShell) vorgesehen?
- Gibt es ausreichende Vorkehrungen für Versionsmanagement (z.B. Versionsnummernvergabe, Labeling, etc.)?
- Gibt es eine ausreichende Dokumentation der Architektur (über reine Codedokumentation hinaus)?
- Gibt es offensichtliche Schwächen in Sachen Sicherheit? Beispiele:
- Anfälligkeit für SQL Injections?
- Ist die eingesetzte Absicherung (Authentifizierung, Authorisierung) der Webseiten und Webservices passend?
- Verwenden Webseiten und Webservices SSL?
- Ist die Verarbeitung sicherheitskritischer Daten (z.B. Tokens in Web APIs) in Ordnung?
- Erfolgt die Speicherung kritischer Daten verschlüsselt? Beispiele:
- Zugangsdaten zu Datenbanken in Konfigurationsdateien
- Kritische Felder in Datenbanktabellen (z.B. Payment-relevante Daten, personenbezogene Daten)
- Wie erfolgt die Verwaltung von Verschlüsselungsschlüssel, Zertifikaten, etc.?
- Sind die Assemblies signiert und/oder strong named?
-
DB-Review
- Erscheint die DB-Struktur robust?
- Namensgebung
- Vergabe von Schlüsseln (Primary Keys, Foreign Keys)
- Etc.
- Ist das DB-Design konsistent?
- Gibt es Indizes (über die von Primary Keys hinaus)?
- Gibt es Business Logik in der DB (z.B. Trigger, Stored Procedures, Functions, etc.)? Wenn ja, werden ähnliche Review-Kriterien darauf angewandt, wie oben bei "Sourcecode Review" erwähnt.
- Ist die Authentifizierung der Anwendungen gegenüber der DB passend?
-
Analyse des Laufzeitverhaltens
- Performanceanalyse mit .NET Profiler (z.B.
ANTS Profiler,
PerfView, etc.)
- Gibt es offensichtliche Performancekiller (Methoden, Algorithmen, Module)?
- Welchen Einfluss hat der Garbage Collector?
- Wie ist die Performance unter Last (aufwendiger Test; möglicherweise erst in einem zweiten Schritt zu machen)?
- Memoryanalyse mit .NET Memory Profiler (z.B. ANTS Memory Profiler, etc.)
- Gibt es offensichtliche Memory Leaks?
- Wie speicherintensiv ist die Anwendung?
- Analyse des DB-Verhaltens
- Gibt es einzelne, offensichtlich langsame DB-Abfragen?
- Gibt es idente DB-Abfragen, die extrem häufig ausgeführt werden?
- Hat das Kommunikationsverhalten der Anwendung mit der DB offensichtliche Schwächen (z.B. Performanceverlust durch Lazy Loading eines OR-Mappers)?
-
Sonstiges, das im Rahmen des Reviews gemacht werden könnte/sollte
- Erfolgt regelmäßig ein Check-in des Sourcecodes in Team Foundation Server oder ein anderes Quellcodeverwaltungssystem?
- Analyse der Umgebungen für Dev, Test, Prod
comments powered by