Site Compass

Herausforderung

Die Reivernet Group beauftragte Redwerk mit der Prüfung eines ihrer Softwareprodukte vor der offiziellen Veröffentlichung. Bei der fraglichen Software handelte es sich um Site Compass, eine Netzwerk-Mapping-App. Site Compass ist für Bauunternehmen gedacht, die ihre Rentabilität verbessern wollen.

Site Compass hilft den Nutzern bei der Verwaltung von Baustellen, indem es alle erforderlichen Daten im Zusammenhang mit der Budgetplanung, der Ausschreibung und der Anlagenverwaltung zentralisiert. Die App vereinfacht auch das Berichtswesen, einschließlich der Erstellung von Auditberichten und Stücklisten.

Für die Reivernet-Gruppe war es entscheidend, dass eine unabhängige Partei die Codeprüfung durchführt. Sie benötigten eine genaue und unvoreingenommene Bewertung der Qualität ihres Produkts. Unser Arbeitsumfang umfasste:

• Überprüfung der Architektur. In diesem Schritt sollten wir sicherstellen, dass die Grundlage des Systems gut konzipiert ist, die Anforderungen erfüllt und für künftiges Wachstum geeignet ist.
• Überprüfung der Datenbank. Hier stellen wir sicher, dass die Datenbank für Leistung, Sicherheit und Datenintegrität optimiert ist.
• Überprüfung der Codequalität. Dieser Teil umfasst die Bewertung der Lesbarkeit, Wartbarkeit und Konsistenz des Codes sowie die Einhaltung moderner Codierungsstandards. Wir wurden gebeten, nur den Backend-Code zu überprüfen.
• Überprüfung der Testabdeckung. Hier stellen wir sicher, dass der Code ausreichend getestet ist und identifizieren Bereiche, in denen zusätzliche Tests erforderlich sind.
• Überprüfung der Sicherheit. Unser Ziel war es, die Anwendung anhand der Top 10 Web-Schwachstellen von OWASP zu bewerten und Strategien zur Abhilfe zu entwickeln.

Wir melden nicht nur die gefundenen Probleme, sondern geben auch detaillierte Empfehlungen, wie sie behoben werden können und wie viel Zeit für die Überarbeitung des Codes benötigt wird.

Lösung

Site Compass wurde in C# mit der Uno-Plattform entwickelt, die es ermöglicht, iOS-, Android- und Windows-Apps in einem einzigen Codesatz zu erstellen. Wir haben jahrelange Erfahrung mit allen Technologien, die in diesem Projekt zum Einsatz kommen, so dass die Aufgabe für uns recht einfach war.

Um den Prozess zu beschleunigen und sicherzustellen, dass wir jeden Fehler finden, haben wir die manuelle Prüfung durch Automatisierung ergänzt, indem wir spezielle Tools wie NDepend und PVS-Studio verwendet haben. Im Folgenden finden Sie einen kurzen Überblick über die Probleme, auf die wir bei jedem Schritt gestoßen sind.

Überprüfung der Architektur

Die Anwendung hat eine mehrschichtige Architektur mit separaten Präsentations-, Code- und Datenbankschichten. Dieser Ansatz ist für Multiplattform-Lösungen wie Site Compass aufgrund der gemeinsamen Codebasis effizient und reduziert die Entwicklungszeit und -kosten. Es kann jedoch dazu führen, dass einige Typen oder Klassen der Codebasis zu generisch und schwer zu pflegen werden.

Was die kritischen Punkte anbelangt, so haben wir festgestellt, dass einige Namespaces voneinander abhängig sind. Zirkuläre Abhängigkeiten machen es schwierig, einen Namensraum zu ändern oder zu testen, ohne den anderen zu beeinträchtigen. Diese enge Kopplung kann die Flexibilität des Codes beeinträchtigen und die Entwicklungszeit verlängern.

Eine Lösung wäre das Verschieben eines oder mehrerer Typen aus den Low-Level-Namespaces in den High-Level-Namespace oder umgekehrt. Eine weitere Option ist die Verwendung der Inversion of Control (IoC), um eine Abstraktionsschicht zwischen abhängigen Komponenten einzuführen und die lose Kopplung zu fördern.

Außerdem stellten wir fest, dass einige Klassen zu tief im Vererbungsbaum lagen, mit einer Vererbungstiefe von 5-8 Stufen. Dies ist eine Abweichung von der objektorientierten Programmierung, die Komposition gegenüber Vererbung bevorzugt.

Lange Vererbungsketten sind problematisch, weil sie das Prinzip der Kapselung verletzen, d. h., die “Eltern”-Klassen können Implementierungsdetails an die “Kinder” weitergeben. Letzteres macht den Zweck getrennter Schichten zunichte, da jeder an der internen Struktur herumspielen kann, was zu Instabilität führt.

