Welcome @RJ-Gamer !
This is an interesting project, potentially useful.
However, I do hope you realize that a number of things that you consider to be “problems” are actually considered strengths in Django by many-to-a-majority of people using Django.
Specifically:
- Fat models
- Single-app structure
- No service layer
You can find many discussions here and other places identifying these features as desireable.
Note - by “single-app structure”, I’m also assuming that you’re limiting yourself to apps contained within the main directory structure of the project, which ignores the recognition of independently-installed apps. (e.g. See Advanced tutorial: How to write reusable apps | Django documentation | Django)
But I can see where this creates an issue. If you include independently-installed apps, then you would need to evaluate packages like the admin, drf, ddt, etc. But if you don’t include those apps, then you may end up flagging projects that are built around independently-installed modules. (In this context, independently-installed does not necessarily mean “third-party”.)
It’s also not clear what files are being counted
Beyond that, I would consider it more useful to flag apps that are too segregated. I would want to look for “cross-app model references” - those tend to be a bigger danger. (If you’ve got two apps that are making regular refereces to each-other’s models, that’s probably a good sign that they should be one app.)
I did try running this against my current pet-project.
It identified 4 fat models - that’s a good thing, and a desired structure for this project.
It identified 3 god apps - That’s actually a good thing, as the base app is relatively small, and the 3 apps integrated by the base app are all about the same size. But, if I ran your check against the “installable” version, where those three apps are separate modules, I’m sure I would then get the “god app” warning on that main app. (Yes, there are two other tiny apps in the project, so there are always going to be three apps in the project.)
It identified 6 methods in views for “missing service layer” due to the size of the view - in most of those cases, the number of lines in the view is inflated because of how I structure my code when defining a context to be rendered. (Each key in the context is on a separate line, so if my view is pulling together 10 different values for the context, that’s going to be at least 10 lines in the view. That’s above any other work being done by the view.)
Your N+1 test is looking for get, which is a very common function to use when retrieving items from a dict. I got a lot of warnings about that for functions that never use the ORM at all - they’re processing dicts.
Aside from the issues above, the architectural issues I see most frequently are:
- ModelAdmin classes too big. (This is generally an indicator that the person is trying to do too much in the admin instead of creating their own views.)
- Models and views broken down into individual files. (Having a
model directory with one-model-per-file within it, or a views directory with one view per file.)
- Django-provided GCBVs being extended beyond their optimal usage. (e.g. Handling multiple different forms by one edit view.)
- Many small inter-related apps that can’t be used independently.
- The needless creation of a service layer adding a level of indirection that doesn’t facilitate understanding of the flow.
(Granted, some of these are subjective and may be difficult to define tests.)
