One of the most common questions I get is, "how can I get better at X?" Whether X is object oriented programming, the MVC design pattern, PHP in general or just some generic question, it's something people are seeking out.
The answer that I always give them is that it's critical for them to understand the fundamentals of whatever they're seeking knowledge in.
On Tuesday, the Socorro team (mainly led by Selena Deckelmann and Brandon Burton) released RabbitMQ into production for Socorro crashes. This was a huge team effort, and it’s a tremendous accomplishment. I’m proud to have been involved in this process.
RabbitMQ will help us process crashes faster, more efficiently and without as much database traffic. We were also able to shut down Monitor, which had previously been responsible for queuing crashes, removing our “single point of failure” from our production environment.
It’s a persistent statement: controllers should have as little code as possible because they’re difficult, nay impossible, to test. Developers should force most of their code into the models instead, where business, validation and other logic can take place. This way, the models are reusable and the code is easily tested in isolation. After all, if the controller can’t be adequately tested, then the controller can’t be expected to contain very much crucial logic. The controller becomes just a data and information traffic cop.
But this is not true. Controllers are no more or less testable than any other kind of code. What’s more, the fact that people believe controllers are largely untestable is an excuse for writing untestable code, not a valid design decision.
Bad code. Most of us have seen it before. And most of us are aware of concepts like “technical debt” as it relates to software development practices. But what most of us never actually think about are the specific business challenges posed by code that is loaded with technical debt and difficult to maintain.
Refactoring code is often at the bottom of a business’ to-do list. Features, deadlines, goals and moving the project forward are crucial things that businesses are focused on. There’s a good reason for that: customers don’t buy software because it’s easy to maintain, they buy software because it solves their problem. And thus, refactoring doesn’t seem to have inherent business value.
I read a very dissapointing post by Anthony Ferrara called Rambling on Internals last week. It describes how frustrated Anthony has become with PHP’s internals mailing list, the process that PHP uses to select and create new features, and the plain fact that there are many trolls on the PHP internals list who have their own agendas, not the agenda of the PHP project, at heart.
Reading Anthony’s article was an eye-opening experience to the challenges that PHP faces. And while I can’t say that I agree with all of his statements or choices, I can say with some certainty that I understand his point of view. PHP Internals has long been known as a troll’s paradise.
Chances are that any developer out there who has been involved in object oriented applications very long has run across the cardinal sin of object inheritance. I know I’ve committed this sin, and you probably have too. The sin of which I speak is a grave one, and it violates several well known and established principles of object oriented application development.
What is this sin of which I speak? It is none other than the addition of new public methods to an object that extends or implements abstract class or application interface, in violation of both the Liskov Substitution Principle and the Dependency Inversion Principle.