One of my current projects at work involves adding new functionality to my oldest web tool. I inherited this Django-powered project way back in 2015 (the tool was in its infancy at the time), and have been the sole designer and developer for the project ever since. It's been pretty rock solid, humming along for the past few years without any major modifications or issues. However, this recently has changed, as management wants to track the tool's data using a new dimension that we weren't considering previously.

These new features require adjustments to the database schema, which means that corresponding front-end changes, for both data entry and reporting, are also needed. The end result is that a lot of code needs to be updated. Digging through this ancient code has been both embarrassing and humbling.

When I inherited this project, I didn't know Python. By extension, I knew nothing about Django, which was still in its relatively early days (Django 1.8 was the latest at the time). I had plenty of web-design and programming experience, which made learning both much easier, but I made a ton of mistakes with both the architecture and implementation of the application. I'm now regretting those mistakes.

One of the most egregious errors in this application, and something I honestly still struggle with to a degree, is writing monolithic methods. Some of the view methods in this tool are many hundreds of lines long. Amidst these lines are dozens of calls to various "helper" functions, many of which are equally as complex and lengthy. It has made figuring out what I was doing painful, to say the least.

I'm trying to remedy this situation by creating stand-alone classes to act as logic processors. The resulting class is easier to read, even if the length of code is nearly the same. So, a sample view using this methodology might look something like this:

class MyView(View):
    def get(self, request):
        vp = MyViewProcessor(request)
        response = vp.process()
        return JsonResponse(response)

The corresponding processor class would then look as follows:

class MyViewProcessor:
    def __init__(self, request):
        self.request = request
        # Other initialization goes here

    def process(self):
        self.load_user_filters()
        self.load_data()
        self.transform_data()
        return self.build_response()

Each of the calls in the process() method are to other methods (not shown) that handle tasks like processing incoming data (from a front-end form), loading data from the database using those filters, etc. This construct, while not perfect, at least makes the code more readable by breaking the work into discrete units.