Project Science

Herausforderung

Complete Network entwickelte Project Science – eine Software, die die Standardisierung, Kategorisierung und Verwaltung von Angebotsdaten in der IT-Branche vereinfacht. Es handelte sich um eine Betaversion, und da sie ihre Frontend-Codebasis umgestalteten, beschlossen sie, auch ein Backend-Audit durchzuführen.

Sie wollten einen frischen, unvoreingenommenen und professionellen Blick auf ihr in Python geschriebenes Backend werfen. Complete Network suchte jemanden mit langjähriger Erfahrung in der Python-Entwicklung und einem umfassenden Code-Review-Service. Redwerk erfüllte diese Kriterien perfekt.

Wir wurden beauftragt, die folgenden Aspekte zu überprüfen:

1. Architektur. Hier sollten wir prüfen, wie der Kern aufgebaut ist, welche Module enthalten sind und ob geeignete Architekturprinzipien und -muster verwendet wurden.
2. Code-Qualität. In diesem Teil der Prüfung sollte festgestellt werden, ob der Code lesbar, wiederverwendbar und zuverlässig ist. Wir untersuchen auch Dinge wie Fehlerbehandlung, Bibliotheken von Drittanbietern und die Erweiterbarkeit des Codes.
3. Überprüfung der Datenbank. Dieser Teil war notwendig, um sicherzustellen, dass die Datenbankstruktur den Projektanforderungen entsprach und relativ einfach skalierbar war.

Unsere Code-Reviews kategorisieren die gefundenen Probleme nach Schweregrad und enthalten Vorschläge zu deren Behebung. Wir geben auch die Anzahl der Stunden an, die für die Überarbeitung des Codes benötigt werden.

Lösung

Bei der überprüften Codebasis handelte es sich um eine Backend-API, die für allgemeine CRUD-Operationen (Create, Read, Update, Delete) für einzelne oder oberflächlich verschachtelte Modelle sowie für das Parsen und Verarbeiten von CRUD-Operationen für tief verschachtelte vollständige Angebote zuständig war.

Die gesamte Codeüberprüfung wurde manuell durchgeführt, ohne auf automatisierte Tools zurückzugreifen. Schauen wir uns an, welche Verbesserungsmöglichkeiten wir in den einzelnen Modulen gefunden haben.

Überprüfung der Architektur

Dieser Teil umfasst die Abschnitte Allgemeine Architektur, Leistung, Skalierbarkeit, Sicherheit, Einstellungen und REST.

Im allgemeinen Teil wird geprüft, ob der Code dem deklarierten Architekturtyp entspricht. Wir überprüfen, ob die Trennung von Belangen implementiert ist und ob es eine Aufteilung in Präsentations-, Geschäfts- und Datenschichten gibt. Außerdem bewerten wir unter anderem Design Patterns, ein Setup-Verfahren für Instanzen und Entity-Einstellungen.

Unsere Prüfung der Projektarchitektur ergab mehrere kritische Punkte hinsichtlich der allgemeinen Architektur, der Leistung und der Sicherheit.

Wir stellten beispielsweise fest, dass Anweisungen zur Definition von Umgebungsvariablen fehlten und die Sicherung der Datenbank zu viele Manipulationen erforderte, damit sie funktionierte. Außerdem entdeckten wir ein unnötiges benutzerdefiniertes Skript zum Ausfüllen der Datenbank und einen Code-Formatierer, der hauptsächlich für JS-Projekte verwendet wurde und nicht wirklich viel bewirkte.

Was die Leistung angeht, so haben wir drei einfache Möglichkeiten gefunden, sie zu steigern, indem wir das Django-Caching, das Caching von Datenbankabfragen und Python-Beschleunigungstools nutzen.

Wir sind auch auf ein kritisches Sicherheitsproblem gestoßen, das mit der Speicherung sensibler Daten in einem öffentlich zugänglichen Ordner zusammenhängt.

Code-Qualität

Unsere Prüfung der Codequalität ergab mehrere Probleme in Bezug auf Lesbarkeit, Wiederverwendbarkeit und Fehlerbehandlung.

Wir stellten fest, dass die Klassennamen selten der CapWords-Konvention folgten und viele Dateien eine falsche Importreihenfolge aufwiesen, was die Lesbarkeit beeinträchtigte.

Ein weiteres Problem war, dass das Ändern des Typs des angezeigten Wertes im Serializer ineffizient durchgeführt wurde – durch Setzen des Attributs anstelle der to_representation-Methode.

Es gab Fälle, in denen die Django-Erstellungslogik ohne Grund außer Kraft gesetzt wurde. Außerdem fanden wir eine veraltete Formatierung von Strings und verschiedene andere Abweichungen vom Django-Kodierungsstil.

Was die Wiederverwendbarkeit anbelangt, so sind uns mehr als zehn leere Dateien aufgefallen. Für einen neuen Entwickler im Projekt wäre es schwierig zu verstehen, was er damit anfangen soll.

Außerdem wurde ein Teil des Codes auskommentiert, ohne dass der Grund dafür angegeben wurde. In solchen Fällen sollte der Code entweder entfernt werden oder es müssen zusätzliche Kommentare hinzugefügt werden, die erklären, warum der Code nicht verwendet wird und ob er wiederhergestellt wird, wenn einige andere Bedingungen erfüllt sind.

Außerdem sind wir über die übermäßige Verwendung von reservierten Python-Wörtern, ungenutzte Funktionen und Teile des Codes gestolpert, die mit Django-filter und dem Django REST-Framework für die Verwaltung paginierter Daten erheblich verkürzt und vereinfacht werden könnten.

Schließlich haben wir noch eine Bemerkung zur Fehlerverarbeitung gemacht. Die Ausnahmeklauseln waren zu weit gefasst, so dass wir vorschlugen, sie nach Möglichkeit zu präzisieren.

Datenbank-Architektur

Die Datenbankarchitektur war typisch und passte gut zu den Anforderungen des Projekts. Wir hielten sie für skalierbar genug und in der Lage, eine steigende Nutzernachfrage zu erfüllen. Unsere Code-Reviewer waren mit diesem Teil des Projekts voll einverstanden.