Project Science

Challenge

Complete Network developed Project Science – software that simplifies standardizing, categorizing, and managing quoting data in the IT industry. It was a beta, and since they were remodeling their frontend codebase, they also decided to do a backend audit.

They wanted a fresh, unbiased, and professional look at their backend written in Python. Complete Network looked for someone with long-standing expertise in Python development and a comprehensive code review service. Redwerk matched those criteria perfectly.

We were tasked to review the following aspects:

1. Architecture. Here, we were to inspect how the core was constructed, what modules were included, and if appropriate architectural principles and patterns were used.
2. Code Quality. This part of the review was meant to determine if the code was readable, reusable, and reliable. We also examine things like error handling, third-party libraries, and code extensibility.
3. Database Review. This one was necessary to ensure the database structure corresponded to the project requirements and was fairly easy to scale.

Our code reviews categorize the found issues by severity and include suggestions for fixing them. We also mention the number of hours needed to refactor the code.

Solution

The codebase under review was a backend API responsible for general CRUD (Create, Read, Update, Delete) operations on individual or shallowly nested models and parsing out and handling CRUD operations for deeply nested full quotes.

The entire code review was done manually without reliance on automated tools. Let’s see what areas for improvement we found in each module.

Architecture Review

This part included the general, performance, scalability, security, settings, and REST architecture sections.

In the general section, we check if the code follows the declared architecture type. We verify if separation of concerns is implemented and if there’s a split into presentation, business, and data layers. We also evaluate design patterns, a setup procedure for instances, and entity settings, among other aspects.

Our review of the project’s architecture revealed several critical issues regarding the general architecture, performance, and security.

For example, we found that instructions on how to define environment variables were missing and the database backup required too many manipulations to make it work. We also spotted an unnecessary custom script to fill in the database and a code formatter that was mostly used for JS projects and didn’t really do much.

As for performance, we identified three simple ways to increase it by leveraging Django caching, database query caching, and Python speed-up tools.

We also encountered one critical security issue associated with storing sensitive data in a publicly available folder.

Code Quality

Our code quality audit revealed several issues in terms of readability, reusability, and error processing.

We saw that class names rarely followed the CapWords convention, and many files had incorrect import order, which impacts readability.

Another issue was that changing the type of the shown value in the serializer was done inefficiently – setting the attribute instead of the to_representation method.

There were instances where the Django creation logic was overridden for no reason. We also found outdated formatting of strings and several other deviations from the Django coding style.

As far as reusability is concerned, we noticed ten-plus empty files. It would be difficult for a new developer on the project to understand what to do with them.

Also, some code was commented out without information on why that was so. In such cases, the code should be either removed or additional comments must be added explaining why the code isn’t used and whether it will be restored if some other conditions are met.

Besides that, we stumbled upon the overuse of Python reserved words, unused functions, and parts of code that could be vastly shortened and simplified with Django-filter and Django REST framework for managing paginated data.

Lastly, we left a remark regarding error processing. The exception clauses were too broad, so we suggested making them more specific whenever possible.

Database Architecture

The database architecture was typical and matched the project’s needs well. We found it scalable enough and capable to meet an increasing user demand. Our code reviewers fully approved this part of the project.