Not only do I enjoy using Laravel as a tool to build great web applications, but I also use it as a learning resource. Laravel is now over 10 years old and has more than 2970 contributors. So there were plenty of developers keeping an eye on the code base to help shape the framework into what it is today.
I want to use this to my advantage and improve my skills as a developer by reading framework code.
For example, if I’m using a method provided by the framework (or any package), I want to test that method and see what it actually works. By doing this, it allows me to do several things:
More often than not, I find that I end up going down a rabbit hole and learning more about how the feature is implemented overall, rather than the specific method. To give an example, let’s say I’m using the Cache::rememberForever() method in my codebase. From here, I might check to see how the remember forever method is implemented for the particular cache driver that I’m using. I can also check if there is any difference between how different cache drivers implement this approach. From there, it might also lead to some other questions about some of the caching function codes and cause me to do some research online.
Now, do not get me wrong, this is not essential in any respect for improvement and it is now no longer something that you want to do. However, I’ve located that it really works genuinely properly for me and has helped me to enhance my abilities and know-how as a developer. I sense love it offers me an excellent risk to take a seat down and test troubles from a one-of-a-kind perspective.
Sometimes, it additionally results in me asking myself “Why is this option been applied in this manner?”. I then become analyzing online thru GitHub issues, pull requests, forums, and discussions to get a know-how of the context at the back of the code. I locate that that is a genuinely excellent manner of locating approximately one-of-a-kind layout patterns, exceptional practices, or procedures that I hadn’t heard of before.
You might think that this approach can be time-consuming. And it certainly can! But you can spend as little or as long as you want. Maybe you just want to quickly test a method you are using and nothing more. Or, maybe you’ll choose to go down a rabbit hole like I sometimes do. The choice is entirely yours.
Another big advantage of this is that you can also find code in a framework (or package) that you think can be improved upon. This can lead to you having to tinker with the code, which enhances your understanding even further, and possibly makes a pull request to contribute. You can also spot errors or places in the document that could be improved. So as an additional side effect, you can do a pull request to update the repository. It can lead to you becoming an open-source contributor, which can be of great benefit to yourself and the web developer community.
You can also use the same approach when working with packages in your code.
So if you are going to use a new package in your project, you may want to take a few minutes to read the package code before uploading. This will help you understand how the package implements the features you need. As a result, it can help you get more in touch with other people’s ways of thinking.
Especially, I learned a lot from Spatie’s Laravel Permission package (spatie/laravel-permission). In a project, I was tasked with implementing roles and permissions to use this package. So while adding it to the project I read the package code and it gave me a better understanding of how Laravel’s permission system works. So, as a result, I’m starting to feel more confident with Laravel’s roles, permissions, and permission system. Since working on this project, I have implemented this same functionality on several other projects and feel more comfortable with a better understanding of the internal licensing mechanisms.
Another technique that I truly like to apply is to cut up my studying into smaller chunks. I try this via way of means of dedicating 10-20 mins an afternoon to studying into a specific subject matter and heading off context-switching.
For example, shall we say that I’ve determined I need to study greater approximately how queue machine works under the hood in Laravel? So at the cease of the day, I’ll spend 20 mins studying thru one of the kind components of the queue machine code (and documentation). Once I sense as I’ve studied thru a massive part of the queue-associated code (after every week or so), I’ll then pass directly to every other subject matter that I’m fascinated in. Staying centered on a specific place or subject matter, makes it simpler to keep in mind what you had been searching on the day before, instead of converting subject matter each day.
Doing this, I think makes future development easier when working around a particular feature, as I have a better understanding of what’s available and how it works. That doesn’t mean you have to know the feature’s code inside and out, but being exposed to the code and understanding it at a high level can certainly help.
Having a high degree of understanding of the inner workings of something is a skill that is not exclusive to growth. It is something that can be transferred into the physical world. For example, suppose you have a car. If anything breaks on it or needs replacement, you may want to take it to a mechanic. But if the problem is something minor and you have a high degree of understanding of what the problem is and the area it affects your car, you may be able to fix it yourself. It’s a skill you probably only learn by diving and tinkering. Having this knowledge can also make things like buying a car easier in the future, as you’ll have a better idea of what to watch out for and what to watch out for.
But back to Laravel, if you are looking for a starting point of different fields to read, the following topics may be helpful:
I hope this article will give you some insight into how you can view the code within the Laravel framework and all the packages to improve your skills as a developer.
If you enjoyed reading this article, I’d love to hear about it. Also, if you have any comments to improve future contributions, I’d love to hear them too.