Frameworks make our lives easier as developers by giving us some of the most common elements of any application, things like authentication, database access, session management, and lets us focus on building our application. But how does one get started learning a framework? I'm going to share with you some tips to learn and understand a framework.
Learn the language first
This might seem obvious but many people simply dive headfirst into the framework before they learn the language that powers it. If you know the language you won't have a hard time debugging a problem, after all, a framework is just a bunch of code written by someone else using that same language. So take your time to learn the basics of that language of your choice. When you feel confidant about your skills move on to learning a framework.
Learn the fundamentals
I probably should have put this at the beginning of the list, fundamentals! Take your time to learn the concepts on which the framework is based on. Take for example Laravel, it's an MVC framework. To get started, learn all you can about the Model View Controller pattern, the Active Record pattern, and other patterns that make up the whole framework. Understanding the fundamentals will make it easier to switch from one framework to another.
Learn design patterns
So how do you know which fundamentals to learn? Honestly, I don't know it's up to you but I tell you this, learn MVC, most frameworks are built on top of this concept, and once you grasp it everything else will come naturally. With that said you should understand the Software Design Patterns. These will help you understand what's going on under the hood of those frameworks because most of the components are based on these patterns. Besides, understanding design patterns will make you a better developer. But there's no need to know all of them though.
Read the docs
The documentation is a great place to start when learning a new framework. Most frameworks are thoroughly documented and there's pretty much everything you need to know to get started. If the docs don't work for you find a tutorial online but at some point you'll get stuck, the docs will be your salvation.
Practice
Practice makes perfect it can't be more true than that so practice, practice, practice. Once you start on a framework build something in it. Build your portfolio website in it, build a side project with the time you get used to the framework.
Look into the source code
Wait, what? This is unnecessary, but I felt I should mention it. At times some feature in the framework is not documented, it could a method, a component or something you have to look into the source code to find it. Or sometimes something is not working and you can't figure out why, try looking into the source, trust me it's illuminating. One day I wanted to do some web scraping in my laravel project and I had Laravel Dusk installed, it's documented as a browser testing framework but it can also scrape the web but that is not documented, I had to look into the source code to find out how to set it up and eventually I figured it out.
Develop your ways
Nothing works for everyone, this worked for me but not may work for you for one reason or the other, so find the ways that work for you.
Top comments (1)
Hi Given! I agree with your article. When I was starting out as a developer, I had the "code-it-and-hack-it" approach. I learned Ruby on Rails without really learning Ruby. Search for Ruby syntax as I needed it. The result was a sloppy code made from copy-pasting off things from Stack Overflow. When I had enough knowledge on RoR and Ruby, I stopped my formal learning and did my job.
Only then a year or so later that I decided to come back to the Ruby on Rails documentation and read a Ruby book did I see how much I was missing!
On design patterns, I really didn't appreciate them when I was learning them piecemeal from sites like refactoring.guru/design-patterns. It was still too abstract for me even if they had an example.
What did it for me was reading the book Five Lines of Code (manning.com/books/five-lines-of-code). By showing me bad code first and then informing me how design patterns (Strategy) improve that, I was able to understand the power of design patterns