My Django Application Refresh: The Joys of Deleting Code

I've been refurbishing an older project -- written in 2008.  Probably with Django 1.0.1.  Certainly with Python 2.5.

The Django 1.3 release has been around since March.  The change underscored the importance of technology refresh.

The best part was to delete code.  There were two significant reasons.

• The testserver command allowed me to eliminate a bunch of low-value test harness.   Without this command, we had to create our own test database, start a server, run integration tests, and then kill the server.  With this command, we simply start and kill the server.
• The RESTful web services can be securely integrated into the main web application.  A simple piece of middleware can authenticate requests based on headers containing ForgeRock OpenAM tokens.  It may be that this was always a feature of Django, but over the last few years, we've figured out how to exploit it with simple middleware.

 

Few things are better than removing old code and replacing it with code written (and tested) by someone else.

In  addition to the deletes, we also rearranged some of the dependencies.  We had (incorrectly) thought of the Django project as somehow central or essential.  It turns out that a bunch of other Python libraries were actually core to the application.  The Django web presentation was just one of the sensible use cases.  A suite of command-line apps could also be built around the underlying libraries.

In addition to this cleanup, we also replaced the documentation with a new Sphinx project.  The project originally used Epydoc markup.  This meant that every single docstring had to be rewritten to use RST markup.  The upside of this is that we corrected numerous errors.

There Was Pain

This wasn't without some pain.
Was the cost worth the effort?  That's the real question here.