Green field projects are certainly rare, but they hold a certain appeal over developers. The ability to ignore all the mistakes of the past, and instead focus on new architecture, new ideas and new methodologies is enticing. And yet, every pile of legacy code spaghetti out there was once a green field project, filled with the majestic hopes and dreams of the engineers who worked on it. What happens?
I know many developers who believe that code simply gets worse over time, that technical debt accumulations are inevitable and that bad decisions haunt us forever. But the truth is that code doesn’t rust. And that means that our ability to make changes is directly related to how well we create the code in the first place.
Good parents teach their children from a young age not to talk to complete strangers, and to tell mom and dad if anyone approaches or tries to talk to them. It makes good sense; children are innocent and will generally believe anything an adult tells them. We do this to protect them.
In object-oriented programming, we have a similar principle for objects. We want to teach our objects not to “talk to strangers”, too. What is talking to strangers for objects? Talking to strangers is relying on objects that we weren’t given, or APIs we haven’t been taught. For example:
It’s a well-accepted concept that code review improves the quality of the code produced by your team. Many teams use code reviews, most famously at Mozilla, where every change bigger than a grammatical typo is reviewed by a peer.
Code reviews are effective because they put a second set of eyes on a particular bit of code, and force one developer to explain to another in clear language what that code does. It’s difficult to get an overly-complicated bit of code reviewed, simply because the reviewer may not be able to understand it, and the chances of getting bad code into the system are greatly reduced by using the code review system.
At just about every conference I go to, several people stop me to ask, “hey, whatever happened to your object-oriented masterclass? I really wanted to take that!”
Well, if you’re one of those people, I have great news for you: the Object Oriented PHP Masterclass is back, and registration is open!
There are millions of PHP developers, but only a (large) handful of contributors, authors and maintainers of open source software. Packagist reports a little under 50,000 packages in the PHP ecosystem. This is a huge number of open source packages, but is a small number compared to the PHP developers in the world.
The truth is, many developers who use open source never contribute to it. Whether that’s out of lack of interest, fear of failure or other considerations, I want to present The Definitive Guide To Contributing to Open Source*.
Few things bring out fights among programmers quite like a fight over documentation. There are many schools of thought, from “document every line” to “let the code self-document.” For the most part, PHP seems to have agreed on a generalized standard for documentation in code, called PHPDoc. Actual blocks of documentation are referred to as “Docblocks”*.
But within PHPDoc, there are many different styles and behaviors. And so, I have developed what I consider to be my “best tips” for documenting your code with Docblocks.