This series is exclusively focused on the art of refactoring code. Make a small change, run the tests, and then make another small change. Each episode provides a variety of long-form examples and pitfalls using real life code. Please note that this series is not chronological. Each episode is unique and may be viewed in any order.
Reflecting upon the code you've written is an important step for any developer. It's not enough to simply extract, refactor, and call it a day. No. Once complete, you must evaluate what you've done. Is the code now better? Is it more clear? Don't underestimate how difficult a question this can be. Our brains manage to trick us at every turn.
Many Laravel apps don’t warrant the complexity of a full front-end framework like Vue or React. In this series, we’ll walk through a handful of simple ways to add dynamic functionality to your apps. By combining various strategies, you can keep your simple Laravel stack, but still build interfaces that feel fast, fresh, and dynamic.
The typical beginner, whether they realize it or not, first learns procedural programming. But, before too long, they level up. Suddenly, an entirely different paradigm is introduced: object-oriented programming. Little do they know that they'll spend years researching and learning exactly what it means to work with objects and messages. In this series, you'll be introduced to the core principles of object-oriented programming in PHP. We'll begin with the basic constructs and work our way up.
We've all written code that misses the mark. Sure, it works, but, still, you're left with the feeling that you've missed something. The difficult part, unfortunately, is recognizing what that "something" is. In this series, we'll review ten techniques, one per episode, to improve the clarity of your PHP code.
You did your best, but somehow that User object, over time, morphed into a monstrous God object. And your controllers started out nice and clean, but now... not so much. We've all been there. In this series, we'll review a number of ideas for whipping convoluted code into shape.
A design pattern is a common solution to a common problem. Nothing more, nothing less. And, while some of these approaches might seem foreign or overwhelming to you, the important thing to remember is that, as a developer, you are in charge. That means you decide when a pattern is appropriate, and when it's completely unnecessary. That's the key.