DEV Community

Cover image for Laravel: Refactoring Code
Jonathon Ringeisen
Jonathon Ringeisen

Posted on

Laravel: Refactoring Code

If you've ever worked on a large codebase you'll understand why refactoring code is important. When I first built my Saas business my workflow went something like this:

1. I have a feature idea.
2. Build the feature idea.
3. Move on to the next idea.
Enter fullscreen mode Exit fullscreen mode

The codebase soon became really messy and was tough to maintain. This was when I realized that I needed to create a more maintainable workflow for the long run.

Here is how my workflow currently is:

1. I have a feature idea.
2. Come up with a plan on how to build this feature.
3. Began implementing the feature.
4. At the end of the day spend an hour or two going back and refactoring the code that I wrote for the day.
5. Write tests.
Enter fullscreen mode Exit fullscreen mode

I am constantly going back and refactoring my code, not sure if it's an OCD thing, but I feel as if it can always be improved upon. Lets jump into an example.

Below is a scope that I use to get the current year of a query.

public function scopeCurrentYear($query)
{
    $business_details = request()->user()->businessDetails()->first();

    if (is_null($business_details->start_tax_date)) {
        return $query->whereYear('date_income_received', Carbon::now()->timezone(request()->user()->timezone)->year);
    } else {
        return $query->whereBetween(
            'date_income_received',
            [
                $business_details->start_tax_date,
                $business_details->end_tax_date
            ]
        );
    }
}
Enter fullscreen mode Exit fullscreen mode

Here is the refactored version. It's not huge changes, but lots of small changes can make a big impact when it comes to readability of your code.

/* 
* Scope that returns query based off current year or 
* based on tax dates.
*
*/
public function scopeCurrentYear($query)
{
    $business_details = request()->user()->businessDetails;

    if (is_null($business_details->start_tax_date)) {
        return $query->whereYear(
            'date_income_received', 
            Carbon::now()->timezone(request()->user()->timezone
        )->year);
    }

    return $query->whereBetween('date_income_received', [
        $business_details->start_tax_date,
        $business_details->end_tax_date
    ]);
}
Enter fullscreen mode Exit fullscreen mode

You'll see that I didn't actually change the way the function performs a task, I simply refactored it to be more easily readable. Let's break it down.

You'll see that I added a block comment that gives a description of what is trying to be accomplished with this scope.

Then, we eliminated the if-else statement and now we do an if check and return the query if it passes, if not we return a different query. A majority of the time an if-else statement can be refactored to be more easily readable.

Then, inside the if check we broke down the whereYear method onto separate lines so that the line wasn't so long.

And lastly, I refactored the whereBetween method to be more readable.

As developers, we spend most of our time reading code. This is why refactoring code and ensuring that it's easily readable is SUPER important. If code is hard to read and understand it makes our lives more difficult.

How would you refactor this snippet of code differently? I'd like to hear some of your feedback!

Top comments (2)

Collapse
 
l3lackheart profile image
l3lackheart
  1. I have a feature idea.
  2. Come up with a plan on how to build this feature.
  3. Began implementing the feature.
  4. At the end of the day spend an hour or two going back and refactoring the code that I wrote for the day.
  5. Write tests.

how about writing test before starting code? so you wont mess up your feature after refactoring the code.

1. I have a feature idea.
2. Come up with a plan on how to build this feature.
3. Write tests.
4. Began implementing the feature.
5. At the end of the day spend an hour or two going back and refactoring the code that I wrote for the day.
Enter fullscreen mode Exit fullscreen mode
Collapse
 
jringeisen profile image
Jonathon Ringeisen

TDD has been something I've been trying to adapt to but I've been having a hard time getting into the habit of it. But yes, you are right I should be writing the tests first. This is something I'll continue to work on and try to build into a habit.