| published by | Software Crafts |
|---|---|
| in blog | Software Crafts |
| original entry | Refactoring a Django project |
Most of my Django career has been brownfield projects, I have walked into code written by others and they are often no longer around, so I am left to make the most of the code presented as is.
My first step is to sort out a local docker compose setup, either using something present in the repo or creating one. This includes using minio for S3 like storage if required, mkcert for SSL & HTTPS locally.
Next I take time to manually map out the dependencies between Django apps (if any exist). I view Django apps as logical sections of the project and so there ought to be strict dependencies between them. I also include database relationships in this map making. This is a combination of tools (pyreverse, graph_models, impluse-cli) and some manual work to get it all together.
Typically this highlights some work to remove a circular dependency or some logical issue. I can then create tickets for these to be addressed in order so eventually the project is a single acyclical directed graph. I find the graph easy to modify in a dot file which allows me to comment out edges to see what the effect would be on the project, essentially experimenting with the logical project layout. I will then ticket up what needs to happen to make the dependencies work as expected.
Finally if there is a single app, then this would be done on a 'smaller' scale with python modules and not apps or I would be inspecting models to understand the structure of the project and would start by moving relevant views, forms, templates & urls into different apps, before finally moving models around once the app structure has worked itself out.
There is more write, but that's enough of a summary for today.