django: how to evaluate a project for refactoring

Question

Has anyone of you done evaluation of a django project and how to improve/refactor it's code base? A pet project in company I work at is becoming more widely used and it would be good to improve its quality before further development. Are there any techniques or methodologies of analyzing django projects before we start putting more and more features into it? We wouldn't like to suddenly realise, that due to earlier poor choice we have to live with something really bad.

Answer 1

What I noticed after working more than a year on a quite large site was mostly this concerning our design/coding. It's not purely refactoring related and probably you already know a lot, but maybe it can help :).

1. Most importantly, we did not always put our code in the right place. There was too many functionality in the view methods, too few in forms and models. I see this problem many times. To handle input, use forms, to format/tweak/... model data, use model methods or properties. Seriously, at one moment I reduced a view of about 150 lines to 20 by just putting code in better places. Improves maintainability and readability very well
2. Many code we wrote actually did not really use the full force of python and/or django. For the first one, reading something like Dive Into Python was a great help, for the second one I just tracked down all complex constructs we built (mostly legacy code from 0.96) and looked if there were alternatives in the django docs. Of course, don't waste your time trying to reduce everything to a one-liner, but certainly with legacy code this can help improve readability and maintainability.
3. Always look on sites like django-snippets, google code, ... if there are decent existing django projects that can take away a lot of your functionality. Often these projects are looked upon by more people and are therefore more stable and performant. If a project doesn't meet all your demands it can even be a good idea of just adding your requirements yourself instead of doing it all custom for your site.
4. Try to keep the application cross-over dependencies minimal. When you would draw a dependency graph (e.g. by linking each app that have foreign keys to each other) it should still be clear and not something where every app is linked to any other app. Typically you'll have some 'helper' apps (e.g. user system, tagging) that are used by many and all other apps are actually only dependent on those apps.
5. Write tests, django has an excellent test suite, so use it. Certainly for parts of code that are common to many apps and are likely to change. Really, nothing so annoying as suddenly noticing a bug you actually solved 4 months ago and you have no clue which update since then broke it again.
6. Take a second look at database normalization, the django orm model is still tightly coupled to relational databases and so it's an important concept, certainly when you work with models that are likely to be expanded later on.

Concerning real refactoring, the only important tool I can think of is South, can help you a lot if your database scheme changes. Otherwise, like a hint I already gave: write tests to make sure your functionality before and after refactoring remains the same.

Answer 2

You can learn about code smells. Some folks say that if your code smells it means you need to consider refactoring.

This is very wide subject in fact. Remeber that:

Premature optimization is the root of all evil -- DonaldKnuth

I personally think that this is also valid for (premature) refactoring.

EDIT: this is also a good resource about code smells: http://www.codinghorror.com/blog/2006/05/code-smells.html