As someone whose love of Laravel is growing the more I use, I get inordinately frustrated as I find code that seemingly goes out of its way to avoid using the beautiful features that the framework affords a developer to make code simpler, safer, more performant, and overall better in nearly every way possible.
Unfortunately, just because someone has adopted a framework does not mean they “get” it. And one of the ways that can happen is if someone tries to reinvent the wheel, whether due to ignorance, habit, or sheer misguided preference. I do not wish to be overly pedantic (something I am heavily prone to) but I am of the opinion if you choose to work within a framework, you should have a good reason for “going your own way” as opposed to using the tools provided for you.
Laravel has (and has had for a while) a beautiful feature call Route Model Binding. To make it easy to understand, in an MVC paradigm, if you have a model with a certain name (say, “Car”) and you name the route (the URL you use to create, read, update, and delete that resource) “/cars”, Laravel basically lets you write really simple controllers for all the most common basic operations you’d want to do on that kind of an object.
But if you think you’re “smarter” than the framework, you’d better have a good reason! Don’t recreate the wheel, because chances are you’ll end-up having to write a lot more code, introduce bugs, and most importantly, really frustrate the next guy who has to work with your code.
In the specific example I’ve been dealing with this evening, a prior developer on a project wrote all the components – the model, views, and the controller – in a way that, to my eyes, seemingly maximizes the effort required to make further changes down the road.
Yes, the application has some nice bits of glitz and he can claim he wrote an Ajaxy web application that he perhaps thought was clever at the time. But, now my client is now stuck with paying more for my time later to make changes that would be trivial had the original developer used more of the framework’s in-built features that can save time.
One of the key differences I’ve been able to pick-up on between inexperienced and experienced developers is that the more experienced developer knows better the hidden costs of certain design choices. A more junior developer may not always fully understand why choosing to go a certain way will end-up becoming a maintenance nightmare down the road. The experienced developers knows this, not because he’s more virtuous – it’s because he’s done it to himself and others so many times before. That is valuable experience that is hard to relay and sometimes just has to be learned. So I appreciate why it’s sometimes hard to put it into words.
This is one of the reasons why good experienced developers are worth more, because their work, which may cost more, will end-up saving a lot more time down the road. But that is not the purpose of this post.
So, while a bit of a rant, I also think there’s a lot of value in sharing this perspective. As someone shared with me recently, remember, the next developer that might be looking at your code might be you. 😀