Project Science

Desafío

Complete Network desarrolló Project Science, un software que simplifica la estandarización, categorización y gestión de datos de presupuestos en el sector de TI. Se trataba de una versión beta y, puesto que estaban remodelando su código frontend, decidieron hacer también una auditoría del backend.

Querían una mirada fresca, imparcial y profesional a su backend escrito en Python. Complete Network buscaba a alguien con una larga experiencia en el desarrollo en Python y un servicio completo de revisión de código. Redwerk cumplía estos criterios a la perfección.

Se nos encargó revisar los siguientes aspectos:

1. Arquitectura. Aquí debíamos inspeccionar cómo se había construido el núcleo, qué módulos se habían incluido y si se habían utilizado los principios y patrones arquitectónicos adecuados.
2. Calidad del código. Esta parte de la revisión pretendía determinar si el código era legible, reutilizable y fiable. También examinamos aspectos como la gestión de errores, las bibliotecas de terceros y la extensibilidad del código.
3. Revisión de la base de datos. Esta era necesaria para garantizar que la estructura de la base de datos se correspondía con los requisitos del proyecto y era bastante fácil de escalar.

Nuestras revisiones de código clasifican los problemas encontrados por gravedad e incluyen sugerencias para solucionarlos. También mencionamos el número de horas necesarias para refactorizar el código.

Solución

La base de código revisada era una API de backend responsable de operaciones CRUD (Crear, Leer, Actualizar, Borrar) generales en modelos individuales o poco anidados y de analizar y gestionar operaciones CRUD para presupuestos completos profundamente anidados.

Toda la revisión del código se realizó manualmente sin depender de herramientas automatizadas. Veamos qué áreas de mejora encontramos en cada módulo.

Revisión de la arquitectura

Esta parte incluye las secciones de arquitectura general, rendimiento, escalabilidad, seguridad, configuración y REST.

En la sección general, comprobamos si el código sigue el tipo de arquitectura declarada. Verificamos si se implementa la separación de preocupaciones y si hay una división en capas de presentación, negocio y datos. También evaluamos los patrones de diseño, el procedimiento de configuración de instancias y la configuración de entidades, entre otros aspectos.

Nuestra revisión de la arquitectura del proyecto reveló varios problemas críticos relacionados con la arquitectura general, el rendimiento y la seguridad.

Por ejemplo, descubrimos que faltaban instrucciones sobre cómo definir variables de entorno y que la copia de seguridad de la base de datos requería demasiadas manipulaciones para que funcionara. También detectamos un script personalizado innecesario para rellenar la base de datos y un formateador de código que se utilizaba sobre todo para proyectos JS y que en realidad no hacía gran cosa.

En cuanto al rendimiento, identificamos tres formas sencillas de aumentarlo aprovechando la caché de Django, la caché de consultas a la base de datos y las herramientas de aceleración de Python.

También encontramos un problema de seguridad crítico asociado con el almacenamiento de datos sensibles en una carpeta de acceso público.

Código Calidad

Nuestra auditoría de la calidad del código reveló varios problemas de legibilidad, reutilización y tratamiento de errores.

Vimos que los nombres de las clases rara vez seguían la convención CapWords, y muchos archivos tenían un orden de importación incorrecto, lo que afecta a la legibilidad.

Otro problema era que cambiar el tipo del valor mostrado en el serializador se hacía de forma ineficiente – estableciendo el atributo en lugar del método to_representation.

Había casos en los que la lógica de creación de Django se anulaba sin motivo. También encontramos un formato anticuado de las cadenas y varias otras desviaciones del estilo de codificación de Django.

En cuanto a la reutilización, observamos más de diez archivos vacíos. Sería difícil para un nuevo desarrollador en el proyecto entender qué hacer con ellos.

Además, parte del código estaba comentado sin información de por qué era así. En estos casos, el código debe eliminarse o deben añadirse comentarios adicionales que expliquen por qué no se utiliza y si se restablecerá si se cumplen otras condiciones.

Además de eso, nos topamos con el uso excesivo de palabras reservadas de Python, funciones no utilizadas y partes de código que podrían acortarse y simplificarse enormemente con Django-filter y Django REST framework para la gestión de datos paginados.

Por último, dejamos una observación relativa al procesamiento de errores. Las cláusulas de excepción eran demasiado amplias, por lo que sugerimos hacerlas más específicas siempre que fuera posible.

Arquitectura de bases de datos

La arquitectura de la base de datos era típica y se ajustaba bien a las necesidades del proyecto. Nos pareció suficientemente escalable y capaz de satisfacer una demanda creciente de los usuarios. Nuestros revisores de código aprobaron plenamente esta parte del proyecto.