Refactor Your PHP legacy Code (real projects examples)
Good developers are defined by the quality of their codes. In the software industry, writing good code means saving the money that may be invested in testing, updating, extending or fixing bugs. In this article, I will show you real-life examples of some techniques and ideas that will help you to clean up your legacy code and refactor it to make it more robust and modular. These techniques will not only help you to refactor your old code but will give you great ideas as to how to write clean code from now on.
What Is refactoring and why do we need It?
Refactoring refers to techniques and steps that help you to write clean code. This is important for other developers, who then will be able to read, extend and reuse the code without the need to edit much.
The next lines will show you some examples of refactoring a legacy code and make it better.
Never refactor a production code that does not have unit tests
My first advice is to not ever start refactoring a legacy code, which does not have proper unit tests. I guess the reason is obvious: You will end up with broken functionalities that are difficult to fix because you won’t be able to figure what’s broken. Therefore, if you need to refactor it, start with testing it first. Make sure the part you are going to refactor is covered by the tests. Check PHPUnit code coverage analysis.
Start refactoring from the deepest point of your code
Take a look at the next picture. This is a real project for a hotel management system that I found on Github. This is a real open source project so the closed source can be worst.
As you can see in this method, there are three levels marked in red. The deepest point should be the nested if/else statement inside the first if condition. Usually, the deepest point is focusing on a single logic which makes it easier to refactor.
Make your methods shorter by dividing them into smaller methods or configuration files/DB table
Maybe, in this case, we can extract it to a private method as following:
The next deepest point will be fetching the post data and loading the views. Now, take a look at the method add() after refactoring the other parts. It is much cleaner, readable and testable.
Always use {} within if-statements
Most of the programming languages support one line if-statements and some developers use it because it is simple, however, it is not readable and it’s easy to cause problems since only one empty line can break the condition and start crashing. See the difference between the two examples:
Do not use magic numbers or magic strings:
In the next example, you notice if rooms are more than 250, it returns an error message. In this case, 250 is considered as a magic number. If you’re not the developer who wrote it, it will be hard to figure out what it represents.
In order to refactor this method, we can figure out that 250 is the maximum number of rooms. Therefore, instead of hardcoding it, we can extract it to variable $maxAvailableRooms. Now, it is more understandable to other developers.
Do not use else-statements if you do not need to:
In the same function availablerooms() you notice the if-statement, in which we can easily get rid of the else part and the logic will still be the same.
Use meaningful names for your methods, variables and tests
In the following example, you can see that there are two methods from the hotel management system called “index() and room_m()”. For me, I cannot determine what their purposes are. I think it would be easier to understand if their names were descriptive.
Use the maximum capabilities of your programing language
Many developers do not use the full capabilities of the programming language they use. Many of these features can save you a lot of effort and make your code more robust. Take a look at the next examples and notice how it can be easy to achieve the same result with less code by just using the type hinting.
I would like to end with a few more quick tips on better coding:
- Use a new array form [ ] instead of the old one array().
- Use === operator instead of == unless it is important to not check for the dataType.
- It is always a good idea to give public methods short descriptive names. It is ok for private methods to have longer names as they have a limited scope.
- Only use general names with methods that implement interfaces example add() and use descriptive names for single classes methods addUser() or addDocument().
- Remove unused methods from your classes.
- Use prefix is/has with functions that return boolean ex: isAdmin($user), hasPermission($user).
- Always use access modifiers in class methods and properties.
- Be careful with interface pollution: Only use methods that users can use publicly.
- Organize classes methods where public methods are on the top.
- Always apply the single responsibility concept to your classes.
More to Read:
- Software Architecture — The Difference Between Architecture and Design
- Software Architecture: Architect Your Application with AWS
- Write clean code and get rid of code smells with real life examples
