Project Science

Défi

Complete Network a développé Project Science – un logiciel qui simplifie la normalisation, la catégorisation et la gestion des données de devis dans l’industrie informatique. Il s’agissait d’une version bêta, et comme ils remodelaient leur base de code frontend, ils ont également décidé de procéder à un audit backend.

Ils souhaitaient un examen frais, impartial et professionnel de leur backend écrit en Python. Complete Network a recherché quelqu’un possédant une expertise de longue date en développement Python et un service complet d’examen de code. Redwerk a parfaitement correspondu à ces critères.

Nous avons été chargés d’examiner les aspects suivants :

1. Architecture. Ici, nous devions inspecter la manière dont le cœur était construit, quels modules étaient inclus, et si les principes et modèles architecturaux appropriés étaient utilisés.
2. Qualité du code. Cette partie de l’examen visait à déterminer si le code était lisible, réutilisable et fiable. Nous avons également examiné des éléments tels que la gestion des erreurs, les bibliothèques tierces et l’extensibilité du code.
3. Examen de la base de données. Ceci était nécessaire pour garantir que la structure de la base de données correspondait aux exigences du projet et était relativement facile à faire évoluer.

Nos examens de code classifient les problèmes trouvés par gravité et incluent des suggestions pour les corriger. Nous mentionnons également le nombre d’heures nécessaires pour refactoriser le code.

Solution

La base de code examinée était une API backend responsable des opérations CRUD (Create, Read, Update, Delete) générales sur des modèles individuels ou peu imbriqués, ainsi que de l’analyse et de la gestion des opérations CRUD pour des citations complètes profondément imbriquées.

L’examen complet du code a été effectué manuellement, sans recourir à des outils automatisés. Voyons quelles pistes d’amélioration nous avons trouvées dans chaque module.

Examen de l’architecture

Cette partie comprenait les sections architecture générale, performance, évolutivité, sécurité, configuration et architecture REST.

Dans la section générale, nous vérifions si le code suit le type d’architecture déclaré. Nous nous assurons que la séparation des responsabilités est implémentée et qu’il y a une division en couches de présentation, de logique métier et de données. Nous évaluons également les patrons de conception, une procédure de configuration des instances et les paramètres des entités, entre autres aspects.

Notre examen de l’architecture du projet a révélé plusieurs problèmes critiques concernant l’architecture générale, les performances et la sécurité.

Par exemple, nous avons constaté que les instructions sur la façon de définir les variables d’environnement étaient manquantes et que la sauvegarde de la base de données nécessitait trop de manipulations pour fonctionner. Nous avons également repéré un script personnalisé inutile pour remplir la base de données et un formateur de code principalement utilisé pour les projets JS et qui n’apportait pas grand-chose.

En ce qui concerne les performances, nous avons identifié trois moyens simples de les améliorer en tirant parti de la mise en cache Django, de la mise en cache des requêtes de base de données et d’outils d’accélération Python.

Nous avons également rencontré un problème de sécurité critique lié au stockage de données sensibles dans un dossier accessible publiquement.

Qualité du code

Notre audit de la qualité du code a révélé plusieurs problèmes en termes de lisibilité, de réutilisabilité et de traitement des erreurs.

Nous avons constaté que les noms de classes suivaient rarement la convention CapWords, et que de nombreux fichiers présentaient un ordre d’importation incorrect, ce qui affecte la lisibilité.

Un autre problème était que la modification du type de la valeur affichée dans le sérialiseur était effectuée de manière inefficace : l’attribut était défini au lieu de la méthode `to_representation`.

Il y avait des cas où la logique de création Django était outrepassée sans raison. Nous avons également trouvé des chaînes de caractères au format obsolète et plusieurs autres écarts par rapport au style de codage Django.

En ce qui concerne la réutilisabilité, nous avons remarqué plus de dix fichiers vides. Il serait difficile pour un nouveau développeur sur le projet de comprendre quoi en faire.

De plus, du code était commenté sans aucune indication de la raison. Dans de tels cas, le code devrait être soit supprimé, soit des commentaires supplémentaires devraient être ajoutés expliquant pourquoi le code n’est pas utilisé et s’il sera rétabli si d’autres conditions sont remplies.

En dehors de cela, nous sommes tombés sur une utilisation excessive des mots réservés Python, des fonctions inutilisées et des parties de code qui auraient pu être considérablement raccourcies et simplifiées avec Django-filter et Django REST framework pour la gestion des données paginées.

Enfin, nous avons émis une remarque concernant le traitement des erreurs. Les clauses d’exception étaient trop larges, nous avons donc suggéré de les rendre plus spécifiques autant que possible.

Architecture de la base de données

L’architecture de la base de données était typique et correspondait bien aux besoins du projet. Nous l’avons trouvée suffisamment évolutive et capable de répondre à une demande croissante des utilisateurs. Nos réviseurs de code ont entièrement approuvé cette partie du projet.