Categories
Tech Posts

Refactoring Bad Design

Most of my development goes towards the academic management system I designed and built, ADAM. This has been ongoing for more than 15 years, having started when I was younger and much more naïve about programming than I am today. I graduated with a computer science degree but it is apparent that an appreciation for “Big O notation”, “linked lists” and balancing “red-black trees” really didn’t prepare me for managing the codebase of what has become a rather complex piece of software.

Recently, I’ve been experimenting with the Laravel framework which, thanks to some forward thinking design work, is part of a drive to revitalise PHP – which only five years ago could have been considered an old and tired language, but which today is being revitalised to contain everything one might need in a modern programming language.

Laravel is built around the core principle that every “thing” in Laravel has an end point, and you interact with those endpoints in standard ways (using the HTTP verbs “get”, “post”, “put”, and “delete”). If you want to get a pupil’s information, you send a “GET” request to that pupil’s endpoint (“pupil/123”). Relying on the HTTP verbs is a great way to standardise things and really forces you to divide your work up into smaller components.

Another thing that I appreciate about Laravel is the “stack” on which it is built: every request passes through the stack and so being consistent with things like permissions and security is made that much easier.

And, of course, there is the final separation of responsibilities in Laravel (along the Model-View-Controller lines), although there is some debate about how effectively this is done with there being some opinion about too much control resting with the view.

ADAM is complex software with a complex problem domain. We are not just getting pupil information and updating it: there is a significant amount of related and linked information which, to be a powerful system, all needs to be available to the users in a variety of formats for both subsequent data collection and analysis.

The thought has crossed my mind that ADAM would be better off with a rewrite from the ground up but the sheer scale of this task would see it taking many years and to be of reasonably little value.

As I’ve become more familiar with the overarching patterns in Laravel, I’ve become importing those techniques into ADAM. Most notably is the breaking up of some very complex code into more manageable bites and keeping each part of the code to manage only the bits that relate directly to the entity in question.

Most of the code overhead has been abstracted away into a single bootstrapping function and this takes care of much of the standard operations that ADAM requires to have performed on each page load.

As always, given the expanse of the code, this is something that is underway but which will take some time yet to complete.

And, because of the evolving language, the goalposts are not stable, but at least by building with better and more widely recognised techniques, it should make the codebase easier to manage as we move forward.