How to prepare a django project for future changes

Question

As I work on my first django powered site, I am constantly learning new things and making all sorts of changes and additions to my apps as I go. I try to follow DRY and pythonic principles and be smart in my coding but eventually I will have to take the site live and am certain that not long after I do, something new and exiting will come down the pipe and I will want to implement it.

Preparing for the future:

With this in mind, do folks have any suggestions about how I can prepare my code now to be as future-ready as possible for these currently unforseen/unknown upgrades/additions to my code base?

Hindsight is 20/20:

What do you wish you had done at the start that would have made your life easier now that your site is up and running ?

Little Things I've Learned (examples):

• use UTC as the default timezone (and use datetime.datetime.utcnow())
• use South to aid future database changes (haven't done it yet, but it seems wise)
• not hard code links in my templates (use get_absolute_url() and reverse lookups)
• create a separate tools app to contain small re-usable templatetags and utility functions that I may want to use in future projects (no need to decouple them later)

These are small tips, and some straight from the django-docs, but I think they help .

How about you? What are your best practices for a new app or project that prepare you for the future?

Answer 1

Not sure how relevant this is outside of the wonderful world of Webfaction.

Use Django checked out from Django's svn repository, rather than whatever your host installed for you when creating a Django app, so you can update Django to get security fixes by running svn up.

I had to do this a few days ago, and whilst it wasn't too painful (remove the Django installation, then run an SVN checkout, then restart Apache), doing it for all my various projects was a bit irritating - would have been much happier to just run svn up.

Answer 2

"something will come up and I'll wish I had implemented it earlier"

That's the definition of a good site. One that evolves and changes.

"future-ready as possible ?"

What can this possibly mean? What specific things are you worried about? Technology is always changing. A good site is always evolving. What do you want to prevent? Do you want to prevent technical change? Do you want to prevent your site from evolving?

There will always be change. It will always be devastating to previous technology choices you made.

You cannot prevent, stop or even reduce the impact of change except by refusing to participate in new technology.

Answer 3

• Deploy into a pure environment using virtualenv.
• Document requirements using a pip requirements file.

I'm sure others will suggest their deployment strategies, but making these changes were big positives for me.

Answer 4

Learn and use South at the outset, so when you make major DB schema changes, you'll have a migration tool already in place. Otherwise, you'll find you end up running two versions side by side while trying to figure out how to port the data, and it gets very VERY messy.

http://south.aeracode.org/

Answer 5

Listen to James Bennett: Read Practical Django Projects, follow http://b-list.org/. Search youtube for his djangocon talk on reusable apps. Read his code (on bitbucket).

An example of advice I've gotten from him: Dependency injection on your views will make your apps much more reusable. A concrete example—refactor this situation-specific view:

def user_login_view(request):
    context = {
        'login_form': forms.LoginForm
    }
    return render_to_response('accounts/login.html', context)

with this generic view:

def user_login_view(request, form=models.LoginForm, template_name='accounts/login.html'):
    context = {
        'login_form': form,
    }
    return render_to_response(template_name, context)

Better still, give your view a generic name like "form_view", rename your form 'form' instead of 'login_form', and pass in your parameters explicity. But those changes alter the functionality, and so aren't a pure refactoring. Once you've refactored, then you can start incrementally changing other things.