Things I Used To Do (That Aren’t Cool Now)

I’m the proud owner of WhichBeach – the website that tells you which beach is best to visit (in Malta) based on the weather, updated hourly.

As I’m picking up the codebase ahead of this Summer’s updates, I can’t help but review and refactor the existing code. It’s interesting to dissect previous design decisions. Also, I’ve learnt so much in the last year that it’s only natural for me to want to bring the standard of an older project up a bit.

Here’s a list of things that I used to do, that aren’t cool now.

I used to not have a coding style guide

I was blissfully unaware that coding style guides even existed! Sure – I had my own patterns that I tried to stick to, but they weren’t enforced.

The solution to this one is easy – I’ve already converted the codebase to PSR-2 – though it was somewhat of a manual process of opening each file and running the PHP Coding Standards Fixer. I’m sure there’s a quicker way through the terminal that I’m not aware of – perhaps someone can enlighten me in the comments.

Edit:

Julio pointed out in the comments that the command to convert your files to PSR-2 is the following:

php-cs-fixer fix --level=psr2 path-to-your-files/

Thanks Julio!

I used to group my files by layer

I organised my code into top level folders like:

• Handlers
• Helpers
• Interfaces
• Listeners
• Observers
• Queues

I’m sure it felt like I was being organised while I was doing it, but it turned out to be highly impractical: you can’t glance at a folder (say “Beaches”) and get an overview of all that business logic that is associated to Beaches – the logic is scattered across different parts of the system.

Also, looking inside these Layer folders, you find code that is quite unrelated to each other, and unlikely to be used together.

I’ve recently been experimenting with Vue and Vueify – the approach taken there is that since the Javascript and Html work so closely together… put them in the same file!

A more general rule might be: Code that works together should be kept together.

The solution to this problem is to carefully refactor and reorganise my code structure.

I used to code without automated tests

I’m scared to change any of the core logic of this project! Sometimes I have to pull in live data to see how the system reacts! I can’t test drive anything!

These are all fears that I used to live without, but haunt me today. A slight exaggeration – yes, but legitimate concerns when moving forward with the project.

The solution is in the works. I’ve set up a testing environment with an in memory database, and have started adding tests to existing functionality. I’m refactoring along the way using the Test Driven approach.

My predicament? Should I first add as many tests as possible to the existing codebase, and then refactor? Or should I refactor as I write the tests, so that the first time the test is written, it changes the code to be inline with my new rules of development? I’m leaning towards the second option, but I have my doubts.

I used to do a lot of image manipulation myself

This stuff is hard. Yes, I used available packages that handled the image manipulations, but I still had to handle a lot of the logic myself.

At the moment, the payoff isn’t worth the work and maintenance. My solution is to get rid of most of my Image related logic, and instead use Spatie’s wonderful Media Library Package. I use it for a number of other projects and it fits the bill perfectly.

I used to have self validating models

A couple of years ago, this seemed to be the thing to do – but I’ve been bitten by this approach a couple of times.

Using Laravel’s Form Request Validation is a good way to get some code out of my Models (the validation rules) and Controllers (the validation logic).

I used to have an administration area

This isn’t a “bad decision” per se – but it doesn’t align with my plans for the future – which is to be a user powered app where logged in users are enabled to do things like add new beaches, comments and reviews.

The solution? Rip out all the administration area! (Yikes!) Then, slowly test drive the front-end driven way to get data into the website from logged in users. I’ll still need to have an authorization system where some content is only editable by administrators – but the idea is to have a lot of user driven content.

Let me know in the comments if you’ve had experience with this before!

---

The above is a rough game plan for the future of WhichBeach, and a reminder that as developers we’re always evolving!

Time to get to work.