Author: DeanBlackborough

Posted on

Laravel 10 – Updating my projects

Image showing two notifications on a phone saying "You have new software updates"

I have numerous projects which are built utilising the Laravel Framework. Each time there is a new major release, you need to ask yourself the same question; how long until I update my project? There are two follow-on questions; in what order should I upgrade? And is it worth upgrading this one?

I try to ensure all my projects get updated to the latest version of Laravel. However, I am not one of those eager users who updates their Apps and website on release day. When it comes to updates, I am conservative with my own projects. It is typically worth waiting for at least some minor releases which catch the inevitable bugs.

Most of the time, the order that I update is simple. The Apps which are in active development and any which could or will benefit from any of the new features go first.

Laravel 10 is different

Laravel 10 is a different release. The major benefit is not the new features, and it isn’t immediately obvious. The major benefit will come with time, all the user land code is now strictly typed.

Unlike previous Laravel releases, for Laravel 10 you should not simply update your composer file and run update. To benefit from the changes in Laravel 10, you need to update all your user land code to be strictly typed. If you simply run composer update you are not benefiting from the new typing. You need to ensure your user land code is strict.

There are services and tools that can help you with upgrading your projects, the obvious one being Laravel Shift. Though if you have several projects, this can get expensive quickly. In addition to the financial costs and time cost, you need to consider whether a project will have any future development. Is the project a personal passion project that is likely to just fizzle out?

Updates have begun

To date, two of my projects are using Laravel 10. I upgraded one with Shift and a little TLC, the other I upgraded manually. At release time, Budget Pro was still in the preliminary stages of development. It had minimal user land code which I needed to type.

With my other umpteen active projects, their time will come. The two most urgent are my API and a large client App for a customer. The updates for these projects are going to be complicated tasks that I will manage manually. I don’t want to hand over the job to Shift because as much as I like Laravel Shift, these projects are too critical. I expect I will start the update when I want to use a new feature introduced in Laravel 10 or a later point release.

Being a solo developer, it can be hard to justify the time. Any time that I dedicate to updating and validating is time I could be using to refactor, add new features, marketing, or anything else.

Posted on

Code duplication, refactor?

The words repetition repeated three times in a notebook. The book is on a wooden table next to a pen and a coffee

Code duplication or DRY (Don’t repeat yourself) is a core principle of software development. The principle itself is solid, duplicated code can and will become a problem. If you have a bug in a piece of code that ends up being duplicated n times you now have n+1 bugs. If you adjusted or tweaked the functionality of duplicated code, same issue, you need to make the same change n more times.

We should try to remove code duplication, which is a given, the question is when?

As with everything, there isn’t one answer, it very much depends on circumstance. For the purposes of this blog post, I’m going to focus on web development. Much of what I mention will apply regardless of the context.

Duplication in views

I’ll start with the easiest one to answer, duplicated code in your views. Views are typically the simplest part of your App. When you have duplicated a section of code more than two or three times, go for it. Create a view component, fragment or whatever your tool supports to remove the duplication.

It is less likely that your view code will fundamentally change, removing the duplication early makes sense. As your experience grows, you’ll end up removing any duplication before it occurs. This makes sense for simple view code that you will most certainly use multiple times.

Controllers

With controllers it depends on what code is duplicated. Is it flow code or is it Business code that should really be somewhere else and shouldn’t live in your controllers.

You should remove duplicated flow code but you shouldn’t make it your priority. Business code deduplication is your priority, it is the code which makes your App do something useful and interesting.

When you are confident you can remove some duplication, go for it, this could be Request handling code, code to prepare the view, whatever lives in your controllers. A good tip, open two controllers’ side by side and look at the code to see the repetition. You will be surprised at how much code you have duplicated and as a consequence, how much you can remove.

Business logic

Duplication in your “Business” logic is a problem. Duplication at this level will eventually hurt you as you will end up with inconsistent behaviour. This is the code which makes your App special, this is the code that you need to work. Problems here undermine your App and annoy your customers.

Regardless, it is still not as simple as “remove the duplication after n cases”. Your business logic is the most complex part of your App, this is the code you are most likely to tweak and adjust.

Before you remove any duplication you need to be certain the code solves your problem. There are going to be bugs and issues with your implementation, especially if it is new code. I would advise waiting a little while. Wait for the inevitable bug fixes or the feature tweaks, make sure the code works first.

We very rarely solve a problem correctly the first time, code inevitably gets rewritten. When you rewrite or refactor the code, remove the duplication then. You will have much more knowledge about the domain, and it won’t be surprising if you solve the problem in a completely different way to the original code.

Don’t worry

When you are beginning your career, don’t worry about code duplication. If a team member or a PR comment asks you to remove the duplication, obviously go for it. As you gain experience, you’ll know when you need to worry about DRY and when you don’t. Your only concern should be gaining experience and solving problems. Don’t worry about writing ‘perfect’ code, no one does.