When I was a new PHP developer, I discovered that there’s a myriad of solutions, options, configurations and frameworks available. I thought, how does one sift through all the noise and get something done? How can anyone have a grasp of the best practices in PHP, and make sense out of all the options? Which extensions do we use, and how do we use them? What’s a best practice, anyway?
This is why I’ve decided to offer “Do This, Not That” for beginning and intermediate PHP developers looking to find a better grasp on precisely how to develop in PHP. This great series of highly focused e-books will offer tips, tricks and best practices focused on core areas of PHP development, including databases, security, filtering, regular expressions, configuration and more. Since it will be a series of tightly targeted solutions, developers will be able to pick all, some or just one of the offerings that solves their specific problem(s).
Were I writing this as an article for a newspaper, the subhead would be “Design Patterns Don’t Cause Application Slowness.” The point of this piece isn’t to defend Active Record per se; it’s to discuss the fact that design patterns aren’t to blame for your application’s problems, and more to the point, design patterns aren’t the problem.
This discussion stems from a discussion with a friend of mine who swore up and down that Active Record was a terrible design pattern that was inefficient, poorly designed, and ill-suited for use by developers. As a PHP developer, it’s easy to embrace this call, especially since it’s always fun to trash Ruby on Rails folks; however, I’m not willing to take the position that design patterns are the cause of performance problems.
Nearly a decade ago, Joel Spolsky came up with a method by which to evaluate software development shops that has come to be known as the Joel Test. This crucial test evaluates a software development company on the basis of twelve criteria points; Spoksly said that “a score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.”
Last week I wrote about five tips to improve object-oriented code. This generated a number of important questions, which I will attempt to answer for those who asked them.
“Often times when a developer gives each object only one responsibility, they tightly couple objects together.” Can you explain?
There are two major pitfalls in object-oriented programming: trying to do too much with an object, and trying to couple a number of objects too closely together. For this example, we’ll use the engine metaphor.
Hey you…yeah you PHP developer, stop doing this: