Crow's nest of SMS Derfflinger
Image via Wikipedia

When I started coding for our latest project at Preona a bit of an epiphany happened. I suddenly got django. Every pattern that used to feel a bit strange and I may have fought a little, suddenly became obvious and simple. Suddenly out of the blue my whole codebase is so marvelously organised and separated into files it brings a tear to my eye.

In the old days the average Django App in my project had a structure a file structure a bit like so:

  • models.py
  • views.py
  • tests.py
  • RandomActualWorkLogic.py
  • AnotherRandomOfWork.py

Sure this works quite alright, but it feels a little weird and after way too much work you suddenly realise that instead of the clean design you envisioned as you started out, you’re left with a crow’s nest of interdependancy, circular crappery and your project is in pretty miserable shape.

This point was really driven home when I figured two different django projects should share some code. Extrapolating a clean interface and making stuff work … was a nightmare. I actually gave up after a week and decided to start afresh.

And boy, was that the best decision ever!

Better application structure

The first step was to take up a better way to organise my codebase inside applications. It goes something like this:

  • models.py
  • managers.py
  • views.py
  • tests.py
  • forms.py
  • decorators.py
  • processing.py — (this is for certain special views)
  • urls.py
  • settings.py

The first result of this organisation is that now everything has its own place. There are no StrangeWorker.py crappy things anymore. All of those reside in a special ‘application’ just for those called a lib. Whenever you are making something and are looking for a place to put it -> the file is an obvious pick!

Another great result is that it’s now much easier to keep applications contained within themselves. Because both its specific url config and its specific settings config are contained within the application you can easily switch it around between projects or even make it a standalone thingy that projects can simply include.

Also because the file structure makes sense now and all those WeirdoWorker.py are separated elsewhere as proper libraries, there is less of a temptation to create mixed and confusing dependancies all over the place.

Conclusion

That’s it for django application structure. If you’ve got any better ideas do mention them on twitter or via the comments below. If not, that’s alright 😛

Either way, join me in the next installment of Django Protip when I’ll be talking about using “Forms, forms for everything”

Enhanced by Zemanta

Learned something new? Want to improve your skills?

Join over 10,000 engineers just like you already improving their skills!

Here's how it works 👇

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet 📖right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

PS: You should also follow me on twitter 👉 here.
It's where I go to shoot the shit about programming.