Um dies zu beheben, müssten eng gekoppelte Funktionalitäten analysiert und ihr Design durch Komposition geändert werden.

Struktur der Datenbank

Wir haben keine Probleme mit der Datenbankarchitektur und der Skalierbarkeit festgestellt. Azure Cosmos DB bietet genügend Flexibilität, um sie zu skalieren und Leistungsprobleme zu lösen. Der einzige Aspekt, der die Leistung der App beeinträchtigen könnte, ist ein Szenario, in dem die Region des Benutzers von der Cloud-Region abweicht, was zu langsamen Ladezeiten führt.

Qualität des Backend-Codes

Wir haben mehrere kritische und mittelschwere Probleme in Bezug auf die Backend-Code-Qualität festgestellt.
Wir haben 38 Methoden mit 7 bis 14 Parametern identifiziert. Das sind zu viele Parameter. Methoden mit zu vielen Parametern sind mühsam aufzurufen und können die Leistung beeinträchtigen.

Eine Lösung besteht darin, dem deklarierenden Typ mehr Eigenschaften/Felder hinzuzufügen, um zahlreiche Zustände zu behandeln. Eine Alternative ist die Bereitstellung einer Klasse oder einer Struktur, die für die Übergabe von Argumenten zuständig ist.

Das nächste Problem sind zu große Typen, die zu dem so genannten “Gott-Klasse”-Phänomen führen. Eine “Gott-Klasse” oder ein “Gott-Objekt” ist eine einzelne Klasse, die versucht, alles zu tun. Sie übt eine übermäßige Kontrolle über andere Klassen im System aus und wird oft so groß, dass sie für die Ausführung aller Aufgaben verantwortlich wird. Das Ergebnis ist ein Code, der schwer zu verstehen, zu pflegen und zu testen ist.

Um eine Gott-Klasse zu reparieren, muss sie in kleinere Klassen mit einer einzigen Verantwortung und klar definierten Grenzen aufgeteilt werden. Versuchen Sie zunächst, die Schnittstelle der God-Klasse beizubehalten und Aufrufe an die neu extrahierten Klassen zu delegieren. Am Ende sollte die God-Klasse eine reine Fassade ohne eigene Logik sein. Dann können Sie sie aus Bequemlichkeit behalten oder wegwerfen und nur noch die neuen Klassen verwenden.

Ein weiterer Punkt, der sich auf die Wartbarkeit und Testbarkeit des Codes auswirkt, ist die Verwendung von statischen Feldern, die nicht schreibgeschützt sind. Wenn sich der Wert nie ändert, sollten Sie ihn schreibgeschützt machen und direkt im statischen Konstruktor oder inline mit seiner Deklaration festlegen. Wenn sich der Wert gelegentlich ändert, sollten wir stattdessen ein Instanzfeld verwenden. Jedes Objekt hat seine eigene “Box”, wodurch Probleme mit gemeinsamen Zuständen vermieden werden.

Wir haben auch übermäßig komplexe, potenziell tote oder schlecht kommentierte Methoden und Methoden mit übermäßig langen Namen gemeldet.

Testabdeckung

Nur ein kleiner Prozentsatz des Codes wurde durch Tests abgedeckt. Eine geringe Testabdeckung bedeutet, dass große Teile des Codes ungetestet bleiben, was dazu führt, dass sich Fehler in die Produktion einschleichen.

Eine frühzeitige und kontinuierliche Qualitätssicherung ist von entscheidender Bedeutung, da Fehler, die in der Produktion gefunden werden, teurer und zeitaufwändiger zu beheben sind, was den Zeitplan für die Veröffentlichung stört und Hotfixes erforderlich macht. Außerdem machen unzureichende Anfangstests die Regressionstests weniger effektiv, da unklar ist, wie sich das ursprüngliche Verhalten in den nicht getesteten Bereichen darstellt.

Sicherheitsüberprüfung

Unsere Sicherheitsüberprüfung umfasste die Überprüfung des Codes auf Injektionsschwachstellen, wie z. B. NoSQL-, LDAP- und OS-Injektionen.

Wir stellten sicher, dass es keine Probleme mit der Authentifizierung, der Offenlegung sensibler Daten, schlecht konfigurierten XML-Parsern und Standard-, unvollständigen oder Ad-hoc-Konfigurationen gab.

Unsere Prüfer suchten auch nach Schlupflöchern, die dauerhafte Bedrohungen ermöglichen. Diese würden es Angreifern ermöglichen, im Falle eines Einbruchs unentdeckt zu bleiben und weitere Systeme und Daten zu gefährden.