What if the codebase is a mess?
I was recently asked: “What if you start a new job and their codebase is a mess?”
We’ve all been there. Here are some of the tactics I’ve used.
I was recently asked: “What if you start a new job and their codebase is a mess?”
We’ve all been there. Here are some of the tactics I’ve used.
I love Django management commands.
For dpaste.com I’ve written several management commands for things that I don’t need a web UI for, like:
expire
- delete expired pastes (invoked by cron)expunge
- manage TOS violations like spamstats
- useful metrics on the current corpus of pastes, and on user activityIn running the site I also use management commands from my django-blocklist app, for tasks like deleting expired entries (via cron) or generating reports.
Python 3.8 (2019) added “assignment expressions”, aka the “walrus operator”.
I generally like things that make Python more expression-oriented, like list comprehensions, but I’m ambivalent about these. It’s pretty easy to impair readability by using them overzealously. Is saving one line of code worth making it harder to notice that an assignment is happening?
However, I’ve found a use case I like a lot. I use them in the Django Python shell when doing exploratory ORM queries.
I’ve replaced my Disqus comment integration with a Mastodon-powered solution. On posts where I’ve enabled comments, you’ll now see a “Load Comments” button and a “Reply” button, both of which talk to the Mastodon API.
Adding commenting to a static site is an interesting puzzle.
I enjoy writing tests because I love what they give me.
I can remember projects with zero test coverage (early in my career, I didn’t even know that was a problem) where implementing and shipping large changes was anxiety-provoking — both during the work, and after deployment. That awful feeling of holding your breath waiting for bugs to manifest.
Welp, I did it, I switched from Sublime Text to Visual Studio Code. Sublime Text was my primary editor for many years, but I’ve moved on!
I can be kind of a stickler about leveraging the ticket/issue tracker in software projects (which always seems to be Jira these days, but nevermind that). I write tickets carefully; I link to related issues; I add comments to note the status of work in progress, or to record info that’s important to the work to be done.